Agentic Engineering: A Practical Workflow for Coding Agents

Agentic Engineering: A Practical Workflow for Coding Agents

Agentic engineering is less about asking a model to write a function and more about giving a software agent a bounded job inside a workflow you can inspect. GitHub’s new guide, “Beyond code generation: A developer’s guide to agentic engineering”, describes a loop that reaches from planning through implementation and observation. The useful question is not whether an agent can produce code. It is whether a team can turn its output into a change that is correct, maintainable, and worth shipping.

That distinction matters because code is only one stage of software delivery. A patch can compile and still misunderstand the requirement. Tests can pass while missing the behavior users care about. And even a correct pull request can sit in a review queue or fail to solve the underlying problem. A practical workflow therefore treats the agent as a capable collaborator—not an unquestioned authority—and makes the human’s job explicit at the points where context, risk, and judgment matter.

Start with a small, testable job

The first step is to define the work before delegating it. “Improve the settings page” is an invitation to guess. A better request says which behavior is wrong, what should happen instead, what must remain unchanged, and how success can be checked. If the task is too large to describe clearly, split it into smaller changes with independent acceptance criteria.

GitHub’s guidance for working with its coding agent emphasizes well-scoped issues and complete acceptance criteria. That advice is useful beyond one vendor’s tool: a model cannot reliably infer hidden product decisions from a vague request. State relevant constraints, point to the right files or examples, and identify required tests. For a bug, include a reproduction if available. For a feature, explain the observable outcome, not merely the implementation you imagine.

A useful prompt can be plain and short: “When a user saves an invalid email, show an inline error and preserve the typed value. Do not change server validation. Add or update tests for the error state.” The point is not to write a perfect prompt. It is to make the desired result concrete enough that both the agent and reviewer can tell whether the task is done.

Ask for investigation before broad edits

For unfamiliar code, separate discovery from modification. Ask the agent to trace the relevant behavior, name the files involved, and summarize its proposed approach before it edits. This creates a chance to catch a mistaken assumption early—when changing direction is cheaper than reviewing a large diff.

GitHub’s agentic-engineering guide frames planning as getting people and agents aligned, including translating requirements into actionable tasks. In practice, a short plan should mention the path through the code, the behavior that may be affected, and the tests that should demonstrate the change. The developer remains responsible for deciding whether the plan fits the architecture and product intent.

This is also where repository context pays off. A coding agent may find patterns already present in the project, but it can also imitate an outdated or awkward pattern. Tell it which conventions matter and where to look. If the task crosses several components, ask it to identify the boundary before it starts touching files. A five-minute investigation can prevent a twenty-file diff that solves the wrong problem.

Keep the change narrow and inspectable

Once the plan is sound, let the agent implement a bounded slice. Ask it to avoid unrelated cleanup and to report what it changed, what it did not change, and which commands it ran. Review the diff—not just the agent’s summary. Look for accidental edits, duplicate logic, unexplained dependencies, broad permission changes, and behavior that strays beyond the acceptance criteria.

GitHub describes cloud-agent work as research, planning, and implementation followed by review and refinement before a pull request. That sequence suggests a healthy division of labor: agents can accelerate the production of a candidate patch, while maintainers retain control over what enters the shared codebase. A pull request is not proof of correctness; it is a review surface where the change can be discussed and tested.

Keep changes small enough to understand. If an agent returns a sprawling patch, ask it to split the work or explain why each file is needed. When the code touches authentication, payments, personal data, or destructive operations, raise the review standard. The cost of a bad change depends on what the software can do, not on how confidently the model describes it.

Treat tests as evidence, not ceremony

Run the relevant tests and inspect their results. If the agent added tests, ask whether they exercise the requirement or merely repeat the implementation’s assumptions. A test that only checks that a function returns a value may not prove that the right value is returned in the right situation. Consider edge cases, invalid input, failure handling, and regressions in adjacent behavior.

GitHub’s tutorial on reviewing AI-generated code recommends starting with functional checks and using automated testing and static analysis. GitHub Actions’ build-and-test guide shows how teams can automate repeatable checks. These tools reduce routine mistakes, but they cannot establish that a requirement was correctly understood. Human review still needs to compare behavior with intent.

A useful report distinguishes what was actually verified from what was not. “Unit tests passed” is more informative than “the code works,” but it is not enough if the change also affects a browser flow or database migration. Record the command, scope, and any missing checks. When tests fail, determine whether the failure is caused by the change, the environment, or an unrelated existing issue before claiming success.

