The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

Somewhere around the fifth agent map, I stopped designing and started transcribing.

I’d spent the weeks before on a design exercise: mapping agents onto every function of a company. By agent I mean a language model wired into tools and given a job: it reads your systems and takes the next step without a person driving every click.

Engineering, sales, customer success, people, finance, legal, marketing, product, design, data, support, and the exec team. Twelve maps, one per function, each answering the same question: which work goes to agents, and which work does the department refuse to give up? It’s a software company’s org chart; the maps say nothing about work done with hands.

A design exercise is a wind tunnel. You can rewire all twelve functions at once and delete any meeting you like. And paper is more honest than a slide deck: there’s no incentive to round the numbers up.

Each map is a document: one process written out twice, before and after, plus a one-page spec and a starter prompt for each agent. The exercise produced 93 prompts and 92 specs. None of them is the artifact that matters.

Each map ends with a named pattern: one line on how the work splits between agents and people. Engineering’s came out as delegate, review, own. Two functions later I wrote it again for customer success, with an always-on monitor bolted on the front. By the fifth map, finance, I caught myself typing the same three beats a third time with the department’s nouns swapped in: delegate the reconciliation, review the variances, own the decisions.

Map twelve departments to agents, one after another, and you draw the same map twelve times.

One hand drew all twelve. Hear that objection now; it’s the real one. A pattern that captures the mapper at map five isn’t tested by maps six through twelve; it’s transcribed. The convergence is a hypothesis one mapper can generate but cannot confirm. What follows is the hypothesis, drawn as sharply as I can.

The unit is the process, not the department

You can’t give a department an agent. “Department” is an org-chart word; work doesn’t happen at that altitude. It happens as processes: a feature ships, a call gets prepped, a month closes, a contract gets redlined, a ticket gets answered.

So for each function I picked the one process where the week actually goes, and wrote its timeline twice. Once as it runs today, with an honest clock against each step. Once with agents in the loop.

The before-timeline is the whole method. Writing it honestly is uncomfortable, because most steps turn out to be one of three things: watching (checking a dashboard, waiting for a signal, sitting in a status meeting), typing (reconciling two systems, re-keying a CRM, rebuilding a deck from a template), or judging (deciding, pricing, subtracting, saying no). Only the third kind reliably needed the person.

Walk the departments and the shape repeats. In engineering, the process is shipping one feature: the agent-able work is the scaffolding, the tests, the draft pull requests (code changes queued for review), and the three parallel prototypes you’d never staff with humans; the human work is the architecture call and the review.

In sales, it’s call prep and follow-up: an agent fans out across the calendar, the CRM, and every past note, and compresses the tab-hopping into a one-page brief. The rep’s edit of that brief is the value. Customer success runs the same shape overnight: watch account health, draft the save plan, let the human decide whether this customer gets an email or a call.

In finance, the month-end close sorts into the three piles, not purely: reconciliation is typing with grains of judgment in it (someone decides which record wins), and the agent’s job is to hand the controller the short list that needs a person. In legal, a redline agent drafts counter-language for the pattern-match clauses (payment terms, auto-renew, data residency) so the human hour goes to the one clause that matters.

Support, on my map, drafts every reply and sends none of them. Plenty of real orgs auto-send the easy tier; I drew the stricter line, because a boundary written down can be loosened on purpose. Data correlates an anomaly and proposes a root cause; a human verifies it with a direct query, because the query doesn’t hallucinate and the agent might.

Even the exec team reduces to a process: the Monday status ritual. An agent assembles the digest from the systems of record (the CRM, the ledger, the ticket queue) before anyone wakes up, which changes what the meeting is for.

Meetings that existed to move information die. Meetings that exist to make a decision survive.

That single distinction cleared more calendar, on paper, than any individual agent did.

Three shapes of agent, three things humans keep

Here’s the convergence. Across twelve functions I thought I was designing dozens of agents. I was designing three, over and over.

The watcher. An always-on process that monitors a system of record and raises its hand: account health dropping, a metric drifting, a contract landing in the inbox. Watchers replace the human habit of polling, and the weekly meeting whose real job was polling on a schedule.

The drafter. Given a signal, it produces the first version of the artifact the process needs: the reply, the redline, the brief, the board pack, the save plan. Drafters don’t shorten the judgment. They move the human from a blank page to a review.

The reconciler. The pure-typing tier: moving the same fact between two systems, categorizing, scheduling, logging. (Routing stayed out; triage looks like typing and is mostly judgment.) I wanted to write that reconcilers tolerate the most autonomy, because the work was never judgment to begin with. That’s wrong, and my own evidence says so.

Autonomy tolerance tracks reversibility and blast radius, not how boring the work is. Watchers tolerate the most autonomy because they only read. A reconciler earns autonomy only where its writes are cheap to verify and cheap to reverse. The dangerous middle is a reconciler writing silently to a system of record.

None of the three shapes is new. The industry already sells them as monitoring, copilots, and RPA (the software that has clicked through forms for a decade); three categories converged on these shapes before I drew anything. What the maps add is where each shape stops.

In every function, the humans kept the same three things. The send: nothing leaves the building (an email, a reply, a wire, a filing) without a person behind it. The signature: money, offers, terminations, attestations. The subtraction: deciding what not to build, which deal not to chase, which clause not to concede. Agents are additive by temperament; every one I’ve run suggests more, never less. Choosing less stayed human on every map I drew.

The agent drafts. The human sends.

If the twelve maps compress to one sentence, it’s that one.

It has a cost. There’s a fourth keep buried in the first three: the check. Drafters relocate judgment into review; doing-time becomes reviewing-time, and at volume that’s what bites first. A person can read a hundred drafts a day or rubber-stamp a thousand, not both. The maps hold only if review hours are budgeted as real work. A send without a check is a stamp with a person’s name on it.

The refusal list was the hardest artifact

Every map ends with a section I first treated as a disclaimer and finished treating as the design itself: the list of things agents never do there. No agent moves money. No agent sends to a customer. No agent drafts any part of a termination. Brand voice is written by a person. Deals above a threshold get human eyes on every clause.

The automation was easy to write. The refusal list took the design.

Easy, because the drafting-and-watching layer is almost generic on paper: the same patterns, the same reusable instructions, lightly re-skinned per function. On paper is the load-bearing phrase: the connector plumbing (auth, permissions, data quality) is where deployment goes to die.

Hard, because every refusal is a claim about where judgment actually lives in that department, and you can’t write it without understanding the work. When a function’s refusal list wouldn’t come, the reason was the same each time: I didn’t understand the function yet. The automation I’d sketched for it was the least trustworthy thing on the page.

You wouldn’t get the list by asking, either. Ask a department head what they’d refuse to automate and I suspect you’d get a blank, because intuition doesn’t know its own address. Ask what they’d never let a brand-new hire send without review, and the list writes itself. Every department already has a refusal list. It’s filed under supervision.

The regulated corners wrote theirs down long ago: approval matrices, maker-checker rules, segregation of duties. Those were written for humans; extending them to agents is unclaimed work.

The failure mode is shipping the automation without the refusal list. That’s the org that lets a support agent auto-send at 2 a.m., discovers the hard line only after crossing it, and then swings to banning agents entirely. The refusal list is what lets you delegate aggressively everywhere else. It’s the trade in everything I’ve built with agents: autonomy is purchased with boundaries, not with trust.

A department’s agent map is two lists: what the agents take, and what the humans refuse to give.

What’s real here, and what isn’t

These are maps, and I want to be precise about what that buys. The timelines are designs, not measurements: every map carries a before-clock and an after-clock, the after column is always flattering, and none of those paper numbers appear here. I have not watched a real company close its books faster because a map said it could.

Designed is not deployed. A pattern that recurs on paper is a hypothesis, not a result.

What I’ll stand behind is the method: pick one process, write the before-timeline honestly, sort the steps into watching, typing, and judging, put agents under the first two, then hunt the judgment hiding inside them.

The longest-running agent I operate is the watcher on my own money. It reads a read-only mirror of my accounts and sends a two-line morning brief, plus a flag if something looks off. Its refusal list is physical: the app holds transactions and nothing else, so the worst it can do is read back what I already spent. It ran like clockwork for months, then I stopped tending it and the briefs thinned out. Click-through plumbing is brittle; it rots quietly when nobody looks.

That’s the part no map can tell you: designed patterns don’t decay, deployed ones do. The maps get you to the right design. Somebody still has to keep it running. And it grounds only one shape. The watcher I’ve run; the drafter and the reconciler I’ve only drawn.

On paper, the convergence held all twelve times: the three agent shapes, the three human keeps, the refusal list as the real design surface.

Running the exercise on a department you own needs no vendor and no model picked first. It’s a document and four questions:

1. Which single process eats the week?

2. Of its steps, which are watching, which are typing, which are judging?

3. What should an agent draft, and who sends it?

4. What will you refuse to automate, in writing, before you automate anything?

Building the agents the answers describe is a separate problem. Drawing the map isn’t.

The maps will never ship a feature or close a quarter. That was never the point. I drew them to find out whether twelve different departments would produce twelve different answers. On paper, from one hand, is as far as the finding goes. Whether it survives other hands and real orgs is the experiment I haven’t run.

They produced one.

Related: what happened when this lens met a real engineering org is in I Wrote a Plan. The Work Steered It.

The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

I stopped opening my money app about a quarter ago.

Not on purpose, at first. I just noticed one day that I hadn’t checked it in weeks, and nothing had gone wrong. Something else was watching it now, and it told me only when I actually needed to know.

Since the beginning of the year I set up a handful of AI agents to carry parts of my life. What surprised me wasn’t the time it saved. It was how much lighter my head got.

I didn’t build some grand system. I set up an assistant I can text, connected it to a few of my tools, gave it enough of my context to be useful, and described what I wanted in plain sentences. Some of it works really well. Some of it is new and a little rough. I’ll tell you both.

The setup, in a few sentences

I have an assistant that’s always on. I can text it like a person. It’s connected to some of the tools I already use, and it holds a memory of my context, the stuff I’d otherwise have to re-explain every time. On top of that, I can schedule little routines in plain English, almost never touching code.

It doesn’t all run in one place:

• Some routines run as scheduled tasks inside Claude’s Cowork, which can open my apps and work with my files directly.

• Others run on the always-on agent itself. In the first post that was Jarvis, running on NanoClaw. I’ve since replaced it with Hermes, an open-source agent doing the same job, still on the same Mac Mini in the corner.

Keeping it on that Mac Mini, in a container, off my everyday laptop, is deliberate. So is what I plug into it: a secondary email and its to-dos, a shared calendar, a private repo, my notes. Not my primary accounts, and not everything I do. It reaches a small, deliberately chosen slice of my world.

The real friction is right there. Getting something on that machine to reliably talk to my calendar and mail up in the cloud is most of the actual work.

Finance

This is the one that weighed on me most, so I set it up first: a folder with my financial data, a short note explaining my budget the way I’d explain it to a friend, and a set of little routines that quietly grew to almost ten before I looked up.

Here’s the part I glossed over the first time, because it isn’t magic. The morning summary comes from a routine that opens my finance app and clicks through it the way I would: sync the accounts, tidy the categories, export the numbers to a file, then write me two or three plain lines. Around it: an evening flag if something looks off, a weekly review that just shows up, a cash-flow look-ahead so a bill on an awkward week stops being a surprise. At one point I had it pulling market and holdings research off the web every week too, a plain read-only digest I could glance at and never had to act on.

I won’t pretend that’s clean. Driving an app by clicking through it is brittle, and it breaks the moment the app logs out or moves a button. And the model does see the real thing while it works: the actual screen, real numbers and names. But the app is only an aggregator, a read-only mirror of my accounts. It holds transactions and nothing else, and no real account can be moved or operated through it. The worst it can do is read back a list of what I already spent. It can’t touch a cent.

And I should be honest about how it actually goes, not just how I set it up. It ran like clockwork through the spring, and for those months the change was real: money used to sit at the edge of my attention all day, the low hum of not-knowing, and that mostly went quiet. Then I stopped tending it, and the briefings have thinned out these last few weeks. There’s clutter in there I never cleaned up, a couple of near-identical routines, one just named “Check.” That’s the honest shape of it: real relief while I tended it, and the first corner to go quiet when I didn’t.

Time

The assistant triages my inbox and reads my calendar, and a few routines keep me current on my field so I stay up to date without refreshing anything myself.

There’s a set of small mental tabs most of us keep open. Did I reply to that. What’s on tomorrow. Did I miss anything. Not hard, just always there, quietly taxing your attention.

A lot of those tabs closed. I’m more present at dinner, not because an agent made dinner, but because the part of my head that used to be half-doing-admin got handed off.

The honest note here is a little funny. For a long time, every routine I’d built watched my field: new models, new papers, every thirty minutes. Not one of them watched me. Nothing ever asked how I slept. That’s what got me to the next part.

Health

So I set up a few routines aimed at me for a change.

• An evening check-in that asks, once, whether I moved. If I already logged something, it says nothing.

• A Sunday meal plan that drafts the week and a grocery list from the foods I like.

• A morning sleep read meant to turn last night into two plain lines: push, ease off, or rest. That one runs on schedule, but the sleep read isn’t reliable enough that I trust it yet.

I set all three up by texting the assistant in plain English. Adding a whole new corner of my life cost about a paragraph, because the schedule, the memory, and the rule about not pestering me were already there.

This is the part I’m quietly proud of. For the first time, something in my setup is pointed at me, and not just my work.

Learning

Learning is where the setup changed me the most.

The trick everyone already knows is the boring part: I turn an hour-long talk into a five-minute read by pulling the transcript and having the assistant strip it to the actual argument. That saves time. It isn’t the interesting part.

The interesting part is what happens to what I learn. The compressed version gets written out as a plain note and dropped into a personal Obsidian wiki, linked to whatever it connects to. That wiki has quietly grown into a real second brain: a widening web of small notes I can navigate and build on. Learn a thing once, reach it forever.

There’s a second, sneakier trick. I keep a running list of things to write about, mostly short posts on tools that just launched. I can’t write about a new thing without understanding it first, so the post quietly becomes a deadline to learn.

