Start With the Premise

I talked to a company recently that is early in all of this. They are getting started, they are sorting out what to use and how, and they are not seeing much benefit yet. They have a lot of motion and not much return.

They are not doing anything wrong, exactly. They are doing what seems obviously correct: adding agentic capability to the way they already work. That is the trap. It's adoption, but not effective adoption, and won't get you where you need to be.

The clearest example is using an IDE. An engineer opens the same editor they have used for a decade, and now an agent panel is in it. They ask the agent to write a function. It writes the function. They read it, fix it, move on to the next function. Nothing about the day has changed except that the typing got faster. From inside that experience, the honest conclusion is that this technology is mildly useful and wildly overhyped.

I understand why they land there. If your context is a file, and your unit of work is a function, then an agent is an autocomplete with opinions. That is genuinely all it can be from that position. The problem is not the assessment. The problem is the position. And it is not really the IDE either. The unit of work, and the engineer's relationship to that work, have fundamentally changed in a way that requires tooling and approaches to change. Realizing that isn't easy.

We are further along at Whitepages. Not because we are smarter, but because we started somewhere else. We started by accepting that engineering itself changed, and that everything around it therefore has to change too. How we changed is ours. It came out of our people, our stack, and our particular history. It probably will not transfer to you cleanly. But the underlying change isn't a matter of taste, and I haven't found a way around it.

So this piece is not a playbook. It is the four things I think you have to accept before any playbook, yours or mine, will do you any good. And they are not four independent observations. They are parts of the same system.

Human time is the expensive resource now

This is the one that reorganizes everything else, so start here.

We have been buying machine time to save human time for decades. Compilers, garbage collection, CI, the cloud. None of that is new. What is new is how much of that work is now purchasable. Two years ago, understanding an unfamiliar subsystem or standing up realistic test data required an engineer's attention and nothing else would do. Today a great deal of that can be delegated for pennies while the engineer does something that actually needs them.

Your engineers are now the scarce, costly input. More precisely, their attention is. The important change is that human attention and the execution of engineering work no longer have to be coupled. An engineer can initiate work, disengage, and return when something actually requires judgment. That was not generally possible before, and it changes the economics of almost everything we do.

Everything they do that an agent could have done is expensive capacity spent on cheap work. Need to understand how an unfamiliar subsystem behaves? Have the agent go read it and report back. Need a test database populated with realistic data? Have the agent build it. Need to know whether three libraries handle a case the same way? Do not go read three sets of docs. Send the agent.

The instinct to just do it yourself because it will only take twenty minutes is the single most expensive habit in engineering right now.

Of course delegation has a cost. Giving direction, checking results, correcting mistakes. Sometimes doing the thing yourself really is cheaper. But the comparison is no longer how quickly you can execute the task. It is how much of your attention the task consumes, and whether that attention was necessary in the first place.

The job is judgment, and it has two rhythms

If agents do the work, what is left is deciding what the work is and deciding whether it came out right. That is judgment, and in practice it arrives in two very different rhythms.

The long rhythm is the spec. Defining what should be built, with enough precision for an agent to act on it, is real work, and it takes real time. It is deep, uninterrupted, and it uses all of you. Deep specification does not parallelize inside a human head. You can have three specs open, sure, but you are only actually thinking about one of them, and the other two are waiting.

The short rhythm is driving. Once a spec exists, the work becomes check and answer, check and answer, check and answer. Each individual moment is shallow. It asks for a decision, not a design. The work has changed from sustained execution to intermittent judgment, and that is precisely what makes concurrency possible. Our seniors run somewhere between ten and twenty concurrent stacks. That number is not a brag; it is a consequence of accepting and embracing this change in how we work. If the unit of work were still sustained execution, it would be impossible.

But that concurrency depends on something important. The work has to be able to progress without you. An agent that needs to ask you a question every thirty seconds is not working independently. It is consuming your attention in smaller, more irritating increments.

And the cost is worse than the time spent answering. Every poorly framed question forces you to reconstruct context you had already left behind. Multiply that by ten concurrent stacks, and you are no longer making decisions. You are constantly rebuilding mental models of work that was supposed to be happening without you. Interruptions don't just consume attention. They degrade the quality of the judgment you have left.

A useful question arrives with enough context to make a decision. A bad one hands you an investigation. The agent should have done the investigation before coming back. What you want is not an agent that never asks questions, but one that only asks questions worth your attention.

That independence is not something you get just by using a better model. It requires the agent to have a way to make progress and determine whether that progress is correct. I'll come back to that.

The two rhythms have opposite requirements, which is why trying to serve both with one posture fails. The spec needs you protected from interruption. The driving is nothing but interruption, and wants to be interrupted well.