Use review as a separate safety layer

An agent’s self-review can find omissions, but it is not independent assurance. A second automated reviewer may add another perspective, yet it can also miss defects or suggest changes based on a misunderstanding. GitHub’s documentation explicitly cautions that Copilot code review is not guaranteed to identify every issue and says its feedback should be supplemented by human review.

That makes review a decision, not a rubber stamp. Read the changed code, examine test coverage, and ask whether the patch introduces security or data-handling risks. Verify sensitive boundaries yourself: authorization checks, input validation, error messages, logging, and access to secrets. A green checkmark indicates that configured checks passed; it does not mean every relevant risk was tested.

The GitHub responsible-use guidance for agents similarly recommends clear, well-scoped tasks and careful review and testing before merging. A sensible team can use agent review to broaden attention, but should preserve a human accountable for the final decision—especially when the consequences of a mistake are significant.

Measure the full path, not just typing speed

The case for coding agents is often made in terms of faster code production. But a faster first draft does not automatically mean a faster or better release. Researchers at MIT Sloan and the University of Pennsylvania studied more than 100,000 developers and reported that increases in coding activity translated into smaller increases in projects and releases. Their research summary points to downstream work such as review, testing, polishing, and launch as potential bottlenecks.

A separate paper available through NBER studies a larger developer sample and likewise distinguishes coding activity from shipped releases. These results are not a guarantee about what any particular team will experience. They do, however, offer a useful reminder: measure outcomes that matter to users, not only lines of code or the number of agent tasks completed.

The evidence is not uniform or timeless. METR’s February 2026 update describes a changing productivity experiment and explains why its estimates are difficult to generalize. Its May survey measures developers’ self-reported value rather than the same thing as task speed. Different studies ask different questions, sample different developers, and examine different tools. Don’t turn one result into a universal prediction about every codebase.

For your own team, track a small set of before-and-after measures: time from a well-defined issue to an accepted change, defects or rework after merge, review time, and whether the feature achieved its intended result. Compare like with like, and include the extra work of supervising the agent. If code output rises but review queues or production defects grow, the bottleneck may have moved rather than disappeared.

Make the workflow repeatable

A dependable agentic workflow can be as simple as this: define the outcome and constraints; ask for a plan; approve or revise the plan; request a narrow implementation; inspect the diff; run tests and static checks; review the behavior and risks; then decide whether the change is ready to merge. Keep notes on what succeeded and what required correction so the next task can be better scoped.

That is not bureaucracy for its own sake. Each step creates evidence. The issue records intent. The plan reveals assumptions. The diff shows the actual change. Tests check selected behavior. Review evaluates whether the evidence is sufficient for the risk. If any link is missing, the answer is not necessarily to ban the agent; it may be to improve the process around it.

The developer’s role changes in emphasis, but it does not disappear. Agents can take on research, implementation, and routine checks; people still supply product context, architectural judgment, accountability, and the decision to ship. The strongest workflow is not the one with the least human involvement. It is the one that directs human attention toward the decisions that matter and makes the machine’s work easy to verify.

What to watch for

Over the next few months, look beyond demonstrations. Are agents completing clearly defined tasks with fewer correction cycles? Do accepted changes hold up after release? Are review queues keeping pace with generated pull requests? Are teams measuring user-facing outcomes rather than activity alone? Do developers know when to let an agent proceed and when to stop it?

Those are practical indicators of whether “agentic engineering” is becoming a reliable discipline or just a new label for code generation. The tools will keep changing. The underlying test remains steady: can a team specify a valuable change, verify the result, and take responsibility for what it ships?

Conclusion

Coding agents can help move work through a software project, but their output is only one part of delivery. Start with a clear task, keep changes reviewable, verify behavior with relevant tests, and preserve human judgment at the merge decision. Then measure whether the complete path—from request to useful release—actually improves. That is a more grounded way to adopt agentic engineering than counting how much code an assistant can produce.

Where agents fit best—and where they need help

The workflow becomes more efficient when the task matches the agent’s strengths and the project gives it enough context. A bounded refactor, a test addition, a documentation update, or a well-described bug can be easier to delegate than a fuzzy product question whose answer depends on unstated customer needs. Even then, “easy to delegate” does not mean “safe to accept without checking.” It means the desired change can be described, the relevant code can be found, and the outcome can be evaluated.

