AI-assisted development

AI tools changed the cost of generating a first draft, not the cost of producing correct code. The first 80% of a function arrives in seconds where it used to take minutes; the remaining 20% — edge cases, error handling, integration with the surrounding code — still takes the same focused effort. Developers who recognised that early are now consistently faster than peers who try to use AI for the whole pipeline.

The other thing that changed is the cost of learning a new technology. A developer asked to wire up a payment provider they have never touched can now get a working scaffold in minutes from a model that has read every other developer's integration. That used to be a half-day of reading docs. The risk is that the scaffold compiles and runs without the developer learning the underlying model — so the second time something goes wrong, they have no mental scaffolding to debug from.

The thing that did not change is the cost of judgment. Deciding what to build, when to ship, where to draw the line on scope, how to architect a system that will survive a year of growth — all of those still take the same human effort. AI tools help the engineering, not the architecture and product decisions.

The most common AI-induced bug is not a syntax error or a logic mistake. It is a function call to a method that does not exist on the library being imported, returning a shape the model believed was correct based on similar-looking libraries it saw in training. The code compiles, the tests pass if they were also written by the model around the same wrong assumption, and the bug surfaces only when the actual library returns something different from what the model imagined.

The detection move is small but disciplined. Before merging AI-suggested code that imports an unfamiliar library, the developer reads the actual library documentation for the specific function being called and confirms the signature matches. Sometimes the model is right. Often it is right about the shape but wrong about a parameter name. Occasionally it has invented a function that does not exist at all.

The same pattern applies to security advice from chat models. The model can produce a plausible-looking encryption setup, a plausible-looking auth flow, a plausible-looking CSP header — and the failure mode is not that the advice is obviously wrong, but that it is almost right with one parameter that matters. The deep-dive on AI security review patterns covers the specific moves that catch this class of failure before it ships.

The workflow most experienced developers settle into is small, scoped, and review-heavy. Ask the model to write the first draft of a specific function or test. Read every line before accepting. Treat the AI output the way you would treat a junior developer's pull request — plausible but unverified. The savings come from the time the AI compresses on the first draft, not from skipping the review.

The most reliable AI uses cluster in three places: scaffolding code for a feature you know the shape of but have not started writing; writing tests against code you have already written and understand; and explaining unfamiliar code by asking the model to walk through what it does. None of those workflows require trusting the AI's judgment — they require the AI to compress generation while the human retains the verification step.

The workflows that go wrong are the opposite: asking an autonomous agent to design and ship a feature without checkpoint reviews; using AI to write code in a part of the codebase you do not know well; trusting AI explanations as authoritative when the underlying system is one the model has not seen recently. Those failures are not the AI's fault — they are workflow choices that put the AI in a position where the human cannot verify what it produced.

The skills AI tools have not displaced are the same skills that distinguish senior engineers from junior ones — deciding what is worth building, judging when a system is over-engineered, reading a 200-line diff and spotting the one line that will cause an incident, knowing the team and the codebase well enough to anticipate what the next developer will need to change.

Those skills are not eligible for automation in any near-term sense, because they require understanding context that lives outside the codebase entirely — the business constraints, the team's history, the stakeholders' actual needs versus the ones they articulated. Developers who invest in those skills now will be increasingly differentiated as the easy generation work compresses.

The other thing that does not transfer to an LLM is the discipline of holding a complex system in your head long enough to reason about it. AI assistants will happily generate a 300-line refactor in 10 seconds; only the developer who has actually thought about how that refactor interacts with three other systems is positioned to catch the integration bug. Reading deeply and thinking slowly are the costs the AI tools push back onto the human, and the developers who pay those costs willingly are the ones whose work continues to be worth more than the model's output.