I can generate a full authentication flow with a database schema, API routes, and unit tests in under 30 seconds.
I can refactor a messy component...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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 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.
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.
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 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!
"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!
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?
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!
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.
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!
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!
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?
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!
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?
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!
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!
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!