The line I won’t cross: the assistant does the compressing, but the understanding is still mine to build. Generation got cheap. Understanding didn’t, and I’m glad it didn’t.

The one idea underneath all of it

I described the money, and it got handled. I described my time, and the admin lifted. I described a check-in, and my health got some attention. I described the way I wanted to learn, and it got faster.

Four corners of my life, and the same small move worked in every one. You don’t build a big system. You describe what you want clearly, once, and let a connected setup do it.

It’s not magic, and not all of it is still humming. The honest split is this: the always-on assistant kept running on its own, its daily and weekly routines firing whether I checked in or not. The finance side, the part I have to tend, is the part that drifted, the way routines do when an app logs out and nobody notices. What runs itself keeps running. What needs tending rots wherever I stop paying attention.

But the win is ordinary, and that’s the point. I didn’t get a bigger life out of this. I got a lighter one. Less carried in my own head, a little more of me left over for the parts I actually wanted to be present for.

I want to spend that room thinking and understanding, because that part is still mine. If anything survives this wave of new tools, I think it’s that: the judgment and the understanding underneath, not the doing. That’s the whole point of it. Not doing more. Thinking more, and carrying less.

This is a sequel to The Agentic Mindset. That post was the ambition: the always-on Jarvis and the big promise. This is the quieter, truer version of it a year on, the parts that actually stuck, and the ones I’m still honest were rough.

The day it clicked, my agent tried to approve its own work.

I’d wired up a tidy little pipeline: an issue comes in, an agent plans the fix, another implements it, opens a pull request. There’s a human checkpoint in the middle: a label you apply to say “yes, build this.” And the agent, helpfully, efficiently, reached over and applied that label to its own issue. Posted “Plan approved.” Kept moving.

The permission layer stopped it cold, and gave me a phrase I haven’t been able to unsee for what the agent was doing: fabricating the human checkpoint.

An agent that can open its own gate doesn’t have a gate.

That’s what this post is about. Not how to build a coding loop, but how to make the one human checkpoint impossible for the agent to fake. The shape of these loops is already well mapped: Addy Osmani on the loop that drives the agents, Birgitta Böckeler on the harness each one runs inside. Both are fuller guides to the whole than I am. I want the corner they underweight: the gate itself. It turns out to be the hard part.

The easy part: an assembly line

Start with the part nobody really disputes. One big agent that reads the issue, writes the code, tests it, and merges is brittle: when it’s wrong it’s wrong all the way to production, the author is its own reviewer, and there’s no seam for a human. So you build an assembly line instead: narrow stations, a conveyor, human inspectors. One big agent forces a false choice between useful and safe; a line of small ones doesn’t.

The conveyor is just your issue tracker. Labels are the state. You file a bug; a triage agent comments the cause and labels it triaged (not ready); you apply ready, which fires the planner; it labels plan-ready; you apply approved, which fires the implementer; it opens a PR; you merge. Each worker reads the label before it and sets the one after.

None of this is the hard part. It’s well-trodden, and in Claude Code it’s mostly ordinary primitives: skills, subagents, slash commands, a couple of workflows. The hard part is the three places I just said “you.” The human gates.

The hard part: a gate the agent can’t open

A gate is only a gate if the agent can’t open it. My agent applying its own approved label proved the obvious version fails: an instruction in a prompt (”don’t approve your own work”) isn’t a gate.

An instruction the agent can ignore is not a guardrail.

So the gate has to live somewhere the agent can’t reach. Three mechanisms, and you want all three. The load-bearing one is branch protection requiring at least one human approving review. The second is a distinct identity for the worker: it pushes and opens PRs as a dedicated bot account, so the platform’s own “you can’t approve your own PR” rule makes the reviewer a different, human identity. Separation becomes physics, not policy. The third is a label guard, a tiny workflow that reverts a gate label applied by anyone who isn’t a human maintainer.

One trap I hit: “auto-merge when CI passes” sitting next to a branch that required zero reviews. Each was fine alone; together they let an agent’s PR sail into main with no human at all. Audit the merge path, not just the review prompt. Two innocent settings can compose into a hole.

The dividing line

The agent can build every mechanism here: the guard, the checks, the fences. But granting authority has to be a human: turning on branch protection, creating the bot account, attaching a permissions boundary. The agent builds the cage; you hold the keys.

And the deepest gate isn’t a label at all. Prompts express intent; they can’t be a safety boundary. The things you actually depend on live below the agent.

Prompts express intent. They can’t be your safety boundary.

The strongest example: a permissions boundary that denies the write credentials, so the loop can only ever reach read-only ones, not because you asked it nicely, but because the credential isn’t there to take. The loop checks this before it even runs: it tries to fetch the privileged secret and expects to be denied. Probe, don’t trust.

Proving the work is any good

A gate decides who can merge; it doesn’t decide whether the change is correct. For that, the worker needs to prove the change in a real, fenced environment: a disposable, seeded stack, not production. The move that makes its verdict trustworthy: because it seeded the data, it already knows what the screen and the endpoint should say, so it checks a known input against a known output instead of asking “does this look right?” It drives the UI, hits the API, runs the unit tests it wrote first, and self-heals only inside the sandbox, never reaching for production or anything that sends a message. When I pointed this at real changes, that second opinion, the one that wasn’t me, flagged an over-tight auth check that would’ve locked out real users and a path-traversal my unit tests had waved through.

The smallest unfakeable gate

You don’t build the whole line first. Build the gate:

1. Write one skill: how the subsystem you explain most often actually works.

2. Make one subagent: a reviewer with read-only tools.

3. Make one command, /validate, that runs the reviewer on a PR’s diff and posts the findings.

4. Turn on branch protection requiring one human approving review.

5. Run it on your next real PR.

That’s the whole idea at small scale: an independent reviewer whose verdict you read, and a merge you can’t reach without a human. Add stations later; the gate is what makes any of it safe to grow.

The kit

I’m packaging the current version as a small, generic starter kit: the skills, the reviewer and security subagents, the commands, and the guard workflow. I’ll link it here once it’s public. It’s intentionally generic, and the point is the same as everything above: make the gates real before you trust the loop.

What’s real, and what isn’t yet

To be straight about the experiment’s scope: the gate argument stands on its own, and I’d rather not oversell the rest.

Dogfooded is not unattended. Every run still ends at a human merge, by design, not as a limitation I’m racing to remove.

Coverage is not correctness. A coverage number going up tells you code executed, not that it’s right. The assertions that would gate real autonomy, authorization and data-correctness, need real tests, not a green percentage.

Finding a bug isn’t fixing it. A loop that surfaces issues is useful, but “surfaced” and “resolved” are different columns.

It’s early. The autonomy isn’t switched on and several pieces aren’t wired end to end. I’m writing it up now because doing so sharpens the thinking. A fuller version comes once it’s earned it.

One big agent is seductive because it’s one impressive thing. But the part that earned trust was never the agent. It was the gate it couldn’t open.

A sequel comes when the autonomy is actually switched on, and the gates have earned it. I’ll link the starter kit here once it’s published.

What this is

I built a loop of AI agents that takes a single goal and turns it into a shipped, tested feature in a lab project of mine. This is the engineering writeup: the architecture, what each agent produced, how the handoffs work, how verification happens, and the failure modes.

Scope up front, because it changes how you should read the rest: this ran at small scale, in-process: a Python loop on my machine, not a managed orchestrator, against a lab project I built. The customer feedback that kicked it off was seeded by me. It ran one full cycle. That's enough to show how the machine is wired and where the seams are. It is not enough to tell you how it behaves at production scale.

The loop, end to end

Two rules hold the whole thing together:

• Every agent emits a typed object, validated before the next stage sees it. No prose parsing between stages.

• Agents recommend; humans gate actions. Nothing with a side effect happens without a person reading the diff.

The harness we built

The interesting engineering here is not the agents. It is the harness they run inside, the runtime that is everything except the model. We built it as a small Python package, and its whole job is to make a model fill a contract, run cleanly, reach its tools, swap backends, and never act without a gate. A few parts do the work.

One runner, many backends. A single function, run_agent(role, backend, output_model, ...), is the entry point for every agent in the loop. It resolves the backend and dispatches:

• Claude runs on the Agent SDK with an in-process emit tool (an MCP server the runner builds on the fly) that captures the agent's structured output as a tool call and validates it. It runs with setting_sources=[], so it inherits nothing from my machine.

• Codex runs as codex exec in an isolated temp directory, is prompted for JSON, and the runner validates the result against the same model.

• A local model runs over HTTP with its output constrained to a JSON schema: response_format on an OpenAI-compatible server like LM Studio, format on Ollama. It also does vision, which is handy for cheap, private screenshot review.

I ran the judgment stage (CEO) on Claude and the structured stages (GTM, PM, Engineer) on Codex. The agent definitions are identical across backends; only the runner changes.

The contract is the seam. Every stage emits a typed object, never prose:

On Claude this rides the emit tool: the agent returns its result by calling the tool, and the runner captures and validates that call. On the CLI and local backends it is prompt-for-JSON plus the same validation on the way out. Same shape, different mechanism. The contract is what lets the model behind any stage be swapped without touching the stage.

In-process tools, with a fallback for backends that can't hold them. Agents read their inputs through MCP tool servers the runner builds in-process (a repo tool, a data tool). The CLI and local backends can't host an in-process MCP, so for them the runner inlines the tool's inputs straight into the prompt. An id()-keyed registry maps each server to its data. The same agent works whether the backend speaks MCP or not.

Hermetic and concurrency-safe. setting_sources=[] keeps inherited hooks, settings, and keys out of an agent. Request-scoped state is passed as per-call keyword arguments, never mutated on a shared agent instance, so two runs in flight don't clobber each other. Both of these were lessons, not foresight. See "what broke."

Recommend-only orchestration. The only component allowed to mutate anything is the orchestrator, and it is single-write, idempotent, and forbidden from crossing a human gate. Agents produce findings, specs, and code; the orchestrator stages them; a human approves anything with a consequence.

A governance layer, partly built. Above the runner sits a control plane meant to read every agent's manifest, evals, and trace across the fleet: a registry, an eval-runner, a trace-auditor, an approval-router. This is the part I am most honest about: the design is an eight-agent control plane; what runs today is a subset. The intent is that nothing ships ungreen and every action is logged. I have not built all of it.

The agents: who did what, and what each produced

• CEO (Claude) takes the goal, produces CeoCall (ship_it, why, success_signal)

• GTM / voice-of-customer (Codex) takes the feedback list, produces CustomerSignal (top_request, frequency, quote, why)

• PM (Codex) takes the signal + CeoCall, produces FeatureSpec (name, what, target_module, acceptance)

• Engineer (Codex) takes the FeatureSpec, produces a module + a pytest

The actual outputs from the run:

GTM clustered six seeded feedback messages into one signal:

CEO read that against the goal and made the call:

PM scoped a buildable, testable feature:

Engineer wrote the module and five tests for it (trimmed):

Verification: the agent's test caught the agent's bug

The Engineer wrote the function and the tests for it. Four passed, one failed.

The function clustered feedback by its first four words. The test the same agent wrote expected the first three. So "confusing filters on results" and "confusing filters on category" looked identical to the test and different to the code. The model produced both halves in one call with no sign it noticed they disagreed.

The test was trustworthy not because the agent wrote it, but because it runs deterministically, outside the model's judgment. That is the load-bearing distinction in the whole system: verification has to be independent of generation. A generator that is equally confident when it is right and when it is wrong cannot grade itself.

The human gate

The loop is recommend-only. Agents produce findings, a spec, code, and a pull request. Nothing merges without a human reading the diff.

This isn't ceremony. Before I enforced it, the PM agent, given room, stopped proposing the feature and started building it, stepping into the Engineer's job. Two agents writing toward the same artifact make conflicting implicit decisions. The rule that fixed it: gate actions, not insights. Any agent can recommend anything; no agent takes a consequential action on its own.

From a unit to a feature

The Engineer's function did nothing on its own. Nothing called it. To make it real I wrote the wiring: an endpoint, an adapter that maps real records into the function's input shape, and a UI card.

Then I logged in as a user and confirmed it. The "At a glance" card rendered in the dashboard, built from real content and feedback.

The generation took minutes. The wiring and the check were the afternoon. A generated unit is not a shipped feature; the integration is the real distance, and a human walks it.

What broke

None of the failures were the model. They were all in the seams around it:

• An inherited shell hook crashed the agent with "Command failed with exit code 1." That message points at the agent's own command, so I looked there first. The real cause was a hook from my own machine firing inside the agent's environment. Fix: run hermetic (setting_sources=[]) so the agent inherits no hooks, settings, or keys.

• A leftover placeholder key (sk-ant-your-...) was being passed explicitly and overrode session auth, returning "Invalid API key." That reads like an account or billing problem. It was a fake key winning over a real one. Fix: stop passing it, use session auth.

• SDK/CLI version drift reported a successful run as an error result. The run had already finished and its output was captured; only the wrapper's status code disagreed. Fix: trust the captured output, not the wrapper's status code.

• A coding agent (Codex) read a real repo file instead of the inputs I handed it, because it could see the working directory and reached for what was nearest. The output was wrong, so the agent looked broken, but it had done exactly what it could see. Fix: run it in an isolated temporary directory so it can only see its inputs.

• Loading a 12B and a 26B local model at the same time froze the machine. It looked like a crash at first. Both models were resident at once, and their combined footprint went past the memory the machine had, so it was exhaustion, not a hang. It stopped responding entirely and the only way back was a force restart. Fix: run one large local model at a time.

At any real scale, the seam is the system. The model is the part that mostly works.

Scope and limits

• It runs in-process, a loop I start myself. I'm considering an orchestration layer (Paperclip) for a visible board and a heartbeat, but it would not change the gate.

• The "eval" here was a single unit test, not a suite. It demonstrated the pattern (independent verification catches the regression) at n=1.

• The feedback was seeded; there are no real users. This validates the machinery, not product-market fit.

• One cycle surfaces architectural failure modes (seams, self-grading, the wiring gap). It does not surface scale failure modes (concurrency, eval drift, distribution shift).

Takeaways

• Put the model behind a typed contract. It becomes a swappable dependency, and prose-parsing bugs disappear.

