Transforming the Backlog with Agentic AI Coding

AI coding might be creating a new kind of technical debt. --> a Verification debt. And I think this could become a much bigger problem than teams expect. One of the most interesting points I heard recently came from Sonar. They showed research comparing traditionally developed projects with projects using AI coding tools. The interesting part wasn't that AI increased productivity. It did. The interesting part was what happened afterwards. The productivity boost faded after a few months. But code complexity and static-analysis warnings remained elevated. That raises an uncomfortable question: What happens when AI helps us produce code faster than we can verify it? Today the answer is usually: "Developers will review it." I'm increasingly skeptical that this scales. Imagine one developer working with several coding agents simultaneously. Each agent creates changes. Those changes generate PRs. Humans still have to understand whether the code is correct, secure, maintainable and consistent with the architecture. At some point, the bottleneck isn't code generation anymore. It's verification. And there's another problem. The more AI-generated code developers review, the easier it becomes to start rubber-stamping changes that look reasonable. So I think the architecture of AI-assisted development will increasingly need three separate layers: 👉 Guidance — give agents architecture, constraints and relevant context before they write code. 👉 Verification — independently check correctness, security, maintainability and compliance. 👉 Remediation — let agents fix the problems that verification discovers. Then repeat the loop. What I find especially important is the word independently. Having the same type of system generate code and effectively judge its own work isn't much of a control. The verification layer needs to behave more like zero trust: Assume the code could have come from anywhere. Human. Claude. GPT. Cursor. Another agent. Then apply the same deterministic quality gates regardless of who created it. For engineering leaders, I think this changes the AI adoption question. It shouldn't only be: "How much faster are our developers coding?" It should also be: "Can our verification capacity keep up with our code-generation capacity?" Because if AI lets us create software 5x faster but creates a growing backlog of code nobody fully understands or trusts, we haven't eliminated the bottleneck. We've just moved it.

AI Coding Workflow: How Developers Build With AI Without Losing Control AI can generate code in seconds. But fast code is not always good code. The real advantage comes from using AI inside a structured development workflow not treating it like a machine that should build everything from one vague instruction. A strong AI coding workflow begins with the problem. Before generating anything, the developer defines what needs to be built, how it should behave, and what success looks like. Next comes context. The AI needs to understand the existing codebase, project structure, dependencies, coding standards, and technical constraints. Without that context, it may produce code that looks correct but does not fit the system. Then the AI creates a plan. It breaks the task into smaller changes, identifies the files involved, and decides how the solution should be implemented. Only after that should coding begin. The agent edits the necessary files, runs commands, and checks whether the application still works. But generated code should never be accepted simply because it runs. The next stage is verification. Tests must be executed. Errors must be investigated. Security, performance, edge cases, and unintended changes must be reviewed. This is where tools like CodeRabbit become invaluable. Instead of blindly trusting AI generated code, CodeRabbit reviews pull requests, explains the changes made by the AI, identifies potential bugs, highlights security issues, checks coding standards, and suggests improvements before the code is merged. If something fails, the AI uses the feedback to revise its work and test again. Finally, a human reviews the changes before they are merged or deployed. The workflow looks like this Define → Provide Context → Plan → Code → CodeRabbit Review → Test → Human Review → Improve → Deploy This is what separates responsible AI assisted development from blindly copying generated code. AI can increase speed. It can explore solutions, automate repetitive work, and help developers move faster. But the developer still owns the architecture, judgement, security, and final decision. The future of coding is not AI replacing developers. It is developers learning how to direct, verify, and collaborate with AI more effectively. If you’re curious about how I build AI into my software projects, here’s one of my open source implementations https://lnkd.in/evnDDBu4

Proud to share the first Adoption Logic article on using AI coding agents with clear engineering discipline, evidence, and human accountability. If your team is exploring AI-assisted delivery, I’d love to compare notes.

