Agentic Engineering: Working With AI, Not Just Using It

The agent did not follow instructions. It followed the system.

A senior engineer at Vercel ships a feature in three hours. The feature required changes across four files, a database migration, a new API endpoint, and updated client-side state management. She did not write most of the code. She did not copy-paste from ChatGPT either. She worked with an agent that understood the project's conventions, had access to the test suite, could read the deployment configuration, and knew when to ask for clarification versus when to proceed. The agent was not a tool she used. It was a collaborator she designed a system around.

This is agentic engineering: the discipline of designing systems, workflows, and feedback loops where AI agents operate as collaborative participants in the engineering process rather than passive code generators waiting for prompts. At product.engineer, we define agentic engineering as the shift from "how do I write a better prompt" to "how do I architect an environment where an agent can do meaningful, reliable work alongside me." It moves beyond "how do I write a better prompt" into "how do I architect an environment where an agent can do meaningful, reliable work alongside me."

The distinction matters for the product engineer. When you own outcomes from problem definition to deployed feature, you need agents that can carry real weight in the process. Not autocomplete. Not a chatbot you interrogate between actual work. A genuine collaborator that maintains context, takes initiative within boundaries, and compounds your capability rather than just your typing speed.

The gap between passive AI assistance (autocomplete, chat, single-prompt generation) and agentic workflows (where the AI maintains state across tasks, has tool access, and operates with defined autonomy) is enormous. That gap is not about better models. It is about better system design.

What agentic engineering actually means

Agentic engineering is not a new framework or a library you install. It is an approach to building software where you treat AI agents as system participants with defined roles, capabilities, constraints, and communication interfaces. You design the system around the collaboration, not around the prompt.

This means thinking about:

• Agent boundaries. What can this agent do? What should it never do? What triggers a handoff back to the human?
• Shared state. How does the agent access the same context I have? How do I see what it has done?
• Feedback loops. How does the agent learn from corrections within a session? How does the system improve across sessions?
• Failure modes. When the agent makes a mistake, how do we catch it early? How do we recover without losing work?
• Escalation paths. What decisions require human judgment? How does the agent signal uncertainty?

If you have read about context engineering, you already understand one critical piece: the information environment determines agent behavior. Agentic engineering takes that further. Context engineering is about what the agent knows. Agentic engineering is about what the agent does, how it participates, and how the entire human-agent system produces better outcomes than either could alone.

Think of it this way. A carpenter does not "use" a table saw. They have a workshop designed around it: material flows in a specific direction, safety guards are positioned for the carpenter's height, the fence is calibrated for the project's dimensions. The saw is powerful, but the workshop design is what makes the carpenter productive and safe. Agentic engineering is workshop design for AI collaboration.

The spectrum: from autocomplete to collaborator

Not every interaction with AI needs to be agentic. But understanding where your workflow sits on the spectrum helps you identify where better system design would compound your output.

Most engineers are stuck between levels 2 and 3. They ask the AI to do something, review the output, paste it into their editor, and repeat. Each interaction starts from zero. No accumulated context. No shared state. No compounding.

Agentic engineering starts at level 4 and designs deliberately for level 5. The difference is not the model's capability. A prompt sent to Claude at level 2 uses the same model as Claude Code at level 4. The difference is the system around the model: persistent context, tool access, file system awareness, iterative feedback, and defined boundaries.

Stripe's engineering team published a blog post in early 2026 describing their internal agent infrastructure. Their agents operate at level 5 for specific domains: payment integration debugging, API migration assistance, and documentation generation. Each agent has a defined "operating agreement" that specifies its capabilities, constraints, escalation triggers, and feedback mechanisms. The result, they reported, was a 3.2x increase in engineer throughput for tasks within those domains, compared to a 1.4x increase when the same engineers used chat-based AI assistance.

The multiplier comes from the system, not the model.

Five principles of agentic engineering

After working with agents in production for over a year, coaching engineers through the transition, and watching both spectacular successes and catastrophic failures, the product.engineer framework for agentic systems distills the discipline into five principles. These are not theoretical. They come from watching real teams ship real products.

Principle 1: Design the boundaries before the capabilities