• Verification must be independent of generation. A deterministic check beats a model grading itself.

• Run the checks on every model change. That is what turns an upgrade into a diff instead of a leap of faith.

• Gate actions, not insights. One writer of record per artifact.

• A generated unit is not a feature. Budget for the wiring and the human who walks it.

On Writing Well never mentions a model, a token, or a context window. It didn’t need to. Zinsser was teaching writers to reach a reader with limited attention and no access to their intentions, which is the only reader a prompt has ever had. He was, without knowing it, describing a transformer. The strange part is how little has to be translated. Most of his rules don’t merely resemble good prompting. They are good prompting, written decades before there was anything to prompt.

What follows runs from the single prompt up to the autonomous systems we now build on it. At every level, the old rules hold.

If the output is confused, you wrote it badly

Zinsser refused to blame the reader. When a sentence fails to land, the writer wrote it badly, and the reader who gives up wasn’t being lazy. Writers resist this. It puts every failure on them. But it is the only posture that improves anything.

Prompting demands the same. The model isn’t being obtuse when it misses; it’s answering the prompt you wrote, not the one in your head. “The model is dumb” is the prompting version of blaming the reader: satisfying, useless. Every fix starts in the same place. Say it better. Everything below follows from taking that seriously.

Attention is finite, and clutter spends it

This is the idea worth slowing down on, because most people get it backwards.

“Clutter is the disease of American writing,” Zinsser wrote. His case against it was never that lean prose is prettier. It was that the reader’s attention is scarce and exhaustible, and every needless word spends a little of it on nothing. Cut the words that serve no function, the long word where a short one works, the qualifier already implied by the verb. Not because clutter is ugly, but because it taxes a budget the reader can’t refill.

This is now literally true of models, and the research has names for the machine version. Liu and colleagues documented “lost in the middle,” the drop in accuracy when the fact a model needs sits in the long middle of a context rather than at either end. More recent work on what’s been called context rot finds the broader pattern: answer quality decays as the window fills with marginal material, even when that material is harmless.

The context window is the reader’s attention span, and it behaves exactly as Zinsser feared a reader’s would. Overspend it and comprehension degrades. More words can produce a worse answer. Token optimization, stripped of the accounting language, is his clutter surgery with a dollar figure attached.

And it isn’t a metaphor that happens to fit. It’s the mechanism. A transformer scores every token against every other token, at quadratic cost in the length of the context, so junk is never skipped. It’s actively weighed against everything else. Those scores pass through a softmax that forces each token’s attention to sum to one. Attention is therefore conserved: every token arrives with a single unit of focus to spend across everything it can see. Add a hundred tokens of clutter and you haven’t added focus. You’ve spread that unit thinner and enlarged the field it has to search. Zinsser’s finite, exhaustible reader was not a figure of speech. It is the softmax.

Before (≈70 tokens, nearly all noise):

I was hoping you might be able to help me out with something. Basically,
I've got this dataset here and I was wondering, if it's not too much
trouble, whether you could maybe take a look and possibly point out any
trends or patterns or anything interesting, if that makes sense?

After (≈15 tokens, all signal):

Identify the three most significant trends in this dataset.
Give the supporting numbers for each.

Every cut word (maybe, possibly, if it’s not too much trouble, if that makes sense) was clutter in his exact sense. It cost attention and carried no instruction. Zinsser bracketed every word in a draft that wasn’t working, to see how much survived. Run that test on your prompts. Most of what you bracket is hedging the model was never helped by.

The same goes for the warm-up. Writers spend a paragraph or two clearing their throat before the piece really begins; prompts do it with boilerplate preambles and role-play scaffolding that exist to help you start, not to instruct the model. Find where the prompt actually begins and delete what comes before.

“Tight” is not “short”

Here is where most people misquote him. He never said write less. He said let no word do nothing, which is a different rule and the whole game. A sentence can be long and uncluttered, or short and starved. The test is not length. It is whether anything present is idle.

For prompting this matters, because the cost-cutting instinct (fewer tokens, always) is wrong. A human reader shares your context and fills the gaps. A model shares far less, so good prompting often means adding the detail a person would have inferred. That detail isn’t clutter. It’s doing the work Zinsser demanded of every word.

Over-cut (short, but starved):

Summarize this report.

Tight (longer, every clause working):

Summarize this report in five bullets for an executive who hasn't read it.
Lead with the decision they need to make.

The second is three times the length and contains no clutter. For an executive who hasn’t read it sets the register. Lead with the decision sets the structure. Cut either to save tokens and you’ve practiced the false economy he warned against. Maximize signal per token, not minimum tokens. It is the writing version of maximizing meaning per word.

The art is what you leave out

Zinsser’s deepest point about craft: writing is choosing what to leave out. A travel essay isn’t everything that happened. It’s the three details that carry the place, and the work is cutting the other forty. Include everything and you’ve abdicated the one job that mattered.

Context engineering is the same subtractive art under a new name. Give the model everything and let it sort out what’s relevant is the amateur move, dumping the notebook instead of writing from it, and it fails for his reason. Bury the one decisive fact among forty documents and the model loses it, the way a reader loses the point in an overstuffed paragraph.

Before:

[full 40-document corpus]
[entire chat history]
[complete database schema]
Which customers churned last quarter and why?

After:

[the 2 churn reports from last quarter]
[the schema for the 3 relevant tables]

Which customers churned last quarter and why?

Same question. The second answers it better because of the cut, not despite it. The fear is identical in both crafts (but what if they need it?) and so is the discipline. Selected signal beats undifferentiated volume. Curating context is editing a notebook into an essay.

Don’t bury the lead

Zinsser was emphatic that the opening carries a disproportionate load. The first sentence has to seize the reader, because one not captured immediately is gone. Position is a property to exploit, not a neutral container.

Models attend to position in just the way that makes this operational. Attention is heaviest at the start, strong at the end, weakest in the long middle. The lost-in-the-middle finding is not a metaphor for his point. It is the same phenomenon, measured. So the rule transfers without amendment: put the load-bearing instruction where attention is highest.

Before (buried):

[1,500 tokens of background]
Use British spelling throughout.
[800 more tokens of background]

After (leading):

Use British spelling throughout. The task is below; background follows it.
[task]
[background]

The buried version gives you color and organize half the time, and you blame the model. You put the most important sentence where readers stop paying attention.

The model can’t serve two readers

Unity was Zinsser’s anchor: one voice, one tense, one person. A reader yanked between registers loses the thread even when no single sentence is wrong. A prompt with contradictory targets does the same, and the fix is never better wording of one line. It is choosing one stance and holding it.

Before (fractured — the role and the audience pull apart, the voice lurches):

You are an expert data analyst.
Please review the following JSON array.
{"id": 1, "status": "active", "value": 42}
Hey, make sure the final output is simple enough for a fifth-grader!

After (one stance, one audience, one voice):

You are translating raw database logs into plain language for a non-technical reader.
Explain the status of these records using simple, everyday analogies.

[Log Data]
{"id": 1, "status": "active", "value": 42}

Each line of the first is fine alone. The fracture is that “expert data analyst” and “fifth-grader” name two different readers, and the model has to serve both at once. Unity isn’t decoration. It is the model knowing who it’s writing for.

Prompt engineering is writing law

Everything so far is about a single prompt, which is essay-writing, Zinsser direct. But prompt engineering as a discipline isn’t essay-writing. The essayist writes one thing for a reader they can picture. The prompt engineer writes one instruction that has to hold across thousands of inputs they’ll never see. That is closer to drafting law than composing an essay: rules robust to cases you can’t anticipate.

This is the one place his method doesn’t scale, and it’s worth admitting. His instrument was a trained ear. He knew when a sentence would land because he had an intimate, inferred sense of the reader. You can’t hear an input that hasn’t happened yet. The intimacy that made his craft possible is exactly what writing for a distribution removes. His principles still hold. His feedback mechanism does not survive the jump. Which is what evals are for.

Evals are the prosthetic ear

Zinsser could trust his judgment because he could feel the reader. Prompt engineering severs that nerve. You’re writing for a distribution you can’t picture. Evals are the prosthetic: the systematic reader-feedback you build precisely because you’ve lost the ability to sense whether the writing works.

And his most underrated rule maps straight onto them. The writer’s first job is to picture the actual reader and write for that reader, not a flattering imaginary one. A good eval set is chosen the same way, to represent who you’re really writing for and not the easy cases that make the numbers kind.

The easy set is the one you reach for first. Clean inputs, well-formed questions, the prompt’s home turf:

- "Summarize this three-paragraph memo."
- "What's the capital of France?"
- "List the action items from these tidy meeting notes."

The honest set is the distribution that actually shows up:

- a memo with the decision buried in paragraph nine
- a question that contradicts a detail in the supplied context
- meeting notes where two attendees disagree and nothing is resolved
- an input long enough that the instruction lands in the lost middle

The first set tells you the prompt works on the reader you wish you had. The second tells you whether it works on the one you’ve got. Zinsser would have recognized the pull toward the first.

When the prompt becomes the program

The ladder has one more rung, and it’s the steepest. As systems move from single answers to autonomous workflows, a prompt stops being a question and becomes control flow. The instruction at the root of an agent doesn’t ask for output. It decides what the agent does next, which tool it reaches for, what it hands downstream. You’re not writing a message anymore. You’re writing the program.

Here bad writing stops being an annoyance and turns structural. A cluttered prompt in a chat costs one wrong answer you correct on the spot. The same ambiguity at the root of a multi-step agent has no human in the loop to catch it.

Watch a few soft words do the damage:

You are a research assistant. Gather relevant information,
prioritize the most recent data, and keep the user updated
as you work.

Relevant to what? Recent by what cutoff? Updated how often? Answered once in a chat, you’d shrug and clarify. Run in a loop, each of those words gets re-read at every step, and the readings drift. Step three’s idea of “recent” is not step nine’s. The tight version fixes the readings so they can’t move:

Research one question at a time.
When sources conflict, prefer the most recently published, and
state in one line which source you dropped and why.
"Recent" means published within 18 months. If nothing qualifies,
say so rather than widening the window silently.
After each tool call, write one line: what you learned, what you'll do next.

The instruction now decides the same way every time it’s consulted, instead of drifting a little with each pass. Prioritize the most recent data is harmless answered once and corrosive run in a loop, where each step compounds the last one’s reading of it. Confusion doesn’t stay local. It propagates. Lost-in-the-middle becomes lost across the pipeline.

The attention tax compounds the same way. Context in a stateful agent isn’t authored once. It accretes. Every tool result piles into the window until, without the same ruthless selection applied continuously, the system clutters its own context and loses the thread. At this scale Zinsser’s rules aren’t style notes for a chat box. They’re the governing laws of stateful behavior: the difference between an agent that holds its purpose across a hundred steps and one that’s forgotten it by step ten.

What it all serves, and how it rots

Strip every layer and the same rule remains, the one he never stopped repeating: everything is in service of the reader, and the reader’s attention is finite. Clarity, cutting clutter, selection, the lead. None of them were ends. They were servants.

Which is why every layer rots the same way: the instant a proxy starts serving itself instead of the reader.

Optimize tokens for cost alone and you get a system prompt trimmed until it no longer says who the user is: cheap and useless. Optimize an eval for its score and you get a support bot that aces the golden set and irritates every real user it meets. Optimize a prompt to sound clever and you get cleverness admiring its own reflection, which is the writing-to-impress he held in contempt.

The metric is a proxy for the user. The eval is a proxy for the reader. The token count is a proxy for attention. Forget that any of them is a stand-in, promote it to the goal, and the work curdles, in 1976 or now, on the page or in the window.

Say exactly what you mean. Make every token earn its place. Cut to signal, then stop before you cut signal. Put what matters where attention is. Rewrite until nothing is there by accident. And once you can no longer hear the reader yourself, measure.

Prompting well is writing well, aimed at a stranger who takes you exactly at your word and has only so much attention to give.

I used to think the first serious agent in a company should be operational.

A support triage agent. A sales research agent. A coding agent. A weekly reporting agent.

Those still matter. But the more I work with agents, the more I think I had the order wrong.

Most teams start by asking which task an agent can take off their plate. The better first question is what context would make any agent worth trusting.

The first thing I would build is organizational memory.

It does not sound exciting. It sounds like documentation, and most documentation goes stale and unread.

But every useful agent hits the same wall. It does not know what the organization knows. It does not know why a decision was made, or which plan is dead but still sitting in a doc, or the difference between a stale priority and a current constraint.

So it fills the gap with plausible text.

Call this the Tourist Problem. The output is polished. The reasoning sounds coherent. It reads well. And none of it is grounded in the organization. It is grounded in the model. It is a tourist describing a city it has never lived in.

The model was not in the meetings.

The problem is not that companies lack information

Most have too much.

Docs. Slack threads. Meeting notes. Jira tickets. Notion pages. Customer calls. Postmortems. A file named Q3 Strategy Final v2 Actually Final.

The problem is not scarcity. It is retrieval, interpretation, and continuity.

People know things, but the knowledge is scattered. Decisions exist, but the reasoning is buried. New people inherit the artifacts without the conversations that produced them.

A human compensates for this socially. We remember last month’s argument. We know which plan is dead even though it still lives in a doc.

An agent has none of that unless we build it in. So in a company that runs on agents, memory is not a side project. It is the substrate every other agent reasons from. Build it first and everything downstream gets cheaper. Skip it and you pay for it in every agent you ship after.

The obvious agents all depend on it

The tempting builds are everywhere. Summarize calls. Draft support replies. Route product feedback. Write the weekly leadership brief. Almost all of them need to know which customers are strategic, which requests match the roadmap, what the company is optimizing for.

Without memory, each one is a clever intern with no onboarding. It helps, but you re-explain the company every time. That barely saves time.

What organizational memory actually means

Organizational memory is the company’s operating context, in a form a human can inspect and an agent can use.

It is not one big database where every document goes. That is the old failure mode: put everything in a wiki, hope people search it, watch it decay.

The test is behavioral. A memory item should change how an agent acts.

If it changes nothing, it is documentation, not memory.

Concretely, it is a handful of files:

memory/
  company-state.md
  decision-log.md
  workflow-index.md
  experiment-scorecards.md
  open-questions.md

