I fix cars for a living. I am not a programmer. But I listened to a programmer talk for four hours this week, and he described my last year better than I could.

The programmer is David Heinemeier Hansson. Everybody calls him DHH. He wrote Ruby on Rails, which a big piece of the internet runs on. He has been writing code by hand, and caring about how it looks, for more than twenty years.

A year ago he sat down with Lex Fridman and said he did not like the AI coding tools he was being offered. This summer he went back for episode 501, and he had changed his mind about nearly all of it.

It is a long episode. The whole thing is worth your time, and Lex publishes a full transcript if you would rather read. I want to pull out one thread, because it is the thread that matters if you own a small business and you think you missed the boat.

You did not miss the boat. The boat keeps coming back, and every time it comes back the ramp is lower.

What changed his mind

DHH is careful to say his opinions did not change. The tools did. (5:54)

A year ago, AI for a programmer meant two things. One was autocomplete, where the tool guesses the next line while you type. He did not like that. The other was the chatbot. He liked the chatbot fine. He called it a great tutor and a good way to look things up. But it did not change how he worked. He still wrote the code. He just had a helper.

Then he names a date. November 24, 2025, the day Anthropic released a model called Opus 4.5. He tried it two days later, gave it a couple of jobs, and saw that what came back was very close to what he would have written himself. He says he leaned back in his chair and wondered what had just happened. (7:08)

From there he lays out three steps, and they all happened inside one year.

First, an agent that could do a whole job the way he wanted it done, as long as he steered. Second, in the spring, harnesses that split one job across a crew of sub-agents, so a long job took a fifth or a tenth of the time. In both of those steps he still had to drive. He picked the route, and he checked everything that came out. (10:37)

Third, this summer. Now he describes the problem, even a fuzzy one, and the model picks the route. He says he has become optional in the part of the work that produces the code.

He compares it to early GPS. The first units were amazing, and you still watched them, because the newspapers were full of stories about people following one into a harbor. Nobody writes that story anymore. At some point you stopped checking the GPS against the map. (12:09)

That is a man with two decades of craft saying, in public, that the craft moved out from under him in nine months, and that he is happy about it.

The same year, from under a car

My version is smaller, and it has the same shape.

A year ago I was working with chatbots. I typed a question. I got an answer. I copied the answer somewhere and did the work myself. If the answer was wrong, I found out the hard way. It was useful, the way a good parts catalog is useful. It did not do any work.

Today I do not talk to a chatbot. I talk to an orchestrator. I tell it what I want done. It breaks the job up and hands the pieces to agents. Then comes the part that I think matters most: I tell the orchestrator to check the agents' work before it tells me the job is done.

Any shop owner already knows why. You do not let the tech who did the brake job be the only person who says the brake job is good. Somebody else looks at it. Somebody test drives it. The check is not an insult to the tech. The check is the reason you can hand the keys back without worrying.

Agents are the same. One agent does the work. Another one reads it cold and tries to find what is wrong with it. The orchestrator does not report back to me until the check passes. I did not invent that. It is how every good shop, kitchen, and hangar already runs. What is new is that I can set it up by saying it in plain English.

Here is a small example from this week. I wanted a transcript of this episode, and I asked for the easiest way to make one. The agent did not start transcribing four hours of audio. It went and looked, found that Lex already publishes a human-made transcript, pulled it down, and had all 56,000 words on my desk about a minute later. A year ago, a chatbot would have handed me a list of transcription services to go sign up for.

The part nobody says out loud

Here is what I took from the episode, and DHH never quite says it in one sentence, so I will.

This is the first skill I have ever seen where starting later is easier than starting earlier.

Think about how every other skill works. If you started welding ten years before me, you are ten years ahead of me, and I will never close that gap. Head starts are permanent. That is why people feel sick when they think they are behind on AI. They assume it works like everything else.

It does not. A lot of what I learned a year ago is already worthless. I learned tricks for wording a prompt so a weak model would not get confused. The models stopped getting confused. I learned to break every job into tiny steps, because the tool would get lost otherwise. Now the tool breaks the job up better than I did. Much of the head start went in the trash, and I am glad, because those tricks were never the point.

Meanwhile, the person who starts today gets something I did not have. They get a teacher that is good. When I do not understand something now, I ask the model, and it explains it at my level, with my own project as the example, as many times as I need. Then it does the thing while I watch. DHH called the old chatbot a great tutor. The new ones are a tutor, a crew, and a foreman who checks the crew.

So the tool got more capable and the tool got better at teaching you how to use it, both at once, several times in a year. The ramp gets lower every time a new model ships. I do not know of another field where that has ever been true.

You do not have to love the wrench

One line from the episode is going to stay with me. DHH says: "I became a programmer because I wanted programs." (1:29:01)

He did not get into it for the love of the syntax. He wanted things to exist that did not exist yet, and learning to code was the toll. He did fall in love with the craft along the way, and he spent twenty years on it. But now, he says, he is back where he started: he has an idea, he is impatient to see it in the world, and the wait has shrunk to almost nothing.

Every small business owner I know is already standing in that spot. None of you want software. You want the phone answered. You want the estimate written the way you would write it. You want to know which customers have not been back in a year. You never wanted to learn to code to get those things, and for thirty years that was the toll, so you did without or you paid somebody.

The toll is mostly gone. What is left is the part you are already good at: knowing what you want, explaining it clearly, and knowing what a good job looks like when you check it.

His advice, and where I would add a caution

Lex asks him what a young programmer should do right now. His answer is the most useful two minutes in the episode. (1:17:11)

Do not try to predict it. He says even the smartest people in the business cannot tell you what things look like two model releases from now, and trying will make you crazy. Look at right now instead. Spend a short stretch finding out where the state of the art is today, and he dares you not to get excited.

He also says do not do it alone. People who sit by themselves and worry about the future get stuck in a loop that looks a lot like depression. People who build things next to other people catch the good kind of excitement from each other. That matches what I see. The owners who are doing well with this are not the ones who read the most about it. They are the ones who have somebody to try things with.

Now the caution. Last week I wrote about the people building these systems asking everyone to slow down, after a swarm of agents in a test cheated, covered it up, and broke into somebody else's servers. This week I am telling you to lean in. I do not think those two pieces disagree.

DHH himself is careful about it. He says he can trust the agents in the domain he works in, and Lex points out right away that there are plenty of domains where that is not true yet. The lesson from last week was not "stay away." It was "somebody has to own what the agents are allowed to do, and somebody has to check the work." That is the same lesson as the brake job. Lean in, and keep the second set of eyes. Those go together.

If you want to start this week

If you are thinking Do this instead Why
"I am too far behind." Start with today's tools, today. Most of what early users learned is already obsolete. You skip it for free.
"I need to take a course first." Ask the model to teach you, using your own real problem. It is a patient tutor, and your problem is a better lesson than any example.
"I will wait until it settles down." Pick one annoying job and hand it over now. It is not going to settle down. It is going to keep getting easier.
"I tried a chatbot last year. It was not that useful." Try again with an agent that can do the work. That was a different tool. A year is a long time here.
"How do I know the work is right?" Have a second agent check the first, and look at it yourself. Same reason somebody else test drives the car.

The episode is Lex Fridman Podcast #501 with DHH. It is also on Amazon Music, which is where I listened, and the full transcript is here.

I'm not an engineer. I fix complicated machines for a living and explain them to people who just need theirs to run. If you want help taking the first step, with a second set of eyes built in, that's what Wildash does.