The first instinct when integrating an agent is to maximize its capabilities. Give it access to everything. Let it do anything. This is wrong. It is wrong in the same way that giving a new hire admin access to production on day one is wrong. Not because they are malicious, but because capability without boundaries produces unpredictable systems.

Start with the boundaries. Define what the agent cannot do. Define what requires confirmation. Define what triggers an escalation. Then expand capabilities within those boundaries.

At Linear, their AI features have explicit "never" lists: never modify an issue's priority without user confirmation, never close an issue autonomously, never reassign work across teams. These constraints are not limitations. They are trust architecture. Users trust the AI because they know its boundaries. Engineers trust the system because they can reason about its behavior.

The product engineer building agentic systems learns to ask: "What is the worst thing this agent could do?" before asking "What is the best thing this agent could do?"

Principle 2: Make state visible and shared

An agent that operates in a black box is a liability. You need to see what it sees, understand why it made decisions, and intervene when its trajectory diverges from your intent.

This means designing for observability from day one:

• Agents should log their reasoning, not just their actions
• Context windows should be inspectable (what did the agent "see" when it made that decision?)
• Tool calls should be auditable
• Intermediate results should be checkpointable

Notion's internal engineering tools team built an agent system for their API documentation generation. Their key design decision: every agent action produces a visible "thought trace" that engineers can review, annotate, and use to correct future behavior. They reported that this visibility reduced agent errors by 41% over three months, not because the model improved but because engineers could catch trajectory drift early and provide corrective feedback that shaped subsequent behavior.

Shared state also means the agent sees what you see. When you make a manual change, the agent should know about it. When the agent makes a change, your IDE should reflect it immediately. The collaboration breaks down the moment either participant is working with stale information.

Principle 3: Build for iterative correction, not one-shot perfection

The autocomplete mindset expects the AI to get it right on the first try. You prompt, you get output, you evaluate. If it is wrong, you try a different prompt. This is exhausting and it does not compound.

Agentic engineering expects iteration. The agent's first output is a draft. Your correction is not a failure; it is data. The system is designed so that corrections improve subsequent outputs within the same session and, ideally, across sessions.

This is where harness engineering connects directly. The harness (CLAUDE.md files, project rules, coding conventions, test configurations) is the persistent correction mechanism. Every time you correct an agent and encode that correction into the harness, you are training the system without training the model. You are accumulating institutional knowledge that makes the next collaboration session start from a higher baseline.

Anthropic's Claude Code documentation calls this "memory" but the engineering principle is older: it is configuration management applied to AI collaboration. Your corrections are code. They live in version control. They are reviewable, testable, and composable.

Principle 4: Match autonomy to confidence

Not all tasks have the same risk profile. A typo fix in a README is low-risk. A database schema migration is high-risk. Your agentic system should modulate the agent's autonomy based on the confidence level of the task.

A practical framework:

• High confidence, low risk: Agent acts autonomously (formatting, linting fixes, boilerplate generation)
• High confidence, high risk: Agent proposes, human approves (refactoring, dependency updates)
• Low confidence, low risk: Agent attempts, human reviews async (documentation drafts, test generation)
• Low confidence, high risk: Agent provides analysis, human decides and acts (architecture changes, data migrations)

This is not a new idea. It is the same principle behind deployment pipelines: automated for low-risk changes, gated for high-risk ones. Agentic engineering applies the same rigor to AI collaboration.

Shopify's internal tooling team presented data at their 2025 engineering summit showing that teams using confidence-calibrated autonomy (agents with variable autonomy based on task risk) shipped 2.7x faster than teams using fixed-autonomy agents. The fixed-autonomy teams either set autonomy too high (and spent time fixing agent mistakes in high-risk areas) or too low (and lost speed on trivial tasks that did not need human review).

Principle 5: Treat the agent as a junior collaborator, not a senior architect

This is the mindset shift that separates engineers who get 2x from agents versus those who get 5x. The agent is not an oracle. It does not have taste. It does not have organizational context. It does not know which tradeoffs your team would make differently from what the training data suggests.

Treat it like a talented junior engineer: fast, knowledgeable about syntax and patterns, tireless, but lacking judgment about what matters, what is risky, and what the user actually needs. You provide the judgment. You provide the product sense. You provide the "why." The agent provides the "how," rapidly and at scale.