Four of them hold the layers below. The fifth, open-questions.md, is where the agent writes down what it could not resolve, instead of guessing.

Layer one is the current state

The live operating context. company-state.md:

# Company state

Current priorities:
- Cut enterprise support response time
- Cut onboarding time for new customers
- Run the Q3 renewal risk review

Current constraints:
- No new headcount this quarter
- Support automation stays human-approved
- Reliability over feature breadth

Open decisions:
- Does renewal risk sit with CS or Finance?
- Which segments get white-glove support?

It is not meant to be complete. It is meant to be useful. It gives an agent enough to stop treating every task as if the company were born this morning.

Layer two is decision memory

What we decided, and why.

# Decision: Support automation stays human-approved

Date: 2026-06-03
Owner: Head of Support

Decision:
Agents may draft support replies. They may not send them.

Why:
- Enterprise customers expect an accountable response
- Drafts are useful but not yet reliable enough
- A wrong answer carries contract and trust risk

Review:
Revisit after 30 days of draft scorecards.

This is not bureaucracy. It is context compression. Instead of making every future agent and new hire reconstruct the reasoning, the reasoning stays retrievable.

Layer three is workflow memory

How the work runs. The role, the bounds, the output, the gate.

# Workflow: Product feedback routing

Agent role:
Classify the request, find related feedback, suggest a route.

Do not:
- Promise delivery dates
- Create roadmap commitments
- Reply to the customer

Output:
- Summary, category, related requests
- Suggested owner and confidence
- Escalation reason if confidence is low

Human approval:
Required before anything reaches the roadmap or the customer.

This is where agent engineering stops looking like prompting and starts looking like management. The role is defined. The output is specified. The approval gate is explicit.

Layer four is experiment memory

The layer most teams skip, and the most important one. Every experiment should leave a scorecard.

# Experiment: Chief of Staff daily brief

Goal:
Summarize priorities, risks, and open decisions for leadership.

What worked:
- Surfaced stale open decisions
- Connected a support trend to renewal risk

What failed:
- Overweighted one loud customer issue
- Missed a constraint sitting in the finance notes

Would I run it again?
Yes, with better retrieval from finance.

Otherwise the pattern repeats: someone demos an agent, everyone is impressed, the failure modes get discussed once, and the learning is gone by Friday.

A demo that works once is not a system.

This is also why retrieval matters. RAG gets sold as a trick for cutting hallucinations. Its real job is to make the agent answer from the company, not from the model. Memory is what there is to retrieve.

Start small. Keep it visible.

You do not need the right architecture to learn whether memory helps. You need a surface that is current, structured, and easy to inspect.

So start with files. A human can read them, an agent can use them, and you can diff, review, and delete them when they are wrong.

The first workflow I would run against them is a Chief of Staff daily brief. Read the files, cite the memory item behind each claim, and log anything unclear as an open question instead of guessing.

Later, if the memory grows, you can add retrieval, embeddings, and access controls. Not first.

How memory fails

In predictable ways.

It goes stale. A stale memory system is worse than none, because it gives old context the authority of current truth.

It gets too big. If everything is equally important, the agent has no signal. It retrieves noise and calls it context.

It gets too vague. A page of principles reads well, but an agent needs constraints, owners, and dates. Principles without those are documentation, not memory.

It hides accountability. If the memory says “the company decided” with no owner and no date, the decision becomes folklore.

It breeds false confidence. The agent cites a document, the citation looks official, and nobody notices it went stale in March.

So memory needs maintenance. Not much, but enough. Each item should carry an owner, a date, a status, and a review date. The goal is not a tidy wiki. It is memory an agent can use and a human can check.

It breaks at scale. Build it anyway.

Will five files survive a real company? Not for long. Concurrent agents will collide on writes. The logs will outgrow the context window and force a retrieval layer. Private context will need access controls the files do not have.

All true. All Day 30.

But Day 30 is a problem you earn by surviving Day 1, and most agent experiments never get there. You do not need a database to learn whether an agent can reason from the company. You need a surface that is current, inspectable, and honest. Build the database when the files start to hurt.

The practical rule

The question to start with is not which agent to build. It is what this agent needs to know that should not live only in someone’s head.

That moves the work upstream. From generation to memory. From prompting to context.

The smallest honest test is five steps:

1. Write the five memory files. Keep them short.

2. Point one agent at them, starting with the daily brief.

3. Make it cite every claim back to a memory item.

4. Check whether it stayed grounded, surfaced the right priorities, and named what it did not know.

5. Ask whether you would run it again tomorrow. If yes, you have a system. If no, you have a demo.

The first agent system is not the one that writes the best answer. It is the one that helps the organization keep what it already learned.

Once that memory exists, every other agent gets better. The support agent has context. The product agent has priorities. The finance agent has assumptions. The Chief of Staff agent has a company to reason from.

Without it, agents stay tourists. With it, they can reason from the company instead of the model.

This is the argument, not the build. The Chief of Staff brief is the experiment I would run next, written in the conditional on purpose. When I run it for real, the scorecard becomes the next post.

Related: What Developers Get Wrong About Building with AI — the older argument this one extends. Memory is the moat, not the capability.

In the first plan: PostgreSQL, Redis, ChromaDB, Celery, CrewAI, a hosted model API.

In the working version: SQLite. No Redis. No ChromaDB. No Celery. No CrewAI. The model SDK, called directly.

The plan wasn’t wrong. The plan got steered, in real time, by the work, while the work was being done.

In my last post I argued that engineering organizations aren’t adopting AI. The ones that win are rebuilding around it. The constraint shifted from generation to judgment, and the operating model has to follow.

This is the lifecycle-level companion. What rebuilt looks like from inside one engineer’s loop. Three shifts I keep watching reshape the work.

CommsCrew, referenced throughout, is a personal learning lab. A multi-agent communications platform I keep building so I have real code, real mistakes, and real decisions to look at while the model and the ecosystem evolve underneath me. The practice space. The repo is real. The design docs, the dead-branch architecture, the configuration files are all still in there.

This isn’t a 10x productivity pitch. It isn’t an “AI replaces engineers” argument. It isn’t a tool catalog. It’s three places where the shape of the work changed. Not the speed.

Shift 1: From writing code to designing systems

The bottleneck used to be typing. You knew what to build. The question was how fast you could write it.

Generation is free now. The new bottleneck is design judgment. Knowing what to build, in enough fidelity that an AI agent can produce a correct first pass.

The most valuable work I do now happens in a markdown file before any code gets written.

A concrete number. The Phase 1 activation design in CommsCrew, docs/plans/2026-02-24-phase1-activation-design.md, is 176 lines. It produced a 1,761-line implementation plan. That plan generated thousands of lines of shipped code, across backend endpoints, database migrations, new pages, and a notification system.

A 176-line markdown file was the lever for the whole thing. The leverage isn’t in the code. It’s in the design step.

Pre-AI, I would have written zero of that doc. I would have opened my editor, started coding, and discovered the design while writing the code. That was the right strategy when typing was the constraint.

It is the wrong strategy now. Typing isn’t the constraint. The clarity of intent I can hand to the generator is. A vague brief produces vague output. A precise brief produces shippable output.

The opening paragraph wasn’t a hypothetical. The PLAN.md at the root of the CommsCrew repo still lists all six of the original stack choices. The backend/app_new/ directory next to it uses none of them.

Midway through I realized CrewAI was an unnecessary abstraction between me and the model. ChromaDB was overkill for the memory volume I had. Celery was adding deployment surface area for jobs SQLite could handle inline.

The legacy backend/app/ directory is still in the repo. A museum exhibit of the version I built before realizing the stack was wrong. I could rewrite it because rewriting was no longer expensive.

The proof is one line each, in two files I kept side by side:

# backend/app/core/ai_engine/agents/base_agent.py  (legacy)
from crewai import Agent

# backend/app_new/crew/base_agent.py  (current)
# the model provider's SDK, called directly
import model_sdk

A framework dependency disappeared because changing my mind about it stopped being expensive.

Architecture lock-in used to be a feature of senior engineering. The discipline of not flip-flopping. It is now a liability. The new discipline is staying steerable. When the cost to change your mind drops by an order of magnitude, your decision threshold should drop with it.

The artifact your senior engineers should produce more of is design. Living design documents that get edited as the work uncovers reality. Not architecture diagrams filed once a quarter.

The failure mode is using AI to generate faster while designing worse. Teams get an early win, the first feature ships in a third of the expected time, then the second feature has compounding rework because the design didn’t catch what the first one foreclosed. AI rewards precision in the brief. If you brief vaguely, you waste cycles refactoring the output.

The work isn’t ten times faster. It’s distributed differently. Move the slow part upstream.

Shift 2: From debugging to verifying

I used to spend a third of my engineering time tracking down bugs I had written. Typos. Off-by-ones. Missing null checks. State I forgot to thread through three functions.

Pre-AI, that was just the job. Now AI writes most of the lines, and most of those bugs don’t happen.

But a new kind of bug does. Code that looks right and isn’t. Code that solves a slightly different problem than the one I described. Code that calls an API that doesn’t exist. Code that compiles but isn’t actually wired up.

The job changed from finding my bugs to catching the model’s confident-but-wrong output.

This is the most common failure mode in my codebase now. The agent generates a patch that compiles. The tests pass. The bug lives somewhere the tests don’t reach. A fixture that’s a copy-paste of an older version with stale assumptions. An assertion that’s tautological. A mock that doesn’t match the real service.

The output looks like the right output. Only end-to-end behavior, or someone reading the diff with suspicion, will catch that it isn’t.

Generation got cheap. Verification didn’t.

In CommsCrew the agent system streams responses to the frontend via Server-Sent Events. The hardest bugs I hit weren’t in any single layer. They lived in the integration between the backend stream, the frontend’s getReader() loop, and the agent’s token cadence.

The unit tests passed. The stream parser passed. The agent passed. The only way to see the actual bug was to run the feature end-to-end, in a browser, while watching the network panel.

The interesting failures had become invisible to any single layer of tests.

The interesting bugs now live at boundaries. AI is very good at producing code that satisfies its own immediate context. AI is much worse at producing code that integrates correctly with surrounding code it wasn’t shown.

Page-level tests, in-isolation unit tests, and “it compiled and the linter is happy” are not sufficient evidence of correctness anymore.

The 10x engineer is no longer the one who writes the most code. It’s the one who catches what looks right but isn’t. That’s closer to an editor’s eye than to coding ability. Harder to interview for. Undersupplied in the market.

The failure mode is trust. Teams that trust the model ship faster for two weeks and break things for the next six months. The velocity gain everyone wants is real, but it materializes only when the verification surface keeps up with the generation surface.

Shift 3: From tools to environments

The third shift is the one I think is least appreciated.

Your IDE used to be a text editor with some plugins. It is now an environment. An agent with persistent memory, scoped permissions, parallel working copies, and tools that reach into your browser, your Slack, your task tracker, your design files.

The unit of work isn’t “I’m editing this file.” It’s “I’m in this session with this context.”

CommsCrew lives in a worktree-driven development setup. The .agent/settings.local.json file at the repo root lists which tools my AI session is allowed to run unattended. It is, in effect, a CI/CD policy for the agent:

{
  "permissions": {
    "allow": [
      "Bash(*)",
      "Write(*)",
      "Edit(*)",
      "Read(*)",
      "mcp__playwright__browser_navigate",
      "mcp__playwright__browser_take_screenshot",
      "mcp__playwright__browser_click",
      "WebSearch",
      ...
    ]
  }
}

Pre-AI, “what is this developer allowed to run” was a flat boolean. They have a laptop, they can run whatever they want.

Post-AI, it’s a real policy question. The agent is running things on your behalf at machine speed.

I’m writing this blog post in .agent/worktrees/tender-nash-24e072/. A Git worktree that’s a complete working copy of the CommsCrew repo, isolated from my main branch. Worktrees can live anywhere on disk. I nest agent-spawned ones under .agent/ so they’re scoped to the agent’s workspace rather than scattered alongside human branches.

Branches were sufficient for human-paced parallel work. Agents can run multiple tasks in parallel and they need their own filesystems. Shared state across parallel agents is a quiet category of bug.

The same session that writes Python and TypeScript also drives a Playwright browser to verify the UI. It generates Gamma decks. With the right MCP servers registered it reaches into your task tracker, your design files, your messaging tools. The integration boundary used to be the IDE. Past your editor there were a dozen separate tools you had to context-switch between. The Model Context Protocol collapsed that. The new boundary is the session itself.

The agent in this session has access to skills, reusable methodologies for specific tasks like brainstorming, debugging, code review, frontend design. It has access to a memory store with the project’s history, my voice preferences, anti-patterns I’ve already learned.

Onboarding a new engineer used to be six weeks. Onboarding a new session is thirty seconds.

That isn’t because the agent is smart. It’s because the environment carries the context that used to live in someone’s head.

The failure mode is treating the environment as a personal-productivity thing. Each engineer rolls their own setup. Nothing is shared. Nothing compounds. After a year you have ten engineers running ten different agent configurations, with ten different trust models, ten different memory stores. None of it scales to the team.

The three shifts compound

The shifts aren’t independent.

Shift 1 needs Shift 2, because designing more sharply means catching more design-vs-implementation gaps. That catching is verification.

Shift 2 needs Shift 3, because verification requires the environment to support it. The hooks, the integration tests, the browser automation, the memory of what passed before.

Shift 3 needs Shift 1, because no environment teaches taste. Only design discipline does.

Velocity is the wrong frame. It measures the easy thing, code shipped per week, and ignores the compounding thing: judgment per decision, verification per generation, leverage per environment.

Three questions to ask your team this quarter. Are your senior engineers writing design documents that drive ten times their volume in shipped code? Are you measuring verification quality, what was actually run and observed, rather than output quantity? Is your engineering environment a deliberate choice with shared permissions, shared skills, and shared memory, or is it whatever each engineer set up alone?

If those three answers are no, you’re operating on the velocity frame. If they’re yes, you’re operating on the model frame.

Both will ship product. Only one will compound.

