How do software engineering organizations adopt agentic engineering practices into traditional engineering standards?
How do humans stay locked in and aligned with the engineering and architectural direction of a project, while deploying agents to do the work?
How do engineers ensure agents don’t drift off path during implementation, and ensure governance stays intact?
How do we let agents do real software engineering work without letting the project drift?
I published an agentic software development lifecycle adoption workbench for this problem.
It is built for software teams using agents in delivery without losing engineering control.
It helps teams move from intake to product shape, then into current-state discovery and workflow mapping.
From there, it carries the work into architecture options, target architecture, and agentic engineering.
It also gives teams a way to think through testing, security, governance, and production readiness.
The workbench includes roadmap planning, templates, and prompts so the ideas can move into repeatable team practice.
This post is the argument behind that workbench. The guide is the operating surface. This essay explains why I think software engineering standards matter more, not less, in agentic delivery.
The software development lifecycle has to adapt
On one end of the hype cycle, we have one-shot vibe-coded applications. They are useful for flushing out ideas, generating solid product features, and creating business requirement artifacts. They do not stand up to the requirements of production systems.
On the other end, development teams who have not fully adopted agentic engineering are too slow to keep up with the competition. Executive leaders expect products and features to be delivered at the speed of a vibe-coded greenfield project. That expectation breaks down when you are supporting enterprise-grade applications serving hundreds, thousands, or more end users.
The logical move is to bring traditional software engineering practices forward into the agentic era. But the trick is not to bring all the heavy maintenance of too much documentation or over-engineered architecture into the workflow. That becomes another maintenance nightmare. Incorporating an agentic approach can ease this burden.
I also think the traditional software development lifecycle must adapt to the agentic era. Thoughtworks has started writing about this as an agentic software development lifecycle shift.
That shift has real implications for teams, governance, culture, and how software organizations structure the work.
Their writing on moving beyond vibe coding and on spec-driven development points in the same direction: agents need disciplined methods, structured context, and clear engineering artifacts if they are going to do production-grade work.
Revisiting this topic, a lot of the conversation around AI and software development moves quickly to speed. Agents can write code faster. They can also generate tests, refactor classes, and review pull requests.
They can summarize logs and document systems.
But the more fundamental question is whether agent-driven work is still moving in the right direction.
Software engineering has always required more than writing code. A good team has to understand the domain, the constraints, the architecture, and the security posture.
The team also has to understand the data model, the customer, and the outcome.
That does not go away because we have agents. In some ways, it becomes more important.
Because now we are not only managing human implementation. We are also managing machine-assisted implementation.
That means the human engineers have to stay locked in.
I think this is where traditional software engineering practices become even more valuable.
Engineering artifacts become operating instructions
Requirements, design specs, and architecture decision records are not just process artifacts.
The same is true for acceptance criteria and test plans.
The same is true for interface contracts, data models, and runbooks.
They are operating instructions for the system and for the people changing it.
If source code is no longer the only thing being evaluated, engineering teams need a solid understanding of the artifacts that explain what the system is supposed to do, why it is shaped the way it is, and what boundaries cannot be crossed.
It turns out that these are also exactly what agents need to stay within the guardrails of a system or product implementation. This work feeds into an organization’s intellectual property and documentation as infrastructure, which I wrote about previously.
These documented operating instructions help humans stay clear on what is being built. Not just at the beginning, but throughout the development process through to production support.
They also give agents the context they need to build out systems and products, while staying aligned to the organization’s unique environment and business dispositions.
If we ask an agent to build without that frame, we should not be surprised when it wanders. It may produce working code that misses the domain. It may solve the local task while violating the architecture. It may add a dependency that creates risk. It may change behavior without understanding why that behavior existed.
I think most people naturally credit this as an agent problem: “this AI stuff doesn’t work, it’s not ready,” when it is actually an engineering governance problem.
The practical answer, at least in my mind, is not to reject agents. It is also not to throw away the standards that made software reliable in the first place. The answer is to make those standards useful for both people and agents.
That changes how I think about the artifacts engineering teams already use:
- A specification document becomes context an agent can use, not just something the team writes before development.
- Acceptance criteria become boundaries for generated code, not just a checklist for a story.
- Business and architecture decision records explain why the system works the way it does, not just what happened in the past.
- Test plans prove that agent-produced work still matches the intended behavior, not just that quality assurance has an artifact.
- Runbooks tell people and agents how the system should be supported after the code reaches production.
This is the shift I am trying to understand more deeply.
Agentic work needs an operating model
Agentic engineering should not mean vibe coding. It should not mean letting the agent run until something appears to work. It should mean humans are clearer about the direction, clearer about the constraints, and clearer about the review points.
Agents can move fast, but engineers still own the judgment and accountability. Architects still own the shape of the system. The team still owns the outcome.
That means agentic work needs a practical operating model.
Before the agent starts, the team should know what problem is being solved and what files or services are in scope.
The team should also know what standards apply, what tests must pass, and what tradeoffs are acceptable.
During implementation, the team needs checkpoints. After a development cycle, the team needs review, test evidence, and a clean explanation of what changed.
The future of software engineering may not be less disciplined. It may require more discipline, because the tools can now act faster than our ability to casually inspect the work.
Keep the standards and make them usable
So the work now is to bring these two worlds together. At least that is my perspective.
Keep the engineering standards, but make them agent-readable. Teach agents to work inside the standards your organization already depends on.
Use agents to move faster, while keeping humans responsible for direction and architecture.
Keep humans responsible for judgment and final accountability.
This is where I see the opportunity for organizations that want to move ahead with agentic engineering.
That is also why I built the agentic software development lifecycle adoption workbench: to give teams a practical place to start turning this discipline into repeatable work.