Francisco Silvério

Posted on Oct 17

Agentic Development as a Process, Not Throwaway Prompts

#ai #claude #softwareengineering #agents

Put five engineers on the same team, give them the same coding agent, and within a month you will have five different agentic workflows: a private prompt library, a rules file that never leaves a laptop, a clever skill nobody else knows exists. Each engineer is faster than before. The team is not, because the problem was never the tool. It was the process, or rather the absence of one.

A team's agent setup (its rules, skills, connectors and quality gates) is shared engineering infrastructure, and it deserves to be designed, versioned and reviewed like any other part of the delivery system. Its purpose is not to remove the engineer, but to move the engineer's judgment to where it matters most. The examples use Claude Code, but every layer maps to open standards that Cursor, Codex and Windsurf support too.

1. From Prompts to a Process

A prompt is a one-time artifact. It lives in a single session, carries the assumptions of whoever wrote it, and disappears when the context window closes. Even an excellent prompt does not scale: nobody else can review it, test it, or improve it.

A process is the opposite. It is:

Shared: every engineer runs the same workflow against the same definitions.
Versioned: it lives in a repository, so every change has history and an author.
Reviewed: changes go through pull requests, like any other code.
Compounding: a fix made once benefits every future session, for every engineer.

We already accept this logic for CI/CD. Nobody expects each engineer to deploy with a personal script; the pipeline is a team asset with owners and a review process. Agentic workflows deserve the same treatment, and the data suggests they need it.

Google's DORA research on AI-assisted software development describes AI as an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. The 2025 report also found that AI adoption now improves delivery throughput while still correlating negatively with delivery stability. Speed without a shared quality system turns into instability downstream.

DORA's follow-up work, the AI Capabilities Model, identifies seven practices that determine whether AI helps or hurts an organization. Three of them read almost like a specification for the process in this article:

A clear and communicated AI stance: engineers know which tools and practices are expected. Ambiguity is a risk, not a freedom.
AI-accessible internal data: agents are connected to internal documentation and systems instead of working from prompts alone.
Working in small batches: a deliberate counterweight to agents' tendency to produce large changes that are hard to review and test.

2. The Reference Pipeline

Setting up an agentic process starts with mapping everything an engineer usually does by hand. Fetching context for the agent or babysitting it through every step is not the engineer's job. Building the skills, tools and connectors that let it work on its own between the human checkpoints is. Here is what that workflow could look like for a typical development team:

flowchart TD
    T["Ticket in the tracker"] --> I["Ingest"]
    I --> RD[("Requirements doc")]
    RD --> G1{{"Engineer validates requirements"}}
    G1 --> P["Plan"]
    P --> BL[("Versioned backlog of slices")]
    BL --> G2{{"Engineer approves the plan"}}
    G2 --> S["Spec for one slice"]
    S --> G3{{"Engineer approves the spec"}}
    G3 --> X["Implement"]
    X --> V["Verify: typecheck, tests, checks"]
    V -- fail --> X
    V -- pass --> AR["Adversarial review agents"]
    AR -- findings --> X
    AR -- clear --> PR["Pull request"]
    PR --> G4{{"Engineer reviews and merges"}}

Each stage produces an artifact that the next stage consumes, and each artifact is a file in the repository, not a message lost in a chat history. The hexagons are the human gates; we will come back to them in section 4.

Ingest. A connector reads the ticket and turns it into requirements: the problem, the acceptance criteria, the stakeholders, and where each requirement came from. A requirement with no source is one the agent invented.
Plan. Requirements become small slices in a versioned backlog, each with its dependencies and its own definition of done. If the agent only ever implements one slice, it cannot produce a 3,000-line pull request.
Implement. For each slice, the agent writes a short spec (approach, files, edge cases, tests) and waits for the engineer's approval. Correcting a spec costs a minute; correcting finished code costs a review cycle.
Verify. Typecheck, tests and checks run until they pass, and only then is a pull request opened. "Done" is defined by the pipeline, not claimed by the agent.
Review. Separate reviewer agents, each focused on one dimension (requirements, code quality, delivery plan), try to break the work before a human sees it. This is Anthropic's evaluator-optimizer pattern: the reviewers produce findings, and a human still decides what to act on.

Traceability ties the stages together. Each slice records which acceptance criteria it covers, so every criterion can be traced to a test:

id: S-03
title: Paginated order history endpoint
depends_on: [S-01, S-02]
covers: [AC-2, AC-4]
definition_of_done:
  - Returns orders for the authenticated customer only
  - Cursor-based pagination with a maximum page size of 50
  - Integration tests cover AC-2 and AC-4, including the empty state
  - Typecheck, lint and the full test suite pass
status: ready

That trace matters most for tests. A suite written by the same agent that wrote the code tends to confirm what the code does, not what the requirement says.

3. The Toolkit, Layered by How Strongly It Holds

The pipeline is executed by a toolkit with distinct layers. The most useful way to organize them is not by feature, but by how strongly each one constrains the agent.

flowchart BT
    R["Rules: advisory<br/>conventions, boundaries, vocabulary"] --> SK["Skills: procedural<br/>ingest, plan, implement, review"]
    SK --> C["Connectors: grounded<br/>trackers, docs, CI, internal systems"]
    C --> E["Enforcement: deterministic<br/>hooks and CI gates that must pass"]

Rules (advisory). Conventions, architectural boundaries and domain vocabulary, in CLAUDE.md or AGENTS.md. Anthropic's own docs describe them as advisory, so keep them short: every extra line dilutes the others.
Skills (procedural). Each pipeline stage is a skill the agent loads only when the task calls for it. This is where the team's process actually lives.
Connectors (grounded). MCP servers for trackers (Jira, Linear), knowledge bases (Confluence, Notion), source control and CI (GitLab, GitHub), business systems (Salesforce) and other internal teams' services. Requirements then come from the source, not from someone's paraphrase.
Enforcement (deterministic). Hooks and CI gates for anything that must happen: formatting, blocking destructive commands, refusing "done" while tests fail. Guarantees go in hooks; preferences go in rules.

The toolkit lives in a repository and changes through pull requests, either as a committed configuration directory or, at scale, as plugins published through an internal marketplace:

.
├── AGENTS.md                 # shared rules, read by most agents
├── CLAUDE.md                 # symlink or one-line import of AGENTS.md
├── .mcp.json                 # team connectors
├── .claude/
│   ├── settings.json         # hooks and permissions, committed
│   ├── skills/
│   │   ├── ingest/
│   │   ├── plan/
│   │   ├── implement-slice/
│   │   └── review/
│   └── agents/               # reviewer subagents
└── docs/
    ├── requirements/         # output of ingest
    └── backlog/              # versioned slices

None of this locks a team into one vendor. Rules map to AGENTS.md, skills to the Agent Skills standard, and connectors to MCP: open formats that most coding agents now read. The exception is enforcement. Agent-level hooks are tool-specific, so the gates that must hold regardless of who, or what, wrote the code belong in CI.

4. The Engineer at Each Gate

Look at the pipeline again and count where a human appears. Not at every step: at four gates. That is the point. The process removes the engineer from the work that does not need judgment, so that judgment can be applied fully where it does.

The reviewer role is increasingly automated; the review itself, the judgment of whether the software is right for its purpose, is not. And accountability does not delegate: the name on the approval belongs to a person.

The research points the same way. A 2026 literature review on software engineering for agentic systems frames the engineer's enduring value around four competencies: intent articulation, systematic verification, multi-agent orchestration and accountable human judgment. None of them is typing code. All of them are engineering.

5. You Won't Be Replaced. Unless You Stop Learning.

Every shift in tooling triggers the same prediction. When deployments moved from manual runbooks to CI/CD pipelines, the engineers who stayed relevant were not the fastest at running scripts by hand; they were the ones who learned to build pipelines.

When infrastructure moved from on-premise racks to cloud APIs and infrastructure as code, the people who struggled were not the ones whose tasks disappeared. They were the ones who refused to learn the new abstraction.

Agentic development follows the same pattern, at a larger scale. The tasks are changing, and much of the typing goes away. What remains is understanding the problem, decomposing it, defining what correct means, and taking responsibility for the result. That was always the hard part of the job.

Engineers are not being replaced by agents. Engineers who stop learning are being replaced by engineers who did not. That was true long before AI, and it will remain true after whatever comes next.

Conclusion: Build the Process Once, Improve It Every Time

A prompt helps one engineer, once. A process helps the whole team, every time, and it gets better with each mistake it absorbs. By treating rules, skills, connectors and quality gates as shared, versioned infrastructure, a team turns agent speed into delivery that meets requirements and holds the QA bar, instead of a faster way to produce pull requests nobody trusts.

The agent writes the code. The team owns the process. The engineer owns the judgment.

DEV Community