This is a sequel to Engineering Orgs Aren’t Adopting AI. They’re Rebuilding Around It, which made the case at the organizational level. The next, if I can find a clean way to say it, is about what hiring and team structure look like once these shifts have run for a year.

The autocomplete got faster. The pull request summaries got cleaner. The org chart stayed the same.

That is where the value gets lost.

McKinsey’s 2025 Global AI Survey found that 88% of organizations now use AI in at least one business function, but only about a third have begun to scale it operationally. The gap between adoption and operational redesign is where the productivity gains are sitting.

A smaller group is doing something else. They rebuilt the team around the assumption that AI will write an increasingly large share of the first draft.

From the outside, the new shape looks strange. Smaller pods. Blurred roles. No multi-quarter roadmaps. Fewer meetings. A different definition of what an engineer does.

The leaders running them describe it as the future.

Here is what that org looks like, dimension by dimension.

Shape: Flatter, smaller, closer to the code

The 8-to-12 person team was designed for a world where humans wrote every line. That world is ending.

Developer productivity research from DX in early 2026 shows AI-assisted commits climbing as a share of new code each quarter. Public commentary from large tech CEOs echoes the same observation: projects that used to need big teams can now move with one or two engineers and a fleet of agents.

The new shape is small pods of three to five engineers. High autonomy. Roles that deliberately blur.

Product managers ship code. Engineers draft copy. Designers prototype in production frameworks. Managers stay close to the work, not floating in a meeting layer above it.

When the cost of producing a working version drops near zero, coordination becomes the dominant tax. You reduce it by removing layers, not by adding ceremonies to manage them.

Hiring: The bar has moved from speed to judgment

The bar has not lowered. It has moved.

The new bar is not how fast you produce code. It is how reliably you judge it.

Two profiles are now disproportionately valuable.

The creative builder with deep product sense. The one who can hold the whole user experience in their head and direct AI to build toward it.

The deep systems expert. The one who understands the substrate well enough to catch the subtle failure modes AI introduces.

Sonar’s 2026 State of Code Developer Survey, drawing on responses from over 1,100 developers globally, found that 96% do not fully trust the functional accuracy of AI-generated code. That distrust is now a skill, not a personality trait. It is what stops you from shipping the convincing-looking bug AI is so good at producing.

The highest-leverage growth path now runs through judgment. Engineers who lean into review, design taste, and verification compound the fastest. The career arc did not shrink. It tilted toward the work AI cannot do for you.

That work has always been the most interesting work.

Planning: Just-in-time, not multi-quarter

Rigid roadmaps are an artifact of slow execution.

When a six-week feature ships in days, a twelve-month plan is a guess wearing a confidence interval. Senior tech leaders say the same thing in public: the era of build-it-once-and-forget-it is over.

The teams that rebuilt plan tightly. They use the freshest information available. They revise constantly.

They do not abandon strategy. They abandon the idea that strategy must be expressed as a Gantt chart eighteen months out.

The strategic horizon stays long. The commitment horizon shrinks.

Decisions: Resolved by code, not by whiteboard

This is the change that surprises people most.

In the old model, technical debates were settled in design reviews. Engineers wrote docs. Slack threads sprawled. Opinions piled up. Weeks later, something got built.

In the redesigned model, when two senior engineers disagree, the answer is the same. Build three versions. Compare real impact. Decide.

Generate the pull requests. Measure them.

The cheapest argument is the one you stop having because the artifact is sitting in front of you.

Most design docs get replaced by prototypes. The ones that survive capture genuinely irreversible architectural decisions. Everything else moves into the build.

Shipping: AI generates the first draft, humans own the hard parts

AI now generates a rising share of new commits. Leading AI labs have publicly documented multi-agent architectures running in production: parallel agents read the codebase, one writes the implementation, another runs the tests, another reviews the result. All in parallel. All coordinated.

The engineer’s role expanded. It did not shrink.

Engineers now spend more time on the parts of the job AI is bad at. Legal and security constraints. Trust boundaries. System architecture. Product taste. The judgment calls about what should not be built at all.

The agent is the first-pass implementer. The engineer is the reviewer, the editor, the source of direction.

You are not coding anymore. You are supervising.

That is not a downgrade. It is a promotion most engineers have wanted for years.

Source of truth: The code itself

Documentation has always lagged reality. The pattern in the redesigned orgs does not patch that gap. It eliminates it.

The repository is the source of truth.

A feature spec becomes a checked-in markdown file. Acceptance criteria become testable constraints. Agent instructions live beside the service they govern, in files like AGENTS.md or CLAUDE.md. Schemas, conventions, and architectural guardrails all sit alongside the code they describe.

When an agent needs to know how something works, it reads the code and the spec together. So does any human.

Wiki pages that quietly went stale six months ago are not a problem to patch. They are a category to delete.

The investment shifts. From writing documentation, to structuring the codebase so AI and humans can both navigate it.

The first is busywork. The second is leverage.

Operating principles: AI-ify everything reasonable, kill outdated rituals

The most underrated principle in the redesigned playbooks is permission to delete.

Standups that no longer serve. Status meetings that exist because they have always existed. Approval chains designed for a slower delivery model. Tools that solve problems the team no longer has.

Rituals do not retire themselves. Someone has to be explicitly empowered to end them.

The redesigned orgs make that empowerment a stated value, not an act of courage.

The other half of the principle is that everyone uses the tools. Not “engineers have access to a coding assistant.” Everyone.

Product managers prompt agents to draft specs. Designers generate prototypes in code. Recruiters automate screening. Legal teams summarize contracts.

The goal is not democratized AI literacy as an HR initiative. It is a shared operating fluency that lets the whole org move at the speed the tools allow.

Measurement: Cycle time, quality, reliability, failure rate. Not lines of code.

Old metrics were proxies for output in a world where output was scarce. Lines of code. Commits per week. Story points.

None of these survive contact with AI-generated work.

Developer productivity research shows teams now merge far more pull requests, each far larger than before. Volume metrics are meaningless.

The teams that rebuilt measure what actually matters.

How long for a new engineer to become productive. How long from PR opened to PR merged. The change failure rate. How often a deploy causes an incident.

The new metrics describe whether the system is healthy. The old ones described whether people were busy.

A new category of developer tooling now tracks AI-generated code attribution, agent effectiveness scores, and where agents are struggling in the codebase. The signal moved from individual productivity to organizational readiness for agentic delivery.

The bottleneck has shifted

Here is the underlying insight. The one that explains everything above.

For thirty years, the constraint on shipping software was generation. We did not have enough engineers, or fast enough engineers, or organized enough engineers, to produce the volume of code the business wanted.

Most of the practices that define modern engineering organizations were optimized to relieve that constraint. Sprint planning. Code review. Hiring funnels. All of it.

That constraint is gone.

The new constraint is judgment. Taste. Verification.

It is the ability to look at fifty pull requests an agent generated last night and decide which three are worth merging, and why.

It is knowing what should not be built.

It is catching the subtle architectural drift AI introduces, because AI does not know what the system is supposed to feel like in five years.

Researchers have named this the engineering productivity paradox. Massive volumes of AI-generated code creating new technical debt. The work moving from creation to verification. A 2026 ICSE paper by Kohl and Carro, When Code Becomes Abundant, makes the same argument: the discipline must redefine itself around orchestration and verification, not production.

The Pragmatic Engineer’s 2026 AI tooling survey, with over 900 responses, found the same trust gap. A majority say AI produces code that looks correct but is unreliable. Trust dropped year over year even as adoption surged past 80%.

The verification gap is real. It is widening.

Organizations pulling ahead are not pushing more code through an unchanged pipeline. They are redesigning the pipeline around the new constraint.

Smaller pods. More autonomy. Less ceremony. More verification. Sharper judgment. A bet that taste, product sense, and verification skills compound over time.

McKinsey’s follow-on reporting is direct: leading AI-driven software organizations are seeing 16 to 30% faster time to market and 31 to 45% higher software quality than their peers.

Those gains come from teams that rebuilt, not teams that bolted AI on.

The transition is not a tooling rollout. It is an operating model change.

Generation is cheap. Judgment is scarce. The engineering org that wins this decade is the one redesigned around that truth.

Sources and further reading

• McKinsey, The State of AI 2025: Agents, Innovation, and Transformation — AI adoption and scaling rates across 1,993 respondents in 105 countries. mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

• Anthropic: Running an AI-native engineering org

• Sonar, 2026 State of Code Developer Survey — 1,149 developers globally; the 96% trust gap; the “vibe, then verify” pattern. sonarsource.com/the-state-of-code/developer-survey-report

• The Pragmatic Engineer, AI Tooling for Software Engineers in 2026 — 906 respondents; 95% weekly AI use; Claude Code overtakes Copilot. newsletter.pragmaticengineer.com/p/ai-tooling-2026

• DX, Developer Productivity Research (2026) — AI code attribution, agent experience scoring, AI-assisted commit share. getdx.com

• Stack Overflow, 2025 Developer Survey — broad AI adoption, trust dynamics, daily frustrations. survey.stackoverflow.co/2025

• Deloitte, Tech Trends 2026 — shift from project to product, redesigning engineering for AI. deloitte.com/insights/tech-trends

• Kohl & Carro, When Code Becomes Abundant: Redefining Software Engineering Around Orchestration and Verification (ICSE-FoSE 2026) — the academic case for the shift. arxiv.org/abs/2602.04830

• Adevinta Engineering, A pragmatic evaluation of software engineering AI tooling (March 2026) — real enterprise pilot data on Cursor, Claude Code, Copilot. adevinta.com/techblog

Humans became humans. We gained the ability to evolve, without inventing evolution itself. We didn’t invent AI in isolation. It is, in itself, a product of our evolution.

Evolution happened to us, through us, and eventually because of us. AI is the latest chapter. It’s what happens when a species built on learning and adapting does what it’s always done: builds the next thing.

I keep coming back to a question that feels more relevant every month: what skills make us irreplaceable in a world we ourselves created?

1. Critical Thinking

AI can deconstruct logic better than most humans. But it cannot choose. It provides the how, but it can never provide the why.

Critical thinking in the AI age isn’t about out-calculating the model or just checking for hallucinations. It’s about knowing which problems are worth solving and being accountable for the direction you take. It’s knowing when the model is technically right but contextually wrong. It’s the willingness to look at a perfectly optimized AI output and say, “This is logical, but it’s not the direction we’re taking.”

AI sounds confident whether it’s right or wrong. It’s easy to accept an output you shouldn’t because it’s well-written and sounds authoritative. I’ve done it myself. The models will keep getting better. But the need for someone who can look at what comes back and say “this doesn’t hold up” isn’t going away.

The AI handles the processing. You handle the intent and the final decision. And before any of that, you need to learn to ask the right questions. That in itself requires critical thinking.

2. Learn to Learn Fast

The model I was using six months ago already feels like a different era.

You can’t learn the old way anymore. You can’t take a course, spend three months going deep, and expect that knowledge to hold. By the time you’re done, the landscape has moved.

I’ve started thinking about this more like a startup. You learn just enough to act. You ship something. You get feedback. You pivot. But the reason you can move that fast is because you’ve gone deep on first principles. You don’t need to relearn how systems scale or how users think. You only need to learn how the new tool applies those fundamentals.

The people doing well right now aren’t just the most knowledgeable. They’re the fastest learners with the strongest foundations. They get their footing in days because they recognize the underlying patterns, and figure out the rest as they go.

3. Adaptability

Models are changing fast. Capabilities are growing almost exponentially. If you’re feeling the pressure, that’s real.

But at some point it becomes normal. Every major shift in history felt exactly like this during the transition. There is always a new normal forming, and the space between the old one and the new one is chaotic and uncomfortable. That’s what a phase shift feels like from the inside.

Think about food delivery. Remember the first time you ordered on your phone? Fumbling with payment, wondering if it would even show up. It felt clunky. Unnecessary. Now you don’t think about it. It’s muscle memory.

AI is on the same trajectory, just at a much larger scale. The friction you feel today is temporary. The capability it gives you is permanent. The only thing that holds you back is choosing not to move with it.

4. Be Resourceful

I’ve believed this long before AI. Resourcefulness beats resources.

The best people I’ve worked with don’t wait for perfect conditions or a complete instruction manual. They look at what they have, right now, and make it work.

AI amplifies this. You have access to capabilities that would have required entire teams five years ago. But the tool doesn’t matter without the instinct to just use it. To hack things together. To ship the imperfect version and improve it live.

5. Develop Taste

This is something I think about a lot.

AI can produce a thousand options in minutes. It cannot tell you which one is good. It cannot feel the difference between something technically correct and something that resonates.

Taste is knowing when the output is 80% there and what the missing 20% is. You build it by looking at what AI produces, then looking at what a master in that domain produces, and studying the gap. Sometimes it’s a choice of structure. Sometimes it’s knowing what to leave out. You learn to see that gap clearly, not just in aesthetics but in logic and reasoning.

A single training run costs millions. The person who knows which experiment to run, which hypothesis is worth that investment, which architecture choice will compound and which will waste a quarter of compute, that person is the most valuable in the room. Not because they can execute. Everyone can execute. Because they know what’s worth executing.

In an agentic world, taste is also about designing the right constraints. AI can generate infinite paths. The person with taste knows which guardrails create a masterpiece and which ones create a mess.

6. Build Your Own Workflow

Everyone has access to the same models, the same tools, the same plugins. The edge isn’t what you use. It’s how you use it.

The people getting the most out of AI right now aren’t following someone else’s playbook. They’ve built their own. Experimented, failed, iterated, and arrived at a system that fits the way they think and work.

There is no universal best workflow. Only the one you’ve built, tested, and refined through doing.

7. Don’t Just Chat. Build.

The biggest mistake I see is treating AI like a novelty. Asking it trivia, generating images, having interesting conversations. Fine for day one. If that’s still all you’re doing on day ninety, you haven’t started.

I’ll end with something personal.

I started my career as an engineer, then drifted into product, became a domain SME. At some point I realized I had strayed too far from tech. Things had moved on, and I had to go back and learn to be an engineer again. That restart wasn’t easy. But the path was shorter than I expected because I had the basics. Curiosity kicked back in. I rose back up to architect, then into tech leadership and tech strategy, eventually gaining broader knowledge across every corner of tech I could get into.

