Process Was Always the Bottleneck

Every week now, some engineer I respect tells me they're worried a coding agent is coming for their job. And every week I give the same answer I've been giving since long before agents could write a line of anything: the code was never the job. I've known this my whole career; anyone who's watched where their week actually goes knows it. I'd just never sat down and put it into words. Watching an agent open a working pull request from a one-sentence issue in twenty minutes finally made me write it down, because the panic is aimed at exactly the wrong part of the profession.
So this post is partly a tooling writeup and partly a defense of my job, and probably yours. If you're a senior engineer losing sleep over coding agents, you of all people should be sleeping fine.
Where the hours actually go
The number I always reach for in this argument comes from Tidelift and The New Stack, who surveyed nearly 400 professional developers about where their hours go: just 32% of their time goes to writing new code or improving existing code. Another 35% went to managing code (maintenance, testing, security) and 23% to meetings, management, and operational tasks. Study after study since has landed in the same neighborhood. The majority of the job is everything around the code: figuring out what to build, reading other people's code, reviewing, coordinating, chasing context, reporting status, deciding whether the thing is even worth building.
And for the doomers, the curve bends the wrong way: the more senior you get, the less code you write. A staff engineer might write real code a few hours a week. What they do instead is decide, scope, review, unblock, and align. That's the judgment work. Nobody promoted them away from the keyboard by accident; the organization figured out that their judgment was worth more than their typing.
So when a coding agent shows up and obliterates the typing, it has automated the junior-shaped 30% of the job and made the other 70% the whole job. If your value was already in the judgment layer, what the agents actually came for is your backlog.
None of that is a fresh insight; it's how the job has always worked. What's new is that at Ariso we've built our entire workflow on that premise, harder than any team I know. The rest of this post is what betting on it looks like, and why my job has never felt more secure or more senior.
Code got cheap
Ivan, our free, open-source coding agent, collapsed the typing part of the job almost overnight. I can run it locally against a stack of tasks, trigger it by commenting @ivan-agent /build on a GitHub issue (I've written about that setup before), or just describe a bug to Ari in Slack and let her file the issue and kick Ivan off herself. Between those three paths I open hundreds of PRs a week, and most of them are ready to ship as written. That part of the job got faster than I ever thought it could, which made the other part slower. Every one of those PRs still has to be judged by a human: is it right, is it wanted, is it safe. The supply of code became effectively infinite; the supply of judgment didn't budge. The typing sped up, and the review and process around it became the queue everything waits in.
Reviewing at volume
Hundreds of agent PRs a week is a wall of diffs, and "just review it all carefully" doesn't scale past the first week. This is the exact spot where the engineer's-job-is-doomed narrative falls apart: it's where humans became more necessary, and where we needed help.
That help is ivan review:
ivan review 412 413 414 --leave-commentsPoint it at one or more PRs and it runs a review pass whose goal, written right into the prompt, is to set the human reviewer up for success. For each PR it produces:
- A summary of what the PR does, so you're not starting cold on a diff you didn't write
- The spots to check first: the specific files, functions, and logic paths carrying the most risk, and why each one deserves your attention
- Concrete findings (bugs, security holes, performance problems) tagged by severity, from critical (must fix before merge) down to nit
- With
--leave-comments, inline comments posted straight onto the PR at the exact file and line
It doesn't approve or merge anything. It compresses a forty-minute cold read into a five-minute guided one, so a human can hold the review line across ten times the volume. My mornings now include a pass where I read Ivan's review of Ivan's code and spend my attention only where the risk actually lives. That's my job with the tedium strip-mined out of it: the judgment is still 100% mine, applied at a volume that would have been impossible before.
If agents write the code and humans keep the judgment, then tooling for the reviewer is the most important tooling in the whole stack. Review was always a core engineering skill (ask anyone who's maintained a large codebase); it's finally getting billed as one.
A tracker that watches you work
Every project tracker rots the same way: it only knows what people tell it, people hate telling it, so it goes stale, so nobody trusts it. Keeping it honest has traditionally fallen to the senior people, in the form of status meetings and roadmap updates.
We run ari-hooks on our dev machines, a small open-source package that wires Claude Code (and Codex, and Cursor) into Ari through the hooks these agents already support. Every time a coding session finishes a turn, it sends what was asked and what the outcome was up to Ari. Ari already knows our meetings, follow-ups, and Slack threads; now she also knows what I actually built today, because my terminal told her.
That feed keeps our Projects view honest without anyone reporting anything. In Ari's Team Space, a project is a name, two dates, and milestones, and Ari writes the status every day from real signals: the sessions that shipped, the PRs that merged, the meeting where a deadline moved. Nobody sets a status by hand. When my co-founder wants to know how phone verification is going, he reads what Ari wrote this morning, based on what I actually did yesterday.
It flows the other way too: when I open my terminal, ari-hooks asks Ari what's worth doing right now, pulled from meetings, follow-ups, and yesterday's work, and prints it into my session before I've typed anything. I've written about that loop before.
Pointing all this capacity somewhere
When shipping is this cheap, the new failure mode is shipping an enormous amount of stuff that doesn't matter. An agent will happily build the wrong thing at 10x speed.
My Ari knows my goals and priorities, near-term ones like "ship phone verification" and the longer arc, written down once, in one place. The morning suggestions are ranked against them. My weekly reflection, drafted from my actual activity via ari-hooks, tracks progress against them and flags what I did that mapped to none of them. Work priorities roll up toward company objectives, so "is this week's work connected to what the company needs this quarter" has a checkable answer.
Deciding what matters and noticing drift used to be senior-engineer and management work done in review meetings, after the drift happened. Now it's ambient. The inputs are still pure judgment, though: which goals, which priorities, what matters. No agent supplies those; someone with taste does.
What my week looks like now
In an average week, agents write most of the first-draft code. I write issues precisely, review diffs with ivan review prepping the ground, make the merge calls, keep the goals sharp, and handle the genuinely hard problems, the ones that were always mine. My typing time went down and my judgment time went up. My output, measured in things that actually shipped and mattered, is the highest of my career.
If you're a senior engineer worried a coding agent is coming for you, run the numbers on your own calendar first. How much of last week was typing code? If it's around 30% (for most seniors it's less), the agents are competing for the slice of your job you were already trying to delegate. The other 70%, the scoping and reviewing and deciding and aligning, didn't shrink. It grew, because someone has to direct and judge all this new capacity, and that someone is you.
Ivan and ari-hooks are MIT-licensed and free, an npm install away. The tracking and alignment layers are what Ari does for a living.

Max Heckel is the founding engineer and CTO of Ariso. Before starting Ariso, he worked at Google, McGraw Hill, JupiterOne, and created SciSummary.
LinkedInReady to try Ari?
The AI player-coach that gives every employee the tools to lead themselves.