We’re not paid to type anymore
Companies used to hire engineers because writing software was expensive. Agents write it now. What a consultant is paid for has changed, and it is not less work.
For most of the years I have been consulting, the deal was simple. Writing software was expensive, so companies paid people who could write it. A consultant sold hours, and those hours went into a keyboard. The deliverable was code.
That deal is over. Agents write the code now, and they write a lot of it. Nobody is going to pay a principal engineer’s rate for typing that a model does in seconds.
That does not mean the work went away. It moved.
What changed
In February, OpenAI described building a product with zero lines of hand-written code. Over five months a small team shipped an internal beta, and the repository grew to something on the order of a million lines: application logic, tests, CI, docs, tooling. Codex wrote all of it. Their summary of the new division of labor was four words: “Humans steer. Agents execute.”
A few days before that, Mitchell Hashimoto wrote up his own path to getting real value from agents. One of his steps was “engineer the harness”: every time an agent makes a mistake, change the environment so it cannot make that mistake again. Better instructions where the agent lacked context; a tool or a check where it needed to be told it was wrong.
Dan Shapiro’s five levels put the whole range on one scale, from “spicy autocomplete” at the bottom to a factory at the top: a black box that turns specs into software, with people designing the system and agents doing the building. StrongDM runs at that end, with specs and scenarios driving agents and validation standing in for code review.
You do not have to believe every number in those posts to see the direction. The keyboard is not the bottleneck anymore.
What the work is now
If agents write the code, someone has to build the place they write it in. That is what clients pay us for now: decades of experience shipping software, applied to the system that ships. In practice it breaks down like this.
How the code is laid out on disk. An agent starts every session cold. What it knows about your system is whatever the repository tells it, in the order it finds it. Clear module boundaries, one obvious home for each kind of thing, and a short operating manual at the root (an AGENTS.md or CLAUDE.md) do more for agent output than any prompt.
Making sure agents understand what to write, and how. Tobi Lütke called this context engineering: “the art of providing all the context for the task to be plausibly solvable by the LLM.” In a codebase that means rules for the conventions you enforce in review, skills for the tasks that repeat, and specs that say what to build before anything gets built.
Giving agents what they need to work. MCP servers for the systems they touch, skills and rules they can load, triggers that start work when an issue is filed or a check fails, and scheduled jobs that sweep for drift overnight.
Building teams, of agents. One agent in one terminal is a tool. Dozens or hundreds working one codebase at once is a team, and it needs what any team needs: separate workspaces, conventions for handing off, rules about who merges what, and an architecture modular enough that parallel changes do not collide. The landscape under all of this changes monthly, so the architecture also has to make it cheap to swap a model, a tool or a host.
Handling what comes in. Requirements still arrive as conversations, tickets and half-formed ideas. Turning them into something an agent can execute without guessing is senior work, and it decides more of the outcome than any model choice.
None of that is new to anyone who has led an engineering team. It is the same job, aimed at a different kind of worker.
Verification is the job
Here is the part most teams skip.
Birgitta Böckeler’s writing on harness engineering splits a harness into two halves. Guides steer the agent before it acts: instructions, rules, specs, templates. Sensors check its work after it acts: tests, linters, type checks, review agents. She also notes what happens when you build only one half. Guides alone give you an agent that follows rules and never learns whether they worked.
In our experience, teams build guides first and stop there. Writing an AGENTS.md takes an afternoon and feels like progress. Building the checks that catch a wrong change, at the volume agents produce changes, takes real engineering.
But that volume is the whole point. A team that reviewed twenty pull requests a week cannot read five hundred. The answer is not to read faster. It is a QA pipeline that can validate hundreds or thousands of changes a week: fast tests on every change, end-to-end sweeps against a running stack, holdout scenarios the agents never see, review agents with narrow briefs, and merge gates that refuse what fails. Anthropic’s notes on harnesses for long-running agents land in the same place: progress you can trust comes from tests the agent has to pass, not from the agent saying it is done.
Verification is where the factory either ships or just types. It is the part we lead with.
Secrets stay out of the context window
Anything in an agent’s context window can end up in a transcript, a log, a commit, or a prompt sent to someone else’s model. So credentials never go there.
The rule we build to is simple: agents get capabilities, never credentials. An agent that needs to query a database calls a tool that holds the connection; it gets rows back, not a password. Secrets live in a vault and are brokered to processes, with keys scoped per project and per host, and an audit log of who used what.
Agents get everything they need and nothing they should not have. That is least privilege, the same principle as always, applied to a new kind of user.
The bar has not moved
Five years ago a good team deployed weekly, and production was reliable. Now the same team might push hundreds or thousands of change sets a day. Customers do not care. They expect production to be exactly as reliable as it was.
Meeting that bar at agent speed takes infrastructure agents can use safely: deploys that prove which build is serving, progressive rollout, rollback in one step, and observability an agent can query when it is asked why something broke. It is ordinary reliability engineering. There is just more of it, and less room for anything done by hand.
Lights on
Shapiro calls the top level a “dark factory”: no human reads the code, ever. We think the useful version is the opposite. A lights-on factory, where every change is visible, verified and reversible, and a person can walk the floor at any time and see exactly what is happening and why.
That is what heka builds. We are not paid to type anymore. We are paid to know what good software takes, and to build the system that produces it every day, at a volume no team of people could match.
If your agents are writing code faster than you can trust it, that is the conversation to have.