Haha welcome to the club! π We are all slowly transitioning from Software Engineers to Professional AI Code Editors. The 99% debugging part is so painfully real.
"Writing the code was never the expensive part" matches what I keep seeing with agents too: the PR appears in an afternoon, then the review and the legacy edge case eat the week. The Jevons angle is the uncomfortable one β cheaper typing just raises the demand for more features, so the review queue never shrinks. Curious whether your team has tried capping PR size for AI-authored changes, or whether the review tax just moved into smaller, more frequent reviews.
Makayis PR in the afternoon review eats the week is painfully accurate. It perfectly captures the illusion of AI speed.
To answer your question honestly: it's a bit of both, but mostly the latter. The Review Tax just fragmented into smaller more frequent reviews. We didn't strictly cap the PR size initially, so a massive 1,000-line PR just became ten 100-line PRs.
But here's the catch: context switching between ten different AI-generated PRs is its own cognitive load. The total mental energy required doesn't shrink just because the PR is smaller. We eventually had to enforce a hard cap (around 200-300 lines) to force the AI to stay focused on one task at a time.
You're 100% right about the queue never shrinking. If we don't fix the feature demand, we're just optimizing how fast we drown. Have you found that capping PR size actually reduces the overall fatigue or does the frequency still wear you down?
Honestly, the cap on its own didn't fix the fatigue for me. Ten small PRs from ten unrelated prompts is just the big PR with extra context switches. What helped more was capping the scope per task, not the line count: one agent session, one intent, one PR, and I batch reviews into a couple of fixed slots a day instead of reviewing whenever something lands. The smaller diffs are easier to reason about, but the real win was that each one tells a single story. The other thing that cut review time was asking the agent to write a short "what I changed and what I didn't touch" note with the diff, so I'm checking claims instead of reverse engineering intent. Your 200-300 line cap sounds about right as a ceiling, though. Did you enforce it in CI or just as a team norm?
Makayis cap the scope, not the line count is the missing piece of the puzzle. You nailed it ten small PRs from ten unrelated prompts is just a fragmented 1,000-line PR. The context switching is what actually drains the mental battery.
The one agent session, one intent, one PR rule is a brilliant way to force the AI to stay focused. And I love the idea of batching reviews into fixed slots. That prevents your entire day from being hijacked by a constant stream of notifications.
Also, the what I didn't touch note is a game-changer. If the agent declares its boundaries you're just verifying claims instead of investigating intent. That saves hours.
To answer your question: it's a mix of both. We have a CI bot that warns (and sometimes blocks) PRs over a certain threshold, but the real enforcement is a team norm. If someone drops a 500-line PR, we kindly ask them to split it. Itβs more about culture than just tooling. How about on your end did you automate the scope check or is it a team agreement?
Mostly an agreement, honestly. Scope is hard to check mechanically: a line count is easy for a bot, "this PR does one thing" isn't. The closest I get to automating it is that "what I changed and what I didn't touch" note. If the agent can't describe the diff in one or two sentences, that's usually the sign it wandered, and I split it before reviewing. A CI warning over a threshold plus a team norm for the rest sounds like the right mix to me.
Makayis if the agent can't describe the diff in one or two sentences it wandered is a brilliant heuristic. I'm stealing that.
You're completely right that scope is hard to automate. Trying to write a linter for this PR does exactly one thing usually just ends in false positives and developer frustration. Using the agent's own summary as a sanity check is a very clever proxy.
Totally agree with the final formula: CI warnings for the hard limits, and team culture for the soft ones. Thanks for the great back-and-forth, this has been super valuable!
My experience rhymes with the 30-second PR story. The shift I made that actually helped was forcing the agent to write down its boundary assumptions before the code: which pieces of legacy behavior it thinks it understands, and which it flagged as unknown. Reviewing the assumptions list is fast; reviewing 500 lines for hidden ones is not. The weird part is that it flips the workflow around: the document becomes the deliverable and the code is just its rendering. I now treat an AI-generated PR the way I treat a vendor's API response: the payload is fine, but I only trust it after I have read the contract it claims to honor.
Has anyone tried making the agent's "unknowns" list a required PR template section? I am curious whether it survives contact with real deadlines.
Odinaka, the vendor API response analogy is absolute perfection. The payload is fine, but I only trust it after reading the contract is exactly the mindset we need for AI PRs.
To answer your question about making the unknowns list a required PR template section: I haven't implemented it yet but I think it would 100% survive deadlines if framed correctly. The trick is that reviewers must reject any AI PR that doesn't include the assumptions section. Once the team realizes it actually saves them hours of reverse-engineering it becomes a lifesaver, not a chore.
It flips the workflow exactly as you said: the document becomes the deliverable, and the code is just the rendering. I'm definitely going to try pitching this to my team. Have you tried it on your end yet?
I haven't β I work solo, so there's no team to enforce it on, and my own PRs get the assumptions list informally in my head. What I have done is the reverse: I require it of the tools I use. Before any AI-generated change touches my codebase it has to state what it doesn't know, because the unknowns list is where the blast radius hides. Your enforcement mechanism is the part I'd steal β reviewers rejecting any AI PR without the assumptions section is what makes it survive deadlines instead of surviving only the quiet weeks. If you pitch it, watch the first production incident: that's the real test, not the calm sprint.
Odinaka enforcing it at the tool level is actually a genius move for solo work. You basically built a one-person guardrail system. And 'the unknowns list is where the blast radius hides' is such a killer phrase.
You are 100% right about the first production incident being the real test. Calm sprints make every new process look like a miracle cure, but nothing tests a workflow like a PagerDuty alert at 2 AM. That's when people either stick to the rules or abandon them completely.
I'll definitely keep that in mind when pitching this to my team. Thanks for the great follow-up!
That 2 AM PagerDuty test is exactly the pitch I would use, because it separates a rule people follow when they are fresh from one they follow when they are tired. An optional template section gets skipped at 2 AM, but a hard gate does not: if reviewers reject an AI PR without an assumptions section, the author has to write down what the model did not know before anyone merges it. I would frame it to your team as incident cost, not paperwork β one wrong vendor assumption shipped at night costs more than every assumptions list you will ever write. Does your team already reject PRs for a missing test, so this could ride that same gate?
Odinaka incident cost not paperwork is a brilliant framing. If I pitch it as just another checklist management will ignore it. But if I frame it as preventing an expensive production incident, it suddenly gets priority.
And you're absolutely right about optional vs. hard gates. Anything marked optional might as well be deleted. It has to be a hard block in the CI or the PR template, or it will just get skipped when people are rushing.
To answer your question: we do have a CI gate that blocks PRs if tests are missing or failing. So you're right tying the assumptions requirement to that same existing gate makes perfect sense. It forces the author to explain intent before they even hit merge.
I'm taking this exact playbook to my team next week. Thanks for the back-and-forth, this has been incredibly valuable!
I'd say the biggest bottleneck is review, and specifically review of code nobody on the team can explain. When a person writes a tricky caching path, you can ask them why. With generated code, the reviewer ends up doing the reasoning the author skipped, so the cost moved, it didn't disappear.
Two things that help: keep generated PRs small enough that one person can hold the whole change in their head, and ask the author to write the edge cases in the PR description in their own words before review. If they can't, the PR isn't ready, no matter how clean it looks.
Security review has the same Jevons problem. Five times more code means five times more surface to check, and the threat model doesn't get faster just because the typing did. Systems thinking is the right conclusion.
Kiell this is an absolutely brilliant breakdown. You just added two massive dimensions I didn't fully explore.
First the reviewer ends up doing the reasoning the author skipped' perfectly captures the hidden tax. And your litmus test for PRs is gold: if the author can't explain the edge cases in their own words, the PR isn't ready. I'm 100% stealing that rule.
Second the security angle is terrifying and spot on. I didn't explicitly call out the security surface area, but you're right: AI scales the codebase instantly, which scales the vulnerability surface. The threat model doesn't get faster just because the typing did.
As you said systems thinking is the only way out. Thanks for adding so much value to this discussion!
Steal away π The "explain the edge cases in your own words" test is cheap, and it works on any PR. Thanks for writing the piece, Harsh. The cost framing is what made the discussion worth having.
Thanks for the kind words, Kiell I'm really glad the cost framing resonated with you.
Honestly it's discussions like these that make writing on dev so rewarding. I've already added the explain the edge cases rule to my team's checklist. Thanks again for adding so much value to this thread!
That's great to hear! I'd love to know how it goes with your team once it's been in the checklist for a while, especially whether it catches things in review that the tests missed. Thanks for writing such a thought-provoking piece.
Thanks Kiell I'm really curious about that too. It'll be fascinating to see if human review catches architectural blind spots that the AI-generated unit tests completely ignored.
We often write tests to prove what we did build, but human review with this rule might be the only way to catch what we forgot to build. If it yields any surprising results it might just turn into a follow-up article! Appreciate the great discussion.
Founder of Hex16, a small web studio in Poland. I build Next.js sites and headless Shopify stores, with GSAP, Three.js and shaders where they earn their place, and look after technical SEO.
The v0 shop I took over had RLS switched off in Supabase and a contact form that sent messages nowhere. Owner's take was "what matters is that it works". Was your 3 weeks the feature or cleaning up after the 30 seconds?
Artur RLS switched off in Supabase literally sent a chill down my spine. That is the ultimate AI-generated nightmare.
And the owner's quote what matters is that it works is probably the most expensive sentence in software engineering. It works until it gets hacked, or until the contact form drops a million-dollar lead.
To answer your question honestly: it was a mix of both. The 30 seconds got me the feature, but the 3 weeks was me cleaning up the Context Debt so it didn't turn into the v0 shop you inherited. If we don't spend those 3 weeks fixing the edge cases, the next dev spends 3 months fixing the blast radius.
Founder of Hex16, a small web studio in Poland. I build Next.js sites and headless Shopify stores, with GSAP, Three.js and shaders where they earn their place, and look after technical SEO.
Haha I'm honored to make it to the stickerπ honestly: 90% of the time, it's only after something breaks. It's the classic firefighter vs. building inspector problem. Management will happily pay you to put out a fire at 2 AM but asking for 3 weeks upfront to install a smoke detector is suddenly too expensive and slowing down delivery.
The only way I've actually gotten that time upfront is by hiding it in the estimate. You don't call it cleaning up AI debt. You call it Security Hardening or Edge-Case QA. If it sounds like actual work on the roadmap they approve it. If it sounds like maintenance they skip it.
Have you ever successfully pitched the 3 weeks upfront, or is it always firefighting for you too?
Founder of Hex16, a small web studio in Poland. I build Next.js sites and headless Shopify stores, with GSAP, Three.js and shaders where they earn their place, and look after technical SEO.
Firefighter vs. building inspector is exactly it. On my side it's a bit easier because I run a small studio and quote fixed prices, so the "3 weeks" never shows up as a separate line. It's just part of what a finished site costs: security headers, RLS checks, form handling, the boring edge cases. Clients don't approve maintenance, they approve a site that doesn't break. Where it gets hard is takeovers like that v0 shop. There the cleanup is visible, and I sell it the way you describe, as an audit with a list of concrete risks instead of "refactoring". A screenshot of an open Supabase table convinces faster than any estimate.
This is a masterclass in client management. Clients don't approve maintenance, they approve a site that doesn't break is such a killer line. You're basically packaging the exact same work (Context Debt cleanup) but framing it as business value.
And the screenshot of the open Supabase table is absolutely genius. Show don't tell. A concrete screenshot of a glaring security risk will always win over a spreadsheet of estimated hours. No client wants to see their data exposed to the world.
It makes total sense for a small studio with fixed pricing you just bake the cleanup into the internal cost so the client gets a working product. Thanks for sharing this perspective, it's incredibly valuable for anyone doing client work!
Software engineer & AI engineer in Lagos. Founder of Stackit, a social savings fintech. I build full-stack web and mobile apps with React, Node.js and PostgreSQL, plus AI agents using MCP.
Location
Lagos Nigeria
Education
Computational Science, Yaba College of Technology, Lagos
Pronouns
he/him
Work
Founder & Software Engineer at Stackit, a social savings app for Nigerians
I think the biggest bottleneck is context and verification. AI has reduced the time it takes to write code, but it hasn't eliminated the need to understand the system the code is entering.
The tricky part is that working code doesn't automatically mean correct code. It might pass tests and still break an existing workflow, introduce a security issue, or fail under real-world conditions.
I also think AI should help us reduce complexity, not just produce more features. Sometimes the best outcome isn't generating 1,000 lines of code; it's finding a way to solve the problem with 100.
The developers who stand out won't necessarily be the ones who generate code the fastest. They'll be the ones who can judge the output, understand the trade-offs, and take responsibility for what eventually reaches production.
AI is making code cheaper, but engineering judgment is becoming even more valuable.
Egbuta this is a fantastic breakdown. You hit on something I wish more teams talked about: Working code doesn't automatically mean correct code. Passing tests is just the bare minimum; surviving real-world conditions is the actual bar.
But your point about reducing complexity is the real masterstroke. AI defaults to adding code to solve a problem. It will happily write 1,000 lines to fix a bug that a senior dev could fix by deleting 50 lines. Using AI to simplify systems rather than just inflate them is the true mark of an expert.
And your closing line is the perfect summary of this entire discussion: AI is making code cheaper, but engineering judgment is becoming even more valuable. I couldn't have said it better myself. Thanks for adding so much value here!
Software engineer & AI engineer in Lagos. Founder of Stackit, a social savings fintech. I build full-stack web and mobile apps with React, Node.js and PostgreSQL, plus AI agents using MCP.
Location
Lagos Nigeria
Education
Computational Science, Yaba College of Technology, Lagos
Pronouns
he/him
Work
Founder & Software Engineer at Stackit, a social savings app for Nigerians
Thank you! I really appreciate that. I agree that knowing when to simplify a system is just as important as knowing how to build it. There's still so much to learn as AI continues to change the way we develop software. I'd love to connect with you here on DEV and keep learning from your insights. Looking forward to more discussions like this!
Thank you Egbuta I really appreciate that, and I just followed you here on DEV.
You're absolutely right knowing when to simplify is a superpower. We're all figuring out this new AI era together, and it's conversations like these that help us make sense of it. Looking forward to seeing your thoughts and keeping the discussion going in the future!
Software engineer & AI engineer in Lagos. Founder of Stackit, a social savings fintech. I build full-stack web and mobile apps with React, Node.js and PostgreSQL, plus AI agents using MCP.
Location
Lagos Nigeria
Education
Computational Science, Yaba College of Technology, Lagos
Pronouns
he/him
Work
Founder & Software Engineer at Stackit, a social savings app for Nigerians
The review bottleneck exposes a fundamental asymmetry between generation and verification that gets glossed over in developer tooling demos.
When an engineer writes code manually, the mental model of edge cases, state transitions, and invariants is built during the drafting process. The code is simply the artifact left behind by that reasoning. When an LLM generates five hundred lines in thirty seconds, that construction step is bypassed entirely. That reasoning work simply moves downstream into verification.
Verifying third-party code without an explicit model of its boundary assumptions becomes an unconstrained search problem. You are no longer just checking whether the implementation satisfies a ticket. You have to reverse-engineer what invariants the model silently ignored while optimizing for local coherence. Auditing for the absence of subtle edge cases requires exploring the entire state space of the surrounding architecture, which takes significantly more time than writing the initial implementation.
This creates an adverse selection trap in pull request reviews. Because thorough auditing is so exhausting, teams inevitably fall back on superficial checks, relying on green unit tests that were often generated by the very same model to test its own assumptions. The true cost of the code does not disappear from the balance sheet. It simply shifts from visible engineering payroll into hidden tail risk that sits dormant in production until an unmapped integration breaks.
Dean this is one of the most brilliant breakdowns of this problem I've read. You've put words to something I was feeling but couldn't articulate.
The unconstrained search problem perfectly captures why reviewing AI code is so exhausting. When I write code, I'm building the mental model as I type. When AI writes it, I'm dropped into the middle of a maze with no map. I have to figure out what it built and why it built it that way simultaneously.
But the adverse selection trap is genuinely terrifying. The fact that the LLM writes the code and then writes the tests to prove its own code works is a massive blind spot. We are literally asking the student to grade their own exam, and we are trusting the A+ because the paper is neat.
How do you personally escape this trap? Do you mandate that tests for AI-generated code must be written by a human, or is there another way to break that hidden tail risk?
The cleanest way to break the circular dependency is invariant decoupling. You never let the model generate both the implementation and the test assertions in the same context.
Either write property-based tests and boundary invariants first, or use a separate adversarial prompt whose only objective is to find state transitions that violate production constraints. If a human has to review anything, reviewing five hard invariant properties takes a fraction of the time needed to audit three hundred lines of self-congratulatory unit tests.
Dean this is incredibly actionable. Invariant decoupling is exactly the term I was missing. the adversarial prompt' idea is a game-changer. Most of us default to write tests to prove this works which as you perfectly put it just yields self-congratulatory unit tests. Flipping the prompt to find three ways this logic breaks completely changes the AI's objective from being a cheerleader to being a red teamer.
I'm definitely going to start using property-based tests for AI-generated logic. Thanks for dropping this gem of a solution!
I am building Oystro because AI coding agents are fast, but speed without oversight is how projects drift from what was intended. I want work you can review, audit, and stand behind.
Good post, and an engaging thread that has extended the post.
Fix 2 assumes that review capacity is a fixed cost that you have to fund. Reviewing a diff is expensive. It would be cheaper to review a shorter plan before the agent starts generating numerous lines of code. Odinaka and Kiell have the same idea but for the PR and edge-case scenario. By keeping the plan in the repo along with the code, any agent can pick up from where it left off. That will take care of the context debt.
George this is a fantastic synthesis of the whole thread. You're absolutely right Fix 2 (funding more review capacity) is a reactive approach. Reviewing a 1-page plan is infinitely cheaper than reviewing a 1,000-line diff.
Keeping that plan in the repo alongside the code is the ultimate antidote to Context Debt. It essentially turns the plan into an ADR (Architecture Decision Record). When the next agent or developer picks it up, they don't have to reverse-engineer the intent; it's right there in the repo.
It shifts the workflow from generate and verify to plan verify and then generate. Huge fan of this idea. How do you usually format these plans? Just a markdown file in the PR, or a dedicated folder in the repo?
I am building Oystro because AI coding agents are fast, but speed without oversight is how projects drift from what was intended. I want work you can review, audit, and stand behind.
Dean Lee's point about the mental model is the heart of it for me. When someone writes code by hand, the edge cases get worked out while typing, and the code is what is left over. With generated code that reasoning never happened, so the reviewer has to rebuild it from scratch, which is why the caching bug took two days to find.
I would add one more place the cost went: deciding what the feature is. Your three weeks started with a detailed prompt, but the legacy system that broke was never in that prompt, because nobody had written down what the change touched and what done meant in production. When that is written first, on one page, both the generation and the review get smaller.
That is also how we scope client work at Ascendra Ventures, one clearly defined problem with a written finish line rather than hours. Cheap code made that page worth more, not less. Which part of your three weeks would it have removed?
This is such a sharp addition. You are absolutely right: the biggest missing piece wasn't just the code review, it was the lack of a defined 'finish line' and impact analysis before generation even started.
To answer your question about my three weeks: writing that one-page scope would have completely eliminated the week I spent debugging the legacy system. If we had explicitly written down 'what this change touches,' we would have realized the AI lacked the context of our old system. It also would have cut the review time in half, because the reviewer would have had a clear baseline to measure the AI's output against.
I love the way Ascendra Ventures scopes client work with a written finish line. It completely flips the script: cheap code makes the scoping phase worth more, not less. Thanks for sharing this perspective, it's going straight into my workflow.
The 30-second PR that takes two days to review is exactly the trade. AI moved the cost from typing to understanding, and understanding still runs at human speed. On my own side projects the expensive bits are never the code. It's store reviews, platform rules, and the one edge case real users find on day one.
Nilamadhab understanding still runs at human speed is a brilliant way to put it. I might have to steal that line!
You're completely right. We get so obsessed with the coding part that we forget the actual expensive bottlenecks of shipping: App Store reviews, platform compliance, and the absolute chaos of day-one user behavior.
AI can write the code for a feature, but it can't predict how a real user will break it in ways we never imagined, nor can it argue with an app store reviewer. The real cost of software has always been outside the editor. Thanks for sharing this!
The review and integration bottleneck is a useful reminder that code generation shifts rather than removes uncertainty. It would be interesting to track time from generated diff to a verified production outcome, split by review, test investigation, and rollback work, rather than using lines or PR count as the productivity proxy.
Alex shifts rather than removes uncertainty is a brilliant way to put it. The uncertainty doesn't disappear; it just changes its address from the author to the reviewer.
Tracking the time from generated diff to verified production outcome is exactly the metric we need. Lines of code and PR counts have always been terrible vanity metrics, but AI makes them even more useless because generating 1,000 lines is now instant.
Splitting that timeline into review time test investigation and rollback work would give us a real picture of AI's ROI. If we see that 80% of the time is spent in test investigation for AI-generated code, that tells us exactly where we need to invest in tooling.
Have you managed to implement this kind of granular tracking on your team yet, or does it currently just blend into overall cycle time?
I do not have a reliable team-level breakdown to cite yet, so I would treat this as a measurement proposal rather than a result. One starting point is to timestamp review, test investigation and any rollback against the same change, while separating elapsed waiting time from active work. That would make a bottleneck visible without assuming every delay came from AI-generated code.
Alex separating elapsed waiting time from active work is a brilliant distinction. That's often where the illusion of slowness comes from.
A PR might take 48 hours from open to merge, but if only 30 minutes of that was actual review and the rest was just sitting in a queue waiting for a senior dev to wake up, the problem isn't AI it's process. Assuming all delay comes from AI-generated code is a trap.
Treating it as a measurement proposal first is definitely the right approach. If you do end up implementing that timestamping system, I'd love to hear what the data reveals. Thanks for the great discussion!
The point about the review tax matches what I've seen. One small thing that helps is asking for a short summary of which existing files and behaviors a change touches, so the reviewer knows where to look first. Do you track review time per PR, and has it gone up since you started using AI?
AIFix that is a brilliant tip. Asking for a blast radius summary which existing files and behaviors are touched before diving into the code is a massive time-saver. It gives the reviewer a map instead of dropping them in the middle of a maze.
To answer your questions honestly no we don't track granular review hours per PR. We rely on gut feel and overall cycle time. But has it gone up since using AI? Absolutely. We are spending way more time reading and verifying code than we ever did writing it.
It's exactly the Review Tax in action. The AI generates it in seconds but the human brain still takes minutes to map the context. Thanks for the great tip
Thanks Harsh, really useful to hear real numbers from your side. Since review time is the bottleneck, one more small habit that helps: ask the AI to list what it did NOT change and what it assumed, next to the blast radius summary. Reviewers then know which assumptions to check first instead of re-reading everything.
AIFix list what it did NOT change is a brilliant habit. AI is always so eager to tell you what it did do but it quietly hides its blind spots.
Forcing it to declare its non-changes and assumptions gives the reviewer a targeted checklist. Instead of re-reading 1,000 lines of code with a fine-tooth comb, you can look at the assumptions list and say Ah it assumed the user ID is always present. Let me verify that specific line.
This combined with the blast radius summary is a total game-changer for code reviews. I'm definitely adding this to my prompt templates. Thanks for sharing such actionable tips!
Glad it's useful, Harsh. If you add it to your templates, a line like "list what you did not change and any assumptions you made" works well. Would love to hear if it catches anything.
"This is hands down one of the best takes on AI-assisted development!
The point about 'Jevons Paradox in Software' and 'Context Debt' hits right at the center. Generating 1,000 lines of code in 30 seconds feels great, but reverse-engineering AI logic during review takes double the time.
In my experience, the biggest bottleneck right now is definitely Integration & Edge-case Review. AI handles syntax and boilerplates effortlessly, but it lacks the historical context of existing systems and legacy code.
Absolutely agree that the shift is from 'writing code' to 'editing & systems thinking'. Brilliant post!
You hit the nail on the head with 'Integration & Edge-case Review. It's fascinating how AI is a genius at syntax and boilerplate, but completely blind to the historical context of our systems. It doesn't know why a certain legacy function exists, so it just happily breaks it.
And you're spot on about the time reversal. Generating it takes 30 seconds, but wrapping your brain around it takes hours. It feels great to know I'm not the only one experiencing this exact shift. Thanks for reading and sharing your experience!
The Jevons framing lands, but the sharper point is the cost moved to verification and nobody budgets for it. A 30-second PR that sits two days in review isn't velocity, it's a queue. Two things that helped us: cap AI-generated PRs around 200 lines - the subtle caching bug you describe hides exactly in 900-line diffs nobody actually reads - and write ADRs for the 'why' that lived in the departed dev's head, or that context stays an unbudgeted tax forever. Are you tracking review latency as a metric, or only generation speed?
Golfover queue not velocity is an incredibly sharp way to put it. A 30-second generation time is meaningless if the PR then sits in a review queue for 48 hours. That's not speed; that's just moving the traffic jam further down the road.
The 200-line cap is a brilliant rule of thumb. It forces the AI (and the author) to be concise, and it keeps the cognitive load manageable for the reviewer so the subtle bugs can't hide.
And I love the ADR (Architecture Decision Record) mention. It is literally the only way to stop Context Debt from becoming permanent when senior devs leave.
To answer your question honestly: right now, we are definitely focused more on generation speed because it's the shiny new metric. But you're right review latency is the real bottleneck. I'm going to start tracking the time from PR open to first human review because of this comment. Thanks for the great reframe!
Brilliant explanation of the Jevons Paradox in tech. For our team, the biggest bottleneck is 100% the 'Review and Trust Tax.' Reviewing AI-generated code feels like grading a student's homework who is incredibly smart but notoriously sloppy. You spend double the time reverse-engineering their logic just to ensure they didn't introduce a hidden architectural bug. Love how you highlighted that the job has shifted from writing to editing. Excellent piece.
Yashish, that analogy is absolutely perfect. Grading a smart but sloppy student's homework is exactly what it feels like.
The worst part about the Trust Tax' is how confident the AI sounds. It writes code that looks aesthetically beautiful and technically correct on the surface, but you have to dig deep just to find out it completely ignored a core business rule.
Since your team feels this 100%, how are you guys currently handling it? Are you leaning more on automated tests to catch the sloppiness, or just accepting the extra review time as the new normal?
The Jevons framing is right, but the review tax is invisible in every metric we track: PR count goes up, cycle-time dashboards stay green, and the real cost hides in the reviewer's head. One thing that helped on teams I've been on: require AI-assisted PRs to declare their assumptions about existing behavior in the description ('this assumes the cache invalidates on deploy X'). Reviewing declared assumptions takes minutes; discovering undeclared ones in production takes the week you described. Is anyone measuring assumption density, or does the trust tax just get absorbed as overtime?
AI has made writing code faster, but I think the bigger challenge is everything around the code: understanding requirements, making the right architectural decisions, testing edge cases, and maintaining the system after launch. A working prototype is only one milestone; getting software to work reliably in a real environment is where much of the effort still goes. The real productivity gain comes when faster coding translates into faster, dependable delivery.
Glen, you nailed it. Everything around the code' is the perfect way to describe it. We've optimized the typing speed but we haven't optimized the thinking speed.
Your distinction between a working prototype and dependable delivery is spot on. AI gives us the illusion of speed because we see something working on our local machine instantly. But as you said, the real effort is in getting it to survive the real environment, the legacy systems, and the edge cases.
The real productivity gain really is just faster dependable delivery. Anything less is just faster tech debt. Thanks for the great insight!
I'd measure time from opening the PR to a verified deployment, including review and rollback work. That would make the caching example much harder to hide behind a fast generation time. I'd bring the same habit to a prachub design exercise: explain the cache boundary and one failure case before asking AI to fill in the implementation.
Emily this is the perfect metric. Measuring from PR open to verified deployment is the only way to get a true picture of developer velocity. If we only count the 30 seconds it took AI to generate the code, we are just lying to ourselves.
I love your design exercise approach even more. Explaining the cache boundary and one failure case before asking the AI to write the code is a brilliant way to prevent Context Debt before it even starts. It forces you to build the mental model first, and then use AI just as a typist.
I'm definitely going to try this explain first, generate second workflow. Thanks for sharing!
The paradox checks out in practice: inference got 10x cheaper, but the expensive parts were never inference. Code review, legacy integration, on-call - that's where the bill lives, and agents generate more code to review, not less. An agent PR still needs a senior human to sign off, so throughput rises while the review bottleneck gets worse. Teams that actually save money treat agent output like intern output: cheap to produce, expensive to trust, until the verification layer exists. Did you measure where the time actually goes in your builds?
Golfover the intern output analogy is absolutely brilliant. It's the perfect way to describe it: cheap to produce, but expensive to trust. An intern's code needs a senior to review it, but AI is like an intern who writes 5,000 lines in a minute, drowning the senior in the process.
To answer your question honestly: no, we haven't strictly measured the minute-by-minute time allocation. We mostly rely on overall cycle time and gut feel. But anecdotally, the time has shifted massively from writing to verifying. The 'verification layer' you mentioned is exactly what's missing in most AI workflows right now.
If we don't build that layer, we're just creating code faster than we can understand it. Thanks for such a great breakdown!
I wouldn't agree with "just as long to ship". With AI, I can develop things quicker than before, and thus get more done in a sprint than before. So a feature that would originally not have made it into the program increment at all (I work in a SaFe managed project) can now be done in the 3 months window. That is real progress.
But the thing is, if you have a mature system and your AI takes 1000 lines to make a change (1000 lines of production code I mean) then your AI has done a bad job. Even medium-sized changes don't take a 1000 lines of production code in clean, well-designed and mature systems. It is the old adage of Robert C. Martin in one of his books: The only way to go fast is to go well.
What that means is, don't use the AI in such broad ways. Don't give it a ticket and tell it to implement it. You have to think about how to implement it yourself, and use AI only to do the implementation for you, not the design of the solution. That's a win-win for both you and the AI: The AI gets to do what it does best (do concretely, well-specified coding tasks) and you get to do what you do best (design good technical solutions). That way you also don't loose the context, because reviewing small, focused changes is way easier than large changes.
EDIT: But the biggest thing is this: I welcome the bottleneck. The bottleneck of review is fantastic, because it makes sure knowledge about the change is getting spread throughout the team, and if done in a disciplined manner (which means you review your own changes as well) it adds a lot to the collective team knowledge. Working well with AI is largely a matter of applying a disciplined approach and sticking with tried and true development principles.
90% of time when I use the Claude models, I know what it's gonna write when I hit enter. I try to not use it to think for me (unless I have a refactoring for something like performance where I know Claude is gonna do a better job than I could), but to code for me. That is a big difference. When you let it think for you, all the bad stuff you described happens. That stuff mostly doesn't happen when I just let it code for me.
Andreas this is a phenomenal pushback, and I absolutely love the nuance you've brought to this. You've completely shifted my perspective on a few things.
You nailed the core distinction: using AI to code for you vs. using it to think for you. If you already know the design and just let Claude handle the boilerplate, you're operating as an architect, not a passenger. That is a massive difference from handing an agent a vague ticket and hoping for the best.
I also really appreciate your EDIT point about welcoming the review bottleneck. I hadn't thought of it as a knowledge-spreading mechanism. If a developer has to deeply review AI-generated code to approve it, they are forced to learn the system. That actually builds collective team knowledge.
And the Robert C. Martin quote is spot on. If a simple change requires 1,000 lines, the AI isn't being helpful; it's just masking bad design.
Thanks for sharing your workflow. 'Think deeply, then let the AI type' is a rule I think every team should adopt.
One more place the cost went that nobody's mentioned here: the metering model. How you're billed quietly shapes how much you burn.
I recently ran the numbers for a comparison on TechRiseUps of every Codex plan against Copilot, Cursor and Claude Code (see it here), and the detail that stuck with me is that Codex switched to token-based metering back in April 2026. That's a completely different experience from a flat $20/seat plan. On flat-rate tools, tokens feel free β developers fire off sprawling agent runs, skim the output, and throw away half of it. That's the Jevons paradox in action, and it feeds the review tax and context debt you're all describing. Under token metering, you suddenly see every one of those exploratory loops on the bill: one "refactor everything" agent session can burn more than the monthly sticker price in an afternoon.
So the pricing model quietly picks which problem you get. Flat-rate plans hide the cost and encourage bloat; usage-based plans surface it and make you think twice before hitting enter. Either way, "free code generation" is only free if you don't count who's paying β your attention in review, or your token bill.
The unit of cost never was typing speed - it was deciding what to build and owning the failure modes. AI shifts hours from writing to reviewing code you did not write, and review is serial senior-person work. Worth tracking cost-per-production-incident instead of cost-per-line: cheap generation that doubles triage load is a net loss. Did your team actually measure this, or does it just feel faster?
Golfover review is serial senior-person work is a brilliant way to put it. You just described the biggest hidden bottleneck in modern engineering. AI can parallelize code generation, but human review is inherently serial. You can only review one PR at a time.
To answer your question honestly: it mostly just feels faster right now. We track overall cycle time but we haven't started measuring the true triage load or the cost of production incidents caused by AI-generated code.
And that's the exact trap you're pointing out. If AI doubles our generation speed but also doubles our triage load, we haven't gained anything we've just moved the stress to the most senior (and most expensive) people on the team.
Tracking cost-per-production-incident instead of cost-per-line is a much better KPI. I'm definitely bringing this up with my team. Thanks for the brilliant reframe!
AI lowers the cost of a first draft, not necessarily the cost of a reliable release. Review, integration, testing, and maintenance still take time, often from the people best placed to do that work. So speed should inform an estimate, not become the estimate: price the full delivery and its scope risk, not just the time spent generating code. Measuring review and verification effort alongside generation time seems essential to knowing whether AI actually improved margins.
Kovrastudio AI lowers the cost of a first draft not a reliable release is the most important business lesson here. It completely changes how we should price software.
If a client or a manager sees the AI generate a feature in 30 seconds, they assume the whole project should be 10x cheaper. But as you said the scope risk and the senior dev's verification time haven't changed.
Selling the first draft is easy but selling the reliable release is where the real value (and cost) is. Measuring review and verification effort alongside generation time is the only way we will ever know the true ROI of AI. Otherwise we are just guessing.
Since you mentioned margins how are you handling this on the client side? Are you still pricing based on the full delivery scope, even if the first draft took minutes?
This piece nails the exact paradox every modern software engineer is currently living through. We've all experienced that dopamine hit of watching an AI spin up a pristine, 500-line feature in seconds, only to spend the next three days untangling subtle edge cases, architectural mismatches, and legacy regressions.It turns out that typing speed was never the limiting factor in software development. The real cost has always been cognitive load, system context, and verification. When code generation becomes frictionless, we simply shift the bottleneck downstreamβturning code review into an exhausting exercise in reverse-engineering machine logic. As you rightly pointed out, if you don't deeply understand what the AI wrote, you don't own the code; the technical debt owns you.
Man this is probably the best summary of the article anyone could write. You basically nailed the entire thesis in one comment!
Dopamine hit is the perfect term for that feeling of watching the AI generate 500 lines instantly. It feels like magic for exactly 30 seconds, right up until you realize you now have to reverse-engineer it.
I love your point about shifting the bottleneck downstream. We didn't eliminate the hard work; we just moved it from typing to reviewing. And the worst part is the technical debt doesn't show up on the sprint board until it's too late.
Thanks for reading and for this brilliant breakdown!
I still consider myself as a beginner, the mindset of a student. Even though I could do it with just one prompt with AI, it still goes against my principles of understanding the code first. I don't find value from any generated code. It's pretentious if I just find myself agreeing without understanding the underlying architecture. Context is already loss at that point. You also said it better, the code owns you when you let that happen.
Elmar this is honestly the best mindset to have. Please don't ever lose it, no matter how experienced you get.
You used a perfect word: pretentious. It really is If you accept a 500-line PR from AI without understanding the architecture, you're just borrowing someone else's homework. It looks great until production breaks and you're standing there with no idea how to fix it.
Honestly many experienced developers have forgotten this principle and just blindly copy-paste. The fact that you're a student who demands to understand the why before shipping puts you way ahead of the curve.
Keep that curiosity alive. The code only owns you if you let it. Thanks for sharing this perspective!
I write about Next.js + TypeScript + AI engineering, with a focus on making sites discoverable to LLMs and AI search. Long-form notes at mudassirkhan.me
the review and trust tax is the line that matches what we see. nobody prices the second pair of eyes on a 1,000 line generated diff, and it quietly becomes the real bottleneck. one thing that helped us was capping generated PRs to a size a reviewer can hold in their head and requiring the failing test to land first, so the review checks intent instead of reverse engineering logic. do you track review hours per PR anywhere, or is it all gut feel right now?
Mudassir nobody prices the second pair of eyes is a brilliant way to put it. That invisible labor is exactly what's killing our velocity.
Capping the PR size to what a reviewer can actually hold in their head is a masterstroke. And requiring the failing test to land first? That completely flips the script. It forces the AI to define the intent and the boundary before it writes a single line of code. You're checking intent instead of playing detective.
To answer your question: honestly, it's mostly gut feel right now. We track overall cycle time, but we don't have a granular metric for 'review hours per PR.' Tools like LinearB or Jellyfish can track this, but it always feels like a guessing game.
I'm definitely going to pitch your 'failing test first' rule to my team. Has it completely eliminated the 1,000-line monster PRs for you guys?
I've found that asking AI to review a smaller diff works much better than letting it rewrite half the codebase. Less to check, fewer surprises later. Cheap code is only useful if you can still understand it a month from now.
Julian cheap code is only useful if you can still understand it a month from now is the perfect summary of this entire problem.
You're spot on about smaller diffs. When we let AI rewrite massive chunks of code, building a mental model of what changed becomes impossible. By keeping the diffs small and focused, we actually stay in the driver's seat and avoid that massive review tax later.
Thanks for sharing this, it's a great rule of thumb!
Hellow everyone. I am.new to the software engineering industry still a fresher.
I do write code using Ai and few myself as well.
Whenever I try to write code myself I find difficulty writing but when I see the code written by ai I clearly understand it the architecture behind it and all.
I feel so undeconrident about this. I feel like I don't know anything and just copy pasting things.
Girish first of all take a deep breath. What you are feeling is 100% normal and honestly it's the biggest side-effect of AI that nobody talks about.
Please don't feel like a fraud. You are not just copy-pasting the fact that you actually read the AI code and understand the architecture behind it is a massive skill. Many experienced devs don't even do that.
The reason you struggle to write from scratch is because AI gives you the destination instantly. It skips the struggle of figuring it out, which is exactly how our brains build muscle memory. It's like reading a recipe perfectly, but struggling to cook without it.
Here is my advice to you:
Type it out, don't copy-paste. Even if the AI generates it, physically type it out line by line.
Play the 'Why' game. Ask the AI: 'Why did you use a map here instead of a for-loop?'
Start small. Turn off AI for 15 minutes a day and write a simple function from scratch. Just to remind your brain that you can.
You are learning in the hardest era of software engineering. Be kind to yourself. You're doing better than you think!
Programming in plain words β Python guides, free tools, and honest learning paths for beginners. Building AheadKit: programming books and practical digital tools.
The review tax is real and I pay it in a dumb, concrete way: last week I had twenty scheduled posts 'verified' by a quick dashboard glance, and the check itself was wrong β it handed me paraphrased titles that didn't match the actual posts. The generation took minutes. Trusting it took an evening of opening every single page. That's the bill nobody puts in the demo. The code is the cheap part now. Knowing it's right is the expensive part, and it doesn't parallelise as nicely as generation does.
Fractional Product Growth & Marketing @ Trent AI | Engineer-turned-Founder | PLG for B2B where the buyer reads the docs | AI, Data & Creator Industries | 3x Exits | Reforge Alumni | Dad
George, this is such a brilliant parallel. It's the exact same paradox playing out in marketing and content creation.
AI made content generation practically free, but as you said, the cost of attention hasn't dropped at all. If anything, it's gone up. When everyone can generate 100 blog posts a day, the premium shifts entirely to curation, trust, and distribution.
It's the same bottleneck we have in software: the creation is cheap, but getting someone to actually consume (or verify) it is where the real work lives. Thanks for sharing this perspective!
Man never inherited why is such a killer phrase. It perfectly captures the essence of Context Debt.
The AI just sees a messy microservice and tries to optimize it, completely unaware that it's actually a critical workaround holding up a legacy business rule. It has the syntax, but zero history. Thanks for the great insight!
ML engineer in Boston. I turn notebooks into boring services: FastAPI, Docker, eval sets and monitoring. Learning WebAssembly; building a static site generator.
Spot on Drew. Maintenance is the invisible iceberg. AI makes writing the code cheap, but it makes maintaining that massive amount of code a nightmare. If we don't factor that into the math, we're just lying to ourselves. Thanks for reading!
We're a place where coders share, stay up-to-date and grow their careers.
So true. These days I am barely writing any code but doing 99% of time editing and debuggingπ
Haha welcome to the club! π We are all slowly transitioning from Software Engineers to Professional AI Code Editors. The 99% debugging part is so painfully real.
"Writing the code was never the expensive part" matches what I keep seeing with agents too: the PR appears in an afternoon, then the review and the legacy edge case eat the week. The Jevons angle is the uncomfortable one β cheaper typing just raises the demand for more features, so the review queue never shrinks. Curious whether your team has tried capping PR size for AI-authored changes, or whether the review tax just moved into smaller, more frequent reviews.
Makayis PR in the afternoon review eats the week is painfully accurate. It perfectly captures the illusion of AI speed.
To answer your question honestly: it's a bit of both, but mostly the latter. The Review Tax just fragmented into smaller more frequent reviews. We didn't strictly cap the PR size initially, so a massive 1,000-line PR just became ten 100-line PRs.
But here's the catch: context switching between ten different AI-generated PRs is its own cognitive load. The total mental energy required doesn't shrink just because the PR is smaller. We eventually had to enforce a hard cap (around 200-300 lines) to force the AI to stay focused on one task at a time.
You're 100% right about the queue never shrinking. If we don't fix the feature demand, we're just optimizing how fast we drown. Have you found that capping PR size actually reduces the overall fatigue or does the frequency still wear you down?
Honestly, the cap on its own didn't fix the fatigue for me. Ten small PRs from ten unrelated prompts is just the big PR with extra context switches. What helped more was capping the scope per task, not the line count: one agent session, one intent, one PR, and I batch reviews into a couple of fixed slots a day instead of reviewing whenever something lands. The smaller diffs are easier to reason about, but the real win was that each one tells a single story. The other thing that cut review time was asking the agent to write a short "what I changed and what I didn't touch" note with the diff, so I'm checking claims instead of reverse engineering intent. Your 200-300 line cap sounds about right as a ceiling, though. Did you enforce it in CI or just as a team norm?
Makayis cap the scope, not the line count is the missing piece of the puzzle. You nailed it ten small PRs from ten unrelated prompts is just a fragmented 1,000-line PR. The context switching is what actually drains the mental battery.
The one agent session, one intent, one PR rule is a brilliant way to force the AI to stay focused. And I love the idea of batching reviews into fixed slots. That prevents your entire day from being hijacked by a constant stream of notifications.
Also, the what I didn't touch note is a game-changer. If the agent declares its boundaries you're just verifying claims instead of investigating intent. That saves hours.
To answer your question: it's a mix of both. We have a CI bot that warns (and sometimes blocks) PRs over a certain threshold, but the real enforcement is a team norm. If someone drops a 500-line PR, we kindly ask them to split it. Itβs more about culture than just tooling. How about on your end did you automate the scope check or is it a team agreement?
Mostly an agreement, honestly. Scope is hard to check mechanically: a line count is easy for a bot, "this PR does one thing" isn't. The closest I get to automating it is that "what I changed and what I didn't touch" note. If the agent can't describe the diff in one or two sentences, that's usually the sign it wandered, and I split it before reviewing. A CI warning over a threshold plus a team norm for the rest sounds like the right mix to me.
Makayis if the agent can't describe the diff in one or two sentences it wandered is a brilliant heuristic. I'm stealing that.
You're completely right that scope is hard to automate. Trying to write a linter for this PR does exactly one thing usually just ends in false positives and developer frustration. Using the agent's own summary as a sanity check is a very clever proxy.
Totally agree with the final formula: CI warnings for the hard limits, and team culture for the soft ones. Thanks for the great back-and-forth, this has been super valuable!
My experience rhymes with the 30-second PR story. The shift I made that actually helped was forcing the agent to write down its boundary assumptions before the code: which pieces of legacy behavior it thinks it understands, and which it flagged as unknown. Reviewing the assumptions list is fast; reviewing 500 lines for hidden ones is not. The weird part is that it flips the workflow around: the document becomes the deliverable and the code is just its rendering. I now treat an AI-generated PR the way I treat a vendor's API response: the payload is fine, but I only trust it after I have read the contract it claims to honor.
Has anyone tried making the agent's "unknowns" list a required PR template section? I am curious whether it survives contact with real deadlines.
Odinaka, the vendor API response analogy is absolute perfection. The payload is fine, but I only trust it after reading the contract is exactly the mindset we need for AI PRs.
To answer your question about making the unknowns list a required PR template section: I haven't implemented it yet but I think it would 100% survive deadlines if framed correctly. The trick is that reviewers must reject any AI PR that doesn't include the assumptions section. Once the team realizes it actually saves them hours of reverse-engineering it becomes a lifesaver, not a chore.
It flips the workflow exactly as you said: the document becomes the deliverable, and the code is just the rendering. I'm definitely going to try pitching this to my team. Have you tried it on your end yet?
I haven't β I work solo, so there's no team to enforce it on, and my own PRs get the assumptions list informally in my head. What I have done is the reverse: I require it of the tools I use. Before any AI-generated change touches my codebase it has to state what it doesn't know, because the unknowns list is where the blast radius hides. Your enforcement mechanism is the part I'd steal β reviewers rejecting any AI PR without the assumptions section is what makes it survive deadlines instead of surviving only the quiet weeks. If you pitch it, watch the first production incident: that's the real test, not the calm sprint.
Odinaka enforcing it at the tool level is actually a genius move for solo work. You basically built a one-person guardrail system. And 'the unknowns list is where the blast radius hides' is such a killer phrase.
You are 100% right about the first production incident being the real test. Calm sprints make every new process look like a miracle cure, but nothing tests a workflow like a PagerDuty alert at 2 AM. That's when people either stick to the rules or abandon them completely.
I'll definitely keep that in mind when pitching this to my team. Thanks for the great follow-up!
That 2 AM PagerDuty test is exactly the pitch I would use, because it separates a rule people follow when they are fresh from one they follow when they are tired. An optional template section gets skipped at 2 AM, but a hard gate does not: if reviewers reject an AI PR without an assumptions section, the author has to write down what the model did not know before anyone merges it. I would frame it to your team as incident cost, not paperwork β one wrong vendor assumption shipped at night costs more than every assumptions list you will ever write. Does your team already reject PRs for a missing test, so this could ride that same gate?
Odinaka incident cost not paperwork is a brilliant framing. If I pitch it as just another checklist management will ignore it. But if I frame it as preventing an expensive production incident, it suddenly gets priority.
And you're absolutely right about optional vs. hard gates. Anything marked optional might as well be deleted. It has to be a hard block in the CI or the PR template, or it will just get skipped when people are rushing.
To answer your question: we do have a CI gate that blocks PRs if tests are missing or failing. So you're right tying the assumptions requirement to that same existing gate makes perfect sense. It forces the author to explain intent before they even hit merge.
I'm taking this exact playbook to my team next week. Thanks for the back-and-forth, this has been incredibly valuable!
I'd say the biggest bottleneck is review, and specifically review of code nobody on the team can explain. When a person writes a tricky caching path, you can ask them why. With generated code, the reviewer ends up doing the reasoning the author skipped, so the cost moved, it didn't disappear.
Two things that help: keep generated PRs small enough that one person can hold the whole change in their head, and ask the author to write the edge cases in the PR description in their own words before review. If they can't, the PR isn't ready, no matter how clean it looks.
Security review has the same Jevons problem. Five times more code means five times more surface to check, and the threat model doesn't get faster just because the typing did. Systems thinking is the right conclusion.
Kiell this is an absolutely brilliant breakdown. You just added two massive dimensions I didn't fully explore.
First the reviewer ends up doing the reasoning the author skipped' perfectly captures the hidden tax. And your litmus test for PRs is gold: if the author can't explain the edge cases in their own words, the PR isn't ready. I'm 100% stealing that rule.
Second the security angle is terrifying and spot on. I didn't explicitly call out the security surface area, but you're right: AI scales the codebase instantly, which scales the vulnerability surface. The threat model doesn't get faster just because the typing did.
As you said systems thinking is the only way out. Thanks for adding so much value to this discussion!
Steal away π The "explain the edge cases in your own words" test is cheap, and it works on any PR. Thanks for writing the piece, Harsh. The cost framing is what made the discussion worth having.
Thanks for the kind words, Kiell I'm really glad the cost framing resonated with you.
Honestly it's discussions like these that make writing on dev so rewarding. I've already added the explain the edge cases rule to my team's checklist. Thanks again for adding so much value to this thread!
That's great to hear! I'd love to know how it goes with your team once it's been in the checklist for a while, especially whether it catches things in review that the tests missed. Thanks for writing such a thought-provoking piece.
Thanks Kiell I'm really curious about that too. It'll be fascinating to see if human review catches architectural blind spots that the AI-generated unit tests completely ignored.
We often write tests to prove what we did build, but human review with this rule might be the only way to catch what we forgot to build. If it yields any surprising results it might just turn into a follow-up article! Appreciate the great discussion.
The v0 shop I took over had RLS switched off in Supabase and a contact form that sent messages nowhere. Owner's take was "what matters is that it works". Was your 3 weeks the feature or cleaning up after the 30 seconds?
Artur RLS switched off in Supabase literally sent a chill down my spine. That is the ultimate AI-generated nightmare.
And the owner's quote what matters is that it works is probably the most expensive sentence in software engineering. It works until it gets hacked, or until the contact form drops a million-dollar lead.
To answer your question honestly: it was a mix of both. The 30 seconds got me the feature, but the 3 weeks was me cleaning up the Context Debt so it didn't turn into the v0 shop you inherited. If we don't spend those 3 weeks fixing the edge cases, the next dev spends 3 months fixing the blast radius.
Thanks for the laugh (and the nightmare fuel)
Going on a sticker for sure. Do you ever actually get those 3 weeks upfront, or only once something breaks?
Haha I'm honored to make it to the stickerπ honestly: 90% of the time, it's only after something breaks. It's the classic firefighter vs. building inspector problem. Management will happily pay you to put out a fire at 2 AM but asking for 3 weeks upfront to install a smoke detector is suddenly too expensive and slowing down delivery.
The only way I've actually gotten that time upfront is by hiding it in the estimate. You don't call it cleaning up AI debt. You call it Security Hardening or Edge-Case QA. If it sounds like actual work on the roadmap they approve it. If it sounds like maintenance they skip it.
Have you ever successfully pitched the 3 weeks upfront, or is it always firefighting for you too?
Firefighter vs. building inspector is exactly it. On my side it's a bit easier because I run a small studio and quote fixed prices, so the "3 weeks" never shows up as a separate line. It's just part of what a finished site costs: security headers, RLS checks, form handling, the boring edge cases. Clients don't approve maintenance, they approve a site that doesn't break. Where it gets hard is takeovers like that v0 shop. There the cleanup is visible, and I sell it the way you describe, as an audit with a list of concrete risks instead of "refactoring". A screenshot of an open Supabase table convinces faster than any estimate.
This is a masterclass in client management. Clients don't approve maintenance, they approve a site that doesn't break is such a killer line. You're basically packaging the exact same work (Context Debt cleanup) but framing it as business value.
And the screenshot of the open Supabase table is absolutely genius. Show don't tell. A concrete screenshot of a glaring security risk will always win over a spreadsheet of estimated hours. No client wants to see their data exposed to the world.
It makes total sense for a small studio with fixed pricing you just bake the cleanup into the internal cost so the client gets a working product. Thanks for sharing this perspective, it's incredibly valuable for anyone doing client work!
I think the biggest bottleneck is context and verification. AI has reduced the time it takes to write code, but it hasn't eliminated the need to understand the system the code is entering.
The tricky part is that working code doesn't automatically mean correct code. It might pass tests and still break an existing workflow, introduce a security issue, or fail under real-world conditions.
I also think AI should help us reduce complexity, not just produce more features. Sometimes the best outcome isn't generating 1,000 lines of code; it's finding a way to solve the problem with 100.
The developers who stand out won't necessarily be the ones who generate code the fastest. They'll be the ones who can judge the output, understand the trade-offs, and take responsibility for what eventually reaches production.
AI is making code cheaper, but engineering judgment is becoming even more valuable.
Egbuta this is a fantastic breakdown. You hit on something I wish more teams talked about: Working code doesn't automatically mean correct code. Passing tests is just the bare minimum; surviving real-world conditions is the actual bar.
But your point about reducing complexity is the real masterstroke. AI defaults to adding code to solve a problem. It will happily write 1,000 lines to fix a bug that a senior dev could fix by deleting 50 lines. Using AI to simplify systems rather than just inflate them is the true mark of an expert.
And your closing line is the perfect summary of this entire discussion: AI is making code cheaper, but engineering judgment is becoming even more valuable. I couldn't have said it better myself. Thanks for adding so much value here!
Thank you! I really appreciate that. I agree that knowing when to simplify a system is just as important as knowing how to build it. There's still so much to learn as AI continues to change the way we develop software. I'd love to connect with you here on DEV and keep learning from your insights. Looking forward to more discussions like this!
Thank you Egbuta I really appreciate that, and I just followed you here on DEV.
You're absolutely right knowing when to simplify is a superpower. We're all figuring out this new AI era together, and it's conversations like these that help us make sense of it. Looking forward to seeing your thoughts and keeping the discussion going in the future!
absolutely
The review bottleneck exposes a fundamental asymmetry between generation and verification that gets glossed over in developer tooling demos.
When an engineer writes code manually, the mental model of edge cases, state transitions, and invariants is built during the drafting process. The code is simply the artifact left behind by that reasoning. When an LLM generates five hundred lines in thirty seconds, that construction step is bypassed entirely. That reasoning work simply moves downstream into verification.
Verifying third-party code without an explicit model of its boundary assumptions becomes an unconstrained search problem. You are no longer just checking whether the implementation satisfies a ticket. You have to reverse-engineer what invariants the model silently ignored while optimizing for local coherence. Auditing for the absence of subtle edge cases requires exploring the entire state space of the surrounding architecture, which takes significantly more time than writing the initial implementation.
This creates an adverse selection trap in pull request reviews. Because thorough auditing is so exhausting, teams inevitably fall back on superficial checks, relying on green unit tests that were often generated by the very same model to test its own assumptions. The true cost of the code does not disappear from the balance sheet. It simply shifts from visible engineering payroll into hidden tail risk that sits dormant in production until an unmapped integration breaks.
Dean this is one of the most brilliant breakdowns of this problem I've read. You've put words to something I was feeling but couldn't articulate.
The unconstrained search problem perfectly captures why reviewing AI code is so exhausting. When I write code, I'm building the mental model as I type. When AI writes it, I'm dropped into the middle of a maze with no map. I have to figure out what it built and why it built it that way simultaneously.
But the adverse selection trap is genuinely terrifying. The fact that the LLM writes the code and then writes the tests to prove its own code works is a massive blind spot. We are literally asking the student to grade their own exam, and we are trusting the A+ because the paper is neat.
How do you personally escape this trap? Do you mandate that tests for AI-generated code must be written by a human, or is there another way to break that hidden tail risk?
The cleanest way to break the circular dependency is invariant decoupling. You never let the model generate both the implementation and the test assertions in the same context.
Either write property-based tests and boundary invariants first, or use a separate adversarial prompt whose only objective is to find state transitions that violate production constraints. If a human has to review anything, reviewing five hard invariant properties takes a fraction of the time needed to audit three hundred lines of self-congratulatory unit tests.
Dean this is incredibly actionable. Invariant decoupling is exactly the term I was missing. the adversarial prompt' idea is a game-changer. Most of us default to write tests to prove this works which as you perfectly put it just yields self-congratulatory unit tests. Flipping the prompt to find three ways this logic breaks completely changes the AI's objective from being a cheerleader to being a red teamer.
I'm definitely going to start using property-based tests for AI-generated logic. Thanks for dropping this gem of a solution!
Good post, and an engaging thread that has extended the post.
Fix 2 assumes that review capacity is a fixed cost that you have to fund. Reviewing a diff is expensive. It would be cheaper to review a shorter plan before the agent starts generating numerous lines of code. Odinaka and Kiell have the same idea but for the PR and edge-case scenario. By keeping the plan in the repo along with the code, any agent can pick up from where it left off. That will take care of the context debt.
George this is a fantastic synthesis of the whole thread. You're absolutely right Fix 2 (funding more review capacity) is a reactive approach. Reviewing a 1-page plan is infinitely cheaper than reviewing a 1,000-line diff.
Keeping that plan in the repo alongside the code is the ultimate antidote to Context Debt. It essentially turns the plan into an ADR (Architecture Decision Record). When the next agent or developer picks it up, they don't have to reverse-engineer the intent; it's right there in the repo.
It shifts the workflow from generate and verify to plan verify and then generate. Huge fan of this idea. How do you usually format these plans? Just a markdown file in the PR, or a dedicated folder in the repo?
Markdown files in the repo in a folder structure that is a state machine. That works.
Dean Lee's point about the mental model is the heart of it for me. When someone writes code by hand, the edge cases get worked out while typing, and the code is what is left over. With generated code that reasoning never happened, so the reviewer has to rebuild it from scratch, which is why the caching bug took two days to find.
I would add one more place the cost went: deciding what the feature is. Your three weeks started with a detailed prompt, but the legacy system that broke was never in that prompt, because nobody had written down what the change touched and what done meant in production. When that is written first, on one page, both the generation and the review get smaller.
That is also how we scope client work at Ascendra Ventures, one clearly defined problem with a written finish line rather than hours. Cheap code made that page worth more, not less. Which part of your three weeks would it have removed?
This is such a sharp addition. You are absolutely right: the biggest missing piece wasn't just the code review, it was the lack of a defined 'finish line' and impact analysis before generation even started.
To answer your question about my three weeks: writing that one-page scope would have completely eliminated the week I spent debugging the legacy system. If we had explicitly written down 'what this change touches,' we would have realized the AI lacked the context of our old system. It also would have cut the review time in half, because the reviewer would have had a clear baseline to measure the AI's output against.
I love the way Ascendra Ventures scopes client work with a written finish line. It completely flips the script: cheap code makes the scoping phase worth more, not less. Thanks for sharing this perspective, it's going straight into my workflow.
The 30-second PR that takes two days to review is exactly the trade. AI moved the cost from typing to understanding, and understanding still runs at human speed. On my own side projects the expensive bits are never the code. It's store reviews, platform rules, and the one edge case real users find on day one.
Nilamadhab understanding still runs at human speed is a brilliant way to put it. I might have to steal that line!
You're completely right. We get so obsessed with the coding part that we forget the actual expensive bottlenecks of shipping: App Store reviews, platform compliance, and the absolute chaos of day-one user behavior.
AI can write the code for a feature, but it can't predict how a real user will break it in ways we never imagined, nor can it argue with an app store reviewer. The real cost of software has always been outside the editor. Thanks for sharing this!
Steal away π Thanks for writing it, the 30-second PR line is going to stick with me too.
The review and integration bottleneck is a useful reminder that code generation shifts rather than removes uncertainty. It would be interesting to track time from generated diff to a verified production outcome, split by review, test investigation, and rollback work, rather than using lines or PR count as the productivity proxy.
Alex shifts rather than removes uncertainty is a brilliant way to put it. The uncertainty doesn't disappear; it just changes its address from the author to the reviewer.
Tracking the time from generated diff to verified production outcome is exactly the metric we need. Lines of code and PR counts have always been terrible vanity metrics, but AI makes them even more useless because generating 1,000 lines is now instant.
Splitting that timeline into review time test investigation and rollback work would give us a real picture of AI's ROI. If we see that 80% of the time is spent in test investigation for AI-generated code, that tells us exactly where we need to invest in tooling.
Have you managed to implement this kind of granular tracking on your team yet, or does it currently just blend into overall cycle time?
I do not have a reliable team-level breakdown to cite yet, so I would treat this as a measurement proposal rather than a result. One starting point is to timestamp review, test investigation and any rollback against the same change, while separating elapsed waiting time from active work. That would make a bottleneck visible without assuming every delay came from AI-generated code.
Alex separating elapsed waiting time from active work is a brilliant distinction. That's often where the illusion of slowness comes from.
A PR might take 48 hours from open to merge, but if only 30 minutes of that was actual review and the rest was just sitting in a queue waiting for a senior dev to wake up, the problem isn't AI it's process. Assuming all delay comes from AI-generated code is a trap.
Treating it as a measurement proposal first is definitely the right approach. If you do end up implementing that timestamping system, I'd love to hear what the data reveals. Thanks for the great discussion!
The point about the review tax matches what I've seen. One small thing that helps is asking for a short summary of which existing files and behaviors a change touches, so the reviewer knows where to look first. Do you track review time per PR, and has it gone up since you started using AI?
AIFix that is a brilliant tip. Asking for a blast radius summary which existing files and behaviors are touched before diving into the code is a massive time-saver. It gives the reviewer a map instead of dropping them in the middle of a maze.
To answer your questions honestly no we don't track granular review hours per PR. We rely on gut feel and overall cycle time. But has it gone up since using AI? Absolutely. We are spending way more time reading and verifying code than we ever did writing it.
It's exactly the Review Tax in action. The AI generates it in seconds but the human brain still takes minutes to map the context. Thanks for the great tip
Thanks Harsh, really useful to hear real numbers from your side. Since review time is the bottleneck, one more small habit that helps: ask the AI to list what it did NOT change and what it assumed, next to the blast radius summary. Reviewers then know which assumptions to check first instead of re-reading everything.
AIFix list what it did NOT change is a brilliant habit. AI is always so eager to tell you what it did do but it quietly hides its blind spots.
Forcing it to declare its non-changes and assumptions gives the reviewer a targeted checklist. Instead of re-reading 1,000 lines of code with a fine-tooth comb, you can look at the assumptions list and say Ah it assumed the user ID is always present. Let me verify that specific line.
This combined with the blast radius summary is a total game-changer for code reviews. I'm definitely adding this to my prompt templates. Thanks for sharing such actionable tips!
Glad it's useful, Harsh. If you add it to your templates, a line like "list what you did not change and any assumptions you made" works well. Would love to hear if it catches anything.
"This is hands down one of the best takes on AI-assisted development!
The point about 'Jevons Paradox in Software' and 'Context Debt' hits right at the center. Generating 1,000 lines of code in 30 seconds feels great, but reverse-engineering AI logic during review takes double the time.
In my experience, the biggest bottleneck right now is definitely Integration & Edge-case Review. AI handles syntax and boilerplates effortlessly, but it lacks the historical context of existing systems and legacy code.
Absolutely agree that the shift is from 'writing code' to 'editing & systems thinking'. Brilliant post!
Dharu thank you so much! That means a lot.
You hit the nail on the head with 'Integration & Edge-case Review. It's fascinating how AI is a genius at syntax and boilerplate, but completely blind to the historical context of our systems. It doesn't know why a certain legacy function exists, so it just happily breaks it.
And you're spot on about the time reversal. Generating it takes 30 seconds, but wrapping your brain around it takes hours. It feels great to know I'm not the only one experiencing this exact shift. Thanks for reading and sharing your experience!
The Jevons framing lands, but the sharper point is the cost moved to verification and nobody budgets for it. A 30-second PR that sits two days in review isn't velocity, it's a queue. Two things that helped us: cap AI-generated PRs around 200 lines - the subtle caching bug you describe hides exactly in 900-line diffs nobody actually reads - and write ADRs for the 'why' that lived in the departed dev's head, or that context stays an unbudgeted tax forever. Are you tracking review latency as a metric, or only generation speed?
Golfover queue not velocity is an incredibly sharp way to put it. A 30-second generation time is meaningless if the PR then sits in a review queue for 48 hours. That's not speed; that's just moving the traffic jam further down the road.
The 200-line cap is a brilliant rule of thumb. It forces the AI (and the author) to be concise, and it keeps the cognitive load manageable for the reviewer so the subtle bugs can't hide.
And I love the ADR (Architecture Decision Record) mention. It is literally the only way to stop Context Debt from becoming permanent when senior devs leave.
To answer your question honestly: right now, we are definitely focused more on generation speed because it's the shiny new metric. But you're right review latency is the real bottleneck. I'm going to start tracking the time from PR open to first human review because of this comment. Thanks for the great reframe!
Brilliant explanation of the Jevons Paradox in tech. For our team, the biggest bottleneck is 100% the 'Review and Trust Tax.' Reviewing AI-generated code feels like grading a student's homework who is incredibly smart but notoriously sloppy. You spend double the time reverse-engineering their logic just to ensure they didn't introduce a hidden architectural bug. Love how you highlighted that the job has shifted from writing to editing. Excellent piece.
Yashish, that analogy is absolutely perfect. Grading a smart but sloppy student's homework is exactly what it feels like.
The worst part about the Trust Tax' is how confident the AI sounds. It writes code that looks aesthetically beautiful and technically correct on the surface, but you have to dig deep just to find out it completely ignored a core business rule.
Since your team feels this 100%, how are you guys currently handling it? Are you leaning more on automated tests to catch the sloppiness, or just accepting the extra review time as the new normal?
The Jevons framing is right, but the review tax is invisible in every metric we track: PR count goes up, cycle-time dashboards stay green, and the real cost hides in the reviewer's head. One thing that helped on teams I've been on: require AI-assisted PRs to declare their assumptions about existing behavior in the description ('this assumes the cache invalidates on deploy X'). Reviewing declared assumptions takes minutes; discovering undeclared ones in production takes the week you described. Is anyone measuring assumption density, or does the trust tax just get absorbed as overtime?
AI has made writing code faster, but I think the bigger challenge is everything around the code: understanding requirements, making the right architectural decisions, testing edge cases, and maintaining the system after launch. A working prototype is only one milestone; getting software to work reliably in a real environment is where much of the effort still goes. The real productivity gain comes when faster coding translates into faster, dependable delivery.
Glen, you nailed it. Everything around the code' is the perfect way to describe it. We've optimized the typing speed but we haven't optimized the thinking speed.
Your distinction between a working prototype and dependable delivery is spot on. AI gives us the illusion of speed because we see something working on our local machine instantly. But as you said, the real effort is in getting it to survive the real environment, the legacy systems, and the edge cases.
The real productivity gain really is just faster dependable delivery. Anything less is just faster tech debt. Thanks for the great insight!
I'd measure time from opening the PR to a verified deployment, including review and rollback work. That would make the caching example much harder to hide behind a fast generation time. I'd bring the same habit to a prachub design exercise: explain the cache boundary and one failure case before asking AI to fill in the implementation.
Emily this is the perfect metric. Measuring from PR open to verified deployment is the only way to get a true picture of developer velocity. If we only count the 30 seconds it took AI to generate the code, we are just lying to ourselves.
I love your design exercise approach even more. Explaining the cache boundary and one failure case before asking the AI to write the code is a brilliant way to prevent Context Debt before it even starts. It forces you to build the mental model first, and then use AI just as a typist.
I'm definitely going to try this explain first, generate second workflow. Thanks for sharing!
The paradox checks out in practice: inference got 10x cheaper, but the expensive parts were never inference. Code review, legacy integration, on-call - that's where the bill lives, and agents generate more code to review, not less. An agent PR still needs a senior human to sign off, so throughput rises while the review bottleneck gets worse. Teams that actually save money treat agent output like intern output: cheap to produce, expensive to trust, until the verification layer exists. Did you measure where the time actually goes in your builds?
Golfover the intern output analogy is absolutely brilliant. It's the perfect way to describe it: cheap to produce, but expensive to trust. An intern's code needs a senior to review it, but AI is like an intern who writes 5,000 lines in a minute, drowning the senior in the process.
To answer your question honestly: no, we haven't strictly measured the minute-by-minute time allocation. We mostly rely on overall cycle time and gut feel. But anecdotally, the time has shifted massively from writing to verifying. The 'verification layer' you mentioned is exactly what's missing in most AI workflows right now.
If we don't build that layer, we're just creating code faster than we can understand it. Thanks for such a great breakdown!
I wouldn't agree with "just as long to ship". With AI, I can develop things quicker than before, and thus get more done in a sprint than before. So a feature that would originally not have made it into the program increment at all (I work in a SaFe managed project) can now be done in the 3 months window. That is real progress.
But the thing is, if you have a mature system and your AI takes 1000 lines to make a change (1000 lines of production code I mean) then your AI has done a bad job. Even medium-sized changes don't take a 1000 lines of production code in clean, well-designed and mature systems. It is the old adage of Robert C. Martin in one of his books: The only way to go fast is to go well.
What that means is, don't use the AI in such broad ways. Don't give it a ticket and tell it to implement it. You have to think about how to implement it yourself, and use AI only to do the implementation for you, not the design of the solution. That's a win-win for both you and the AI: The AI gets to do what it does best (do concretely, well-specified coding tasks) and you get to do what you do best (design good technical solutions). That way you also don't loose the context, because reviewing small, focused changes is way easier than large changes.
EDIT: But the biggest thing is this: I welcome the bottleneck. The bottleneck of review is fantastic, because it makes sure knowledge about the change is getting spread throughout the team, and if done in a disciplined manner (which means you review your own changes as well) it adds a lot to the collective team knowledge. Working well with AI is largely a matter of applying a disciplined approach and sticking with tried and true development principles.
90% of time when I use the Claude models, I know what it's gonna write when I hit enter. I try to not use it to think for me (unless I have a refactoring for something like performance where I know Claude is gonna do a better job than I could), but to code for me. That is a big difference. When you let it think for you, all the bad stuff you described happens. That stuff mostly doesn't happen when I just let it code for me.
Andreas this is a phenomenal pushback, and I absolutely love the nuance you've brought to this. You've completely shifted my perspective on a few things.
You nailed the core distinction: using AI to code for you vs. using it to think for you. If you already know the design and just let Claude handle the boilerplate, you're operating as an architect, not a passenger. That is a massive difference from handing an agent a vague ticket and hoping for the best.
I also really appreciate your EDIT point about welcoming the review bottleneck. I hadn't thought of it as a knowledge-spreading mechanism. If a developer has to deeply review AI-generated code to approve it, they are forced to learn the system. That actually builds collective team knowledge.
And the Robert C. Martin quote is spot on. If a simple change requires 1,000 lines, the AI isn't being helpful; it's just masking bad design.
Thanks for sharing your workflow. 'Think deeply, then let the AI type' is a rule I think every team should adopt.
One more place the cost went that nobody's mentioned here: the metering model. How you're billed quietly shapes how much you burn.
I recently ran the numbers for a comparison on TechRiseUps of every Codex plan against Copilot, Cursor and Claude Code (see it here), and the detail that stuck with me is that Codex switched to token-based metering back in April 2026. That's a completely different experience from a flat $20/seat plan. On flat-rate tools, tokens feel free β developers fire off sprawling agent runs, skim the output, and throw away half of it. That's the Jevons paradox in action, and it feeds the review tax and context debt you're all describing. Under token metering, you suddenly see every one of those exploratory loops on the bill: one "refactor everything" agent session can burn more than the monthly sticker price in an afternoon.
So the pricing model quietly picks which problem you get. Flat-rate plans hide the cost and encourage bloat; usage-based plans surface it and make you think twice before hitting enter. Either way, "free code generation" is only free if you don't count who's paying β your attention in review, or your token bill.
The unit of cost never was typing speed - it was deciding what to build and owning the failure modes. AI shifts hours from writing to reviewing code you did not write, and review is serial senior-person work. Worth tracking cost-per-production-incident instead of cost-per-line: cheap generation that doubles triage load is a net loss. Did your team actually measure this, or does it just feel faster?
Golfover review is serial senior-person work is a brilliant way to put it. You just described the biggest hidden bottleneck in modern engineering. AI can parallelize code generation, but human review is inherently serial. You can only review one PR at a time.
To answer your question honestly: it mostly just feels faster right now. We track overall cycle time but we haven't started measuring the true triage load or the cost of production incidents caused by AI-generated code.
And that's the exact trap you're pointing out. If AI doubles our generation speed but also doubles our triage load, we haven't gained anything we've just moved the stress to the most senior (and most expensive) people on the team.
Tracking cost-per-production-incident instead of cost-per-line is a much better KPI. I'm definitely bringing this up with my team. Thanks for the brilliant reframe!
AI lowers the cost of a first draft, not necessarily the cost of a reliable release. Review, integration, testing, and maintenance still take time, often from the people best placed to do that work. So speed should inform an estimate, not become the estimate: price the full delivery and its scope risk, not just the time spent generating code. Measuring review and verification effort alongside generation time seems essential to knowing whether AI actually improved margins.
Kovrastudio AI lowers the cost of a first draft not a reliable release is the most important business lesson here. It completely changes how we should price software.
If a client or a manager sees the AI generate a feature in 30 seconds, they assume the whole project should be 10x cheaper. But as you said the scope risk and the senior dev's verification time haven't changed.
Selling the first draft is easy but selling the reliable release is where the real value (and cost) is. Measuring review and verification effort alongside generation time is the only way we will ever know the true ROI of AI. Otherwise we are just guessing.
Since you mentioned margins how are you handling this on the client side? Are you still pricing based on the full delivery scope, even if the first draft took minutes?
This piece nails the exact paradox every modern software engineer is currently living through. We've all experienced that dopamine hit of watching an AI spin up a pristine, 500-line feature in seconds, only to spend the next three days untangling subtle edge cases, architectural mismatches, and legacy regressions.It turns out that typing speed was never the limiting factor in software development. The real cost has always been cognitive load, system context, and verification. When code generation becomes frictionless, we simply shift the bottleneck downstreamβturning code review into an exhausting exercise in reverse-engineering machine logic. As you rightly pointed out, if you don't deeply understand what the AI wrote, you don't own the code; the technical debt owns you.
Man this is probably the best summary of the article anyone could write. You basically nailed the entire thesis in one comment!
Dopamine hit is the perfect term for that feeling of watching the AI generate 500 lines instantly. It feels like magic for exactly 30 seconds, right up until you realize you now have to reverse-engineer it.
I love your point about shifting the bottleneck downstream. We didn't eliminate the hard work; we just moved it from typing to reviewing. And the worst part is the technical debt doesn't show up on the sprint board until it's too late.
Thanks for reading and for this brilliant breakdown!
I still consider myself as a beginner, the mindset of a student. Even though I could do it with just one prompt with AI, it still goes against my principles of understanding the code first. I don't find value from any generated code. It's pretentious if I just find myself agreeing without understanding the underlying architecture. Context is already loss at that point. You also said it better, the code owns you when you let that happen.
Elmar this is honestly the best mindset to have. Please don't ever lose it, no matter how experienced you get.
You used a perfect word: pretentious. It really is If you accept a 500-line PR from AI without understanding the architecture, you're just borrowing someone else's homework. It looks great until production breaks and you're standing there with no idea how to fix it.
Honestly many experienced developers have forgotten this principle and just blindly copy-paste. The fact that you're a student who demands to understand the why before shipping puts you way ahead of the curve.
Keep that curiosity alive. The code only owns you if you let it. Thanks for sharing this perspective!
the review and trust tax is the line that matches what we see. nobody prices the second pair of eyes on a 1,000 line generated diff, and it quietly becomes the real bottleneck. one thing that helped us was capping generated PRs to a size a reviewer can hold in their head and requiring the failing test to land first, so the review checks intent instead of reverse engineering logic. do you track review hours per PR anywhere, or is it all gut feel right now?
Mudassir nobody prices the second pair of eyes is a brilliant way to put it. That invisible labor is exactly what's killing our velocity.
Capping the PR size to what a reviewer can actually hold in their head is a masterstroke. And requiring the failing test to land first? That completely flips the script. It forces the AI to define the intent and the boundary before it writes a single line of code. You're checking intent instead of playing detective.
To answer your question: honestly, it's mostly gut feel right now. We track overall cycle time, but we don't have a granular metric for 'review hours per PR.' Tools like LinearB or Jellyfish can track this, but it always feels like a guessing game.
I'm definitely going to pitch your 'failing test first' rule to my team. Has it completely eliminated the 1,000-line monster PRs for you guys?
I've found that asking AI to review a smaller diff works much better than letting it rewrite half the codebase. Less to check, fewer surprises later. Cheap code is only useful if you can still understand it a month from now.
Julian cheap code is only useful if you can still understand it a month from now is the perfect summary of this entire problem.
You're spot on about smaller diffs. When we let AI rewrite massive chunks of code, building a mental model of what changed becomes impossible. By keeping the diffs small and focused, we actually stay in the driver's seat and avoid that massive review tax later.
Thanks for sharing this, it's a great rule of thumb!
Hellow everyone. I am.new to the software engineering industry still a fresher.
I do write code using Ai and few myself as well.
Whenever I try to write code myself I find difficulty writing but when I see the code written by ai I clearly understand it the architecture behind it and all.
I feel so undeconrident about this. I feel like I don't know anything and just copy pasting things.
Healp me out with thia.
Girish first of all take a deep breath. What you are feeling is 100% normal and honestly it's the biggest side-effect of AI that nobody talks about.
Please don't feel like a fraud. You are not just copy-pasting the fact that you actually read the AI code and understand the architecture behind it is a massive skill. Many experienced devs don't even do that.
The reason you struggle to write from scratch is because AI gives you the destination instantly. It skips the struggle of figuring it out, which is exactly how our brains build muscle memory. It's like reading a recipe perfectly, but struggling to cook without it.
Here is my advice to you:
You are learning in the hardest era of software engineering. Be kind to yourself. You're doing better than you think!
The review tax is real and I pay it in a dumb, concrete way: last week I had twenty scheduled posts 'verified' by a quick dashboard glance, and the check itself was wrong β it handed me paraphrased titles that didn't match the actual posts. The generation took minutes. Trusting it took an evening of opening every single page. That's the bill nobody puts in the demo. The code is the cheap part now. Knowing it's right is the expensive part, and it doesn't parallelise as nicely as generation does.
same thing in marketing tbh. there's way more content out there now and getting anyone to actually read yours costs what it always did
George, this is such a brilliant parallel. It's the exact same paradox playing out in marketing and content creation.
AI made content generation practically free, but as you said, the cost of attention hasn't dropped at all. If anything, it's gone up. When everyone can generate 100 blog posts a day, the premium shifts entirely to curation, trust, and distribution.
It's the same bottleneck we have in software: the creation is cheap, but getting someone to actually consume (or verify) it is where the real work lives. Thanks for sharing this perspective!
Context Debt is the right name β the model can sprint a PR, but it never inherited why that fragile microservice exists.
Man never inherited why is such a killer phrase. It perfectly captures the essence of Context Debt.
The AI just sees a messy microservice and tries to optimize it, completely unaware that it's actually a critical workaround holding up a legacy business rule. It has the syntax, but zero history. Thanks for the great insight!
The maintenance side is what people leave out of the math. Agreed.
Spot on Drew. Maintenance is the invisible iceberg. AI makes writing the code cheap, but it makes maintaining that massive amount of code a nightmare. If we don't factor that into the math, we're just lying to ourselves. Thanks for reading!