Speed is not the metric. Quality is.

‍

‍

‍

AI makes us faster. That part is real, and I do not think anyone in engineering still disputes it.

What has been on my mind more is what happens after the code is generated. The review. The security check. The quality gate. That work did not go away. It moved, and most of the teams I have talked to are still figuring out how to absorb the shift.

I spent two days at DEVWorld 2026 in Amsterdam with our frontend team. It is one of the larger developer conferences with a strong AI engineering focus: multiple stages, dozens of talks, and AI in software development running through almost all of them. I came back with some questions I wanted to write down, partly to make sense of them for myself.

Key Takeaways

• AI changed development from writing code to reviewing code. The load on any single task dropped, but we are running more work in parallel, so the total cognitive load on a given day looks about the same.
• Faster output creates a false sense of progress. Quality and security debt accumulate quietly until they surface as something expensive to fix.
• Automated accessibility testing via screenshot comparison has real infrastructure cost. Whether that cost is justified depends on what your current process actually misses.
• Teams that stay current do it consistently, not in bursts. Conferences help calibrate that work, not replace it.
• Adopting AI heavily without adjusting how you validate the output is where teams seem to be running into trouble.

What AI development actually looks like in 2026

A year ago, using AI in development mostly meant autocomplete. You typed, it suggested, you accepted or ignored.

That model is gone. Today, we work conversationally. You describe what you want, explain the objective, provide the constraints. The tool writes the code. Your job is to understand the objective well enough to explain it clearly, and then to evaluate what comes back.

This shift changed where the work sits. Architecture decisions, technical judgement calls, output review: those take more experience and more context than writing a function. AI removed the mechanical part and made the harder part more visible. On our frontend team, that is where most of our time goes now: evaluating generated solutions, checking whether they fit the system, whether they introduce risk, whether they match what the client actually needs.

Throughput went up. Reviewing a single change is lighter than it used to be, but at the same time we are running more work in parallel, so on a typical day the cognitive load is about the same, just spread across more things at once. That is the part that I think is quietly catching teams out.

The vulnerability problem

Security was a dominant theme at DEVWorld. Not security in the abstract, but specific cases of vulnerabilities introduced or exploited because of AI-generated code. People came with examples of what had gone wrong.

The pattern that came up most often was simple: output velocity goes up, review cadence stays the same, and security gaps start to build. The code is syntactically correct, it passes tests, and it has a problem that only careful analysis would catch. By the time that problem surfaces, fixing it costs more than the velocity ever saved.

One tool that came up was OSV Scanner. We already use Dependabot to flag outdated or vulnerable dependencies, and OSV connects to a broader, actively maintained vulnerability database that goes beyond version-level checks. It is one of a few options we are considering as a possible additional layer. We have not committed to it yet.

Our current security approach is not passive. We run AI-assisted code analysis with human review on top, and those reports inform both cloud-side decisions and our internal processes. Security runs alongside development.

The harder question is what happens to teams where the security review process was sized for the old development pace and nobody adjusted it when velocity doubled.

The accessibility question we did not resolve

One talk covered automated accessibility testing in detail, specifically a method that runs a browser through all your pages on every change, takes screenshots, and compares them against a baseline to detect regressions across visual, interaction, and accessibility standards.

This opened up a debate on our team that we have not closed.

Our current process is to test as we develop, catch issues early, and validate manually where needed. The argument for automated screenshot comparison is straightforward: it catches regressions that slip through during active development, things that were working two weeks ago and are now broken because of a change made somewhere else in the codebase. If you are only testing as you build, you can miss that category of problem entirely.

The other side is infrastructure cost. Setting this up properly takes time, and if our current process is already catching the cases that matter, the investment might not be justified. We left Amsterdam without a conclusion on this, and we still have not reached one.

The speed metric and what it hides

At DEVWorld, productivity came up in almost every talk. Lines of code, features shipped, tickets closed. These numbers are easy to generate and easy to report, so teams lean on them.

What I kept noticing was how rarely anyone talked about the time spent reviewing AI-generated output. That time exists. It scales with velocity. On most teams, it does not get tracked with the same rigour as the output itself. So the productivity picture looks better than it is. More code went out the door, but the quality and security work that should accompany that output got pushed to later. Later usually arrives as an incident or a refactor that costs more than the speed gains ever added up to.

Teams that adopt AI heavily and keep the same validation standards as before are building up technical and security debt they cannot fully see yet. By the time it is visible, it is already expensive.

What we took back

A few things came out of DEVWorld that are still in active discussion at Untile.

Automated accessibility testing via screenshot comparison. We are still evaluating. The benefit is clear in principle. Whether it covers ground our current process misses is what we are trying to understand.

A few security tooling options, including OSV Scanner, as possible additions on top of what we already run. Still informal at this stage.

Neither is live yet. We are not rushing these decisions, and that is deliberate. Implementing a tool because you saw it at a conference and it sounded good is how you end up with infrastructure that nobody really owns.

What the event confirmed is that treating review as a first-class activity, something that scales with development pace rather than staying fixed, is the right direction for us. We have not solved this, and the conference made it clear we are working through the same problem as a lot of other teams.

‍