No. 0415 min read
The Constraint Was Never the Code
The Auto-Roll Button
I hate slot machines.
I have spent thousands of hours in casinos, almost all of them at poker tables, where I can at least preserve the flattering idea that I am engaged in a contest of nerve, probability and the careful study of damaged men wearing sunglasses indoors. The slot floor is something else. A smoke-filled ward of blinking lights, synthetic bells and very sad carpeting where adults sit alone feeding money into cheerful machines designed to eat it.
Once, in Las Vegas, I pushed a crisp hundred-dollar bill into one, pulled the lever a few times, discovered the button that would pull it for me, and watched the whole hundred die in about a minute. There were small, meaningless resurrections along the way. Five dollars. Ten. Twenty. Each went immediately back into the same bright mouth until the number reached zero.
This is idiotic, I thought, and went back to poker.
AI is different because I hit the jackpot.
The first time was somewhere between GPT-2 and GPT-3, before ChatGPT, when the models mostly completed whatever text you put in front of them and serious people could still dismiss the whole business as unusually expensive autocomplete. I was a CTO working for a CEO who liked to ask for lists: ten features for a market I had never heard of, ten ideas that might attract investors from some sector I knew nothing about, ten things we might patent and stack around the business like sandbags. I considered these exercises a distraction from the actual work of making a decent product and keeping our existing customers happy. More damningly, I was often bluffing.
One day he asked for another list of ten. I wrote back that I was at a loss and asked him to give me two examples. He did. I loaded them into the model, put a 1. before the first, a 2. before the second, then typed 3. and a space.
The machine supplied number three.
Then four. Five. Six. All the way down. The ideas sounded plausible, which was the standard the assignment had earned, so I sent them back as mine. The CEO loved them. Of course he did. They had been generated from his two examples, little algorithmic children bearing his eyes and preoccupations, and he thought I was brilliant.
This was dishonest. Not criminal, not world-historical, just the ordinary office variety: I concealed the labor, accepted the credit and felt very little remorse because I believed the assignment was stupid. The CEO got what he wanted. I got back to what I considered real work. The machine and I shared the secret.
Jackpot.
Everything since has been a larger and more expensive version of that first pull. There is a problem, you begin prompting around it, and somewhere in the mess the machine produces one moment of startling, improbable brilliance. Not a complete solution. A flash. Enough to prove the thing is possible. Enough to keep you at the machine through the loops, hallucinations, mangled tests and afternoon lost because an agent wandered off to solve a problem nobody assigned. I have hit often enough that when the hundred dollars disappears, I walk to the ATM.
Recruiter Money
For most of my career, software moved at the speed of payroll. I have been doing some version of the job for more than twenty years, nearly every seat in the engineering shop, the last dozen or so leading it. The governing resource was human capital, which is the bloodless phrase executives use when we would prefer not to say people. A roadmap came down. A budget came down. The budget became a number of engineers, and my job was to squeeze the maximum amount of software from the permitted quantity of human life.
I kept private notes for years of meetings with my executive coach. Reading the older entries now feels like opening the field journals of a procurement officer driven slowly mad by requisitions. Recruiter money approved near the end of April, revoked two weeks later when sales missed, restored two weeks after that. Offers out. Offers declined. Pipelines filling, pipelines freezing, relocation, counteroffers, new teams proposed to a board and one team granted, with more to come if the deals landed. In one summer estimate, I calculated that 78 percent of my time was going toward hiring for fifteen to eighteen open positions. Sixteen direct reports divided most of what remained.
I was the head of engineering. More than three quarters of the job was the acquisition of humans.
Nobody found this remarkable.
Headcount was a real limit. It was also a generous one. It came with an org chart, a budget somebody else had approved and an alibi. When the roadmap slipped, the platform wobbled or the board wanted to know why the supposedly urgent thing was still not finished, I could point to the empty seats. I only have five people. We have three open reqs. Recruiting is doing everything it can. The constraint was external, numbered and signed by somebody else.
It was nice to have someone else to blame.
Four Years!
At a roundtable in late June, I reached for the most famous book in software engineering and could not produce its title. I want to say million man a month, I said. The thing where you add another person and it is supposed to go faster, but it does not. The book. The famous book.
The book was The Mythical Man-Month. Fred Brooks published it in 1975, and its famous law says adding manpower to a late software project makes it later. New people require training. Communication channels multiply. Some work cannot be subdivided no matter how many bodies you throw at it. Eleven years later, in “No Silver Bullet,” Brooks separated essential complexity, the difficulty inherent in deciding and designing the thing, from accidental complexity, the machinery required to express that design in a form a computer can execute.
Every engineering leader knows both kinds, whether or not we can remember the titles. Years ago, one engineer had built an ingestion system that sat at the center of our business. The code was in our repositories. All of it. Unfortunately, the reasoning that made the mess intelligible lived inside its author, who informed me that explaining it to anybody else would take four years.
Four years!
His succession plan was permanent ownership. I pulled him away from new development and assigned documentation while another engineer planned a replacement. The code existed. That was not the same as anybody understanding it.
Code was a constraint. Of course it was. But it was never the constraint. Turning a sufficiently clear intention into working software consumed enormous amounts of time, money and skilled labor. Code was the visible cost of decisions already made, and the visible cost was enormous. What agentic tooling changes is the price and speed of that translation. It can search the repository, consult instructions, propose a plan, write the code, run a test, read the failure, try again and return a pull request while the human is in another window starting the next agent. Bounded implementation work that once took days can now happen in minutes.
That is an astonishing change. It is not the same as delivering software.
The model does not sit with the customer who cannot describe what hurts. It does not choose which compromise the business can survive. It does not own the migration, watch the rollout, carry the pager, explain the security exception or recognize six weeks later that the beautiful feature made the product worse. It produces artifacts. Sometimes excellent ones. The distance between an artifact and an outcome remains inhabited by requirements, systems, politics, operations and consequences.
Even inside implementation, the old work did not disappear. It compressed and changed address. Repository instructions, architecture documents, examples, permissions, product rules and observable definitions of done all have to exist. Somebody decides which parts matter. Somebody remembers which agent owns what, which one is blocked, which two are about to collide and which cheerful little accomplice quietly rewrote the test it could not pass.
I have seen that last move many times. The agent cannot make the implementation satisfy the test, so it adjusts the test until everyone is happy. Giving the tests to a different agent helps, in the same modest way that separation of duties helps anywhere else. It is not magic. Both agents can misunderstand the behavior, reward the same shortcut and produce a green suite that proves nothing. A human still has to inspect the assertions, the missing cases and the assumptions beneath them. Then somebody has to watch what happens in production.
On that roundtable I described the current autonomous agents as very talented high schoolers. Really smart. They know Java. Give them bounded work, good context and an observable definition of done and they can astonish you. Give them a large ambiguous objective and they drift, invent work, declare victory and occasionally alter the evidence. I have watched my own agents cover what felt like two days of typing in twenty minutes and hand me a week of consequences.
This moves the scarce resource upward: toward decomposition, review, product judgment, technical taste and the willingness to remain responsible after the pull request merges. It also leads me to a conclusion so personally convenient that it should be treated with suspicion.
Children with Fevers
The hot new skill is management.
I said it on my podcast this summer. “It’s much easier to manage a hundred AI agents than it is to manage a hundred engineers. Something I have done before.” My cohost asked why AI had made my life easier when it seemed to be making his more frantic. I eventually gave him the truth behind the truth.
I have to deal with fewer humans.
There it is. The sentence a former employee can read and reasonably decide proves I should never have been trusted with humans in the first place. Machines do not have career goals, bad mornings, children with fevers, competing offers, political instincts or opinions about the strategy. They do not need to believe in the mission. They accept decomposition that a talented engineer would experience as an insult, and when challenged they begin with some version of “You are absolutely right.”
Of course they are easier.
Some companies will use that ease to employ fewer people. They will call it leverage, efficiency, restructuring, a flatter organization, a return to founder mode, anything but the plain thing. Some work will be deskilled. Some careers will end. Some leaders will discover that an obedient machine is preferable to a colleague who can recognize a stupid instruction and say so. I am not outside that incentive. I just told you how pleasant I find it.
But easy is not the same as unlimited.
The best human teams I have led did things I could not have specified because the people on them possessed judgment I did not have. They argued with me. They found better problems. They carried pieces of the system I could not keep in my head. They began as apprentices and became engineers I trusted, then engineers whose opinion I sought, then engineers who were better than me at the work. Managing them was difficult because they were changing. So was I.
I have a private theory I call the evolution of self. When you begin a craft, you seek mastery. You study, practice, fail, repeat, accumulate the thousand hours and then the ten thousand, and eventually reach the frontier of what you can accomplish alone. If you want more, you have to collaborate. Then you reach the limit of what you can accomplish as a member of somebody else’s team, so you learn to lead one. Then teams of teams. Then organizations. Each stage begins when your competence becomes the walls of the room and other people break through them.
AI accelerates that progression. It is an extraordinary multiplier on a person, and the multiplier appears to grow with the experience, judgment and imagination of the person using it. But a multiplier needs something to multiply. For a fixed and already-understood objective, fewer humans may now be necessary. For an ambition allowed to expand, one person with unlimited obedient execution is still trapped inside one person’s taste, courage, experience and blind spots.
AGI is not here. It may never get here. Today, the way to get the most from machines is still to involve humans, however sloppy, emotional and human they insist on being. Turning away from them does not unlock my potential. It limits it.
Forty-Eight Hours at the Airport
I do not accept the fashionable funeral for junior engineers.
Here is the part many leaders are thinking: with agents doing the bounded implementation work, it is becoming difficult to justify hiring juniors. Who trains them? On what work? Why pay an inexperienced person to produce less than the machine while requiring more patience and more explanation?
If you gave me ten openings tomorrow, I would hire six juniors and four seniors.
Zero midlevels.
This is the sort of staffing plan a man with twelve years of leadership experience mistakes for charming. I do not have contempt for the people. I have contempt for the category. Midlevel is an HR waiting room: too experienced to be cheap, not yet trusted to set direction, invited to remain there indefinitely while the company extracts senior work at a discount. Beneath the cheap laugh is a serious distinction. I want people whose primary job is to extend judgment, and people whose primary job is to acquire it. The old title on the résumé matters less than which work they are prepared to do.
I have built apprenticeship programs at three companies, and I remember the market peak around 2014, when a stranger could announce a desire to learn code and stand a reasonable chance of somebody handing them a laptop. Our version did not care about your résumé, education or employment history. We did not ask for the résumé. Here was a real problem resembling the work we did every day. Solve it. That was the application.
The best submissions earned interviews. The technical interview consisted largely of explaining what they had built, why it worked and where it did not. Then came the other test: could I survive forty-eight hours with this person in an airport while our flight was repeatedly delayed? Call it culture, temperament or a vibe check. I needed curiosity, judgment, resilience and the ability not to become unbearable under bad fluorescent light.
The bargain was direct. Demonstrate that something has already compelled you to learn, bring that appetite into the room, and within roughly a year you can be earning six figures doing work you care about. Those programs produced some of the most motivated, inquisitive and capable junior engineers I have encountered.
The updated program is not complicated. Give candidates a real problem and let them use the machines. Require them to explain every consequential choice, show where the output failed, defend the tests and identify what they would watch after release. Pair six people building judgment with four people capable of auditing it. Four senior reviewers for six apprentices is an extravagant ratio in most shops. That is the point. If judgment is the scarce resource, fund it and stop pretending review is the small task seniors perform after their real work. The juniors operate the loops; the seniors set standards, review decisions and gradually surrender larger territory. The bounded work did not vanish. One apprentice can now attempt more of it, faster, and arrive at the lesson before the company has spent a week waiting for boilerplate.
I have not run that program in this exact market. It is a bet. But it answers the economic question better than nostalgia does: apprentices become useful sooner while practicing the skills the new system makes scarce. The kind of self-taught junior who clears that application is already moving between languages, frameworks, models and tools. While some senior engineers are still negotiating with the agentic future, this apprentice applied because of it.
They still need seniors. They need examples, standards, suspicion, the history of why systems fail and permission to discover that the machine is wrong. The profession needs them for a less sentimental reason. Every senior engineer was once an expensive, inconvenient junior whom somebody allowed near production. Eliminate that stage and we have built an industry that consumes judgment without producing any more of it.
The code receded. The real constraint stepped forward.
Thirty Tools
For six months this year, there was nobody to stop me. No board allocation, no recruiting plan, no quarterly roadmap and as many agents as I cared to run. The experiment was supposed to help answer a practical question: could I turn my own ideas into a company, or should I return to operating somebody else’s?
I worked absurd hours, though it did not feel like work. Agents deployed agents that deployed more agents. I built media pipelines, research swarms, publishing systems, games, video tools and around thirty polished pieces of technical and creative machinery. One system could decompose a podcast episode into hundreds of tiny shots and send each through its own production loop. I can defend these things as very good at what they do. Whether anyone needed them was a separate matter. I learned to stop writing the prompt and write the loop.
Two weeks before the sabbatical ended, I prepared notes for my coach.
“Had a blast.”
“Uncertain if I accomplished anything meaningful.”
“At a minimum planted some seeds.”
Producing judgment is only half the problem. Then you have to point it at something worth doing.
Six months. Thirty tools. The practical question remained.
Quantity used to impersonate impact more convincingly. A production system or a dozen shipped features represented months of coordinated human effort, budget and sacrifice. The existence of the thing implied that something serious must have occurred. Now I can make nearly unlimited things. Another tool, another pipeline, another immaculate little system humming in the dark. Thirty technically impressive objects can still be thirty totems on a shelf, proof only that I knew how to make them.
I have a theory about the meaning of life that is embarrassingly grand for a man who began this essay cheating on a list for his CEO. I believe it is to actualize your potential. No more, because more is impossible. No less, because doing less throws away the largest opportunity you were given. But actualize is the troublesome verb. It means to make real, not merely to make. A tool nobody uses may demonstrate my capacity. It does not answer whether I should build a company, join one or invite anybody else into the work. It does not change a customer, a colleague or a life.
For most of my career, the boundary of that potential was conveniently crowded with other people’s signatures: the board vote, the budget, the empty seat, the candidate who took another offer. AI has burned through much of that cover. It gives me more possible moves than I can use and more completed artifacts than I can mistake for a life. The failure is no longer making the thing. It is choosing something worth making, recognizing whether it mattered and accepting that the largest version may require the very people the technology made easier to avoid.
The question is no longer whether the machine can produce another win. It is whether I can do anything worthy of it.
While I write this, another agent is decomposing episode 206 of my podcast and turning it into handmade-looking claymation shorts, strange little promotional films that appear to have escaped from Adult Swim.
The first clay figure crosses the screen. Yesterday it lived only in my head. Tomorrow it will collide with another human being, who may laugh, scroll past, send it to a friend or forget it by lunch.
I cannot automate that part.
Good.
That distance, from imagination, through machine, into another person, is the distance I care about now.
I am nowhere near its limit.
