{"slug": "ai-is-writing-more-of-the-code-but-developers-are-becoming-responsible-for-more", "title": "AI Is Writing More of the Code — But Developers Are Becoming Responsible for More Than Ever", "summary": "A developer argues that as AI agents take over more code generation, testing, and review, engineers are writing less code but remain fully accountable for the systems they approve and deploy. The piece warns that when the same model writes both implementation and tests, a shared misunderstanding can pass CI while shipping the wrong feature, creating a form of \"understanding debt\" where teams own code nobody fully comprehends.", "body_md": "AI is writing more code.\n\nThat part is obvious now.\n\nDevelopers can ask an agent to:\n\nAnd in many cases, it works surprisingly well.\n\nBut something else is happening at the same time.\n\n**Developers are writing less of the code, while becoming responsible for more of it.**\n\nThat is the part I think we are underestimating.\n\nBecause when production breaks at 2 AM, nobody is going to ask:\n\n“Which model generated this function?”\n\nThey are going to ask:\n\n**“Who owns this system?”**\n\nAnd the answer is still us.\n\nA traditional development workflow looked something like this:\n\n```\nUnderstand requirement\n        ↓\nDesign solution\n        ↓\nWrite code\n        ↓\nTest it\n        ↓\nReview it\n        ↓\nDeploy it\n        ↓\nMaintain it\n```\n\nThe developer touched almost every stage.\n\nThat had problems.\n\nIt was slower.\n\nIt required more manual work.\n\nBut there was one big advantage:\n\n**The person responsible for the code usually understood how it was created.**\n\nNow the workflow is changing.\n\n```\nUnderstand requirement\n        ↓\nAsk AI to plan\n        ↓\nAI writes implementation\n        ↓\nAI writes tests\n        ↓\nAI fixes errors\n        ↓\nAI reviews code\n        ↓\nDeveloper approves\n        ↓\nProduction\n```\n\nLook carefully at where the human appears.\n\nSometimes the developer is only deeply involved at the beginning and the end.\n\nThat creates a strange new situation.\n\nThe developer may be responsible for:\n\nYet the developer still owns the result.\n\nThis is the mistake I think teams need to avoid.\n\nAI-generated code can make something feel less like your responsibility.\n\nIt is easy to think:\n\n“The agent generated it.”\n\nBut production systems do not care who typed the code.\n\nIf you merge it, approve it, or deploy it, it becomes part of the system you own.\n\nThat means you are still responsible for questions like:\n\nAI can help answer these questions.\n\nBut it cannot remove your responsibility for them.\n\nThis becomes especially dangerous when AI writes both the code and the tests.\n\nImagine this:\n\n```\nRequirement\n    ↓\nAI misunderstands requirement\n    ↓\nAI writes implementation\n    ↓\nAI writes tests for its interpretation\n    ↓\nAll tests pass\n```\n\nTechnically:\n\n**Green CI.**\n\nPractically:\n\n**Wrong feature.**\n\nThis is one of the most important things developers need to remember in AI-assisted development.\n\nTests can prove that code behaves according to a certain expectation.\n\nThey cannot automatically prove that the expectation itself was correct.\n\nIf the same model creates both the implementation and the test, they can share the same misunderstanding.\n\nThat is why human review still matters at the requirement level.\n\nThe developer role is slowly changing from:\n\n```\nWrite\nTest\nDebug\n```\n\nto something closer to:\n\n```\nDefine\nConstrain\nDelegate\nInspect\nVerify\nApprove\nOwn\n```\n\nThat is not necessarily bad.\n\nIn fact, it can be incredibly productive.\n\nBut it requires a different skill set.\n\nThe best developer may no longer be the person who can type code fastest.\n\nIt may be the person who can:\n\nThose are engineering skills, not typing skills.\n\nThis is where I think the real risk begins.\n\nSuppose an AI agent adds a feature across 15 files.\n\nIt modifies:\n\nEverything passes.\n\nYou review the diff quickly.\n\nYou merge.\n\nThen two months later, something breaks.\n\nNow you need to answer:\n\nWhy was this implemented this way?\n\nBut maybe nobody knows.\n\nThe AI session is gone.\n\nThe reasoning was never documented.\n\nThe developer who approved it only reviewed the output.\n\nThis is how teams can slowly build systems that **work but are no longer deeply understood**.\n\nWe already talk about technical debt.\n\nBut AI introduces something slightly different.\n\nI think of it as:\n\nTechnical debt is often:\n\n“We know this code is messy, but we shipped it anyway.”\n\nUnderstanding debt is:\n\n**“We own this code, but nobody fully understands why it works this way.”**\n\nThat can be even more dangerous.\n\nBecause messy code is visible.\n\nMissing understanding is harder to detect.\n\nEverything may look fine until something unusual happens.\n\nOne simple way to reduce this problem is to stop giving agents enormous tasks.\n\nCompare these two prompts.\n\nBad:\n\n```\nBuild the full subscription system.\n```\n\nBetter:\n\n```\nAnalyze the current billing architecture.\n\nExplain which files need to change.\n\nDo not modify code yet.\n```\n\nThen:\n\n```\nImplement only the subscription data model.\n\nDo not change unrelated files.\nAdd the billing service using the existing service pattern.\nAdd tests for the new behavior.\n```\n\nSmaller tasks create smaller diffs.\n\nSmaller diffs are easier to understand.\n\nAnd code that is easier to understand is easier to own.\n\nOne of the most useful changes you can make is simple:\n\n**Ask the AI to explain what it plans to do before it changes anything.**\n\nFor example:\n\n```\nBefore writing code:\n\n1. Explain the current architecture.\n2. List the files you plan to change.\n3. Explain why each change is needed.\n4. Identify possible risks.\n5. Wait for approval before implementation.\n```\n\nThis gives you a chance to catch bad direction early.\n\nFixing a bad plan is cheap.\n\nFixing 800 lines generated from a bad plan is not.\n\nTraditional code review often focuses on lines.\n\n``` js\n+ const result = await processPayment()\n```\n\nBut with AI-generated code, the more important review may be:\n\nWhy is payment processing happening here?\n\nThat is a different level of review.\n\nInstead of only asking:\n\n**Is this line correct?**\n\nAsk:\n\n**Should this responsibility live in this module?**\n\nInstead of:\n\n**Does this function compile?**\n\n**Does this architecture make sense?**\n\n**Does the test pass?**\n\n**Is this testing the right behavior?**\n\nAI is making syntax cheaper.\n\nThat means developers need to spend more attention on decisions.\n\nThis rule becomes much more important in the AI era.\n\nYou do not need to memorize every line.\n\nBut you should be able to explain:\n\nIf someone asks:\n\n“Why does this work this way?”\n\nand your answer is:\n\n“The AI generated it.”\n\nThat is not enough.\n\nOnce it is merged, it is your system.\n\nAI is extremely good at saving developers from repetitive work.\n\nThat is where it can create huge value.\n\nLet it help with:\n\nBut be careful when the AI starts generating:\n\nThe higher the blast radius, the more human understanding should increase.\n\nNot decrease.\n\nIf AI made an important design choice, capture the reason.\n\nNot this:\n\n```\n// Process the payment\nprocessPayment();\n```\n\nBut something like:\n\n```\n// We process payment before creating the final order because\n// failed payments must not create confirmed inventory reservations.\n```\n\nThat tells the next developer why the code exists.\n\nArchitecture Decision Records can also help for larger choices.\n\nThe AI session will disappear.\n\nThe reasoning should not disappear with it.\n\nThere is another interesting effect here.\n\nThe more code AI writes, the more valuable debugging becomes.\n\nBecause when generated code fails, someone still needs to understand:\n\nAI may help investigate.\n\nBut a developer who does not understand the system will struggle to know whether the AI's explanation is correct.\n\nThat is why I think debugging may become an even more important skill in the AI era.\n\nWriting code is becoming easier.\n\nUnderstanding why a system is broken is not.\n\n```\nPrompt\n↓\nGenerate\n↓\nTests pass\n↓\nMerge\n```\n\nTry this:\n\n```\nDefine requirement\n        ↓\nAI analyzes existing system\n        ↓\nAI proposes plan\n        ↓\nDeveloper reviews plan\n        ↓\nAI makes small change\n        ↓\nDeveloper understands diff\n        ↓\nTests run\n        ↓\nFailure cases reviewed\n        ↓\nArchitecture reviewed\n        ↓\nMerge\n```\n\nThe AI is still doing a lot of work.\n\nBut the developer remains connected to the reasoning.\n\nThat is the important part.\n\nBefore merging, ask:\n\nIf not, keep reviewing.\n\nNot just the test.\n\nThe real requirement.\n\nLook for hidden assumptions around data, APIs, users, permissions, and infrastructure.\n\nNetwork timeout?\n\nDatabase error?\n\nDuplicate request?\n\nPartial write?\n\nUnexpected input?\n\nBecause somebody will eventually maintain it.\n\nMaybe you.\n\nThis is probably the most important idea.\n\nAI can reduce:\n\n**typing**\n\n**boilerplate**\n\n**implementation time**\n\n**repetitive work**\n\nBut it does not automatically reduce:\n\n**responsibility**\n\n**risk**\n\n**ownership**\n\n**maintenance**\n\n**production consequences**\n\nIn fact, AI may increase the amount of software a developer is responsible for.\n\nOne engineer may soon oversee the amount of code that previously required several people to produce.\n\nThat makes engineering judgment more important, not less.\n\nFor years, software development was strongly associated with writing code.\n\nNow code itself is becoming easier to produce.\n\nSo the valuable skills move upward.\n\nUnderstanding the problem.\n\nChoosing the architecture.\n\nDefining constraints.\n\nRecognizing risk.\n\nReviewing decisions.\n\nDebugging failures.\n\nProtecting maintainability.\n\nTaking ownership.\n\nThose things are much harder to automate completely.\n\nAI may write more and more of our code.\n\nThat is probably going to continue.\n\nBut there is a dangerous assumption hiding behind that productivity:\n\n**If AI writes the code, AI owns the consequences.**\n\nIt doesn't.\n\nYou do.\n\nThe future developer may write less code personally.\n\nBut they may be responsible for **more code, more systems, and more decisions than ever before**.\n\nSo maybe the most important question in AI-assisted development is no longer:\n\n**“Can the AI build this?”**\n\nIt is:\n\n**“If I approve this, do I understand it well enough to own it?”**\n\nBecause generating code is becoming cheap.\n\n**Owning software is not.**", "url": "https://wpnews.pro/news/ai-is-writing-more-of-the-code-but-developers-are-becoming-responsible-for-more", "canonical_source": "https://dev.to/robertadam987_/ai-is-writing-more-of-the-code-but-developers-are-becoming-responsible-for-more-than-ever-55ni", "published_at": "2026-09-23 03:44:46+00:00", "updated_at": "2026-09-23 04:22:49.879632+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/ai-is-writing-more-of-the-code-but-developers-are-becoming-responsible-for-more", "markdown": "https://wpnews.pro/news/ai-is-writing-more-of-the-code-but-developers-are-becoming-responsible-for-more.md", "text": "https://wpnews.pro/news/ai-is-writing-more-of-the-code-but-developers-are-becoming-responsible-for-more.txt", "jsonld": "https://wpnews.pro/news/ai-is-writing-more-of-the-code-but-developers-are-becoming-responsible-for-more.jsonld"}}