The Pass: Agentic Engineering

Software development has entered a different era. You are no longer the line cook standing over the stove. You are what Steve Yegge calls the executive chef at the pass, the station where every dish is inspected before it leaves the kitchen, directing a brigade of sous-chefs who handle the mechanical work: chopping, prepping, plating. In engineering, agents are those sous-chefs. They compile, run tests, and retry at high speed so you can focus on direction and standards.

The tools have changed, and our leverage has gone up with them. One engineer can now cover far more surface area and make broader architectural decisions if they know how to direct that leverage.

In the old model, your hands were in everything. You chased every error, ran every build, and hunted every missing dependency, doing each step manually even when the work was predictable.

In the new model, agents handle the prep and the plating: repetitive edits, refactors, test runs, and obvious fixes. You still own the meal, and you still decide what leaves the kitchen, but your hands are no longer on every pan. You may not type a single line of code in a given session, but you remain accountable for all of it. You examine the work, make judgments, course-correct when needed, and uphold standards.

Your value shifts from labor to leadership, and the tools you use must match that shift.

What You're Actually Giving Up

You give up the tactile satisfaction of building something line by line, the flow state of a long coding session, and the pride of knowing every line came from your hands. Those losses are real, and anyone who says otherwise hasn't felt the craft.

But you are not giving up the core of engineering. You still need to understand how the system works, still own correctness, still read code with judgment, and make architectural calls that guard the integrity of the codebase.

You stop being the one turning every screw and start being the one deciding which screws matter. The work moves closer to intent than execution. Your responsibilities widen, you make more calls faster, and the mental load shifts from mechanics to judgment.

This trade works in your favor, but only if you stay honest about what you're trading.

Why Terminal Alignment Matters

Modern coding assistants like Claude Code operate natively in the terminal because that's where they can effect change. The Unix philosophy of composable commands, clean text streams, and observable output gives agents direct access to the system. They read compiler messages, test results, and error logs exactly as the toolchain produces them, and they modify the system through the same interface.

Humans work in the terminal because that's where the agents are. When you work in the terminal, you see exactly what the agent sees, the same stdout, and the same verification commands, which makes effective oversight possible.

IDEs provide tremendous value for hands-on coding: intelligent autocomplete, integrated debugging, and visual navigation. But in agentic workflows, where you're overseeing rather than typing, the IDE's interpretation layer creates a gap between what you see and what the agent works from. An IDE might show you a type error from its language server before you've saved the file, while the agent is working from actual compiler output that presents the error differently. When these versions diverge, you lose the tight feedback loop that makes oversight effective.

The terminal shows you the compiler's actual words and the system's real state, which is the source of truth your agents work from. When you work in the same environment, you eliminate translation overhead. You understand the agent's choices and catch its drift the moment it begins. In kitchen terms, this is the pass: truth hits the counter before anything moves forward.

A simple setup works: two panes, with the agent's session on the left showing every command and retry, and your editor on the right. You move between them the way a chef moves between the pass and the line, watching the agent hit an error, opening the file, understanding the context, deciding whether to redirect or step in.

Example: you ask the agent to run the test suite. A few seconds later, a Rust compiler error hits the left pane:

error[E0308]: mismatched types
  --> src/user.rs:42:9
expected `UserId`, found `Option<UserId>`

The agent's reasoning appears immediately below:

The function signature expects UserId but we're returning Option<UserId> 
from the database lookup. I'll unwrap the Option with proper error handling.

It proposes a change:

let user_id = db.lookup_user(email)
    .ok_or(UserError::NotFound)?;

Then it reruns the tests, and you watch this cycle complete. The tests pass, the error handling is correct and consistent with the codebase's patterns, so you approve and move on.

But suppose instead the agent had done this:

let user_id = db.lookup_user(email).unwrap();

You see it immediately. The tests might pass for the happy path, but you know this code will panic in production when a user isn't found. You instruct:

"Don't use unwrap here. Return a proper error using our UserError type."

The agent corrects course. You've caught the issue within seconds because you were watching the same output it was working from, in real time.

This rhythm settles in quickly. The panes are simply two vantage points on the same work, helping you steer the system without losing the thread.

Oversight as a Discipline

In this model, your job is not to type, it's to see.

You watch the agent as it prepares code, runs tests, interprets errors, and proposes changes. You decide when it's correct, when it needs guidance, when to throw the work out, and reset. The terminal matters because it shows you the agent's actual thinking: the failures it hits, the paths it tries, the boundaries of its competence.

Bad oversight is easy to spot: letting the agent run unattended, merging diffs without reading them, giving vague instructions, or treating it like a senior engineer when it doesn't have that judgment. These habits erode quality fast. Oversight is leverage, and leverage collapses when attention drifts.

Good oversight means staying close to the work. You watch the agent's approach and ask whether it's reasoning or just thrashing. When an error appears, does it adjust or simply retry the same thing? You make small corrections early, "not that path, try this one," so the agent doesn't spend twenty minutes digging the wrong hole. When it loops, drifts, or starts fixing things that weren't broken, you step in and fix the root cause yourself rather than issuing more instructions.

The rule is simple: instruct when clarity will help the agent succeed, intervene when it can't succeed without you.

What Bad Oversight Looks Like

Bad oversight shows up quickly. It looks like letting the agent run unattended and assuming it will sort things out, merging diffs without reading them, trusting the tool instead of verifying the work, giving vague or shifting instructions, letting the agent loop on the same error, or treating it like a senior engineer and expecting judgment it doesn't have.

These habits don't just slow work; they erode quality. Oversight is leverage, and leverage collapses when attention drifts.

What Good Oversight Looks Like

Good oversight is active and disciplined.

Before execution, you ask whether the goal is clear, whether the agent has enough context, and whether it knows the constraints and standards.

During execution, you watch its approach. Is it reasoning or thrashing? When an error appears, does it adjust or simply retry? Is it still solving the problem you asked for, or has it drifted?

After execution, you check the diff against intent. You look for subtle bugs and edge cases, and confirm the change fits the architecture and standards of your codebase.

You make small, precise corrections: "Not that path, try this one." You instruct early so the agent doesn't spend twenty minutes digging the wrong hole.

Recognizing When the Agent Is Stuck

Agents fail in predictable ways: looping on the same approach expecting different results, drifting toward related but incorrect problems, losing context and guessing wrong, or overcorrecting by fixing things that weren't broken.

When you see these patterns, you intervene immediately, resetting, clarifying, or taking over the part that's blocking progress rather than letting the agent burn cycles. This is not passive work; it's focused and fast.

Instruction vs. Intervention

The rule is simple: instruct when more clarity will help the agent succeed, and intervene when it can't succeed without you. If the agent is missing context or drifting slightly, give it tighter constraints and more specific guidance. If it's repeating mistakes or its reasoning is fundamentally wrong, stop giving instructions and fix the root cause yourself.

The New Shape of Engineering

The role is changing, but the fundamentals remain. You still own clarity, intent, correctness, and direction. What's different is the leverage. Agents expand what you can tackle, and the terminal keeps you grounded in what's actually happening.

The engineers who thrive in this era will be the ones who can see the whole kitchen, guide the brigade, and keep the quality bar steady while the work moves faster than ever.