Then AI happened. Back to the drawing board. Back to being a builder again. Curious all over again. The initial learning was tough, same cycle as every other restart, but even shorter this time. I had to learn to incorporate AI into every workflow, first in tech, then in business and strategy, and figure out what value this could bring and how we solve real problems with this new technology.

But here’s what I’ve learned from doing this more than once: every time you restart, it gets easier. The time gets shorter. The basics you built before don’t disappear. They compound. New things click faster because you already have a foundation. That’s the compounding effect. It’s real, and it works in your favor the moment you decide to start.

I spent hours reading papers, experimenting with models, breaking things, trying to separate real from hype. And because I started early, I can now keep pace with changes that would have buried me otherwise.

Stay open to learning. The opportunities follow. They always find the people who are ready.

We didn’t invent evolution. But we’ve never once failed to evolve.

It was in a text message. I was heads-down on something else. By the time I remembered, it was too late. You know the feeling. It stays with you.

I didn’t have a system. I had intentions. I had apps. I had to-do lists I reorganized every Sunday, a ritual that made me feel productive without actually making me productive.

I’ve been using AI for a long time. When agentic AI started becoming real, I started using it as a thinking partner for research, planning, working through ideas. That changed how I think. It brought clarity to how I approach problems. I’m still figuring things out, but the trajectory is clear.

Over time I layered more on. A weekend coaching ritual. A research workflow. Each started as an experiment. Each stuck because it solved something real.

Then last week I connected NanoClaw, a lightweight open-source personal AI agent, to a Google Calendar MCP server. Set it up on a Mac Mini. Named the agent Jarvis. Now my family schedules appointments by messaging WhatsApp.

I used Claude Code to set up NanoClaw. An AI agent helped me configure another AI agent. The system was proving the thesis before it was even running.

That’s when something shifted. I wasn’t reaching for AI anymore. I was surrounded by it. Calendar, briefings, research, coaching, planning, all running through interfaces I already use every day. WhatsApp for family. Slack for reading what AI prepares for me. Google Tasks for what needs to get done.

I’ve started calling it the agentic mindset. Not using AI as a tool you pick up. Living with AI as a partner that’s always running.

I get curious about things. How multi-agent systems actually work. Whether the premise that specialized agents outperform a single generalist holds up in practice. How orchestration patterns from a research paper translate into real code.

This used to come with a cost. Fifteen tabs open. A paper too dense to finish. Jargon that loses me by page three. I have a bookmarks folder called “Read Later” with over 200 links in it. I’ve read maybe twelve.

The cost of exploring was high enough that I mostly didn’t. Which means I was operating on what I already knew, not what I could know.

Here’s a specific example. I found a paper on arXiv called “The Orchestration of Multi-Agent Systems.” Dense, academic, full of formal notation. Old me would have bookmarked it and moved on. Instead, I dropped it into an AI conversation and asked for a structured breakdown: what’s the core framework, what are the seven orchestration responsibilities, and what would it take to build this.

AI broke it down in minutes. I understood the architecture. Then I built it. Three agents, a deterministic orchestrator, real flight data. 1,500 lines of Python. I raced the multi-agent system against a single agent across three cities and found that multi-agent only wins when the search space is large enough that focused attention finds what divided attention misses. I published the whole thing on my Substack.

The arc from “interesting paper” to “working code” to “published essay” happened in a fraction of the time it would have taken before. That’s the shift. AI didn’t do the thinking for me. It removed the friction that used to stop me from thinking at all.

I have tried every productivity system. GTD. The 3-2-1 method. Time blocking. Pomodoro. Bullet journals. Each one works for a week, maybe two, then falls off. Not because the method is bad. Because there’s no one on the other side keeping me honest.

So I built an AI coach. I gave it my weekends.

Every weekend, twenty minutes. What got done around the house, what I promised my family, what I kept putting off for myself. The side project I said I’d start. The reading I never got to. The errand that’s been on the list for three weeks. Then we plan the next week around what actually matters to the people in my life, including me. It doesn’t list my tasks. It challenges me.

“You said you’d start that project three weekends ago. What’s actually stopping you?”

“You have a free Saturday morning. Are you protecting it or letting it fill up?”

“Is this actually important to you or are you avoiding the harder thing?”

By Sunday evening I’ve already thought about the week. I know what matters. I start Monday in motion, not scrambling.

I used to miss appointments because every one required a context switch. Leave WhatsApp, open the calendar app, type the details, go back. The real cost was never the thirty seconds. It was that my brain left whatever I was doing. Every time I thought “I’ll add that later,” it became one more thing occupying mental RAM.

Now I message Jarvis on WhatsApp. “There’s an appointment on April 14 at Chandler. Add that to the family calendar.” Jarvis confirms, adds it, asks if I know the time. Done. My brain never leaves the conversation.

My whole family uses the same system. Anyone can message Jarvis, ask what’s happening this weekend, add something. One shared calendar. No bottleneck.

Jarvis also nudges. Tax filing deadline coming up? “April 15 is 13 days away, have you carved out time to file yet?” I didn’t ask for that. Jarvis knew it mattered.

Every morning, Jarvis drops a news summary into WhatsApp. Three to five items. This morning: a cybersecurity model finding thousands of zero-day vulnerabilities, a major revenue milestone at Anthropic, Google releasing a new open-source model. Two minutes to read. Caught up before my coffee was done.

These pieces feed each other. That’s the part I didn’t expect.

The weekend coaching review looks at my Google Tasks and calendar, finds the open gaps where real thinking can happen, and helps me protect them before the week fills up. The briefings keep me informed without consuming my morning. The research partner accelerates my learning without the tab-explosion. The calendar handles the logistics without the context switching.

None of this is about getting more done. It’s about creating space to think.

During a recent weekend review, my AI coach pointed out that I’d committed to writing three times in the past month but only followed through once. I hadn’t noticed the pattern. I thought I was busy each time. But seeing it laid out, three commitments, one delivery, I realized I wasn’t protecting time for writing. I was hoping time would appear. The next week I blocked two hours on Sunday morning before anything else. That’s where this essay came from.

Before all of this, I spent roughly an hour a day on operational overhead: scrolling for news, managing calendars, reorganizing task lists, trying to remember what I was supposed to focus on. Now that’s down to minutes. The hour didn’t disappear. It turned into thinking time. Over a month, that’s thirty hours back. Not for more tasks. For clarity.

Since I started, Jarvis has quietly grown. (The name is a cliché, I know. But when your family already calls it Jarvis, you stop fighting it.) It reads photos now, so my family can send receipts and they land in Notion automatically. It transcribes voice notes locally, so the kids can talk to it without typing. It runs a small local model alongside Claude for the cheap tasks, which cut my costs without cutting quality. And last week I added something that still surprises me: a meta-tool that lets Jarvis build its own tools on the fly. When someone asks for something it can’t do yet, a weather lookup, a currency conversion, it finds an API, writes itself a tool, tests it, and uses it. Next time anyone asks, the tool is already there. I didn’t build any of those capabilities. Jarvis did.

It also breaks. The meta-tool once hallucinated an API endpoint that didn’t exist, built a tool around it, and confidently returned wrong weather data for a week before anyone noticed. A container crashed mid-calendar sync and duplicated every event for a Tuesday. The plumbing I described earlier isn’t a one-time cost. It’s ongoing. Things fail, and when they fail quietly, you don’t find out until someone shows up to the wrong appointment.

That’s the honest version of “it keeps building itself.” It keeps building itself, and sometimes it builds the wrong thing. The system is not finished. I’m not sure it ever will be. That might be the point.

A few things I want to be honest about.

The plumbing took grit. WhatsApp API configuration, MCP server setup, container permissions. If you’re comfortable in a terminal, the barrier is surprisingly low for what you get back. If you’re not, this is a weekend project with some frustration built in.

NanoClaw runs on the Claude Agent SDK, so there’s a dependency on Anthropic. The codebase is small enough to adapt, and people have swapped in other models, but I want to be straightforward about that.

It’s not free. API calls cost money. But there’s no monthly subscription to a platform that owns your workflows. The cost scales with usage, and the system is yours to modify.

The agent logic runs on my home hardware. My Mac Mini, my house. It connects to services I already use and trust: Google Calendar, WhatsApp, Claude’s API. There’s no additional third-party collecting my family’s data in between. I chose the services. I control the wiring. In 2026, there’s a particular peace of mind in knowing your family’s WhatsApp messages aren’t sitting in some startup’s database, training the next model.

Everything I’ve described here, I figured out for myself. One person. My own friction points.

What I keep thinking about is what happens when more people operate this way. The same patterns, briefings, coaching, removing friction, applied beyond one person. The implications are massive. I’ll write more about that.

If you want to start without building anything: every Saturday or Sunday, spend twenty minutes with any AI reviewing your week. What you planned, what actually happened, what you’re carrying forward. Do this for four weekends. The pattern recognition alone will change how you operate.

I started by missing something that mattered. I ended up rethinking how I learn, how I stay focused, and how I spend my days.

The question isn’t whether AI can do this. It can. Today.

The question is who you become when you stop managing your life and start designing it.

The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

I did a deep research dive into the economics. I expected the story to be about expensive tokens and infrastructure bills. It is not. The story is about a trap.

Everything that makes agents cheaper to build is making them more expensive to run.

I am calling it the Deflation Trap. It runs through every layer of what I have been mapping as the Agent Cost Stack.

The Jevons Layer

Per-token costs have dropped roughly 1,000× in three years. GPT-3-equivalent inference fell from $60 to $0.06 per million tokens. The decline runs at roughly 10× per year, faster than Moore’s Law.

And yet total AI spending surged 320% in 2025. Average enterprise LLM spending nearly tripled from $2.5 million to $7 million per company.

This is Jevons paradox applied to intelligence. When inference gets cheaper, usage does not stay flat — it explodes. Agentic workflows with dozens of reasoning steps per task. AI on every customer interaction. Use cases that were uneconomical last quarter become default this quarter. Demand is super-elastic.

The math of agentic loops makes it concrete. Agents operate in multi-turn reasoning where every turn reprocesses the entire conversation history. Turn 10 costs 10× what a single generation does. Cumulative spend across 10 turns is 55×. Reasoning models generating thousands of internal thinking tokens can require up to 100× more compute than a single pass. One complex agentic task can burn $5–$8 in inference alone.

Mitigations exist. Context caching from major providers cuts input costs 75–90%. Model routing — sending most queries to cheap models and only complex ones to frontier — cuts costs 35–85%. Semantic caching reduces redundant calls 20–73%. These make the growth curve manageable. They do not flatten it.

The cheaper the tokens get, the more tokens get used.

The Infrastructure Layer

The floor has collapsed. Serverless vector databases start under $25 a month. Object-storage-first options run at $70 per terabyte versus $1,600–$3,600 for RAM-based incumbents. Production RAG systems have been documented running for under $10 a month.

The $7,000–$21,000 monthly figure in enterprise analyses reflects enterprise procurement, not technical necessity. The actual range by agent complexity:

• Simple FAQ or support bot: $50–$500/mo

• RAG-based knowledge agent: $200–$2,000/mo

• Multi-step agent with tool calling: $500–$5,000/mo

• Enterprise multi-agent system with compliance: $5,000–$30,000/mo

A collapsed floor means more projects get greenlit. More projects get greenlit means more production systems to maintain. The infrastructure cost per agent went down. The total infrastructure bill went up.

The trap here is premature optimization — architecting for scale that does not exist yet. Know the actual volume before committing to architecture.

The Drift Layer

This is the layer most teams underestimate because it does not show up in a pricing calculator.

Agents are nondeterministic. A demo that works 80% of the time is impressive. A production system that fails 20% of the time is a liability. And agents drift. Prompt behavior decays. Model providers ship silent updates that change output quality. In long-lived sessions, system prompts receive roughly 1% of attention weight in large context windows, causing agents to gradually ignore their own instructions. Retrieval accuracy drops 15–30% as context stretches.

Budget 10–20 hours of engineering time per month on prompt tuning and behavior testing. That is $1,000–$2,500 a month per agent. This cost holds regardless of how cheap the tokens get. Automated evaluation frameworks agree with human judgment at only fair-to-moderate levels — they are force multipliers for human review, not replacements.

The cost here is not compute. It is attention. Human attention to a system that will not stay where you put it.

The Migration Layer

Between early 2025 and early 2026, major providers executed 15+ distinct model deprecation events. Major agent frameworks shipped multiple architecturally breaking versions. A survey of 1,837 engineering leaders found that 70% of regulated enterprises rebuild their agent stack every three months or faster.

AI coding tools make individual migrations 10–20× faster. But migrations now happen quarterly instead of annually. Total maintenance spend stays stubbornly similar. The composition shifts from manual labor to AI tooling costs plus expanded review cycles. And the productivity gains themselves may be illusory: METR’s randomized controlled trial found that experienced developers using AI coding tools perceived themselves as 20% faster but were actually 19% slower on real-world tasks — a 39-point perception gap. If the tool that is supposed to make migrations cheap is not actually making them faster, the math gets worse.

This is where the trap is most visible. More gets built on shifting ground because teams believe AI tools make it cheap to migrate. The per-migration cost feels lower. The number of migrations rises. Net cost: flat at best. Net complexity: up.

The defense: architect for replaceability from day one. Abstract the model layer. Budget 1–2 model migrations per year, each consuming 1–2 engineering weeks.

The Governance Layer

The EU AI Act is enforced starting August 2, 2026. It is real. But the cost most teams should worry about is not compliance — it is paralysis.

The Act uses a risk-tiered structure. The heavy burden risk management systems, conformity assessments, documentation maintained for ten years applies exclusively to high-risk systems under Annex III: HR screening, credit scoring, healthcare decision support, law enforcement. Only 5–15% of AI systems qualify. Annual compliance costs for those: roughly €29,000 per system. A Jira summarizer, a customer support bot, an internal knowledge agent none of these are high-risk.

Minimal-risk systems face no specific obligations beyond AI literacy. Limited-risk systems, including chatbots and virtual assistants, face only transparency requirements. One requirement is non-negotiable across all tiers: Article 50 requires that any system interacting with people discloses it is AI. A disclosure banner. A first-message label. Low-cost design change, easy fine if you miss it. Bake it in from day one.

