Software Engineering as a Craft

I keep coming back to tractors when I think about AI and software. One driver can cultivate land that once took many people to work. The machine changes how much labor you need. Knowing what to grow, where to grow it, and whether the harvest is any good still matters.

The scale of that shift is worth remembering: U.S. agricultural output nearly tripled between 1948 and 2017 while labor use fell by 76 percent. Machinery was part of that, alongside advances in science and organization. More output stopped requiring proportionally more hands. USDA

Software has its own version of this. A bigger roadmap often turns into a headcount request. Hire a squad, split the backlog, coordinate the work. AI gives us a chance to change that equation. When an agent can handle routine implementation, a smaller team can attempt work that previously needed more people.

For a bootstrapped builder, that’s room to ship without expanding payroll. For a venture-backed team, it creates an opportunity to spend runway on learning what customers need before staffing up. Neither outcome is automatic. But the possibility changes what I look for in an engineer: someone who can understand the business, choose a solution, and own what ships.

Grinding through implementation has always been only part of that job. A clinic asking for a booking system might have a scheduling problem or a cancellation problem. You can generate the CRUD either way. Figuring out which problem is costing them time determines whether any of it helps.

That’s the skill I want to keep developing: getting useful context quickly, spotting the assumption nobody has checked, and turning an ambiguous request into something we can test. Brooks covered the difficulty of deciding what to build in No Silver Bullet. Cheaper implementation gives us another reason to take that difficulty seriously. Brooks

Knowing your stack still pays off. Someone needs to catch the race condition, question the abstraction, and understand why the generated patch passes tests but breaks an assumption elsewhere. Domain knowledge and technical depth belong together. You need enough of both to know what you’re signing off on when you merge.

That’s craft, as I understand it.

It usually starts with an itch. Some workflow annoys you. You think you can make it better. You build a version, put it in someone’s hands, and find out how much you missed. If you care about the problem, that feedback pulls you back into the work.

After enough cycles, your judgment improves. You ask better questions before opening the editor. You recognize the shortcut that will hurt later and the abstraction you can safely postpone. Other people sharpen that judgment: users, maintainers, the person who knows why the business has that apparently absurd rule. There’s a reason collaboration sits at the center of domain-driven design. Evans

That care has to survive contact with a deadline. Sometimes the right move is a script. Sometimes it’s a migration with a rollback plan. Craft includes knowing how much engineering the situation deserves. Every extra moving part becomes something you’ll have to explain, debug, or remove.

I judge AI by the same standard. The Copilot experiment showed faster completion of a defined coding task. Useful, but I also want to know whether shipping that task moves the product forward. A shorter path through the wrong backlog still leaves you with the wrong product. Copilot experiment

The opportunity I care about is a shorter loop between an idea and evidence. Use an agent to explore the codebase, compare approaches, or get a prototype in front of a user. Inspect the result. Test the assumptions. Spend some of the time saved learning what the next version actually needs.

This is what I mean when I say AI doesn’t change the craft. The workflow can change completely while the responsibility stays with whoever ships. We still need to understand the problem, make tradeoffs, and live with the consequences.

Give me the tractor. I want to cover more ground. I also want to know enough about the field to make the work count.