GitHub’s guide describes more than code-writing: it discusses planning, assigning routine issue work, handling implementation, and learning from what happens after shipping. That broader loop is important. An agent that can prepare an implementation may also help organize the work, but the team still needs a clear route for feedback. When a defect appears, capture the evidence in a place where it can become a reproducible issue and regression test. Otherwise the same failure may recur, whether a person or agent wrote the original code.

A common failure mode is to treat a plausible explanation as proof. Agents can state that they followed a pattern, but the diff may use the wrong abstraction. They can report tests passed, but perhaps they ran only a narrow subset or the test did not cover the changed behavior. They can produce a polished pull request description while omitting an important file. The remedy is not to demand impossible certainty from the model; it is to make claims auditable. Ask for exact changed files and test commands, then verify those details independently.

Context itself has costs. If an agent must inspect a large repository to find a small feature, it may spend effort navigating or make a plausible but inconsistent choice. Good repository documentation, focused issues, clear ownership, and dependable tests help human contributors too; they are not merely prompt decorations. When an agent repeatedly needs a person to explain the same architecture, that is a sign to improve the shared project context rather than endlessly lengthen each prompt.

Set boundaries before giving tools access

The permission model should match the job. A request to suggest a patch usually does not require the ability to merge it, publish a release, or alter production data. Keep write access narrow, prefer reviewable branches and pull requests, and be particularly cautious with credentials, deployment workflows, and destructive commands. If an agent can run commands, understand which environment those commands affect before authorizing the task.

This is ordinary engineering hygiene applied to a system that can act at speed. The GitHub responsible-use material notes that agent outputs may be inaccurate or incomplete and that users should review them against their requirements. A sensible boundary lets the agent do useful work while containing the consequences of a wrong guess. For example, letting an agent open a draft pull request is meaningfully different from granting it an unattended production deployment path.

Teams should also consider what information enters the prompt and tool context. Repository code may include internal details, and connected tools can expose issue trackers, logs, or other systems. Follow the organization’s rules for sensitive information, and avoid pasting secrets or customer data into a task just because it seems helpful. The goal is to give enough context to solve the task—not every available piece of context.

Design a small experiment instead of declaring victory

If a team wants to know whether agentic engineering helps, it can begin with a small pilot. Pick a few recurring, low-risk task types. Record a baseline for how long they take and what review or rework they require. Use the same acceptance criteria with the agent, and compare not only first-draft time but also total time until an accepted change, subsequent defects, reviewer effort, and the usefulness of the finished result.

Be cautious about simple before-and-after comparisons. The people who choose to use an agent may work on different tasks from those who do not. A team may also improve its prompts, tests, and project documentation at the same time as it adopts a new tool. Those changes are valuable, but they make it harder to attribute the result to the model alone. Record the conditions and limits of the experiment, and avoid turning a small local test into a claim about the whole profession.

The research offers reasons to measure carefully, not a single verdict. The NBER study follows a large population of GitHub developers and analyzes coding activity and releases; the METR update discusses the difficulties in measuring task-level speed as developers adopt newer agentic tools. The measures differ, and neither guarantees your team’s outcome. The responsible conclusion is that impact depends on the task, tools, project context, and the work required after code is generated.

A team can define success in practical terms: a particular category of small change reaches review sooner without increasing defects or imposing more correction work on maintainers. If the first draft is faster but the patch takes longer to explain, test, or repair, the workflow has not yet produced a net gain. If the agent helps a developer handle useful work that would otherwise have waited, that may matter even when the clock does not show a dramatic reduction. Make the outcome explicit before measuring it.

Sources

1. Beyond code generation: A developer’s guide to agentic engineering — GitHub Blog, November 6, 2026.
2. Best practices for using GitHub Copilot to work on tasks — GitHub Docs.
3. Review AI-generated code — GitHub Docs.
4. Building and testing your code — GitHub Docs.
5. Application card: GitHub Copilot Agents — GitHub Docs.
6. AI boosts worker productivity—but does that translate to final outputs? — MIT Sloan, 2026.
7. Productivity Effects Across Generations of AI Coding Tools — National Bureau of Economic Research, 2026.
8. We are Changing our Developer Productivity Experiment Design — METR, February 24, 2026.
9. Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity — METR, May 11, 2026.