AI coding agents do not remove the need for engineering discipline - they make it more important AI coding agents can be remarkably effective. They can explore a codebase, propose a plan, implement a focused change, run checks, and explain what they found. The difficult part is not getting an agent to write code. The difficult part is knowing what the code is meant to achieve, which decisions are safe to delegate, how to verify the result, and who remains accountable for what goes live. That is why I have been developing a practical approach I call "Governed Specification-Driven Development". The premise is simple: before implementation, make the intended outcome, boundaries, acceptance conditions, and risk level explicit. Then give an agent a small, coherent piece of work. Finally, verify the result independently and record the human decision needed next. 'Outcome -> Specification -> Risk decision -> Bounded slice -> Implementation -> Verification -> Independent review -> Human decision' This is not an argument for slowing teams down with paperwork. A concise specification can remove the repeated clarification that otherwise happens during implementation and review. It is also not an argument for treating AI as a junior engineer that needs constant supervision. The better analogy is a very capable implementation partner operating within clear authority, context, and verification boundaries. Some work is straightforward and reversible. Some work touches data, permissions, payments, production systems, or legal commitments. A mature AI-enabled delivery process should make that distinction visible and route the higher-risk work to an explicit human decision. The approach is deliberately tool-neutral. I am currently applying it first with Codex, but the underlying method is about durable repository artefacts, reviewable delivery slices, and evidence - not a single vendor. Over the next few months I will share practical lessons from building the method, including how to start with one low-risk pilot rather than attempting a company-wide AI transformation. If your engineering team is using coding agents but wants more confidence in scope, review, and delivery evidence, I would be interested in comparing notes.

Your AI coding workflows don't fail because the model is weak; they fail because the human gives the model too much authority before the work has been properly defined. I shared Issue 15 of The Modern Engineer on spec-driven AI-assisted coding and agent control, and the core argument is simple: don't ask an agent to "build the feature" and let it discover the architecture while writing code. Write the spec first. In production systems, implicit decisions become expensive very quickly. When you tell an agent to "add authentication," it might also add password reset, email verification, a new authentication library, global middleware changes, unrelated routing changes, and abstractions nobody asked for. The issue is not always that the code fails immediately. The deeper issue is that the decisions were never owned, reviewed, or made explicit. That is where spec-driven AI coding changes the workflow. A spec is not documentation. It is an execution contract that defines why the work exists, what is allowed, what is forbidden, and how correctness will be validated. If a decision is not in the spec, the agent should not invent it. The strongest AI-assisted coding workflows separate planning from execution, because planning requires exploration while execution requires discipline. The agent should not plan and execute in the same step. A better workflow looks like this: 1. Define the spec. 2. Review the scope. 3. Execute one task. 4. Validate against the spec. 5. Update the spec only when reality requires it. This is how you stop AI agents from drifting: not by writing longer prompts, and not by hoping the model "understands the codebase," but by turning intent, constraints, and boundaries into version-controlled text. In the issue, I show how to structure production-grade AI specs using context, scope, constraints, tasks, verification gates, agent rules, and multi-agent review patterns. The key lesson is this: AI coding agents are not engineers. They are execution engines. The engineering work is deciding what should happen, what must not happen, and what "done" actually means. Reliable AI-assisted coding comes from constraining uncertainty, not amplifying it. Write the spec first, then let the agent execute. Full article: https://lnkd.in/eeP7UwZG --- 📌 Subscribe to The Modern Engineer for production-grade AI Engineering. Real architecture and code. No fluff. 👉 https://www.elliotone.com

