The job moved up a level

The team this used to take

Picture the old way to build this. A backend developer, someone on the front end, a reliability engineer to keep it up, an operations person for the incidents at three in the morning, a legal review for the disclaimers, and somebody watching the cloud bill. That is a team, a few months, and tens of thousands of dollars before the first user arrives. For a side project about hurricanes the arithmetic never worked. So projects like it did not get built.

I built it and I run it alone, and it costs about $15 a month. The code was the easy part. What changed is not that I type faster. What changed is that I could hold all of those roles at once.

And here is the half of the change that gets less attention than it deserves. Building software got cheaper and everybody noticed. Running software is where the money and the people always went: the on-call rotation, the monitoring bill, the person who picks up the page. A product is not what it costs to write, it is what it costs to keep alive. That is the cost now falling, and it is the one that decides whether a thing survives its author losing interest.

Building got cheap. Judgment did not.

It is fashionable to say the AI writes the code now, and it mostly does. Andrej Karpathy has been making the point for years. In 2023 he wrote that the hottest new programming language is English, and in his 2025 Software 3.0 talk he frames the prompts themselves as the program. That part is real. The first working version of almost anything is now nearly free.

A working version is not a product, and that gap is where the experience lives. Karpathy has the tidiest phrasing for it: a demo is works.any(), a product is works.all(). One good run makes a demo. A product is every run working, including the ones nobody is watching. The model is fluent and tireless and has no opinion about whether its code will still stand a year from now. Karpathy describes the human job as keeping the AI on a tight leash, pairing fast generation with fast verification. I felt that on every commit, and I have the ratio to prove it: 91 of the first 184 commits were me correcting something that already looked finished.

My leash is a short list of principles I refuse to bend, and I would not expect a model to supply any of them. It will not insist on a test before the code. It will not keep one source of truth so two parts cannot drift. It will not hold that line on the four hundredth commit. That insistence, held until the system has a spine, is now most of the job.

Knowing who to put in the room

Microsoft's 2025 Work Trend Index has a name for the emerging role. It calls it the agent boss, defined plainly as a human manager of one or more agents. That is what this felt like. In a single day I would direct a software engineer in the morning, a legal reviewer after lunch, then an incident responder and a cost analyst before I shut the laptop.

There is a step before directing them that turned out to matter more than anything that happens after: deciding which experts are in the room at all. Jim Collins built a whole chapter of Good to Great around first who, then what, and the makeup of the room shapes a decision more than almost anything said inside it.

I learned that writing these very posts. For days the wording would not land. The facts were right, the structure was right, the sentences were flat. Nothing I tried fixed it, because I was asking the wrong room. The moment I brought in a conversion copywriter, an agent whose entire job is making a reader care, the words clicked. The fix was not a better prompt. It was a better specialist in the seat.

Harvard Business Review has the tidy version of this: teams solve problems faster when they are cognitively diverse, when the room genuinely sees differently. With AI, that room is something you assemble on demand, one agent at a time, which makes the roster the thing to get right. An engineer, a reliability specialist and a copywriter reading the same paragraph each catch a different flaw.

Here is the part I do not see the model doing for me yet. Knowing who to call still lives in you, learned over years of watching which kind of expert unlocks which kind of problem. Nothing told me the room needed a copywriter. I had to know that.

The dial I still set by hand

One judgment call the room never made for me is how reliable each part of the system deserves to be. Google's SRE book states the uncomfortable version: 100% is probably never the right reliability target, because each extra nine costs more than the one before it and past a point your users cannot tell the difference. Reliability is a dial with a price, not a virtue to maximize.

So I turn it up where a person would feel a failure, and down where nobody would notice. The checks a visitor's experience depends on run every sixty seconds from outside my infrastructure. The internal loop that watches slow-moving signals ambles along every fifteen minutes, because its alarm thresholds are measured in hours. That single distinction, felt failure versus late job, is most of the reason the bill stays near free, and it is a decision I would not delegate: the model does not know which failures my users would forgive.

The sunk cost AI wrote off

Count the managed tools this small project stands on. Vercel, Neon, Cloudflare, Anthropic, Hetzner, Grafana, GitHub Actions, plus a secrets vault and a zero-trust door in front of the operations dashboard. I am not an expert in most of them and the product is not worse for it. A year ago that sentence would have been an admission of risk.

In the old world every one of those tools charged an entry fee: days or weeks inside its documentation before it earned a place in a stack, paid by a person and lost with that person. That accumulated tool knowledge is one of the largest sunk costs in an engineering career, and it distorts decisions the way sunk costs always do. Teams keep a vendor because somebody spent a year getting good at it. Architectures stay modular on the diagram and immovable in practice, because swapping a managed service means paying the learning fee again.

