Why I Price AI Work in Hours, Not Magic

<p>There's a story going around that AI coding agents collapse the cost of building software to nearly zero. I don't believe it, and I think the people repeating it haven't shipped much with these tools in anger. What AI changes is the shape of the work, not whether the work exists.</p><p>When I use an agent to write a chunk of AIREP or touch Gripswich OS, the typing part does get faster. Boilerplate, scaffolding, a first pass at a migration, a test skeleton — that's genuinely quicker than it was two years ago. But the typing was never the expensive part of software. The expensive part is deciding what's correct, what's safe to change, and what the system is actually supposed to do when a real business depends on it. None of that got cheaper. If anything it got more expensive, because now I'm reviewing code I didn't write line by line, from an author that has no memory of why a decision was made five minutes ago unless I wrote it down.</p><p>This matters for how I think about estimating and pricing work, even internally. If I treated "the AI wrote it" as a reason to compress an estimate, I'd be quietly moving risk out of the plan and into production, where it's a lot more expensive to find. A junior engineer who writes fast but unreliable code doesn't save you time — they move the time to the review and fix stage, and often with interest. I think the honest version of AI-assisted estimating keeps the review and verification time intact, and only shrinks the first-draft time. That's still a real win, it's just a smaller and more specific one than the hype suggests.</p><p>I've written before about treating AI agents like junior staff instead of tools, and this is the pricing consequence of that stance. You don't pay a junior staff member nothing because they're fast at drafting. You pay for the judgement that wraps around the draft — the person deciding what's worth building, what's dangerous to touch, what the business actually needs this quarter versus what's merely interesting. That judgement layer hasn't been automated in anything I use, and I'm skeptical it will be soon, because it depends on context that lives outside the codebase: what a customer actually complained about, what regulatory constraint applies, what trade-off the business is willing to live with.</p><p>My view is that this is actually good news for small, bootstrapped shops like mine. If the value were really collapsing to "whoever has the best agent," there'd be no defensible position — anyone with API access could replicate AIREP or Gripswich OS in a weekend. But that's not what's happening. The defensible part was never the code. It's the accumulated judgement about what small businesses in Australia actually need from a quoting flow, or how a climbing gym's membership and sign-in system has to behave on a Saturday morning when forty people show up at once. AI makes it faster to encode that judgement into software once you have it. It doesn't manufacture the judgement for you.</p><p>So when I think about what AI has actually bought me, it's not "ten times the output." It's closer to: I spend less time on mechanical translation of a decision into code, and the same or more time on making sure the decision was right in the first place. That's a less exciting sentence than "AI 10x'd my productivity," but I think it's the true one, and it's the version that holds up when the system is running a real business instead of a demo.</p>