It started as a small experiment.
I had been working with AI for about eight months at that point. The sessions felt productive. Features were getting built faster than before. The general sense was that the AI was saving time and the workflow was better than without it.
But I had a nagging feeling that some of that time was going somewhere it should not. The corrections at the end of each session. The adjustments before a pull request. The small fixes that felt automatic, barely worth noticing individually.
So I started writing them down. Not obsessively. Just a rough log at the end of each session. What I corrected, approximately how long it took.
Two weeks later I looked at the numbers. The correction time was not small. It was not the minor overhead I had assumed. It was a significant portion of every session. And when I projected it across a month, across a year, it was a number that made me stop and think seriously about what I was actually doing.
The corrections fell into categories almost immediately.
Some were logic errors. Places where the AI had misunderstood the requirement or made a technical mistake. These were real AI failures in the traditional sense. They were also relatively rare and varied enough that they did not suggest a systemic pattern.
The majority were something else entirely. They were project mismatches. The component structured in a way that worked but did not match the project's pattern. The state placed somewhere reasonable but not where this project puts state. The naming that made sense in isolation but did not follow the convention. The import that went directly to a file instead of through the feature's public API.
None of these were React mistakes. They were project-specific decisions the AI made without guidance because no rules existed to make them differently.
And they were not random. They were the same categories of correction every session. Different files. Different features. Same corrections. Because the missing rules were always the same missing rules and the AI was always filling those gaps with its own decisions.
Over two weeks I logged corrections across roughly thirty sessions.
Logic errors and genuine AI mistakes: approximately eight percent of total correction time. Varied, unpredictable, the kind of thing you review carefully regardless.
Project mismatch corrections, the category that rules would have prevented: approximately seventy-eight percent of total correction time. Consistent, predictable, the same categories appearing session after session.
The remaining fourteen percent was genuinely ambiguous, things that could go either way and where I made a judgment call.
So roughly four out of every five minutes I spent correcting AI output were minutes spent on something that a rule could have prevented. Not edge cases. Not genuinely uncertain situations. Predictable, repeatable corrections that I had been making session after session for eight months without ever thinking to write them down.
When I calculated the projection, the number was significant. Hours per month spent on corrections that should not have needed to happen. Over a year it was the equivalent of weeks of productive development time spent on something entirely preventable.
Correction time is invisible in the way that matters most. It does not show up on a sprint board. It does not appear in a time tracking system. It does not surface in velocity metrics or planning conversations.
It disappears into the texture of individual sessions. A few minutes here. A few minutes there. Each individual correction is too small to flag, too routine to mention, too automatic to register as a cost.
The result is that teams and individual developers consistently underestimate the real cost of working with AI without rules. The productivity gain from generating code faster is real and visible. The productivity loss from correcting the output of that generation is real and invisible.
The net benefit of AI in a workflow without rules is significantly smaller than it appears. Because the correction time is never subtracted from the time saved.
For freelancers the equation is even more direct. Correction time is not billable. Every minute spent fixing a project mismatch the AI introduced is a minute that contributed nothing to deliverable output. Multiply that across a year and it is a meaningful reduction in effective hourly rate that never shows up anywhere.
I did not set out to run a controlled experiment. But the log continued after I started adding rules and the comparison was informative.
The logic error category stayed roughly the same. Genuine AI mistakes do not respond to project rules because they are not caused by missing project knowledge.
The project mismatch category collapsed. Not eliminated entirely, there were still occasional corrections as I discovered gaps in the rules and filled them. But the consistent, predictable corrections that had made up the majority of my correction time largely stopped appearing.
The total correction time per session dropped by more than half within the first month. By the second month it had dropped further as the rule set became more comprehensive.
The productivity gain that the AI was supposed to provide finally materialized in full. Not because the AI got better. Because the time that had been going into corrections started going into building instead.
Here is what the rules that made the biggest difference looked like:
Rules that eliminated the highest-volume corrections:
1. Component structure follows the presentational or container pattern without exception. No component mixes both. This single rule eliminated the most common structural correction I was making.
2. State belongs in a dedicated hook within the feature. Not in the component. Not in a shared store unless genuinely needed across independent features. This eliminated the second most common correction.
3. Imports go through feature index files. No direct imports across feature boundaries. This eliminated a category of correction I had been making so automatically I had stopped noticing it.
4. Names use the project's established patterns. handleX for event handlers. useX for hooks. isX and hasX for booleans. No variations. This eliminated the naming corrections that had been appearing in almost every session.
Four rules. The corrections they covered represented the vast majority of the time I had been spending on project mismatch fixes. Writing them down took less time than a single session's worth of corrections.
Most conversations about AI productivity focus on the time saved by generating code faster.
That number is real. AI does generate code faster than writing by hand. For many tasks the speedup is significant.
But the conversation rarely includes the time spent correcting the output of that generation. And without that number, the true productivity impact of working with AI without rules is invisible.
When you measure both, the picture changes. The time saved by faster generation minus the time spent on avoidable corrections gives you the real productivity gain. For most developers working without rules, that real number is substantially smaller than the apparent number.
For developers working with rules, the correction time that was offsetting the generation speed largely disappears. The real productivity gain approaches the apparent one.
That is not a marginal improvement. It is often the difference between AI that genuinely transforms a workflow and AI that feels like it should be transforming the workflow but somehow never quite delivers on the promise.
The AI is generating code faster than you could write it by hand. That part is working.
What is not working is the time going into correcting what it generates. That time is not random or unavoidable. It is concentrated in predictable, repeatable categories that rules eliminate.
Track the corrections for two weeks. Write down what you fix and roughly how long it takes. Look at the categories. Write rules for the ones that keep appearing.
The number that changes everything is waiting for you in that log.
I built a free 24 point checklist that helps you identify exactly that. The structural gaps where your AI is making decisions without constraints and your correction time is paying the price.