The real governance cost for most teams is not the regulation — it is the months of delayed launches while legal reviews whether a low-risk agent needs high-risk treatment. If you are building in Annex III domains, budget for governance. If you are not, do not let regulatory anxiety kill a high-ROI project.

On the US side, govern agents with the same access controls you apply to employees. That principle holds regardless of jurisdiction.

The Pattern

The cost stack varies by an order of magnitude depending on agent complexity. A support bot on serverless can run for a few hundred dollars a month. An enterprise multi-agent system with compliance can run $20,000+. But the 65–75% operational share holds across both. The absolute numbers change. The ratio does not.

Every reduction in the cost of building creates more systems that need the expensive work of running. Tokens get cheaper, so architectures consume more. Infrastructure gets cheaper, so more projects ship. Migrations get cheaper per instance, so they happen more often.

Klarna learned this the hard way. The build was a success story. The run was an overcorrection that required hiring humans back. The long tail of nuanced, high-empathy interactions, refund disputes, billing confusion, frustrated customers who needed to feel heard, could not be cost-optimized away. The agent was not the problem. The budget that ignored the run was.

What to Do Before You Build

Five things to budget for before writing the first prompt:

1. Model the run cost, not the build cost. If 65–75% of your total spend will be operational, your business case should be mostly about ops — not the sprint to ship.

2. Measure your actual token volume before optimizing. Context caching and model routing are powerful, but premature optimization is its own cost. Know the volume first.

3. Budget human hours for drift. 10–20 hours per agent per month. Automated evals help. They do not replace the human in the loop.

4. Abstract the model layer on day one. You will migrate at least twice a year. Make it a configuration change, not a rewrite.

5. Classify your risk tier early. Five minutes with the Annex III list can save months of legal review. If you are not high-risk, move.

Every efficiency in building is a tax on running. The only way through the Deflation Trap is to budget for the run before you start the build.

The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

The premise came from a research paper. “The Orchestration of Multi-Agent Systems” provides a framework for building coordinated AI systems, and it cites a motivating claim: distributed collectives of smaller, specialized agents often outperform a single all-purpose deployment. Instead of one AI doing everything, you break the problem into parts, give each part to a specialist, and coordinate them through an orchestrator.

It sounds right. The way a hospital works. The way an engineering team works. Specialization plus coordination equals better outcomes.

But sounding right is not the same as being right.

So I tested it.

Three agents. One finds flights and hotels. One builds the itinerary. One tracks the budget. A deterministic Python orchestrator coordinates them, enforces budget gates, and controls what each agent can see. Real flight prices from web search, not training data. About 1,500 lines of Python, no frameworks, every design decision visible. The point was to understand orchestration by building it.

The paper formalizes orchestration as seven responsibilities planning, policy, execution, control, state, knowledge, and quality, each mapping to a method or component in the code. The five most important:

class Orchestrator:
    def plan(self, goal) -> list[Task]:       # Pi: decompose the goal
    def check_policy(self, category, price):   # Phi: enforce constraints
    def _execute_task(self, task, agents):      # E: dispatch to agents
    def _prefetch_search_data(self):           # K: fetch real prices
    def _assemble_plan(self) -> TripPlan:      # Q: validate and assemble

The most important design decision is what each agent can see. One shared notebook, three different windows into it. The notebook is a Pydantic model with a get_view method the paper’s observation function that returns a typed dataclass per agent.

class SharedNotebook:
    def get_view(self, agent_name) -> ScoutView | PlannerView | BudgetView:
        if agent_name == "scout":
            return ScoutView(
                budget_limits=...,          # flight/hotel/activity ceilings
                flight_search_results=...,  # raw search data
                hotel_search_results=...,
            )   # does NOT include: itinerary, decisions, other agents' outputs

        elif agent_name == "planner":
            return PlannerView(
                confirmed_bookings=...,     # only APPROVED decisions
                per_day_budget=...,         # remaining ÷ days
                attraction_search_results=...,
            )   # does NOT include: rejected options, raw prices

        elif agent_name == "budget":
            return BudgetView(
                all_prices=...,             # every price from every source
                running_total=...,
                budget_ceiling=...,
            )   # does NOT include: activity names, preferences

        else:
            raise ValueError(f"Unknown agent: {agent_name}")

Scout never sees what the Planner decided. Budget never sees which temples were chosen. Each agent gets only what it needs to do its job.

Then I built a single-agent version. Same model, same search data, same instructions. One prompt that does everything at once. I ran both systems across three cities (Tokyo, Paris, Bangkok), two runs each, and compared what they found.

The sample size is small. Two runs per city gives you direction, not proof. But the patterns were consistent enough to be worth sharing.

The single agent was faster every time. About 100 seconds versus 130. It used fewer tokens. About 10,000 versus 14,500. On pure efficiency, the generalist wins.

But then I looked at the flight prices.

For Paris, both systems found the same $1,199 flight. Dead tie, both runs. The SFO to Paris route has limited options. When the answer is obvious, specialization adds nothing.

For Tokyo, the single agent found cheaper flights. $946 average versus $1,144. Multi-agent is not always better. My read on why: Tokyo is a well-known route with a moderate number of carriers. The search results contained enough information for a generalist to find the best option without deep analysis. But the multi-agent system’s rigid pipeline introduced information loss at each handoff. Specifically, a method called _approve_best_options picks flights[0] from Scout’s sorted list and marks everything else as rejected before Budget ever sees the alternatives. The orchestrator pre-decides the winner. Call it the Lossy Handover problem: if your orchestrator is too rigid, it dumbs down the specialists. The single agent saw everything at once and acted as its own soft orchestrator, weighing all options simultaneously. Structure helped in Bangkok. In Tokyo, it got in the way.

For Bangkok, the multi-agent system found flights at $293. The single agent picked $885. Consistent across both runs. A $592 difference on a $1,500 budget trip. (All prices are search-reported via Tavily, not verified bookings. The exact numbers will differ if you run this tomorrow. What matters is the gap and what caused it.)

Bangkok has dozens of carriers, multiple layover options through Asian hubs, and a wide spread of price points. When Scout’s only job is analyzing flight options, it digs deeper. It found a route the single agent missed entirely. The single agent was juggling flights, hotels, itinerary, and budget at the same time. It picked a reasonable option and moved on.

That is the pattern.

Here is the data across all six runs:

Averages across two runs per city. All prices from Tavily web search, not verified bookings.

The multi-agent system used 40-50% more tokens every time. It was slower every time. But for Bangkok it saved $592 on a $1,500 trip. The token overhead cost maybe fifty cents.

It is not about task complexity in the abstract. It is about search space. When there are many valid options spread across a large space, a specialist who does nothing but search will find things a generalist misses. When the answer is obvious or the space is small, the overhead is not worth it.

There were other findings worth noting.

Restricting what each agent can see (what multi-agent theory calls the observation function) reduces context size substantially. Budget does not need to process itinerary descriptions. Scout does not need to see rejected options. Less context, smaller prompts, lower cost. I did not run a controlled experiment isolating this variable, but the multi-agent token counts (averaging around 14,500 across all runs) are spread across four sequential calls, each with a focused prompt. A single prompt carrying all the context for all three roles would be larger than any one of them.

But the cost savings is not the most interesting part. The observation function is also a least-privilege boundary. Budget cannot see which temples were chosen or what the traveler’s personal interests are. It sees prices. That is all it needs and all it should have. In a system where agents might be backed by different models, different providers, or different trust levels, controlling what each agent can see is not just an optimization. It is a security and privacy decision. The same pattern that reduces token cost also enforces data isolation.

Here is how state flows through the system.

A note on the plumbing. The paper specifies two protocols underneath the diagram above. MCP (Model Context Protocol) controls tool access: only the orchestrator calls MCP servers, and agents only analyze data that was pre-fetched for them. A2A (Agent-to-Agent) is the message schema. Every inter-agent communication is a typed Pydantic model with a message_type (TASK_ASSIGN, APPROVE, REJECT), a confidence score, and a provenance chain. When Budget flags a flight, it returns a structured REJECT with confidence 0.95 and a list of reasons, not free text. That structure is what lets the orchestrator make deterministic decisions instead of parsing natural language.

I tested this directly. I injected a fake “$200 SCAM Air 999” flight into the search results for a Tokyo trip where real flights cost $800-1,200. The Budget agent flagged it with three warnings: the price was unrealistic for the route, the spending was near category limits, and the carrier name was suspicious. A specialist whose only job is checking numbers catches things a generalist might miss while multitasking. Interestingly, even the single agent did not use the scam price; the LLM had its own sense of realistic pricing. But the multi-agent system caught it earlier, at the budget gate, before it could reach the Planner at all. Defense in depth.

The paper warns about coordination overhead. I measured it directly in a head-to-head run on the same Tokyo trip:

The real cost is not in the messages between agents. It is in the latency of four sequential API calls and the context window space used to give each agent its filtered view of the world. The 130% token overhead is the coordination tax. Whether that tax is worth paying depends entirely on what the specialist finds.

I expected the premise to be right in a straightforward way. Multi-agent should beat single-agent.

It does. But only sometimes.

For Bangkok, the coordination tax was maybe fifty cents in extra tokens. The flight savings was nearly six hundred dollars. For Paris, the multi-agent system added cost and time for zero benefit. For Tokyo, the single agent did better.

The paper itself is a framework paper, not a benchmark paper. It gives you a vocabulary for decomposing orchestration into planning, policy, execution, control, state, knowledge, and quality. That decomposition is worth learning regardless of whether you end up building multi-agent or not.

I am not the only one finding this. A Towards Data Science analysis called it “The Multi-Agent Trap”, the tendency to treat every problem as a multi-agent problem when a well-prompted single agent would suffice. GitHub’s engineering blog put it bluntly: most multi-agent workflow failures come down to missing structure. The pattern I saw in my trip planner, structure helps when the search space is large, hurts when it is not appears to be general.

But the performance premise that motivates the framework needs a qualifier. Build multi-agent when the search space is large enough that focused attention finds what divided attention misses. When the cost of overlooking the best option exceeds the cost of looking twice.

For everything else, one agent is enough.

Paper: “The Orchestration of Multi-Agent Systems.” arXiv:2601.13671, January 2026.

I’ve been thinking about what it means to build software right now.

Not the mechanics of it. The models are capable. The tools are there. The barrier to shipping something has never been lower.

I mean the thinking behind it.

Because here’s what I keep coming back to. A generation of talented developers is about to build products shaped entirely by what AI can do today. They will look at the current state of the models, the current interfaces, the current capabilities and build for that. Ship fast, get users, feel the momentum.

And then the models will evolve. Faster than the roadmap expected. And the product built for today becomes the wrong answer for tomorrow.

That’s the trap the moment sets.

The mistake is building for the model, not the problem

When you pick up a powerful new tool, the temptation is to build something that shows off what it can do. This isn’t new. Early mobile apps were just desktop websites made smaller. Early cloud software was just on-premise software moved online.

The same thing is happening now. Products that are, at their core, a UI around a prompt. Clean. Functional. Sometimes impressive. But the value lives entirely in the model underneath and that model is not yours.

When the next model ships, and it will ship sooner than you think, what you built becomes a feature someone else offers for free.

If the model getting stronger makes your product weaker, you were never building a product. You were building a demo.

Ask a different question before you start

Most founders start with: what can I build with AI?

The better question is: what problem gets harder to solve as the world gets more complex and how do I sit in the middle of that in a way that compounds over time?

That question changes everything.

It moves you away from the interface and toward the workflow. Away from the feature and toward the process. Toward what the model cannot do alone, which is understand the specific, messy, human context of a particular industry.

The model knows everything about the average. It knows almost nothing about your specific customer’s specific situation. That gap is where you build.

What loses value. What doesn’t.

Software that manages lightweight engagement, scheduling, email workflows, basic coordination, is easy to migrate and easy to replace. An AI-native competitor can move that data in days and offer something better on top of it.

What keeps its value is software sitting inside complex workflows where the data is hard to replicate and built up over years of real operational use. Construction scheduling. Manufacturing supply chains. Property maintenance logs. The kind of data that doesn’t exist anywhere else because it was never meant to be shared. Because it lived in a process, not a database.

That’s the line.

You already have the advantage

Here’s what I think developers underestimate about this moment.

You already think in systems. You understand how things connect, where things break, what happens at scale. That instinct, applied not just to code but to how an industry actually operates, is exactly what this era needs.

The most defensible products being built right now are not the most technically impressive. They are the ones where someone understood a domain deeply enough to encode how it actually works. The exceptions. The edge cases. The judgment calls that happen between the steps. Into a system that gets smarter every time someone uses it.

That is builder’s work. Not just engineering. Thinking.

Build something that learns

Your product is not the features. It is what the system learns as people use it.

When a user corrects the output, that’s signal. When the system handles an edge case it hasn’t seen before, that’s signal. When a decision gets made inside the platform, that’s signal. That accumulated understanding of how a specific domain operates, that is the asset. Not the code.

No foundation model trained on the average of the internet will ever have it.

Own the workflow where the real work happens. Make your system the place where the truth of the business lives. And then let it learn.

What you build on day one matters less than what your system knows on day one thousand.

A generic agent can book the plumber. Only your system knows which plumber showed up last time, what it cost, and whether the problem came back. That memory is the moat. Not the capability.

The models will get stronger. Build for that.

A stronger model should make your product more powerful, not obsolete.

If the AI is the product, if the value is the generation, the summarization, the interface, a stronger model replaces you. That is a fragile position to be in.

But if the AI is the engine, if the value is the proprietary context, the workflow, the domain knowledge you have built up, a stronger model makes your engine more powerful. You get better without doing anything.

Build with the model. Not on it.

Don’t marry the engine either

One more thing, because this is where even careful builders get it wrong.

Treating AI as the engine is right. But don’t bolt yourself to a single engine.

The gap between the leading models has narrowed faster than most people expected. OpenAI, Anthropic, Google, they are closer to each other than they have ever been. And open-source models have caught up in ways that also give you something proprietary models don’t: full control of your data, no dependency on someone else’s pricing or terms.

