AI Made Code Cheap. Owning It Is Still Expensive

The cost of maintaining AI-generated code is the part nobody wants to talk about, and it is the whole point of a piece GitHub just published called The cost of saying yes has changed. Their argument is short: writing code got cheap, but owning it did not.

I build and run a growing pile of free tools on this site, mostly alone. That one sentence describes my last six months better than anything I could write myself. So here is my take on what it actually means when you are the only person who will ever have to fix what the model wrote.

---

🔍 Cheap to write is not the same as cheap to keep

GitHub draws a line between two costs that used to move together:

• Cost of production — how long it takes to get working code in front of you.
• Cost of ownership — how long it takes to review it, trust it, and live with it forever.

AI collapsed the first one and left the second one exactly where it was. Their line is worth quoting directly:

"A change is not cheap just because the code was cheap to generate. It's cheap only if a human can confidently review and own the result."

That "confidently review" clause is the trap. A model can hand me 300 lines in ten seconds. Reading those 300 lines well enough to sign my name to them takes the same effort it always did, maybe more, because I did not write them and have no memory of the decisions inside.

Key takeaway: The bottleneck moved from typing to trusting. If you cannot own the output, the fast generation saved you nothing.

---

📊 Which changes are actually cheap to own

The useful part of the GitHub post is a rough sorting of changes into cheap-to-own and expensive-to-own, regardless of how fast the code appears. Here is how I read it:

Change type	Cheap to own?	Why
Adding a display field that already exists in the backend	✅ Yes	Bounded, visible, easy to verify
Refactoring a well-tested helper	✅ Yes	Tests catch regressions for you
Small, contained modifications	✅ Yes	You can hold the whole thing in your head
Anything touching authorization	❌ No	A wrong guess ships a security hole
Data-retention or privacy semantics	❌ No	Mistakes are quiet and legally serious
Billing or compliance logic	❌ No	Errors cost real money and trust
Anything that creates a support burden	❌ No	You pay for it in every ticket after

Notice the pattern. The cheap changes are ones where a mistake is obvious and reversible. The expensive ones are where a mistake is silent, spreads, or shows up as an email from a confused user three weeks later. AI does not change that pattern at all. It just makes it much faster to generate code in both columns, which is exactly the risk.

---

🛠️ Generate the patch first, then decide

GitHub suggests flipping the usual order of work. Instead of arguing about whether a change is worth doing, you:

1. Produce the smallest possible patch that could do the job.
2. Read the diff as concrete evidence of what the change really touches.
3. Then decide whether the true ownership cost is acceptable.

They call the generated patch a kind of "price check." It turns a vague argument into a real artifact you can look at. They also point out that the "debate cost" of arguing about feasibility often runs longer than just generating a candidate and seeing what it drags in.

This maps cleanly onto how I work solo. I no longer plan a feature in the abstract. I ask the model for the thinnest version, then I read every line of the diff before I believe any of it. A small side-by-side text diff checker is genuinely useful here when you want to compare what you asked for against what came back, especially when the model quietly rewrites things you did not mention.

Bottom line: The diff is the honest part. The prompt is a wish; the patch is the price tag.

---

💡 What this means for a solo builder or small team

If you are a student, a freelancer, or a two-person team in Sri Lanka shipping on a tight budget, this shift cuts both ways.

The good news: you can now attempt things that used to need a whole team. A one-person shop can produce a real feature in an afternoon. The free tier of most AI coding tools is enough to learn on, and generation cost is close to zero.

The catch: you are also the only owner. There is no senior engineer down the hall to catch the authorization bug the model invented. Every line the AI writes becomes a line you maintain at 2 a.m. when it breaks. So spend your saved time on the part that stayed expensive:

• Read the whole diff. Every time. No exceptions on auth, money, or user data.
• Keep patches small enough that you can actually hold them in your head.
• Write the test before you trust the refactor, so the cheap column stays cheap.
• Say no to changes whose ownership cost you cannot personally carry, even when the code is free to produce.

The number that matters was never how fast you write code. It is how much code you can safely own. AI raised the first number and left the second one flat. The engineers and small teams who win the next few years will be the ones who treat "yes" as a maintenance commitment, not a typing task, and who are honest about how many yeses one person can actually hold.