AI Is Writing More of the Code — But Developers Are Becoming Responsible for More Than Ever

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.

AI is writing more code. That part is obvious now. Developers can ask an agent to: And in many cases, it works surprisingly well. But something else is happening at the same time. Developers are writing less of the code, while becoming responsible for more of it. That is the part I think we are underestimating. Because when production breaks at 2 AM, nobody is going to ask: “Which model generated this function?” They are going to ask: “Who owns this system?” And the answer is still us. A traditional development workflow looked something like this: Understand requirement ↓ Design solution ↓ Write code ↓ Test it ↓ Review it ↓ Deploy it ↓ Maintain it The developer touched almost every stage. That had problems. It was slower. It required more manual work. But there was one big advantage: The person responsible for the code usually understood how it was created. Now the workflow is changing. Understand requirement ↓ Ask AI to plan ↓ AI writes implementation ↓ AI writes tests ↓ AI fixes errors ↓ AI reviews code ↓ Developer approves ↓ Production Look carefully at where the human appears. Sometimes the developer is only deeply involved at the beginning and the end. That creates a strange new situation. The developer may be responsible for: Yet the developer still owns the result. This is the mistake I think teams need to avoid. AI-generated code can make something feel less like your responsibility. It is easy to think: “The agent generated it.” But production systems do not care who typed the code. If you merge it, approve it, or deploy it, it becomes part of the system you own. That means you are still responsible for questions like: AI can help answer these questions. But it cannot remove your responsibility for them. This becomes especially dangerous when AI writes both the code and the tests. Imagine this: Requirement ↓ AI misunderstands requirement ↓ AI writes implementation ↓ AI writes tests for its interpretation ↓ All tests pass Technically: Green CI. Practically: Wrong feature. This is one of the most important things developers need to remember in AI-assisted development. Tests can prove that code behaves according to a certain expectation. They cannot automatically prove that the expectation itself was correct. If the same model creates both the implementation and the test, they can share the same misunderstanding. That is why human review still matters at the requirement level. The developer role is slowly changing from: Write Test Debug to something closer to: Define Constrain Delegate Inspect Verify Approve Own That is not necessarily bad. In fact, it can be incredibly productive. But it requires a different skill set. The best developer may no longer be the person who can type code fastest. It may be the person who can: Those are engineering skills, not typing skills. This is where I think the real risk begins. Suppose an AI agent adds a feature across 15 files. It modifies: Everything passes. You review the diff quickly. You merge. Then two months later, something breaks. Now you need to answer: Why was this implemented this way? But maybe nobody knows. The AI session is gone. The reasoning was never documented. The developer who approved it only reviewed the output. This is how teams can slowly build systems that work but are no longer deeply understood . We already talk about technical debt. But AI introduces something slightly different. I think of it as: Technical debt is often: “We know this code is messy, but we shipped it anyway.” Understanding debt is: “We own this code, but nobody fully understands why it works this way.” That can be even more dangerous. Because messy code is visible. Missing understanding is harder to detect. Everything may look fine until something unusual happens. One simple way to reduce this problem is to stop giving agents enormous tasks. Compare these two prompts. Bad: Build the full subscription system. Better: Analyze the current billing architecture. Explain which files need to change. Do not modify code yet. Then: Implement only the subscription data model. Do not change unrelated files. Add the billing service using the existing service pattern. Add tests for the new behavior. Smaller tasks create smaller diffs. Smaller diffs are easier to understand. And code that is easier to understand is easier to own. One of the most useful changes you can make is simple: Ask the AI to explain what it plans to do before it changes anything. For example: Before writing code: 1. Explain the current architecture. 2. List the files you plan to change. 3. Explain why each change is needed. 4. Identify possible risks. 5. Wait for approval before implementation. This gives you a chance to catch bad direction early. Fixing a bad plan is cheap. Fixing 800 lines generated from a bad plan is not. Traditional code review often focuses on lines. js + const result = await processPayment But with AI-generated code, the more important review may be: Why is payment processing happening here? That is a different level of review. Instead of only asking: Is this line correct? Ask: Should this responsibility live in this module? Instead of: Does this function compile? Does this architecture make sense? Does the test pass? Is this testing the right behavior? AI is making syntax cheaper. That means developers need to spend more attention on decisions. This rule becomes much more important in the AI era. You do not need to memorize every line. But you should be able to explain: If someone asks: “Why does this work this way?” and your answer is: “The AI generated it.” That is not enough. Once it is merged, it is your system. AI is extremely good at saving developers from repetitive work. That is where it can create huge value. Let it help with: But be careful when the AI starts generating: The higher the blast radius, the more human understanding should increase. Not decrease. If AI made an important design choice, capture the reason. Not this: // Process the payment processPayment ; But something like: // We process payment before creating the final order because // failed payments must not create confirmed inventory reservations. That tells the next developer why the code exists. Architecture Decision Records can also help for larger choices. The AI session will disappear. The reasoning should not disappear with it. There is another interesting effect here. The more code AI writes, the more valuable debugging becomes. Because when generated code fails, someone still needs to understand: AI may help investigate. But a developer who does not understand the system will struggle to know whether the AI's explanation is correct. That is why I think debugging may become an even more important skill in the AI era. Writing code is becoming easier. Understanding why a system is broken is not. Prompt ↓ Generate ↓ Tests pass ↓ Merge Try this: Define requirement ↓ AI analyzes existing system ↓ AI proposes plan ↓ Developer reviews plan ↓ AI makes small change ↓ Developer understands diff ↓ Tests run ↓ Failure cases reviewed ↓ Architecture reviewed ↓ Merge The AI is still doing a lot of work. But the developer remains connected to the reasoning. That is the important part. Before merging, ask: If not, keep reviewing. Not just the test. The real requirement. Look for hidden assumptions around data, APIs, users, permissions, and infrastructure. Network timeout? Database error? Duplicate request? Partial write? Unexpected input? Because somebody will eventually maintain it. Maybe you. This is probably the most important idea. AI can reduce: typing boilerplate implementation time repetitive work But it does not automatically reduce: responsibility risk ownership maintenance production consequences In fact, AI may increase the amount of software a developer is responsible for. One engineer may soon oversee the amount of code that previously required several people to produce. That makes engineering judgment more important, not less. For years, software development was strongly associated with writing code. Now code itself is becoming easier to produce. So the valuable skills move upward. Understanding the problem. Choosing the architecture. Defining constraints. Recognizing risk. Reviewing decisions. Debugging failures. Protecting maintainability. Taking ownership. Those things are much harder to automate completely. AI may write more and more of our code. That is probably going to continue. But there is a dangerous assumption hiding behind that productivity: If AI writes the code, AI owns the consequences. It doesn't. You do. The future developer may write less code personally. But they may be responsible for more code, more systems, and more decisions than ever before . So maybe the most important question in AI-assisted development is no longer: “Can the AI build this?” It is: “If I approve this, do I understand it well enough to own it?” Because generating code is becoming cheap. Owning software is not.