This means you still need to be a strong engineer. You still need to understand the system deeply. You still need taste. In fact, agentic engineering requires more judgment, not less, because you are reviewing and directing more output per unit time. The product engineer who works with agents is not someone who codes less. They are someone who thinks more and types less.

The agentic engineering workflow in practice

Here is what a concrete agentic engineering session looks like for a product engineer shipping a feature. This is not theoretical. This reflects actual workflows I have observed and practiced.

Morning (30 minutes): Context loading and direction setting

The engineer opens their IDE with an agent session. The agent has already loaded the project's conventions from configuration files. The engineer describes the feature at the product level: "We need to let users export their dashboard data as CSV. They have been requesting this for months. It should work for any dashboard, handle large datasets without timeout, and respect permission boundaries."

The agent asks two clarifying questions about edge cases. The engineer answers. The agent proposes an implementation approach: streaming endpoint, background job for large exports, permission check at the query level. The engineer agrees with the approach but specifies that they want the progress indicator to use the existing WebSocket infrastructure rather than polling. This specification-heavy phase is where product.engineer's 30-30-30 rule applies directly to agentic workflows: investing 30% of time in defining constraints and boundaries upfront means the agent operates within a well-specified envelope for the remaining 70%.

Midday (2 hours): Collaborative implementation

The agent writes the initial implementation across four files. The engineer reviews each file as it is produced, making corrections in real-time. "Do not create a new service class here; extend the existing ExportService." The agent adjusts and continues. The engineer catches a potential issue with the permission check and explains the edge case (shared dashboards have different permission semantics than personal ones). The agent incorporates this and adds a test case for it.

Afternoon (1 hour): Testing and refinement

The agent generates integration tests based on the implementation. The engineer adds three scenarios the agent missed (all related to organizational context: specific customer configurations that create edge cases). The agent runs the test suite, identifies two failures, proposes fixes, and the engineer approves both.

Total time: 3.5 hours for a feature that would have taken 1.5 to 2 days with traditional development. The quality is higher because the test coverage is more thorough. The engineer's judgment was applied at every critical decision point. The agent handled the implementation velocity.

From Felipe's experience

In my work as a Senior Product Engineer at AWS, I have seen the transition from "AI as tool" to "AI as collaborator" happen in real-time across teams. The engineers who struggle are the ones who try to hand off entire problems to agents and then spend more time debugging the agent's output than they would have spent writing the code themselves. They are using AI, not working with it.

The engineers who thrive are the ones who invest time in system design: setting up their project conventions, calibrating agent boundaries, building feedback loops that compound over sessions. Having coached over 12,000 engineers and hired 600+, I can tell you the pattern is clear. The best product engineers today are not the fastest typists or the ones who memorize the most API signatures. They are the ones who can architect a collaboration with an AI system that multiplies their judgment across more surface area. That is agentic engineering in its purest form.

The difference between a 2x engineer and a 10x engineer in 2026 is not raw coding ability. It is system design for human-AI collaboration.

Common anti-patterns to avoid

Agentic engineering fails in predictable ways. Recognizing these anti-patterns saves time:

The Delegation Trap. Handing the agent a vague, complex task and expecting a perfect result. "Build me an authentication system" is not a collaboration. It is a delegation that will require more time to fix than to build correctly in partnership.

The Correction Spiral. Spending more time correcting the agent's output than the task would take manually. If you are on your fourth correction for the same issue, stop. The system is not set up correctly. Fix the boundary or the context, not the output.

The Amnesia Loop. Correcting the same mistake in every session because corrections are not persisted into the system. If you tell the agent the same thing three times, that information belongs in a configuration file, not in your memory.

The Autonomy Cliff. Giving the agent full autonomy on a high-risk task because it handled simpler versions well. Competence on easy tasks does not predict competence on hard tasks. Match autonomy to the specific task's risk profile every time.

The Isolation Pattern. Using the agent in isolation from your team's workflow. If the agent's output does not go through code review, does not run in CI, and is not subject to the same quality gates as human-written code, you have a shadow workflow that will diverge from team standards.

Measuring agentic engineering effectiveness

