{"slug": "ai-can-write-code-faster-than-i-can-understand-it-heres-my-rule-for-fixing-that", "title": "AI Can Write Code Faster Than I Can Understand It - Here’s My Rule for Fixing That", "summary": "A developer has introduced a \"knowledge debt\" problem in AI-assisted coding, where AI agents can improve a codebase faster than the engineer can understand it. To counter this, the developer established a 2:1 rule: for every two hours of AI-generated code, one hour must be spent manually consolidating the result through reading, testing, documenting, and modifying the code. The rule aims to protect the engineer's ownership and understanding of the code, preventing dependency on AI for future changes.", "body_md": "AI coding agents are useful.\n\nBut if the codebase improves faster than your understanding, you create a new problem:\n\nKnowledge debt.\n\nMy current rule is simple:\n\nFor every 2 hours of AI-agent generation, I spend 1 hour manually consolidating the result.\n\nThat means reading, testing, documenting, and modifying the code myself before moving on.\n\nAI can accelerate the work.\n\nBut I still need to own the result.\n\nI had a strange moment after spending around 7 hours with Codex modernising an old PHP/MySQL project.\n\nOn paper, the session had gone well:\n\nThis was exactly what I wanted.\n\nBut there was one uncomfortable problem:\n\nI did not fully understand what had just been built.\n\nThat is the strange part of AI-assisted development.\n\nYou can look at your own repository and see progress everywhere, while also feeling a gap underneath it.\n\n```\nRepository progress\n      ↓\nCleaner structure\nMore automation\nMore tests\nBetter tooling\n      ↓\nBut weaker ownership\n```\n\nThat was the moment I realised the real risk was not that AI had written bad code.\n\nThe risk was that AI had written useful code before I had properly caught up.\n\nThis article is not anti-AI.\n\nThe problem is not AI.\n\nThe problem is unreviewed acceleration.\n\nIf the output grows faster than your understanding, you do not just gain productivity.\n\n**You also create knowledge debt.**\n\nBefore AI coding agents, progress was slower.\n\nThat was frustrating, but it had one advantage:\n\nI usually understood most of what I had written, because I had struggled through it manually.\n\nWith AI, the relationship changes.\n\nThe codebase can improve faster than your understanding.\n\nThat creates a new kind of debt:\n\nAI-generated code can reduce technical debt in the repository while increasing knowledge debt in the engineer.\n\nKnowledge debt looks like this:\n\nSymptom |\nWhat it means |\n|---|---|\n| 🐛 I cannot confidently debug it | I do not understand the failure modes |\n| 🧠 I cannot explain the design | I do not understand the trade-offs |\n| 🔁 I need AI for every change | I have become dependent |\n| 🧪 I do not understand the tests | I do not know what is actually protected |\n| 🎤 I cannot explain it in an interview | It is not portfolio-ready |\n\nThat last point matters.\n\nA portfolio project is only valuable if I can explain it under questioning.\n\nIf I cannot describe the architecture, trade-offs, tests, risks, and changes I personally validated, then it is not really my project yet. It is AI-assisted output sitting in my repository.\n\n**That does not mean AI should not be used.**\n\nIt means AI usage needs discipline.\n\nThis is the distinction I had to make:\n\nReview checks the output.\n\nConsolidation protects the engineer.\n\nThey are related, but they are not the same thing.\n\nReview asks |\nConsolidation asks |\n|---|---|\n| Does this code look acceptable? | Can I work with this code independently? |\n| Do the tests pass? | Do I understand what the tests prove? |\n| Does the diff look reasonable? | Can I explain why the change works? |\n| Is anything obviously broken? | Can I debug it without AI? |\n| Can this be merged? | Do I actually own this? |\n\nA review might catch obvious problems.\n\n**Consolidation goes deeper.**\n\nIt means manually rebuilding ownership after AI has accelerated the output:\n\nThat is the difference.\n\n**Review is quality control.**\n\n**Consolidation is skill protection.**\n\nMy current rule is simple:\n\nFor every 2 hours of AI-agent generation, I spend 1 hour manually consolidating the result.\n\nThat means if I spend 7 hours using Codex, I owe the project roughly 3 hours of consolidation.\n\nThis is not punishment.\n\nIt is skill protection.\n\nThe goal is not to slow everything down for the sake of it.\n\nThe goal is to make sure the speed does not come at the cost of ownership.\n\nThe 2:1 ratio gives me enough AI usage to benefit from acceleration, but enough manual work to keep my understanding from falling too far behind.\n\nAI can help me move faster.\n\nBut I still need to remain the engineer responsible for the result.\n\nConsolidation is not passive reading.\n\nIt is active ownership.\n\nStep |\nWhat I do |\nWhy it matters |\n|---|---|---|\n1 |\nRead the code manually | Understand the actual implementation |\n2 |\nRun the tests myself | Understand what is protected |\n3 |\nModify one thing without AI | Prove I can work independently |\n4 |\nDocument the architecture | Turn vague understanding into clear explanation |\n5 |\nUse AI as a tutor | Reduce knowledge debt instead of creating more |\n\nExpand on Consolidation\n\nThe first step is simple, but easy to skip.\n\nRead the code.\n\nNot just the summary.\n\nNot just the AI explanation.\n\nThe actual code.\n\nI want to understand:\n\nThe goal is to trace at least one full execution path from start to finish.\n\nFor example:\n\n```\nRequest comes in\n   ↓\nRoute/controller handles it\n   ↓\nService layer processes logic\n   ↓\nRepository/database layer is called\n   ↓\nResponse is returned\n```\n\nIf I cannot trace the flow, I do not understand the change yet.\n\nIt is not enough to see that CI passed.\n\nI want to run the tests locally and understand what they actually prove.\n\nQuestions I ask:\n\nThis matters because AI can generate tests that look convincing but only prove shallow behaviour.\n\nA passing test suite is useful.\n\nBut a test suite I understand is much more valuable.\n\nThis is the most important anti-atrophy step.\n\nI force myself to make at least one small manual change.\n\nExamples:\n\nThis proves that I am not just observing the code.\n\nI can actually work with it.\n\nMy rule is:\n\n> If I cannot safely modify the code without AI, I do not fully own it yet.\n\nThat does not mean I will never use AI again on that project.\n\nIt means I should be capable without it.\n\nAI should be acceleration, not dependency.\n\nThis is where vague understanding becomes clear understanding.\n\nAfter a large AI-assisted change, I try to write a short explanation of:\n\nFor example:\n\n```\nBefore:\n- Logic, database access, and rendering were tightly coupled.\n- Testing was difficult because most behaviour depended on direct database access.\n- The project had limited separation between application concerns.\n\nAfter:\n- Services handle business logic.\n- Repositories handle persistence.\n- Tests protect critical behaviours.\n- CI/CD validates changes before merge.\n- Docker provides a more reproducible development environment.\n```\n\nThis is especially important for portfolio projects.\n\nIf I cannot document it, I probably cannot explain it properly in an interview.\n\nAnd if I cannot explain it in an interview, the project is not doing its job.\n\nDuring consolidation, I try not to ask:\n\n> Add the next feature.\n\nInstead, I ask:\n\n> Explain this file line by line.\n\n> What assumptions does this code make?\n\n> Where could this fail?\n\n> What tests are missing?\n\n> What would you ask me in a code review?\n\nThat changes the role of AI.\n\nIt stops being a code factory and becomes a reviewer, tutor, and sparring partner.\n\nThis is where AI becomes very useful for learning.\n\nThe same tool that can create knowledge debt can also help reduce it, depending on how it is used.\n\nAfter a long AI-agent session, I do not want to rely on vibes.\n\nI want a repeatable checklist.\n\nThe goal is simple:\n\nBefore I generate more code, I need to prove I understand what was already generated.\n\n```\n## AI Agent Consolidation Checklist\n\n### 🔍 Scope Review\n- [ ] I reviewed every file changed by the AI.\n- [ ] I understand the purpose of each new file.\n- [ ] I understand the main execution flow.\n- [ ] I identified any code I do not yet understand.\n\n### 🧪 Test Review\n- [ ] I ran the test suite locally.\n- [ ] I understand what each test validates.\n- [ ] I added or modified at least one test manually.\n- [ ] I identified the highest-risk untested behaviour.\n\n### 🛠️ Manual Ownership\n- [ ] I made at least one small manual code change.\n- [ ] I can explain why the change works.\n- [ ] I can revert or debug the change without AI.\n\n### 📝 Documentation\n- [ ] I documented the architecture in my own words.\n- [ ] I wrote a before/after summary.\n- [ ] I updated README or project notes if needed.\n\n### 🎯 Portfolio Readiness\n- [ ] I can explain the change in an interview.\n- [ ] I can explain what AI helped with.\n- [ ] I can explain what I personally reviewed or changed.\n- [ ] I can describe what I learned.\n```\n\nThis checklist is not about slowing AI down for no reason.\n\nIt is about converting generated output into owned knowledge.\n\nAI generation creates output.\n\nHuman consolidation creates skill.\n\nMy principle is simple:\n\nAI can draft infrastructure and automation, but humans must own the blast radius.\n\nWhen infrastructure is codified, code review is not just about correctness.\n\nIt is about operational safety.\n\nThis rule matters for application code.\n\nBut it matters even more when the “code” changes infrastructure, operating systems, identity, networking, or security controls.\n\nWhy?\n\nBecause the blast radius changes.\n\nWith application code, partial understanding can create:\n\nThat is bad.\n\nBut with infrastructure and IT automation, partial understanding can change the environment itself.\n\n```\nAI-generated automation\n      ↓\nTerraform / Ansible / PowerShell / Bash / Kubernetes / CI/CD\n      ↓\nCloud resources, servers, laptops, networks, identities, policies\n      ↓\nReal infrastructure or OS-level changes\n      ↓\nPotential production impact\n```\n\nThat is a very different risk profile.\n\nA bad helper function might break a feature.\n\nA bad infrastructure script might:\n\nFor example, imagine asking AI to produce a PowerShell script to harden Windows registry settings.\n\nOn the surface, that sounds useful.\n\nBut if I do not understand every registry path, service change, permission change, and file operation, that script could move from “hardening” to “breaking the operating system” for thousands of devices very quickly.\n\n```\nAI-generated hardening script\n      ↓\nRegistry / services / permissions / system files\n      ↓\nApplied across endpoints or servers\n      ↓\nBoot failure, broken login, disabled services, outage\n```\n\nThat is why “mostly understood” is not good enough for infrastructure or systems automation.\n\nThe minimum standard should be:\n\nIf this code can change infrastructure, identity, networking, security, operating system behaviour, or data access, I need to understand exactly what it does before I run it.\n\nFor IaC and IT automation, consolidation is not just a learning exercise.\n\nIt is an operational safety control.\n\nApplication code:\n\nCan I understand the behaviour?Infrastructure and systems automation:\n\nCan I understand the blast radius?\n\nI do not think there is anything wrong with using AI in portfolio projects.\n\nIn modern engineering, avoiding AI completely may become unrealistic.\n\nThe issue is not whether AI helped.\n\nThe issue is whether I still own the result.\n\nThere is a big difference between these two positions:\n\nWeak framing |\nStrong framing |\n|---|---|\n| “AI built this for me.” | “I used AI to accelerate parts of the implementation.” |\n| “I accepted what it generated.” | “I reviewed, tested, modified, and documented the result.” |\n| “The project works.” | “I can explain how and why it works.” |\n| “I need AI to change it.” | “I can work on it independently.” |\n\nThat distinction matters.\n\nEmployers may increasingly expect engineers to use AI tools, but they still value:\n\nA stronger portfolio description would be:\n\n```\nAI-assisted legacy modernisation project.\n\nUsed Codex to accelerate scaffolding and refactoring,\nwhile retaining ownership through \n- manual review\n- tests\n- CI/CD validation\n- documentation\n- post-generation consolidation\n```\n\nThat is honest.\n\nIt does not pretend AI was not involved.\n\nBut it also shows engineering discipline.\n\n**I do not want to hide AI usage.**\n\n**I want to prove that I used it properly.**\n\nAI becomes harmful when it replaces the struggle that creates understanding.\n\nFor me, these are the warning signs:\n\nWarning sign |\nWhat it suggests |\n|---|---|\n| 🚫 I accept code I cannot explain | I am trusting output instead of understanding it |\n| 🧯 I cannot debug without asking AI | I do not understand the failure modes |\n| ➕ I keep adding features instead of reviewing changes | I am stacking knowledge debt |\n| 🧪 The tests pass, but I do not know what they prove | I may have false confidence |\n| 🧱 I cannot draw the architecture from memory | I do not understand the system shape |\n| 😬 I feel anxious when AI is unavailable | AI has become a dependency |\n| 📚 I stop reading documentation | I am outsourcing learning |\n| 🧠 I stop forming my own design opinions | I am losing engineering judgement |\n\nThat is when AI stops being an accelerator and starts becoming a dependency.\n\nThe danger is not that AI makes you productive.\n\nThe danger is that it can make you look productive while quietly weakening your understanding.\n\nThat is the trap I am trying to avoid.\n\nThe workflow I am **not aiming for**:\n\n```\nPrompt → accept → prompt again → accept again\n```\n\nThat is how *knowledge debt* stacks up.\n\nA healthier loop looks like this:\n\n```\nHuman defines architecture and constraints\n      ↓\nAI drafts implementation\n      ↓\nHuman reviews the diff\n      ↓\nHuman runs tests and tools\n      ↓\nHuman manually changes one part\n      ↓\nHuman documents the result\n      ↓\nAI is used as reviewer / tutor\n      ↓\nNext generation cycle begins\n```\n\nThe shorter version:\n\n```\nDesign manually\n      ↓\nGenerate selectively\n      ↓\nReview deeply\n      ↓\nTest automatically\n      ↓\nDocument clearly\n      ↓\nOwn the result\n```\n\nThis gives AI a useful place in the workflow.\n\nIt is not banned.\n\nIt is not blindly trusted.\n\nIt is used deliberately.\n\nThat is the difference.\n\nAI agents are not going away.\n\nAnd honestly, I do not want them to.\n\nThey are useful.\n\nThey can accelerate boring work, suggest patterns, create tests, explain unfamiliar code, and help modernise old projects faster than I could manually.\n\nBut speed has a cost if I do not deliberately consolidate afterwards.\n\nMy current rule is simple:\n\nFor every 2 hours of AI-generated progress, I spend 1 hour rebuilding ownership.\n\nThat means:\n\nThe goal is not to code slower.\n\n**The goal is to make sure I am still an engineer, not just the person pressing accept.**\n\nAI should accelerate my learning curve, not outsource it.", "url": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-understand-it-heres-my-rule-for-fixing-that", "canonical_source": "https://dev.to/safesploit/ai-can-write-code-faster-than-i-can-understand-it-heres-my-rule-for-fixing-that-7d", "published_at": "2026-05-29 13:26:47+00:00", "updated_at": "2026-05-29 13:43:22.306853+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-products", "ai-ethics", "ai-safety"], "entities": ["Codex"], "alternates": {"html": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-understand-it-heres-my-rule-for-fixing-that", "markdown": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-understand-it-heres-my-rule-for-fixing-that.md", "text": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-understand-it-heres-my-rule-for-fixing-that.txt", "jsonld": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-understand-it-heres-my-rule-for-fixing-that.jsonld"}}