Agentic engineering is the practice of building software with AI coding agents that plan, write, run and fix code over many steps, while engineers set the goal, give the agents context and review what they produce. The engineer spends less time typing each line and more time deciding what to build, checking the agents’ work and taking responsibility for what ships.
With the agent writing most of the code, two questions matter more than before: what the agent was told to build, and how anyone decides its output is right. The term agentic engineering is also used for building agentic AI systems, which is the job of an “agentic AI engineer.”
Agentic engineering differs from vibe coding at the acceptance step, which changes how the workflow runs and what the engineer does. Teams building regulated products also need review practices, checks for failures and controls for agent-made changes.
How Is Agentic Engineering Different From Vibe Coding?
Vibe coding is prompting an AI tool for code and judging the result by whether it seems to work, often without reading the code at all. Agentic engineering uses the same kind of agent, but the engineer reads the code, the tests and the review evidence before accepting a change.
Vibe Coding Accepts Code Because It Runs
In vibe coding, a working demo is enough to accept a change, so the change stays once it runs and the output looks right. That bar suits prototypes and throwaway tools. To decide when vibe coding is the better fit and when to switch approaches, compare vibe coding with spec-driven development.
Agentic Engineering Accepts a Change on Evidence
In agentic engineering, a change needs evidence that it does what was asked, such as passing tests and a person who reads the diff and accepts it. At the review stage, these questions help you compare the two approaches and decide what evidence a change needs:
| Vibe coding | Agentic engineering | |
|---|---|---|
| Who reads the code | Often nobody | The engineer, in review |
| What counts as done | The output looks right | Tests pass and a person accepts the change |
| Where the task comes from | A conversational prompt | A written task with acceptance criteria |
| Record left behind | The chat history, if anyone keeps it | Task, diff, test results, review and approval |
| Typical fit | Prototypes and throwaway tools | Software a team maintains and ships |
A project belongs in the right-hand column once its code will be maintained, audited or shipped to customers.
How Does an Agentic Engineering Workflow Run?
An agentic engineering workflow is a loop. You write the task, the agent works through it in its own environment, and a person decides whether the result merges.
Unlike autocomplete, which suggests the next lines inside an editor and stops there, a coding agent interprets a goal, opens files and traces errors to gather context, then edits several files and runs the test suite on its own. A change proceeds from task to merge through these steps:
- You define the task and its acceptance criteria. When the task is written as an issue, hosted coding agents can use its verification steps to check whether the work is finished before opening a pull request.
- You give the agent context. You usually provide a repository instruction file, such as AGENTS.md, with the build, lint and test commands, the project’s conventions and the merge requirements, plus the requirement the change implements.
- The agent plans. In plan modes, the agent explores the codebase with read-only tools and drafts a plan, and it makes no code changes until you approve that plan.
- The agent edits, runs tests and fixes failures. The agent works in an isolated, often temporary environment, runs the tests and linters, reads what failed and tries again.
- The agent opens a pull request. The agent creates the branch, writes commit messages and opens a draft. On some setups each commit links back to the session log that shows why the change was made.
- A named engineer reviews the change. The reviewer reads the diff and the test results, then approves it, asks the agent for changes or rejects it.
- The change merges through the repository’s gates. Required status checks and required human approvals have to pass first.
People keep control at the checkpoints between those steps. You approve the plan before the agent writes code and read the diff before you accept a pull request. On some setups, a user must approve continuous integration workflows before they run on an agent’s push.
Repository controls commonly block hosted coding agents from approving or merging their own pull requests, and an agent’s approval doesn’t count toward the required number of approvals. A repository rule can also stop the person who asked for the change from approving it. After merge, many setups have no formal checkpoint, so reverts often become the main signal that an accepted change was wrong.
What Does an Engineer Actually Do in Agentic Engineering?
The engineer’s work changes from writing the implementation to specifying it and reviewing what the agent produces.
Specify an Agent-Sized Task and Its Context
Before the agent runs, you split the work into agent-sized tasks, write each one, name the requirement it serves and settle open questions, because the agent will act on whatever the task does not specify. For each run, you also curate context by providing instruction files, linked requirements and coding conventions. A study of agent context files in 466 projects, presented at the 2026 Mining Software Repositories (MSR) conference, found no established content structure for them yet. So each team decides what goes into these files and who keeps them current.
Review Each Change and Own the Result
Engineers review each change the agent produces before it merges. Researchers who studied reverted agent pull requests found that the most common cause was overengineering or side effects, at 22.33%. Functional incorrectness accounted for a slightly smaller share, at 22.13%.
When you read the diff against the task, you can identify both causes, which a passing build alone may miss. The review needs to cover unnecessary complexity and side effects as well as functional errors.
You remain responsible for what ships. Professionals who use AI stay professionally responsible for work generated by or including AI output, under a practice advisory from Engineers and Geoscientists British Columbia. AI-generated technical work gets at least the same scrutiny as human-created work under the National Society of Professional Engineers’ review standard for AI-generated work.
What Practices Make Agentic Engineering Work?
Before accepting agent output, you can check whether each of these practices is in place:
- Small, scoped tasks: A change small enough to read in one sitting gets a real review. In a study of 567 agent pull requests, pull requests too large or complex to review effectively were among the three most common reasons maintainers rejected them.
- Acceptance criteria written before the agent starts: The agent uses the criteria to determine when to stop, and you use them to review its output. In a study published in IEEE Access, prompts stating preconditions and postconditions raised average pass@1 accuracy (the share of problems solved on the first attempt) in all three programming languages tested.
- One current source for requirements: An outdated copy pasted into a chat or a markdown file cannot replace the approved requirement agents need. Stack Overflow found that project requirements topped the context developers want AI agents and assistants to have, at 85%.
- Tests the agent must pass: A test suite gives the agent feedback it can act on inside its loop. Tests derived from the requirement check what was asked, while tests the agent writes from its own code check only what it built.
- Sandboxed execution with narrow permissions: To guard against excessive agency, the Open Worldwide Application Security Project (OWASP) recommends that you limit permissions to the minimum necessary. The limited permissions restrict what an agent can change by mistake.
- Required human review: Nothing an agent produces counts as verified until a person accepts it. Automated review agents can add comments, but their approval is input to the human decision rather than a substitute for it.
- A record of what the agent was asked and produced: The task, the context it read, the session log, the diff and the approval together explain why a change exists. AI-generated artifacts that enter the supply chain without provenance or approval are one of the DevSecOps risks for AI that the National Institute of Standards and Technology (NIST) has identified.
Several of these practices depend on what the agent reads before it starts. Assembling that input is its own discipline, grounding AI agents in the right information.
Where Does Agentic Engineering Go Wrong?
Many agentic engineering failures involve the input the agent worked from or the checks used to accept its output. Four failure modes recur in published studies of coding-agent output.
Agents Build From Outdated or Incomplete Requirements
When requirements are missing or stale, an agent can omit required behavior or implement it incorrectly. Missing requirements can become “unknown unknowns” to language models, which may default to “common sense” completions that conflict with users’ actual needs.
Beyond missing requirements, ambiguous requirements can lead to code built to the wrong interpretation of what was asked. Agents can still produce faulty code from clear requirements, so requirement quality can improve correctness without proving that the code is correct.
Staleness is harder to spot when the same requirement exists in several places. For example, an email thread, a shared document and a ticket can each contain a different threshold value. The agent implements whichever copy you give it, and the reviewer may be checking against another.
Code Passes Tests but Satisfies No Requirement
A passing test suite shows that code does what the tests check, and no more. When researchers extended the HumanEval benchmark’s tests 80-fold, reported pass rates dropped. Pass@k fell by up to 19.3 to 28.9%, which means the original tests had scored a significant amount of wrong code as correct.
Agents can also implement something other than the assigned task, a failure the Multi-Agent System Failure Taxonomy (MAST) calls disobeying task specifications. An agent that solves a slightly different problem, then writes tests for its own version, produces code that passes build checks but meets no documented requirement.
Agents Write Code With Security Weaknesses
In a user study presented at the 2023 ACM Conference on Computer and Communications Security (CCS), participants given an AI code assistant for security-related programming tasks wrote significantly less secure code than participants without one. Participants using the assistant were also more likely to believe their code was secure. Less secure code that its writers trust more needs a careful review.
Dependencies that agents install add a separate security risk. Researchers testing code-generating models found that 19.7% of the packages the models recommended didn’t exist. An attacker can publish a malicious package under a name that models repeatedly recommend, and an agent that installs dependencies on its own may pull it in.
Several Agents Work Without One Source of Truth
When each agent reads its own copy of the requirements, two agents can each pass their tests and still disagree. Inter-agent misalignment is one of three failure categories the MAST researchers found after annotating more than 1,600 traces from multi-agent systems.
Researchers studying parallel coding agents reported a related problem: “Parallel coding agents can produce patches that work alone but fail when merged.” One requirements record that every agent reads is one condition for their outputs to agree.
How Do Teams Building Regulated Products Govern Work Done by AI Agents?
Regulated teams govern agent work with the controls their standards already set for software changes. Each change traces to an approved requirement and passes tests linked to that requirement; a named engineer accepts it, and the team keeps a record of what the agent produced.
Tracing Each Agent-Made Change to an Approved Requirement
You put the approved requirement’s ID in the agent’s task and require the pull request to reference it. A change that implements something no approved requirement asks for has no traceable link to an approved requirement, whoever wrote it. The reviewer sends it back without tracing it after the fact.
For medical device software, FDA recommends source code traceability analysis to verify that all code is linked to established specifications and established test procedures (section 5.2.4). For work assessed against Automotive SPICE, maintain bidirectional traceability between the software units you develop and the software detailed design (SWE.3.BP4). You must obtain approval for change requests before implementation (SUP.10.BP3).
Verifying the Change With Tests Linked to the Requirement
For work assessed against Automotive SPICE, also maintain bidirectional traceability between verification results and verification measures (SWE.4.BP4). For airborne software, apply the independence requirements of DO-178C. The test cases for low-level requirements cannot be developed by the same person who coded those requirements (section 6.2).
Agents complicate that independence requirement. If you use agents, decide in advance how you treat tests an agent drafted for code the same agent wrote. Deriving tests from the requirement, and having a different person or process own them, is one defensible answer.
Accepting the Change Through a Named Engineer
Agent actions and outputs need appropriate governance, authorization controls, auditability and human oversight, according to NIST. Human review then becomes the limit on how much agent output a team can accept. For example, engineers conducting AI-assisted code migrations at a large software company reported that “The bottleneck in the process was the speed at which engineers could review the changes.” They deliberately limited how many changes they generated each week to avoid overwhelming reviewers.
Agentic teams can use review tooling to shorten review without weakening it. Jama Connect® is a web-based requirements management and traceability platform for complex, regulated product development, and its reviews run in the same system that stores the requirements under review.
IonQ reports a 25% decrease in review cycle time with Jama Connect. If agents produce changes faster than you can review them, a shorter review cycle can let you accept more changes while maintaining the same acceptance criteria.
Keeping a Record of What the Agent Produced
An auditor may ask which requirement version the agent worked from, what it was asked to do, what it produced and who accepted it. You can find part of that record in commits linked to session logs. The requirement version and the approval have to come from the system that stores the requirements.
When agents read requirements through the Model Context Protocol (MCP), the protocol itself covers only part of the record. Under MCP, a person should be able to deny the agent’s tool invocations, while role-based access control and audit logging depend on the server implementation, so whether a given server produces attributable records is a question to ask about MCP for requirements management before you connect it. Alongside the requirement version and approval record, decide what your agentic workflows should record before an auditor asks.
How Jama Connect Supports Agentic Engineering
Jama Connect provides the Product Context Layer your engineering team needs to tie agent tasks to approved requirements and acceptance records. That record is what spec-driven development depends on: approved specifications guide what agents build and give engineers something to verify the results against. Governed requirements and traceability keep that work aligned as the specifications change. Jama Connect connects requirements, risks, tests, Systems Modeling Language (SysML) models, code repositories, simulations, defects, reviews, approvals, verification evidence and change history into a governed system of record. The Traceability Information Model (TIM) defines how requirements, models, code, tests, simulations and verification results relate to one another. Anything performed with AI inside Jama Connect is versioned and documented as being generated by AI, so the record covers AI work performed inside Jama Connect and excludes work performed in external AI tools.
For the first failure mode, agents building from outdated requirements, the Jama Connect MCP Server (released 4 May 2026 for Cloud and Self-Hosted deployments) lets agents query approved requirements under existing permissions, lifecycle workflows and audit requirements. When a requirement changes, suspect links flag the downstream items that trace to it. Before a requirement becomes an agent’s input, Jama Intelligence, an add-on for Jama Connect Cloud, evaluates its text against 30 of the 40 INCOSE rules and the six Easy Approach to Requirements Syntax (EARS) patterns and suggests refinements the engineer accepts or rejects. For the second and fourth failure modes, the TIM shows when a required test link is missing, and every agent can read the same requirements record. The third, security weaknesses in generated code, needs code scanning and review outside requirements management.
Building Agentic Engineering Into a Regulated Program
You can start with one requirement set with a known owner. Each agent task should reference a requirement ID in that set, and you should measure review cycle time before and after. If your agents already open pull requests faster than your reviewers can trace them to requirements, a Product Context Layer is the place to start, and you can see it in action.
Frequently Asked Questions About Agentic Engineering
What is the difference between agentic engineering and an agentic AI engineer?
An agentic AI engineer designs, builds and maintains systems made of autonomous agents that reason, plan and use tools. Agentic engineering for software development means using coding agents to build any kind of software. Check which sense a job posting or paper intends before you compare roles or practices.
Do coding agents need MCP to read requirements?
No. An agent can read requirements from an issue, a repository file or a prompt. MCP gives agents a standard way to query another system’s data. MCP has been stateless since its 2026-07-28 specification, so each request includes its own version and capabilities.
How can a team tell whether agentic engineering is working?
Revert rate is one signal you can calculate from data your team already has. Researchers who studied reverted agent changes found that 2.66% of agent pull requests contained at least one reverting commit. In the same study, the revert rate for human-authored pull requests was 4.68%. Revert rate means more when tracked alongside review cycle time, because fewer reverts do not indicate an improvement if reviews take longer.
How much access should a coding agent get?
Access should reflect the project’s stakes, and in a governed environment an agent should work under the same permissions as the project it connects to. For a high-stakes regulated program, use sandboxed environments, read-only access to requirements and no direct write access to production systems. The Jama Connect MCP Server enforces the project’s existing permissions, lifecycle workflows and audit requirements on every agent interaction.