Tooling exists to broker your attention

Once you see the two rhythms, what tooling is for becomes obvious, and it is not what your editor is for.

Your tools have one job now. Tell you when a decision needs you, and give you enough context to make it cheaply. That is it. An editor assumes your attention belongs to the artifact in front of you. Agentic work assumes your attention belongs wherever judgment is currently required. Those are different organizing principles, and no amount of panel real estate turns one into the other.

Our tools are all built on this. TRM, our Terminal Review Monitor, keeps the review queue visible and shows each engineer which reviews or responses are waiting on them. Stack handles the progression of work through the stack, including what happens after a PR merges. Neither helps anyone write code. They exist to keep humans focused on the work that actually requires them.

They work well for us. They might work for you. I would not bet on it, and I would not start there.

Independence requires oracles

This is the piece that makes the rest possible.

An agent can only work independently if it has some way to determine whether what it is doing is correct. Otherwise, it has to come back to a human to find out. And if every agent has to come back to a human for verification, you have not eliminated the bottleneck. You have moved it from execution to review.

Agents do their best work inside guardrails, against oracles, with fast and unambiguous feedback. They do their worst work when the definition of correct lives in a person's head or in the vibes of a prompt.

The spec tells the agent what success looks like. The oracles let it determine whether it is getting there. Those are different jobs, and you need both. A beautifully written spec without a way to check the result still leaves the agent guessing, or asking you. Neither scales.

So push correctness down into things that check themselves. Into the type system. Into the linter. Into the tests, the CI, the schema, the automation. Every rule that exists only as a convention someone learned in code review or a sentence in AGENTS.md is a rule that will be violated at scale, quietly, forever, and the only backstop is a human reading diffs.

This changes what language and stack choices are worth. They were never purely preference, but the weighting has moved. Types, schemas, linters, deterministic builds, fast tests, and anything else machine-checkable are worth more than they were two years ago, because every invariant the machine enforces is one less thing a human has to watch.

And there is a compounding effect here. The more an agent can verify for itself, the longer it can work independently. The longer it can work independently, the less frequently it needs a human. The less frequently it needs a human, the more concurrent work that human can direct. That is where the leverage comes from. Not from faster code generation, but from reducing the amount of human attention required to produce correct work.

This does not mean everything can be mechanically verified. A test can tell you that the software behaves as specified. It cannot tell you that the specification was the right thing to build. That remains judgment. But there is an enormous amount of verification between those two boundaries that we historically asked humans to perform, and we should stop doing that.

The general rule: if a check can be deterministic, it must be. Human review is the most expensive verification mechanism you have. Spend it only where nothing else can go.

And this isn't a temporary accommodation for unreliable agents. More capable agents will need less correction, certainly. But correctness you can establish independently is still more valuable than correctness you have to trust an agent to recognize. Better agents make the system more effective. They do not eliminate the need for oracles.

What you build on top of this is yours

Those are the four. Human attention is the expensive resource, so it should be spent on judgment rather than execution. Judgment arrives in two rhythms, so tools should route it rather than help you execute. And none of that scales unless agents can work independently, which requires oracles that let them verify their own progress without constantly returning to a human.

These are not separate improvements to the engineering process. They reinforce each other. If the work cannot proceed independently, concurrency becomes interruption. If correctness cannot be established mechanically, review consumes the attention you saved on execution. If your tools cannot broker attention, the engineer becomes the scheduler for a collection of agents. And if you never change what the engineer spends their attention on, you have simply made the old process faster.

Everything we have built at Whitepages is downstream of those, and everything you build should be downstream of them too, and the two will not look alike. Your culture is different. Your codebase is different. Your people are different.

This is also a journey, not a destination. If we are at an eight and you are at a two, some of what works for us right now will simply not work where you are standing.

I used to think that meant you had to walk through three, four, five, six, and seven. I am less sure now. Maybe you can skip levels. If you can, please do. There is no prize for suffering through lessons someone else already paid for. I honestly don't know whether the intermediate steps are load-bearing or just a historical accident, and you'll have to make that call yourself.

But there is a difference between skipping the path and skipping the foundation. You might not need our tooling, our workflow, or the intermediate organizational changes we made along the way. You do need a way for agents to establish correctness without constantly returning to a human. Without that, they cannot work independently, and without independence, concurrency is just a more expensive way to interrupt your engineers.

What I am confident about is the four. They have held for a while now. They might not hold next year. But if you build around them today, you are likely to see something real. And if instead you bolt agents onto the way your engineers already work, you will get faster typing, faster searching, faster function-writing, and surprisingly little leverage. You will have adopted the technology and insulated yourself from the change.