I spent a week last month trying to decide whether to reach for a component library or build something small and custom. A standard problem. Normally I'd make the call in an afternoon. Weigh the time cost against the maintenance debt, measure the friction points in the UI, make the trade-off, move on.
This time I kept stalling. Not because I couldn't generate either solution. A good prompt gets me either path in an hour. The component library is documented. The custom build is straightforward. The actual cost of producing code has stopped being the constraint.
I was stalling because I had to figure out what I actually wanted. Not what was faster. Not what had fewer dependencies. What did I want the software to do, and what was I willing to trade to get there.
That's craft now. Not the code. The intention.
When Execution Stopped Being the Bottleneck
For a long time, "software craftsmanship" meant writing code that was clean, maintainable, elegant to read. It was the difference between someone who shipped sloppy work and someone who wrote code that would last, code that other people could inherit without cursing your name six months later.
That still matters. But it's not the bottleneck anymore.
The bottleneck is deciding what deserves to exist.
You can generate a component library integration in forty minutes. You can generate a custom component in fifty. The time delta is noise now. What you actually spend your time on is whether the custom version is worth the ongoing maintenance. Whether the library forces a mental model that's actually wrong for this problem. What breaks quietly if you choose wrong.
These are intention questions, not craftsmanship questions.
When I was learning, good developers were distinguished by their ability to write correct, maintainable code at speed. That was a real skill. You had to hold the whole system in your head and translate it into code that others could read and modify. Now the system-holding is still necessary, but the translation is automated. The bottleneck has moved upstream.
A junior developer can now generate technically perfect code. It will pass tests. It will follow style rules. It will do what you asked. But if you asked the wrong question, it will do the wrong thing perfectly.
The Thing You Can't Automate
I've noticed it in code reviews. A PR comes in that's technically flawless. Tests passing, patterns followed, everything the linter wants. But I find myself asking: why did you choose this approach? Not because something's broken. Because I can't see the reasoning in the code anymore. The code itself no longer carries the weight of difficult choices. It's too clean.
The uncomfortable truth is that sometimes the right answer is inefficient. Sometimes it's weird. Sometimes it violates a rule because you've discovered a specific constraint that makes the rule wrong in this case. Those decisions used to show up in the code, visible to anyone reading it, proof that someone was thinking. Now they don't. The code can be flawless and thoughtless simultaneously.
This changes what junior developers should actually be learning. Not "write clean code fast." That's commoditized now. It's "know when to break your own rules and why." It's "understand the system deeply enough to know when a pattern doesn't fit." It's "ask the right question before you ask the code to answer it."
It also changes what you should be optimizing for in your own work. I used to try to get faster at writing code. That was the right goal when code-speed was the binding constraint. Now I'm trying to get better at asking questions. At running thought experiments before I open a file. At noticing when I'm about to solve the wrong problem elegantly instead of the right problem messily.
The Thing That Doesn't Work Anymore
The weird part is that this should make software better. If everyone's spending more time thinking and less time typing, we should ship fewer bad decisions. But I'm not sure we do. The cheaper the code becomes, the more of it we generate. The more we build things that don't need to exist. The more we ship because we can, because the friction of shipping has dropped below the threshold of "maybe this isn't worth doing."
The constraint that used to be time-to-ship, and thus made you think hard before you shipped, has dissolved. Now the constraint is intention. Do you actually think this matters? Are you shipping it because it solves a real problem or because it was fun to build?
Those are harder questions. They don't have right answers waiting to be discovered. They require you to know something about what you're trying to do and why, and then to hold that intention steady while you build it. They require discipline about the scope of your own attention.
That's the craft now. The thinking before the code. The discipline to notice when you're building something because you can, not because you should.
