--- title: "Make the Demo Survive Your Codebase" description: "Use a solo AI coding gain in capacity plans only after comparable work passes your real codebase, acceptance checks and operating requirements." author: "Gunner Technology" published: "2026-11-11" url: "https://www.gunnertech.com/blog/test-solo-ai-coding-gains-before-capacity-planning" --- # Make the Demo Survive Your Codebase A solo AI coding demo can inform team capacity only after comparable work survives your existing codebase, acceptance checks and operating requirements. Until then, it shows what happened under the demo's conditions. Before you promise an earlier delivery date or change a hiring plan, find out which conditions made the speed possible. ## What does a solo coding demo actually establish? A solo coding demo establishes that its operator could complete that particular task under those particular conditions. It may be a useful discovery. It does not establish how much recurring work your team can deliver while maintaining the product you already have. In [100x Developers](https://jcarreras.es/posts/100x-developers/), the author questions sweeping productivity multipliers while allowing that beginners and narrowly defined tasks can see dramatic gains. The article also distinguishes the effort to build a tool from the benefit people get by using it. Those are different claims, and a capacity plan needs to say which one it relies on. Record what the demonstration actually included: the starting code, the operator's experience, the requirement, the tools and the stopping point. Was a working screen enough? Could the operator change the requirement while building? Were existing users depending on the behavior? An unanswered question belongs beside the result, not buried underneath a promised deadline. ## What has to match before the gain can travel? The comparison needs the same kind of requested outcome and the same acceptance standard. Acceptance means the conditions the result must satisfy before someone can call it correct. Write those conditions before either route starts, including the existing behavior that must keep working. Imagine a demonstration that adds a CSV export to a new application. In an established product, the comparable job might also need to respect account permissions, preserve filters and handle the supported data volume. If the demonstration never attempted those requirements, its completion time cannot stand in for the complete export change. Compare with the route your team would otherwise use, including its existing automation. Preserve the repository state and tool setup for each attempt. Use matched tasks or fresh runs that do not receive the previous solution; replaying a solved problem can flatter whichever route goes second. Record differences you cannot control and keep them out of any confident capacity promise. ## How do you find which condition changes the result? Keep the work's requirements fixed and record what happens as it crosses each real boundary. Follow implementation, integration with existing code, independent checks, approval and release readiness separately. This turns a vague complaint that company work is slower into a specific account of where the demonstration stopped being representative. If the agent needs a person to explain an old business rule, record the missing context. If it produces a patch quickly but fails permission checks, record the rejected attempt and repair. If it passes but waits for a release decision, preserve the wait separately from execution. [Rework belongs in the productivity number](https://www.gunnertech.com/blog/rework-belongs-in-the-productivity-number), including the fixes someone quietly makes before calling the run successful. Do not remove a required check to recover the demo's speed. Improve the route instead: supply the missing rule at intake, provision an isolated test environment or collect approval evidence automatically. People still decide what gets built and whether the result is right. Repeatedly carrying files and reconstructing status should become factory work. ## Does a useful tool prove faster development? A useful tool proves its benefit only when people use it successfully; that benefit does not by itself prove faster development. An export that saves tedious manual work may be worth building even when implementation takes longer than expected. Keep the delivery comparison and the value of the resulting feature in separate records. For delivery, compare the effort, elapsed time, failed attempts and intervention required to reach the agreed result. For value, identify whose work changes and observe whether the tool actually helps them. If agents make the implementation cheaper, that improves the investment. It does not entitle the same saved effort to appear again as a developer speed claim. This distinction also protects good small projects. You can approve a useful automation because its expected benefit justifies its full operating cost. You do not have to turn its author into a new category of developer or pretend its build conditions describe every other item in the backlog. ## When can the result change your capacity plan? The result can change the plan when the gain repeats on comparable work under the conditions your forecast assumes. Attach it to that class of work and name what the evidence excludes. A successful export route does not establish capacity for a data migration or an unresolved product decision. Use [the AI coding pilot](https://www.gunnertech.com/blog/measure-an-ai-coding-pilot-during-adoption) to establish repetition after the demo passes this initial comparison. Keep unsuccessful attempts in the record. If a gain depends on an expert rescuing every run, include that person's availability in the plan until the rescue becomes a control the factory can repeat. Gunner Technology's position is that a striking demo should earn a bounded trial before it earns a delivery commitment. Build the route inside a product or repository you own, retain its checks and evidence, and widen it when the result holds. The useful discovery is which work you can now deliver reliably, and exactly what machinery makes that possible. In response to [100x Developers](https://jcarreras.es/posts/100x-developers/) by Jcarreras. ## Quick answers ### Should the demo's original operator run the comparison? They can, but record their preparation and intervention. Have someone else judge the result against acceptance conditions fixed before the attempt. ### What if the existing process has no reliable timing record? Record comparable work through the current route before claiming a gain. You can investigate a promising demonstration while leaving its capacity impact unproven. ### Can one successful trial justify reducing headcount? It cannot establish how the rest of the team's work will behave. Staffing decisions need evidence across the work being reassigned, including operating responsibility and the people needed when the route stops.