[{"data":1,"prerenderedAt":104},["ShallowReactive",2],{"blog-post-en-measuring-ai-assisted-development":3},{"id":4,"title":5,"author":6,"body":7,"category":87,"date":88,"description":13,"excerpt":89,"extension":90,"gradient":91,"icon":92,"meta":93,"navigation":94,"path":95,"seo":96,"stem":97,"tags":98,"__hash__":103},"posts_en\u002Fblog\u002Fmeasuring-ai-assisted-development.md","What AI-Assisted Development Is Actually Worth","jose",{"type":8,"value":9,"toc":79},"minimark",[10,14,17,22,25,28,31,35,38,41,44,48,51,59,66,69,73,76],[11,12,13],"p",{},"The claims about AI-assisted development tend to arrive as multipliers. Two or three times faster; ten times for the more enthusiastic. Having run this across several products for a while now, we think the multiplier framing is the reason the numbers never quite survive contact with a real team.",[11,15,16],{},"The clearer way to say it: the cost of producing code fell by a large factor. The cost of shipping a product did not fall by the same factor, because producing code was never the whole cost — and the parts that did not compress are now proportionally larger.",[18,19,21],"h2",{"id":20},"what-actually-got-faster","What actually got faster",[11,23,24],{},"The gains are real and they are concentrated in specific places.",[11,26,27],{},"Conventional implementation work — a CRUD surface, a form flow, a well-specified migration, an API client against documented endpoints — is dramatically faster. So is anything where the shape of the solution is known and the work is volume rather than difficulty. Unfamiliar territory benefits too, in a different way: getting oriented in a new library or an unfamiliar codebase is much faster than reading documentation cold.",[11,29,30],{},"The common factor is that these are all cases where the answer is well represented in what the model has seen and verification is straightforward. Both conditions matter. Where either fails, the gains fall off sharply.",[18,32,34],{"id":33},"what-did-not-get-faster","What did not get faster",[11,36,37],{},"Deciding what to build did not get faster. Neither did agreeing on a data model that will still be right in two years, or the work of understanding why an existing system behaves the way it does before changing it.",[11,39,40],{},"Review did not get faster in any meaningful sense, and this is the one that actually governs throughput. If code arrives three times as quickly and review capacity is unchanged, review becomes the constraint almost immediately. Teams that report enormous speedups have usually either not hit this yet or resolved it by reviewing less carefully, which is a decision with a delayed and invisible cost.",[11,42,43],{},"Operations did not get faster either. Incidents, support, migrations, and the long tail of keeping software alive scale with how much software exists and how many people use it, not with how quickly it was written.",[18,45,47],{"id":46},"the-measurement-we-found-useful","The measurement we found useful",[11,49,50],{},"We stopped tracking velocity in any form, because in this environment it mostly measures generation speed and generation speed is no longer scarce.",[11,52,53,54,58],{},"Two things turned out to be worth watching. The first is ",[55,56,57],"strong",{},"cycle time from decision to production"," — how long between committing to build something and having it running for real users. It includes review, testing, and deployment, so it captures the constraint rather than routing around it, and it is the number that actually moved for us.",[11,60,61,62,65],{},"The second is ",[55,63,64],{},"defect escape rate",": how many problems reach production per unit of change shipped. This is the counterweight. A team can improve cycle time by reviewing less, and the effect is indistinguishable from genuine improvement for roughly one quarter. Watching both together is what makes either meaningful.",[11,67,68],{},"Neither is novel. Both predate any of this. That is somewhat the point — the metrics that survived are the ones that were measuring the right thing before, and the metrics that broke are the ones that were always proxies for effort rather than outcome.",[18,70,72],{"id":71},"the-honest-accounting","The honest accounting",[11,74,75],{},"For us the effect has been roughly this: features that are conventional and well understood land substantially faster, in some cases by a large factor. Work that is genuinely novel, or that touches systems where being wrong is expensive, moves somewhat faster but not dramatically, because the binding constraint there was never typing.",[11,77,78],{},"Averaged across a real roadmap that nets out to a meaningful improvement and not a revolutionary one. The revolutionary part is elsewhere: it is not that each product got faster to build, it is that the number of products a small team can responsibly operate went up. That is a different claim than a velocity multiplier, and it is the one we would actually defend.",{"title":80,"searchDepth":81,"depth":81,"links":82},"",2,[83,84,85,86],{"id":20,"depth":81,"text":21},{"id":33,"depth":81,"text":34},{"id":46,"depth":81,"text":47},{"id":71,"depth":81,"text":72},"business","2026-06-15",null,"md","linear-gradient(135deg, rgba(99,102,241,0.4), rgba(79,70,229,0.2))","i-heroicons-chart-bar",{},true,"\u002Fblog\u002Fmeasuring-ai-assisted-development",{"title":5,"description":13},"blog\u002Fmeasuring-ai-assisted-development",[99,100,101,102],"Engineering Management","Productivity","AI","Measurement","z7RFAnlXQA1XwGSw_2siF0hZ4dTz_6PT3UNHSwaZxsA",1789948888819]