𝗧𝗮𝘀𝗸-𝗟𝗲𝘃𝗲𝗹 𝗧𝗼𝗼𝗹𝘀 𝘃𝘀. 𝗧𝗿𝗮𝗷𝗲𝗰𝘁𝗼𝗿𝘆-𝗟𝗲𝘃𝗲𝗹 𝗠𝗲𝘁𝗵𝗼𝗱𝗼𝗹𝗼𝗴𝘆 Most AI coding tools focus on a single task. They ask: "Is this change correct?" This approach has a limit. If you only look at individual changes, you lose sight of the whole project. You cannot see if the system is moving in the right direction. I analyzed three different approaches: Trellis, OpenSpec, and AGE. Here is the breakdown of how they differ. 𝗧𝗵𝗲 𝗧𝗵𝗿𝗲𝗲 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵𝗲𝘀 - Trellis: A productized framework. It gives you 12 preset skills like brainstorming and code checks. It works well if you want to start today. - OpenSpec: A spec-driven framework. It uses a "spec + delta + archive" cycle. It is great for managing incremental changes. - AGE (Attractor-Guided Engineering): A methodology, not a product. It focuses on the entire repository trajectory. 𝗧𝗵𝗲 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹 𝗗𝗶𝘃𝗶𝗱𝗲 The main difference is the organizational unit. 𝟭. 𝗧𝗮𝘀𝗸-𝗟𝗲𝘃𝗲𝗹 (𝗧𝗿𝗲𝗹𝗹𝗶𝘀 & 𝗢𝗽𝗲𝗻𝗦𝗽𝗲𝗰) These tools focus on the single change. They manage a specific task or a specific delta. - They lack a way to maintain the "big picture" of the repository. - They rely on humans to keep the project direction on track. - They do not distinguish between current behavior and the future goal. 𝟮. 𝗧𝗿𝗮𝗷𝗲𝗰𝘁𝗼𝗿𝘆-𝗟𝗲𝘃𝗲𝗹 (𝗔𝗚𝗘) AGE focuses on the whole repository. It uses an "attractor" to define where the code should converge. - It tracks the history of every decision through logs and bug notes. - It uses a promotion ladder to turn errors into automated tools. - It moves from bug note → lesson → prompt → script → lint rule. - It uses independent AI agents for "draft reviews" and "closure audits." This allows humans to step back. 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗠𝗮𝘁𝘁𝗲𝗿𝘀 If you use task-level tools, you might fix a bug today but break the architecture tomorrow. You are just stacking changes. If you use trajectory-level methodology, you are building a system that learns. Every failure becomes a permanent guardrail. You are not just fixing code; you are evolving the engineering process itself. Trellis is for immediate productivity. AGE is for long-term evolution and full AI automation. Source: https://lnkd.in/ga6DNwAr Optional learning community: https://t.me/GyaanSetuAi

People often think that when they use AI coding tools that the code is the product. After rebuilding a massive mono-repo of 5 years worth of code over the last 6 weeks I disagree. AI is changing how we write software. But I think it’s also changing what software engineers are paid to do. For years, the development process looked something like this: 1. Understand the problem. 2. Design the solution. 3. Write the code. 4. Test it. Writing the code was the biggest job. Today, tools like Claude Code can turn a well-defined design into working software in hours. That changes things. The scarce skill is no longer writing code, it’s everything that comes before and after it. I’ve found my workflow now looks more like this: Think What problem are we actually solving? Is there a simpler solution? What are the business rules? Where are the edge cases? Design Challenge the architecture. Question every assumption. Think about performance, security, maintainability and how this feature fits into the wider platform. This is often an iterative conversation with AI, refining the design until it feels right. Generate Now let AI build it which used to be the longest phase. Today it’s often the shortest. Govern This is where many teams underestimate the work. - Review the implementation. - Run automated tests. - Test locally. - Deploy to staging. - Test again. Monitor production. Improve what you learn. This isn’t about checking whether AI wrote good code. It’s about making sure the system behaves as intended. That’s the Red Queen* lesson. When one activity becomes dramatically faster, another becomes more valuable. Coding hasn’t disappeared. It has become cheaper. Good judgement hasn’t become cheaper. It has become more valuable. The engineers who thrive over the next decade won’t necessarily be the ones who write the most code. They’ll be the ones who ask the best questions, design the best systems and create the confidence to ship software quickly without losing control. In the AI era, the product isn’t the code. The product is the quality of the decisions that shape it. *Check the first comment for more similar ideas