On this project the AI paid the entry fees. It read the documentation, wrote the configurations, and told me things about each tool I did not know to ask. The consequence is the modularity everyone draws and few have: nothing should tie me to any of these except what the tool actually does.

I have not had to swap a vendor yet, and by my own rule that keeps this a hypothesis rather than a result until I do.

The wall that fell, and the one that did not

Almost everyone has ideas. What almost nobody had was a cheap way to find out whether an idea was any good, because finding out meant building the thing, and building the thing meant a team, a budget and a quarter. The idea was never the scarce part. Execution was the wall, and it was expensive enough that most ideas died on the wrong side of it, technically possible and economically pointless.

That wall is much lower now. When a real, operated product costs a few weeks and $15 a month instead of a team and tens of thousands of dollars, a whole category of things crosses from not worth it to why not. The hobby that needed a legal review. The internal tool never quite worth a developer's quarter. The experiment nobody could justify funding.

The second wall did not move at all. Getting a thing in front of people, earning attention, and turning that into use still takes distribution, marketing and luck. None of that got easier.

What it did to the job description

I used to be in the fix loop. Read the report, write the change, push it. For repair work I am now a level above it: I write the rules the machine must satisfy, I set the budgets it spends, I read the audit trail it sends, and I hold the switch that turns it off.

That is a management job in the most literal sense, over a workforce that happens to be software. What struck me is how familiar it feels. Clear expectations written down rather than implied. Real gates instead of vibes. Trust extended in proportion to the controls that make it safe. Accountability that stays with me regardless of who, or what, did the work. If the last decade of my career was learning to lead engineers, this project suggests the skill transfers better than I expected it to.

How I govern a build like that end to end, constitution first, adversarial review on every irreversible decision, is its own story about a different system: Laws before code.

The fear worth answering

If AI does the junior work, where does the next experienced builder come from? It is the right question and it deserves a straight answer rather than optimism.

Here is what I noticed. They were not world-class in any of those fields. They were good enough to argue with, which turns out to be the useful threshold. And the good-enough specialists I leaned on were not only doing work, they were teaching me the edges of crafts I am not expert in, every single time I had to judge their output and hand it back. You learn a field surprisingly fast when you are forced to grade it all day. The room is not only how the work gets done. It is, if you let it be, the new apprenticeship, and you learn from it exactly as fast as you can tell good work from bad.

So the thing to protect is the ability to tell. But I want to name the risk people are actually facing, because it is not the one in the headlines. The risk is not that AI takes the work. The risk is standing still: treating this as something happening to you, waiting for it to settle, and still waiting when the people who moved have three things shipped.

What is left, and why it is the hard part

The system runs itself. It does not manage itself, and the gap between those two words is the whole remaining frontier.

Managing itself means deciding what to build. Taking feedback from the people using it and judging which of it deserves to become work. Changing its own interface. Weighing a feature against a performance fix against leaving well alone. Those are the decisions I have kept, and not because the machine would do them badly. Product judgment needs guardrails I have not designed yet, and unlike the operational ones, those guardrails would have to be dynamic, because the right answer moves as the product moves.

I am not claiming a fully autonomous product exists. I am claiming the operations half is further along than most people think, that the mechanism can be shown rather than demoed, and that the product half is a question of guardrails and judgment rather than one of capability. That is a much shorter distance than it was a year ago.

Whose time this is

Until very recently, having an idea was not enough and neither was being good. To get as far as a prototype you needed to know the right people, or the funds to pay them, or the specific skills yourself and the months to spend. Most ideas died right there.

That is no longer the case. Grit, the courage to try something you have not done before, a set of AI specialists to lean on, and the discipline to keep refining when the first answer is wrong will get you to a prototype. And a prototype is where the conversations start. It is what turns "I have an idea" into something a person can react to, fund, join or buy. The starting line moved, and it moved for far more than software.

This is a small system held to the practices a company would apply, run by one person. What it suggests is not that anyone can build anything. It is that the people who get the most out of the next decade will be the ones willing to do: to hold an opinion, to learn a field well enough to judge it, and to keep going after the first version turns out to be wrong. Doers. Dreamers. Generalists.

And the part I did not expect, which is the part I would repeat to anyone: playing every craft, the ones I know and the ones I do not, made me more well-rounded than any single role ever did. I am a platform engineer who ended up doing design, legal and copywriting for three weeks, and I was better for all of it.

If you have been waiting for the barrier to come down before you start something, it came down. This is your time.