You cannot improve what you do not measure. Here are metrics that matter:

• Throughput per judgment call. How much output does each human decision produce? In a well-designed agentic system, one architectural decision by the engineer should cascade into multiple correctly implemented components.
• First-attempt accuracy. What percentage of agent output is accepted without correction? Track this over time. If it is not improving, your system is not learning.
• Correction-to-configuration ratio. When you correct the agent, how often does that correction get encoded into persistent configuration? A healthy ratio is above 50%.
• Escalation rate. How often does the agent correctly identify tasks that need human judgment? Both false positives (unnecessary escalations that slow you down) and false negatives (missed escalations that cause errors) matter.
• Time-to-first-commit. How quickly does a new feature go from description to first working commit? This measures the full agentic loop, not just code generation speed.

PostHog tracks these metrics for their internal AI-assisted development workflow. They reported in their engineering blog that time-to-first-commit dropped 58% after they invested two weeks in agentic system design (primarily harness configuration and boundary definition). Their correction rate dropped from 34% to 12% over three months as their configuration files accumulated institutional knowledge.

The future is collaborative systems

Agentic engineering is not about replacing engineers. It is about redesigning the engineering process to include AI as a first-class participant. The product engineer of 2026 and beyond is someone who designs these collaborative systems as deliberately as they design their software architecture.

The agents will get better. Models will be more capable, context windows will expand, tool use will become more reliable. But better models without better system design just means faster generation of output that still needs the same amount of human review. The advantage comes from the system, not the model.

Start with boundaries. Make state visible. Build for iteration. Match autonomy to confidence. Keep your judgment central. That is agentic engineering. Not a prompting technique. A systems discipline.

Key takeaways

• Agentic engineering designs systems where AI agents collaborate within defined boundaries, not just respond to prompts.
• The productivity gap between passive AI use (GitHub's research measured a 55% speed improvement at the autocomplete level alone) and agentic workflows comes from system design, not better models.
• Match agent autonomy to task risk: high confidence and low risk gets full autonomy, low confidence and high risk stays human-led.
• Treat AI agents like talented junior engineers who need direction, review, and clear boundaries to produce quality work.
• Encode every correction into persistent configuration so the system improves across sessions without retraining the model.

FAQ

What is the difference between agentic engineering and prompt engineering?

Prompt engineering focuses on crafting individual inputs to get better outputs from a model. Agentic engineering is a systems discipline that designs the entire collaboration environment: boundaries, shared state, feedback loops, escalation paths, and autonomy calibration. Prompt engineering is one small component within an agentic engineering system.

Do I need to be a senior engineer to practice agentic engineering?

You need enough engineering judgment to set meaningful boundaries and evaluate agent output. In practice, this means you need solid fundamentals: understanding of system design, testing, deployment, and the domain you are working in. A mid-level product engineer with strong system thinking can practice agentic engineering effectively. A junior engineer without those fundamentals will struggle to set appropriate boundaries or catch agent errors.

Which tools support agentic engineering workflows?

As of mid-2026, the tools most aligned with agentic engineering principles include Claude Code (persistent context, tool access, project configuration), Cursor in Composer mode (multi-file context, iterative correction), and custom agent frameworks built on Anthropic's or OpenAI's APIs with tool use. The specific tool matters less than the system design around it. Any agent with persistent context, tool access, and configurable boundaries can support an agentic workflow.

How does agentic engineering relate to product engineering?

A product engineer owns outcomes from problem to production. Agentic engineering multiplies that ownership by enabling one engineer to execute across more surface area without losing judgment or quality. Their unique advantage in agentic workflows is the ability to provide product context, user empathy, and business judgment that agents cannot generate independently.

Is agentic engineering just "using AI tools better"?

No. Using AI tools better is prompt engineering. Agentic engineering is designing systems where AI agents participate as collaborators with defined roles. The difference is architectural: you are not optimizing inputs to a tool, you are designing a collaborative workflow that distributes cognitive work between human judgment and machine execution.

Related reading

• What Is a Product Engineer?
• Context Engineering: The Skill That Replaced Prompt Engineering
• Harness Engineering
• From Vibe Coding to Vibe Engineering
• Don't Build Agents, Build Skills