The hardest problems are semantic conflicts. "Two agents modify different parts of the system while making incompatible assumptions about how it should evolve." We've already solved this problem in the human world, it's called collaboration. So why is this so challenging in the agentic world? https://orca.space was built on one simple idea: we already know how to scale intelligence through collaboration, we just need a tool that allows us to do it.

Vibe coding lets you build almost anything now. It also lets you build an unbelievable amount of garbage. I lean on AI a lot to build small automations for my work, and it has genuinely changed how much one person can get done in a day. But the longer I do it, the clearer one thing gets: the tool is rarely the hard part. The hard part is knowing exactly what you want and being able to say it cleanly. Here is my honest position. I do not want an AI that makes my decisions for me. I want automations that work the way I work, that follow my patterns and my logic. AI helps me build those, but only as far as I can describe what I actually need. The moment my own thinking is fuzzy, the output is fuzzy too. Garbage in, garbage out has never been more true than it is right now. And this is where I keep hitting the real problem, and it is not a technical one. A lot of people do not actually know what they want. So they communicate it badly, the result misses, and then they are frustrated with the tool or with the person on the other end. In procurement you feel this instantly, because everything eventually comes down to money, and money does not forgive vague. You have to be exact. So I have started putting far more effort into being precise, with AI and with people alike. And when I genuinely do not know something yet, I have learned to pause the conversation instead of filling the gap with a guess. I would rather come back once I actually have the data to say something exact than confuse a person or a system with a half answer that quietly sends everyone in the wrong direction. I think clear communication is becoming one of the most underrated skills of the next few years. As companies shrink their teams and hand more and more tasks to agents, a single misunderstanding no longer stays small. An agent that confidently acts on the wrong instruction can cause real damage before anyone even notices. The technology will keep getting better. The open question is whether we get better at telling it, and each other, what we actually mean. So I am curious how you see it: is clarity a skill we still take far too lightly?

I turned an AI coding meme into reality. You know the one: “I asked AI: migrate my entire codebase to this new pattern and make no mistakes. It worked for hours, created a beautiful architecture, and in the end, nothing worked.” Except this time, it worked. What was supposed to be a quarterly goal was completed with only a few hours of human effort. The key was not a better prompt. It was a better harness. “Make no mistakes” should not be written in your prompt. It should be enforced by your harness. Prompts express intent. Deterministic rules enforce correctness. This means investing heavily in static typing, linter rules, automated tests, architectural boundaries, and repeatable workflows. My migration happened in four stages. First, I built a new module using the target architecture. During that process, I refined the architecture and created the types, tests, and linter rules needed to enforce it. Second, I migrated a few existing modules with the AI agent. I provided detailed guidance, observed where it struggled, and identified edge cases that were not yet covered. From this process, I created a reusable migration skill and strengthened the deterministic checks. Third, I selected a particularly challenging module. The agent migrated almost all of it correctly. I added a few more linter rules and refined the skill again. Finally, I was confident enough to run the migration at scale. I asked the agent to migrate the entire frontend codebase to the new architecture. After several hours of work: - 6,800 files were changed - 200,000 lines were changed - The application was working - All tests were passing Each team reviewed its own modules. They found a few small issues with boundaries and component organization, but nothing that blocked the PR. After the merge, I opened one final PR to update the linter rules and migration skill based on what we had learned. A migration that would normally require several teams and weeks of work was completed with only a few hours of human effort. More importantly, the codebase is now easier for AI to work with. It has fewer competing patterns, clearer boundaries, and stronger automated checks. AI-assisted engineering is not just about generating code faster. It is about building systems where correctness is continuously enforced, allowing both humans and AI to move faster with confidence. In my next post, I’ll go deeper into the practical changes you can make to your harness to enable work like this.