How Software Gets Built Is Changing. What Hasn't Changed Is Riskier to Forget.

One of our engineers estimated recently that a routine CRUD module that used to take two days now takes half a day, first draft, with AI-assisted tooling doing the scaffolding. That's not an exaggeration or a sales pitch; it's a genuinely accurate description of how much faster the mechanical part of writing code has gotten for an experienced developer who knows what to ask for and how to check the answer. What's changed less, and what we think gets dangerously underweighted in that excitement, is everything the mechanical part of writing code was never actually the bottleneck for.

What's genuinely faster now

Boilerplate, scaffolding, first-draft implementations of well-understood patterns, and test writing have all gotten meaningfully faster with AI-assisted tooling in the hands of someone who already knows what correct looks like. We use these tools ourselves, daily, for exactly this layer of the work. Pretending otherwise wouldn't make us more credible, it would just make us slower than we need to be at the part of the job that was never where the real value was.

What hasn't gotten any faster

Understanding what the business actually needs, as opposed to what a ticket describes, hasn't gotten faster. Architectural judgment, the trade-offs between three technically valid approaches that only someone who's watched each of them fail in production actually understands, hasn't gotten faster. The depth of code review needed to catch a plausible-looking but subtly wrong implementation, the kind an AI tool produces confidently and grammatically correctly, hasn't gotten faster, and arguably needs to get slower and more deliberate now, not less. Security review, production incident response, and the judgment call to tell a client "what you're asking for is the wrong fix" haven't moved at all, because none of them were ever bottlenecked on typing speed.

The new failure mode we're actually seeing

The teams getting into trouble aren't the ones using these tools. They're the ones shipping AI-assisted code faster than they're reviewing it, where "it compiles and passes the obvious test case" has quietly started standing in for real review. We've inherited codebases where entire modules were generated in an afternoon and merged the same day, and the technical debt inside them is often worse than hand-written debt, because it's syntactically clean, confidently structured, and looks reviewed even when it wasn't, which makes it easy to trust and expensive to unwind six months later when an edge case it never handled finally shows up in production.

How this has actually changed the way we work

We use AI-assisted tooling for exactly the layer it's genuinely good at: scaffolding, boilerplate, a faster first draft to react to instead of a blank file. What hasn't changed is who owns the architecture decision, who does the review, and who's accountable when something breaks in production, which is still a person on our team who understands the system, not a tool that generated part of it. The speed gain is real and we're not going to pretend otherwise. It's just a gain in the part of the job that was rarely the actual risk. The parts that were always the risk still need the same judgment they always did, and if anything, they need more of it now that the volume of code moving through review has gone up.

If you're evaluating a vendor or a team on how fast they can generate code, you're measuring the part that got easy for everyone. Ask instead who's reviewing it, who's accountable for what it does in production six months from now, and whether that person actually understands the system or just approved a diff that looked fine. That's still the question that predicts whether the software holds up.