Your developer demonstrates a feature that took “one afternoon with AI.” The price drops. The timeline shrinks. You sign. Six months later a payment goes out twice and nobody can explain the code that did it, because nobody ever read it.
Nobody is lying to you in that story. That is what makes it dangerous.
What the 2026 numbers actually say
AI in software work is now universal, and the numbers are public. Google’s DORA report (about 5,000 technology professionals) found 90% use AI at work. Stack Overflow’s 2025 survey (49,000 developers) found 84% using or planning to use AI tools. The same survey measured something the pitch decks skip: 46% of developers distrust the accuracy of AI output, the first year distrust outweighed trust (survey.stackoverflow.co/2025/ai).
DORA’s own finding is sharper still: AI adoption correlates with better throughput and worse delivery stability. Their phrase is the honest one: AI amplifies what is already there. A disciplined team ships faster with AI. A sloppy team ships slop faster, and the slop reaches your customers at machine speed.
Even the feeling of speed is under investigation: a randomized trial (METR, 2025) measured experienced developers at 19% slower on their own mature codebases while they believed they were about 20% faster. One study, one narrow setting, worth reading before accepting a feeling as a forecast.
The question nobody asks out loud
Not “do you use AI?” Everyone does; asking it buys you nothing. The question is: what happens between AI writing code and that code reaching my customers?
The answer you want has named layers: the machine checks that run before anything ships, the human who reviews what the machine cannot judge, and the rule about what is never allowed to act on its own. The answer you do not want is a smile and the word “iteratively.”
Where we put the line
Our rule, in use on every build: AI does the reading, sorting, extracting, and drafting. Plain automation (rules written once, checked, and safe to run twice) handles the rules, because rules do not hallucinate. A human approves anything that matters. Nothing auto-sends to a customer. Nothing commits a payment.
I paid for that rule the expensive way. Years ago I built a hosting panel and, riding the first wave of AI coding tools, let the machine run while I watched anime. The feature count climbed. So did the bugs, and I burned hours and tokens fixing what a day of structure would have prevented. Speed without governance gets expensive: the lesson arrived on my invoice, which is why it is a rule here and not a slogan (this story is the founder’s, and it is on the record so you can judge how we learned it).
The governance also has a second line of defense: nobody at Anito signs off on their own work, and that includes work produced with AI. The person who accepts the output is never the person (or machine) who produced it.
There is a quiet reason the earlier posts in this series keep returning to machine checks, and this is it: reviews scale only when the boring part is automated. A type contract and a gated build catch the shape mistakes and the broken checks before a human spends attention, so the reviewer’s judgment goes on the decision the machine cannot make: is this the right behavior, is this safe to ship, who does this touch. AI raised the volume of produced code. The answer is not more heroes reading everything. It is more of the work checked by machines and the remainder checked by a different human, in that order.
The check, in four questions
Put these to any developer quoting with AI in the pipeline, us included:
- “Show me what happens between AI writing code and it reaching production.” You want a named pipeline, not a description of a mood.
- “Who reviews AI output, and are they the person who prompted it?” The review should be a different pair of eyes.
- “What can AI touch on its own?” The answer that keeps you safe: nothing that reaches a customer or moves money without a human.
- “What tests would catch a wrong answer the AI was confident about?” Confidence is not correctness. Tests are.
For the business-workflow version of this (reading documents, sorting mail, drafting replies with a human approving), see our safe AI automation checklist and our workflow and AI automation service. If a quote is riding on AI speed, discuss your project with us before you sign it. We will tell you what the quote should be able to answer, and the answers will tell you whether you need us.
Common questions
Should we forbid AI in projects we pay for?
You would be paying 2026 prices for a 2019 workflow, and most teams would hide the AI anyway. The productive demand is governance: named checks before shipping, review by someone other than the person who prompted the AI, and a hard rule that nothing customer-facing or money-moving acts on its own. Ask for those three in writing; the teams that have them will say so in one sentence.
What is “bounded AI”?
AI confined to the parts of a workflow where being wrong is recoverable and visible: reading, sorting, extracting, drafting. The parts where being wrong costs money (sending to a customer, committing a payment, deleting a record) stay with plain rules and a human approval step. The phrase on this site carries a specific commitment: AI assists, and a human approves anything that matters.
Does AI-written code need different tests?
It needs the same tests taken more seriously. Machine-written code tends to look correct and fail at the edges, so the tests that matter are the ones that poke boundaries: empty input, double submission, missing files. A type contract and a named test pipeline catch the majority of it before shipping, which is why the previous posts in this series keep returning to those two.
How do we know a developer actually has governance and is not just claiming it?
Ask for the artifact, not the assurance: the checklist document, a sample review record, the test names. Teams with governance produce it in minutes because it already exists. The ones without it will offer a promise, and a promise is the thing this entire blog is built to price correctly.