I spent more than twenty years building software. I was a developer first, and then a chief technology officer four times over, mostly in education technology. I know how the work is done, because for two decades I did it by hand. I do not really do it anymore.
My team at AWS helps companies turn an idea into a product. For years the work was done by hand. We wrote a requirements document. Sometimes we wrote a press release for the product before it existed, to force clarity about what we were actually building. It was slow, and it was the same shape every time.
Then the tools caught up, one capability at a time. When Claude Sonnet 3.5 arrived in 2024, I could hand it the requirements and get back a prototype you could click through, so I did. When the coding tools I use, Kiro and Claude Code, learned to search the web, I had them run the market research too. An AI agent is nothing exotic: a model that reads files, runs commands, and follows written instructions without you watching each step. For months these stayed one-off uses, a prototype here, a research pass there, each assembled from scratch. Then I noticed I was rebuilding the same sequence by hand every time. So I wrote the sequence down as a set of plain-language procedures and made it the repeatable process it should have been all along. It is open source now, and it runs on three different AI coding tools, Kiro, Claude Code, and Cursor, because the steps do not care which model executes them. That toolkit, not any single prototype, is the most useful thing I have made at AWS.
That is the whole of my method now, at work and at home. The method fits in a sentence.
I don't write things. I notice them.
I have built something like a hundred small pieces of software in the last two years, and I wrote the code for almost none of it. I do not write the instructions either. What I do is notice friction, describe it to a model clearly, and decide whether what comes back is worth keeping.
I could still write the code. That is exactly why I find it worth saying that the writing is no longer the job. The job moved up a level, to noticing and deciding.
The loop
The move is always the same. I have done it enough times to name the steps.
Notice the friction. Something in your week that is annoying, repetitive, or just slightly worse than it should be. Not a feature idea. A specific irritation you actually have.
Ask the model to solve it in a way that makes sense. That last part is the judgment, and it is most of the skill. I am not asking for any solution. I am shaping it: keep it local, keep it legible, keep it simple enough that I can tell when it breaks. This is the part my old job trained, not the coding. Sometimes the sensible move is not to build at all, but to fix something that already exists. Five of my tools are other people's open-source projects that I forked and repaired for my own use, including the one that pulls my kids' school grades.
Find out if it is any good. Use it for a week. Most software promises to save time and quietly costs more than it saves. You only learn which by living with it.
Decide whether to keep it. Two questions. Is the solution actually good? Is the friction actually worth removing? If either answer is no, throw it away.
I throw away most of it. I have a folder of roughly fifty-five abandoned projects: a chess engine, a solar-system simulator, a dozen things I can no longer explain. People hear "build your own software" and picture a tidy workshop. Workshops are full of failed cuts. The cheapness of trying is only an advantage if you are willing to discard most of it. That is the discipline.
Keep, or promote
What survives splits in two.
Most good tools just run. The camera that tells me in plain language who is at the door. The briefing that reads my mail each morning and explains, in writing, why it thinks each message can wait. These solve a real annoyance well enough to keep, and that is all they need to do. They are tasks I no longer perform.
A few tools are good, and reusable, and a little bit new. Those get promoted. I ask the model to turn the one-off into something durable: a skill, a library, or a pattern. A skill is a written procedure the agent can follow again. A library is shared code that two projects can both call. A pattern is an idea that turned out to travel. When I noticed three of my home cameras running the same kind of logic three slightly different ways, I had the model lift the common part into a library. A script I wrote once to pull records out of a county database became a skill the day I needed those records again for something else.
Promotion is the part to be stingy with. Not every good tool deserves to become infrastructure. Make a skill out of everything and you have built a second mess on top of the first. The bar is high on purpose: good, reused, and novel enough to be worth a name.
What changed
None of this is a new idea. I ran this exact loop as a CTO. See a problem the team keeps solving by hand, and build a tool or a process so they stop. That is most of what technical leadership is.
But I ran it a few times a quarter, not a few times a day. Each cycle cost a developer weeks, so I spent them only on the biggest, most expensive frictions. A problem had to be worth a salary before it was worth solving. Everything below that line, you lived with.
Two things moved the line. The cost of a cycle fell from weeks to an evening, sometimes an hour. And the range of problems one person can solve stopped being bounded by what that person already knows how to build. I do not know how to write a computer-vision pipeline. I did not need to. So the loop no longer runs only on problems worth a salary. It runs on a trash can, a county website, the hourly readout from my electric meter. The threshold dropped to the floor, and now the loop runs on everything.
Why this compounds
The tools also accumulate, and each one makes the next problem cheaper.
When I wanted a spoken news briefing in a voice I liked, I did not start from nothing. I had forked two text-to-speech engines months earlier, for something unrelated. That work was just sitting there. The briefing took an evening instead of a month, because the hard part was already a tool. This happens constantly now. A new problem turns out to be most of the way solved by something I built for an old one. The pile grows, and the cost of the next thing falls.
Doing the task pays back once. Building the tool pays back every time the task returns, including the times you have not imagined yet. Most people still reach for the AI to do the task faster. That returns the time the task took, once. The leverage is one level up, in deciding what to keep.
What outlasts the model
The models change every few months. The one that built most of this is two generations gone. If your investment lives in clever prompts tuned to one model's quirks, you are renting.
The tools do not churn. The skills are written in plain language, and they have survived every upgrade untouched. A better model arrives, reads the same instructions, and does the same jobs better. As a CTO I used to depend on a vendor staying in business and not raising the price. Now I depend on my own accumulated notes and tools, and any capable model can run them. The durable thing was never the model. It was never my code either. It is the growing pile of solved problems.
Monday
You do not need a basement full of computers, or a career writing software. You need one friction and the willingness to throw away the first answer.
Pick the most annoying recurring thing from last week. Describe it to an AI tool that can take actions, Claude Code is mine, and tell it not only what to do but how you want it done. Use the result for a few days. Then be honest. Is it good, and did it matter? If not, delete it. If so, keep it, and the next time a similar problem shows up, notice that you are already halfway done.
Do that a dozen times and your week looks different. Not because you learned to code. Because you stopped doing a handful of things by hand, and started keeping the few that earn it.