Over the last several months, I have spoken with many developers and engineering teams about how they are using AI for software development.
The conversations usually start with tools. Which model are you using? Do you prefer agent mode? Are you doing specification-driven development? Have you created custom agents? How much of the code is written by AI?
All useful questions. But after a while, I noticed that the teams getting real value were not separated by one model or one workflow. They had understood something more fundamental: AI coding has to be designed as a system.
Giving every developer a coding agent is not a system. It is a capability. To scale it safely, we first need to be clear about what humans continue to own. Then we can ask what new skills engineers need in order to carry those responsibilities in an agentic way of working.
This is the framework I have arrived at from those conversations, from observing teams, and from applying AI coding in my own work. A more detailed version of what happens if you don't have such a methodology is covered in one earlier post here.
A faster car needs good brakes
Let me use a car analogy, because software engineering has apparently not suffered enough car analogies already.
If you build a car capable of going very fast, you need a powerful accelerator. But you also need excellent brakes. Nobody looks at a Formula 1 car and says, "The brakes are slowing it down. Let us remove them for more velocity."
The brakes are what allow the driver to use the speed.
AI coding is similar. Agents, tools and context give us acceleration. Verification, ownership and guardrails give us control. Real software delivery has unclear requirements, legacy systems, production incidents, security boundaries and users who find exactly the path nobody tested.
The objective is not maximum speed at every moment. It is controlled speed across the whole journey.
So let us start with control: what are the core human responsibilities in an Agentic SDLC?
Core human responsibilities in an Agentic SDLC
These are not temporary jobs we retain only until the models become better. They are the responsibilities that keep engineering accountable even as agents take on more of the work.
Build and continuously update context
Agents need access to architecture, requirements, domain knowledge, coding standards and operational lessons. Humans remain responsible for deciding which information is correct and which decisions should guide future work.
Context is not a one-time setup activity. A new feature changes the data model. An incident reveals a missing constraint. A production integration behaves differently from the documentation. If the source of truth is not updated, the agent will continue following the old understanding, usually with great confidence and impressive speed.
AI can help draft and maintain context documents. The team still owns their accuracy. Capturing what changed after every delivery cycle is one of the most important habits in an Agentic SDLC.
Verify AI output
AI output should be treated as a contribution to verify, not a finished result to accept.
Verification includes correctness, security, compliance and product fit. Unit tests, integration tests, static analysis, security scanning and architecture checks provide valuable evidence. But a change can pass all of them and still expose the wrong information, introduce unnecessary complexity or solve the wrong user problem.
This is where engineering expertise matters. The human reviewer should not only ask, "Does the code work?" The reviewer should ask, "Is this the right behavior, does it fit this system, and are the consequences acceptable?"
Maintain cognitive ownership
This is the responsibility I worry about most.
If developers repeatedly accept code they cannot explain, delivery can become faster while the team's ownership of the system becomes weaker. Eventually the application behaves in a way nobody can diagnose without asking another agent to interpret what the first agent generated.
That is not scale. It is dependency.
Maintaining cognitive ownership means understanding the important decisions, being able to diagnose production behavior and recognizing when a confident answer does not fit the architecture or domain. Developers do not need to type every line, but the team must remain capable of owning every outcome.
Work agent-first
Human responsibility does not mean keeping routine execution with humans.
Developers should ask whether an agent can perform the first pass of implementation, analysis, testing, documentation or investigation. Instead of starting with typing, the engineer starts with intent, context, constraints and acceptance criteria.
Working agent-first is not the same as accepting the first agent answer. It means using the agent as the default execution partner while humans direct the work, evaluate trade-offs and verify the result.
Apply guardrails
Important rules should not depend on a developer remembering to include them in a prompt.
Privacy rules, security policies, quality thresholds, approved dependencies, testing expectations and deployment controls should be encoded into the engineering system wherever possible. A useful guardrail is explicit, produces actionable feedback and is difficult to bypass accidentally.
Guardrails exist at more than one level. Some run inside the agent workflow through deterministic hooks. Others already exist in our build and delivery pipelines. We need both.
Deterministic hooks: controls inside the agent loop
Prompts are probabilistic. A clear instruction improves behavior, but it does not guarantee that the model will follow the rule every time. Deterministic controls are useful when "usually" is not a sufficient standard.
Hooks allow teams to run fixed checks at defined points in the agent lifecycle. Depending on the development environment, they can run before or after a tool call, before a change is considered complete, or when an agent attempts a sensitive action.
For example, hooks can:
- block edits to protected files or generated artifacts;
- prevent commands that contain known destructive patterns;
- detect secrets before they enter a prompt, log or commit;
- run formatting, linting or focused tests after a code change;
- require an architecture check when particular modules are modified;
- stop completion when required evidence is missing.
The important distinction is that the agent does not decide whether to run the hook. The control runs because the event occurred. That makes hooks useful for rules that should be consistent regardless of the model, prompt or developer.
Hooks should still be small, fast and understandable. If every tool call launches the entire test suite, developers will find a way around the system. The best hooks provide immediate local feedback while more comprehensive checks run later in CI.
Do not replace the quality system you already have
Agentic development does not make existing engineering controls obsolete.
If the repository already has unit tests, integration tests, code review, static analysis, dependency scanning, secret scanning, security checks and deployment approvals, keep them. These controls are independent of the agent conversation and provide a consistent standard for code written by humans or AI.
In fact, AI makes these checks more valuable. Agents are good at responding to precise tool feedback. A failed test, quality-gate violation or security finding gives the agent a concrete problem to solve instead of relying on another round of general prompting.
I think of the layers this way:
- Instructions and context guide the agent toward the expected solution.
- Hooks enforce fast, deterministic controls during the agent loop.
- Local tests and quality tools verify the change before it leaves the developer environment.
- Pull-request and CI checks provide an independent gate before merge.
- Deployment controls and production monitoring protect the running system and reveal what pre-production checks missed.
No single layer is sufficient. Together they create defense in depth without asking humans to inspect every low-level action manually.
What skills do engineers need?
Once the human responsibilities are clear, the next question becomes practical: what must engineers learn to work this way?
These skills sit on top of software design, coding, testing, security and domain expertise. They do not replace those foundations. They make them usable through agents.
Design agents with reusable skills
I find it more useful to discuss custom agents and agent skills together.
A custom agent packages a repeatable role or workflow. It might turn a feature idea into a structured backlog item, review an API against architecture rules, implement an approved story, investigate a production issue or prepare a release.
The skills give that agent the knowledge required to perform the role well. Every product has local knowledge that a general model will not know: business terminology, architecture decisions, data rules, security constraints and operational lessons.
For example, a billing agent may need skills that explain chargeback rules and authoritative data sources. An identity agent may need account-normalization rules and access boundaries. A review agent may need the team's architecture principles and quality expectations.
The agent defines how to approach the work. Its skills provide what it needs to know.
The engineering challenge is to identify which work is stable enough to standardize and which knowledge should be reusable. A large collection of vaguely different agents creates more confusion, not more capability. Start with repeated work where the inputs, expected output and review criteria are already reasonably clear.
Connect agents through MCP
An agent that can only edit code is useful. An agent that can also read the work item, inspect documentation, run a browser test and check the quality report can complete a much larger engineering loop.
MCP integrations connect agents to tools and enterprise systems. They reduce context switching and allow the agent to work with current evidence instead of whatever the developer remembered to paste into the conversation.
But every connection expands the blast radius. A read-only documentation tool, a browser tool and production database access do not carry the same risk. Engineers need to understand approved servers, least-privilege permissions, authentication, data exposure and which tool actions require confirmation.
Connecting an agent to everything makes a good demo. Connecting it responsibly is the actual engineering skill.
Engineer context
The same model can produce excellent output for one project and generic tutorial code for another. The difference is often the context.
Context engineering is the work of selecting and structuring requirements, architecture, domain knowledge, coding conventions and operational information so the agent receives what matters for the current task.
More context is not automatically better. Giving the agent every document the organization has ever produced is not context engineering. It is document dumping. Useful context is relevant, accurate, current and safe.
Engineers also need to understand context boundaries. Which information belongs in repository instructions? Which knowledge should be loaded as a reusable skill? What should be retrieved only for a specific task? What is too sensitive to send to a model at all?
Design meaningful human involvement
Most teams say they keep a human in the loop. That can mean anything from a serious architecture review to somebody clicking "Approve" because the diff is long and the agent sounds confident.
Human involvement has to be designed according to risk.
Engineers need to decide what the agent can do independently, what evidence it must provide, which actions require approval and who is qualified to approve them. A documentation update, database migration and authorization change should not share the same autonomy level.
The goal is not to place a human in every agent action. That would reproduce the old process with extra waiting. The goal is to place qualified human judgment at decisions where context, consequences and accountability matter.
Design deterministic guardrails
Engineers also need to know when an instruction is enough and when a control must be deterministic.
This includes designing hooks, choosing the right local checks, integrating agent work with the existing CI pipeline and deciding where a hard failure is appropriate. A style preference may belong in context and linting. A restriction on exposing secrets should not depend on model interpretation.
This is a different mindset from prompt writing. The question is not only, "How do I ask the agent to behave?" It is also, "How does the system prevent or detect an unacceptable action when the agent does not behave as expected?"
Fundamentals first, workflow second
One pattern in my conversations with developers is the search for the one correct workflow.
Should everything begin with a detailed specification? Should the agent always create a plan and wait for approval? Should developers use one long-running agent or several specialized agents? There are strong opinions, usually supported by a screenshot of something working once.
My view is that the fundamentals matter more than the workflow label.
Specification-driven development is useful when scope and behavior need careful agreement. Plan-and-execute works well for complex changes where sequence and dependencies matter. An exploratory debugging session may need an agent to inspect evidence and adapt continuously. A small, low-risk fix may need very little ceremony.
Engineers should understand the task, risk and available feedback, then choose the workflow.
The framework provides questions that remain useful across those choices:
- Does the agent have the right context and skills?
- Does it have appropriate access to tools?
- What can it do independently?
- Which deterministic hooks should apply?
- What evidence will verify the result?
- Which independent CI checks must pass?
- Which decisions require qualified human judgment?
- How will this cycle update the context for the next one?
Once those questions have good answers, teams can adapt the process without losing the engineering controls.
No comments:
Post a Comment