The Pass: Agentic Engineering

We are entering a different era of software development. You are no longer the line cook standing over the stove. You are the executive chef at the pass, the station in a kitchen where every dish is inspected before it leaves, directing a brigade of sous-chefs who handle the mechanical work: chopping, prepping, and plating. In engineering, agents are those sous-chefs. They compile, run tests, and retry at high speed and high volume so you can stay focused on direction and standards. Your job is to decide what gets built, in what order, and to what standard.

That is the new rhythm of engineering.

We are shifting how we build software because the tools have changed. Our leverage has gone up. 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, hunted every missing dependency. The work was artisanal: each step was done manually, even when predictable.

In the new model, agents handle the prep and the plating: the repetitive edits, the refactors, the test runs, the obvious fixes. You still own the meal. You still decide what leaves the kitchen. But your hands are no longer on every pan.

This is not less engineering. It is engineering at a higher altitude. You may not type a single line of code in a given session. You may not personally design every subsystem. But you remain accountable for all of it. You examine. You judge. You direct. You course-correct. You uphold standards.

Your value shifts from labor to leadership.

And the tools you use and how you use them must match that shift.

Note: The executive-chef metaphor traces back to Steve Yegge's "Vibe Coding" and is quoted in IT Revolution's article "You're the Head Chef, Not a Line Cook."

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. The pride of knowing every line came from your hands. Those losses are real. 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. You still own correctness. You still read code with judgment. You still make architectural calls and 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, such as Claude Code and Codex, operate natively in the terminal. This is not an aesthetic choice or a throwback to earlier computing. It is a practical necessity: the terminal is where agents and humans can see the same ground truth.

Agents operate on direct system output. They read compiler messages, test results, and error logs exactly as the toolchain produces them. When you work in the terminal, you see what the agent sees. That alignment eliminates a major source of friction in agentic workflows.

You read stdout. The agent reads stdout. You verify via ls and grep. The agent verifies via ls and grep. This shared environment is not just convenient; it is essential for effective oversight.

In traditional development, IDEs provide tremendous value through features like intelligent autocomplete, integrated debugging, and visual navigation. These tools remain effective for hands-on coding. But in agentic workflows, where you are primarily overseeing rather than typing, the IDE's interpretation layer can create a gap between what you see and what the agent is working from.

A concrete example: an IDE might show you a type error from its own language server before you've even saved the file. Meanwhile, the agent is working from the actual compiler's output, which might present the error differently or flag additional issues. When these versions diverge, you lose the tight feedback loop that makes oversight effective.

The terminal shows the compiler's actual words, the toolchain's actual behavior, and the system's real state. This is the source of truth your agents work from. When you work in the same environment, you eliminate translation overhead. You see what the agent sees. You understand its choices. You catch its drift the moment it begins.

From a UNIX perspective, this was always inevitable. The operating system is the IDE. The shell is the lingua franca. Tools coordinate through composable commands, clean text streams, and observable output. Agents thrive in this environment because it is composable, scriptable, and transparent.

The terminal is where the system's real behavior shows itself. Every command, log, compiler complaint, and test result appears without filters or interpretation. In kitchen terms, this is the pass, the station where truth hits the counter before anything moves forward. It is the moment where you see what is actually happening and decide what comes next.

Working in the terminal keeps you connected to the heartbeat of the project. You watch agents operate in real time. You see the failures as they happen. You track how the system responds. You stay in conversation with the work instead of waiting for a summary.

A simple setup works: two panes. On the left, the agent's session: every command, every retry, the full narrative of its work. On the right, your editor. You read files, pivot contexts, run your own commands, and make corrections when needed.

You move between them the way a chef moves between the pass and the line. You see the agent hit an error. You open the file. You understand the context. You decide 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 reruns the tests. You watch this cycle complete. The tests pass. You review the diff. The error handling is correct, consistent with the codebase's patterns, and doesn't introduce edge cases. 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. Your job is to see.

You oversee the agent. It prepares code, runs tests, interprets errors, tries fresh approaches, and proposes changes. You watch this unfold. You decide when it is correct. You decide when it needs guidance. You decide when to throw the work out and reset.

You remain the arbiter of quality.

The terminal matters here because it shows you the agent's actual thinking. You see the failures it hits, the paths it tries, the boundaries of its competence. You are watching the work at the same fidelity the agent sees it.

What Bad Oversight Looks Like

Bad oversight shows up quickly: letting the agent run unattended, assuming it will sort things out without intervention. 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. Treating it like a senior engineer and expecting judgment it does not have.

These habits do not 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. 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. You 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 does not spend twenty minutes digging the wrong hole.

Recognizing When the Agent Is Stuck

Agents fail in predictable ways:

Loop failure: doing the same thing again, expecting a different result.

Drift failure: chasing a related but incorrect problem.

Context failure: missing a key piece of information and guessing wrong.

Overcorrection failure: fixing things that were not broken.

When you see these patterns, you intervene. You do not let the agent burn cycles. You reset, clarify, or take over the part that is blocking progress.

This is not passive work. It is focused and fast.

Instruction vs. Intervention

A simple rule helps:

• If the agent is missing context, instruct.
• If it repeats a mistake, intervene.
• If it drifts, instruct with tighter constraints.
• If its reasoning is fundamentally wrong, intervene.
• If it is close but slightly off, provide more specific instructions.
• If it is generating churn, intervene and fix the root cause yourself.

Instruct when more clarity will help it succeed. Intervene when it cannot succeed without you.

The New Shape of Engineering

The role is changing, but the fundamentals remain the same. You still own clarity, intent, correctness, and direction. What has changed is the leverage. Agents expand what you can tackle. The terminal keeps you grounded in what is actually happening. Your oversight is what turns that combination into reliable progress.

The engineers who thrive in this era will not be the ones who cling to every keystroke. They 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.

The question is not whether this shift is coming. It is whether you are willing to operate at this new altitude—to value judgment over keystrokes, to maintain technical depth while delegating execution, and to become the kind of engineer who can direct leverage without losing sight of quality.