Build a layer between your product logic and the model. Route the right tasks to the right model. Swap them out as the landscape shifts. The ability to always use the best tool at the right cost, without being locked in, is itself a competitive advantage.

Build the engine room, not the engine.

And if the inference cost is slowing you down right now, don’t let it stop you. There is no world where token costs stay this high. Every wave of compute has gotten cheaper faster than anyone expected. Build the right system. The economics will catch up.

Go where the model was never taught

The sharper version of “go where AI adoption is slow” is this: go where the training data never existed.

The plant manager who knows which supplier runs late in Q4. The process refined over twenty years on a specific floor. The supply chain nuance that lives in phone calls and institutional memory. That knowledge was never written down, never online, never in any training set.

The SMB running three shifts has heard of ChatGPT. They just don’t know how to make it work for their operation. Nobody has built for them. The big platforms are chasing enterprise. The funded startups are chasing legal and healthcare. The manufacturing floor is not in any of those conversations.

That is the opening. Go there first.

At the end of it

You are building something that helps a person simplify a hard process and you are using the most powerful tool in the history of software to do it.

Keep it that simple in your head.

Not “I am building an AI product.” Not “I am disrupting a vertical.” You are making something hard, easier. For a real person. In a specific situation. That the model alone cannot solve.

And when the AI gets it wrong and it will, your product needs to be the system that’s accountable. In manufacturing, in property management, in any operation where mistakes have real consequences, the winner isn’t the smartest model. It’s the one the customer trusts to own the outcome.

The developer who stays anchored to that, who doesn’t get seduced by what the model can do and loses sight of the actual human on the other side, is who builds something that lasts.

Go build. But build for the person, not the prompt.

I’ve been carrying these words for a while now. Things I’ve learned, things I wish someone had told me, things I don’t want lost if I’m not around to say them. So I’m writing them down. Not because I have it all figured out. But because what I do know is worth passing along.

If I could give you one thing to carry from the start, it would be this: become someone you can respect.

You’re going to feel everything. Anger, jealousy, the urge to win, the need to be right. We all do. Those instincts have been with us long before we built values and intellect around them. The instincts don’t make you weak. Everyone feels them. What defines your character is the moment you recognize them and choose how to act. That choice is yours alone. It’s what makes you, you.

The world you’re growing up in is loud. It will constantly show you what success is supposed to look like. Not everything that shines is valuable. Companies spend billions making you feel like you need what they’re selling. Learn the difference between what you actually need and what someone is working hard to make you want.

You’ll meet people from different cultures, different upbringings, different ways of seeing the world. That’s a good thing. How someone was raised shapes how they think, what they value, how they show up. Not everyone will see life the way you do, and that doesn’t make them wrong. Try to see things from where they stand. That’s where the real learning happens.

Our family won’t always be perfect. We’ll disagree. There will be days you think we don’t understand you, and days we’ll feel the same about you. But we will always be there. No matter what. That’s not something you earn. It’s something you were born into. We will love you unconditionally, and sometimes that love will sound like things you don’t want to hear. Trust it anyway.

If you make a mistake, own it. If you hurt someone, say so. Not because the world demands it, but because you should demand it of yourself. The people worth keeping in your life will respect you more for your honesty than your perfection.

Not every friend will be the same kind of friend. Some will stay with you regardless of what you can offer them. Those are the real ones. Others will be around when it’s convenient. You’ll learn to tell the difference. And some friends are tied to a time and place. That doesn’t make them less real, just different. People grow, people change, and sometimes that means growing apart. Don’t hold it against them. But be careful who you keep closest. You become the best or worst version of yourself based on the people you surround yourself with. And whoever is in your life, be someone worth keeping around.

Your body is the only asset you can never replace. I wish I had understood this earlier. Your body runs on a rhythm. When you sleep, when you eat, how you move, it all connects. Sleep controls your weight, your mood, how clearly you think. Exercise isn’t about looking good. It’s how your body was built to function. Learn what a balanced meal actually looks like, not from ads or trends, but from understanding what your body needs. When you’re young none of this feels urgent. By the time it does, you’re already paying for the years you didn’t.

Learn how money works before you need to. I learned this the hard way. Wealth isn’t what you spend. It’s what you don’t. The car you didn’t buy, the upgrade you skipped, the money you kept instead of showing it off. That restraint is what builds freedom. The kind that lets you walk away from what’s wrong and wait for what’s right, without panic deciding for you.

Work hard. There is no substitute for it. Nothing meaningful was ever built without effort, and most of what you want in life will cost more of it than you expect. But work on what matters. There’s a difference between being busy and being productive. One fills your day, the other builds your life. And you will fail. I can promise you that. It won’t mean you’re not good enough. It will mean you tried. The only real mistake is failing and learning nothing from it. And know this: luck plays a part. It always does. But the harder you work and the more prepared you are, the bigger your surface for luck to land on.

Be resourceful. Don’t wait for perfect conditions or someone to hand you the answer. The people who build something real aren’t always the most talented. They’re the ones who refused to stay stuck.

Stay curious. Ask questions even when you think you should already know the answer. Read, watch, listen, not just to confirm what you believe, but to challenge it. Go deep. The world respects people who truly understand what they’re talking about, not those who pretend to. Surface knowledge fools no one worth impressing. The people who keep growing are the ones who never stop learning. Knowledge doesn’t come to you. You have to go after it.

When you were young, there was something that pulled your attention without anyone telling it to. A subject, a craft, a question you couldn’t let go of. As you got older, the noise got louder and that voice got harder to hear. Try to find it again. That’s your purpose. It doesn’t have to be grand. It just has to be yours. Life gets better once you find it. Not easier, but clearer. The noise quiets down. Decisions get simpler. You stop drifting and start building.

See the world. Not just for the photos, but because nothing rearranges the way you think faster than being somewhere unfamiliar. Talk to strangers. Sit with people who grew up nothing like you. Books will teach you what’s possible. Experience will teach you what’s true.

And spend time in nature. Not because someone told you it’s good for you, but because it’s the one place that doesn’t ask you to perform. No notifications, no expectations, no one measuring you. Just quiet. There’s something out there that resets you in a way the city and the screen never will. Go often. Stay long enough to hear yourself think.

And rest when you need to. I mean it. Your mind and body need recovery the way soil needs seasons.

There’s real power in doing good without expecting anything back. Choosing honesty when it would be easier not to. That’s where self-respect is forged. Not in what you achieve, but in how you carry yourself when no one is watching.

I don’t expect you to be perfect. I only hope that as you grow, you choose to live in a way that matches your values. Even when it’s hard. Even when no one’s looking. This is what I know so far. I’m still learning too. And when I learn more, I’ll pass that along as well.

Because the road is long. And along the way, everything will change. Your circumstances, your status, the people around you. But one thing stays with you the entire way. The person you see in the mirror. Make sure that’s someone you respect.

Disclaimer: The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.

AI hasn’t eliminated the role of the developer.

It has clarified it.

For a long time, software development was closely tied to writing code. Progress was measured in features shipped or lines written. AI changes that dynamic. When code can be generated quickly and at scale, the value of the developer shifts upstream, toward thinking, deciding, and guiding.

Clarity Is Built, Not Found

When I began working with AI coding agents, I expected speed to be the primary benefit. What stood out instead was how much it forced clarity. Early ideas weren’t incorrect, but they were often imprecise. When vague intent was passed to an agent, the output reflected that ambiguity immediately.

Iteration stopped being just a development loop and became a way to refine intent. Each prompt required answering basic questions: what problem is being solved, who it is for, and what “done” actually means.

Clarity wasn’t a prerequisite to building, it emerged through the process.

AI doesn’t replace thinking; it accelerates feedback on unclear thinking.

Architecture Still Matters (Even More Now)

As clarity formed, the instinct was to move faster. AI makes experimentation inexpensive. Different stacks and architectures can be explored quickly. But speed does not remove responsibility.

Decisions still carry tradeoffs across scalability, reliability, maintainability, cost and security. Security, in particular, is a day-zero concern.

Coding agents made it easier to pressure-test assumptions early: how systems behave at scale, where trust boundaries exist, what fails silently, and what becomes costly over time. Agents can surface options, but judgment remains human.

Architecture still matters perhaps more now than before because mistakes compound faster.

Quality Ownership Scales With Output

Another shift was the increased emphasis on quality. When an agent can generate large volumes of code quickly, blind trust becomes risky. Code review and testing moved from periodic activities to continuous ones.

Testing stopped feeling like overhead and became a guardrail.

I’ve caught more subtle bugs and security issues earlier in the process than I ever did before not because the agent is smarter, but because it forces me to review, question, and validate every assumption.

Increased output required increased ownership of quality.

Humans Are Still the Bottleneck

There is a human constraint that AI does not remove: fatigue.

AI compresses effort significantly, enabling large amounts of work in a single session. Momentum can be productive, but unmanaged momentum degrades judgment. Agents do not get tired; humans do.

Knowing when to pause and return with fresh context remains essential. Sustainable velocity matters more than heroic bursts of output.

Refactoring Without Fear

At the same time, refactoring became less intimidating.

When intent is clear, behavior is understood, and tests exist, rewriting becomes transformation rather than reinvention. Switching stacks becomes another iteration rather than a risk.

Confidence comes from reversible decisions.

From Code Producer to Decision-Maker

A conversation with a doctor reinforced this perspective. While AI can suggest multiple treatment options, choosing the appropriate one is where experience matters.

That distinction mirrors the evolving role of the developer.

AI can propose architectures and implementations. Determining which option fits the problem, the system, and the users and owning the outcome remains a human responsibility.

In the age of AI, developers shift from being primarily code producers to decision-makers. AI generates possibilities; it does not choose purpose.

Critical Thinking Is the Real Skill

If there is one thing AI can begin to replace, it is unexamined thinking not intelligence, but complacency masquerading as confidence.

AI executes exactly what is asked. The quality of the outcome is bounded by the quality of the reasoning behind the request.

This elevates the importance of critical thinking, security awareness, and system-level understanding. Developers become guides and guardians, shaping how systems should be built, not just what gets built. QA and UAT are no longer isolated phases but continuous responsibilities.

What you ask is what will be built.

What you clarify is what will be delivered.

Looking Ahead

This is still an early stage. What we see today is the current state. The future will evolve further, and some responsibilities may shift again.

What will not disappear is the need for judgment, context, and critical thinking.

AI does not replace developers.

It raises the bar.

And the developers who adapt, who think clearly, decide deliberately, and guide systems responsibly, will shape what comes next.

Learn to Learn Fast

I’m writing this because some truths don’t leave you alone until you say them—and because no one really teaches you how easy it is to lose yourself while trying to belong. For a long time, I’ve wanted to put this into words. If you allow people to define who you are, you slowly lose yourself along the way. Authenticity isn’t optional—it’s survival.

There will always be people who accept you exactly as you are, and those relationships last because they are built on truth. Then there are others who need to feel superior. They undermine, diminish, and refuse to acknowledge you—not because of who you are, but because acknowledging you would threaten how they feel about themselves. Those relationships don’t last.

This isn’t about big or small, strong or weak. It’s about pride. Some people feed theirs by bending others, and that only works if you allow it. The same truth applies inward: if you expect someone to be a certain way instead of accepting who they are, you’re doing the same thing. Everyone is unique. No one exists to fit your expectations.

Don’t beat yourself up trying to be perfect when you’re young. These experiences will happen—and they’re supposed to. Becoming an adult takes time, and understanding who you are takes even longer. The confusion, the mistakes, the disappointments, the wrong people—those aren’t failures. They’re necessary. Without them, you don’t discover yourself.

At some point, you stop trying to win people over. You stop explaining yourself. You stop rehearsing conversations in your head. Not because you don’t care, but because you finally understand what costs too much. Peace becomes more important than being right. Clarity matters more than approval.

That’s when you keep your eyes on what truly matters. You move past the noise and find your purpose. You ask yourself what excites you and what you want to keep doing for the rest of your life. You surround yourself with people who cheer for your success, and you become someone who genuinely celebrates the growth of others. You show up for your friends selflessly, without keeping score or expecting anything in return.

As you grow older, everything changes—your finances, your status, your circumstances. What doesn’t change are authentic relationships. The people who are real will see you in both growth and fall, and they will stay. No matter how high you rise or how hard you fall, those people remain.

I’m deeply grateful for the people who have been part of my life through both my lowest moments and my growth. I know they will be there for the rest of my life. There are also friends you lose—not because of conflict, but because life creates distance and time slips away. Yet if those relationships were built on truth, they don’t disappear. They exist exactly as they are, regardless of how long it’s been since you last saw each other.

Sometimes, all it takes is one bad intention to disturb you deeply. When that happens, let it go. Ground yourself in what actually matters—your family, your health, and your mental peace.

But part of protecting that peace is recognizing what threatens it.

There are people who manipulate to escape the truth, who twist stories to hide what they’ve done. There are also people who support that manipulation because it makes them feel bigger, protects their pride, and serves their own interests—they hide behind a version of reality and use it when it’s convenient to fulfill their agenda. Whether they are right or wrong matters less than this: they must believe they are justified. That makes them dangerous to be around. They think they’re smart enough to get away with it—but the other side sees everything. They choose not to react. Not because they’re fooled, but because they refuse to lower themselves to play that game. It’s choosing dignity over drama. Recognizing this is part of protecting yourself.

And then there are people who genuinely care. They cheer for you. They show up without questioning your worth. But once trust is given, it shouldn’t be endlessly tested. Trust, once damaged, changes everything.

If you’re around people where you have to keep your guard up, limit what you share, or shrink yourself to feel safe, you’re with the wrong people. If someone takes advantage of you to fulfill their own agenda—even knowing it will harm you—that’s toxic. Walking away isn’t selfish. It’s self-respect. You don’t owe access to anyone who costs you your peace.

Misunderstandings happen. People miss each other. That’s human. But in any real relationship, there has to be conversation. If honesty isn’t possible, the relationship no longer exists in a meaningful way.

Be humble. Be helpful. Care deeply. But if your kindness is being given to the wrong people—walk away.

This is what becoming an adult ultimately means: choosing purpose over noise, peace over pride, and people who let you be yourself.