Here’s what the current moment in software development actually means.
For the past fifty years, being a good developer meant knowing how to build things. Syntax. Data structures. Design patterns. The craft of translating a requirement into working code. That skill was genuinely rare and valuable, and the industry compensated accordingly.
AI changes the economics of that skill. Not because it eliminates it — the AI still gets things wrong, still needs direction, still requires someone who understands what correct looks like. But because construction is no longer the scarce resource.
What’s scarce now is something harder to define and harder to train for.
Taste
Architects don’t swing hammers. That’s not a status statement — it’s a functional one. The architect’s value is in knowing what to build: which constraints matter, which trade-offs are acceptable, what the thing should feel like to live in. The construction happens because of their judgment, not instead of it.
Software developers are increasingly in that position. AI handles the construction. The developer’s job is the architectural judgment: knowing what good software feels like, knowing what to build and what not to build, knowing when a solution is clean versus when it just appears to work.
That judgment is taste. And taste is not something you acquire by learning another framework.
Taste comes from using software. From noticing when something is annoying to debug at 2am. From caring about the experience of the next person who touches your code. From reading code written by people who had more or less of it. From caring, generally, about quality as a thing-in-itself rather than a requirement to satisfy.
The Shift That’s Happening
The developers who struggled before AI tended to struggle with construction: slow typing, fuzzy syntax recall, difficulty translating abstractions into code. AI solves most of that. It’s a genuine democratization of the construction layer.
But the developers who thrive aren’t the ones who struggled before. They’re the ones who were already past the construction problem — who were spending their cognitive energy on what to build, not how to spell it. AI gives them back hours they were spending on implementation, and they spend those hours on judgment.
The gap between them and developers without taste is widening, not narrowing.
What Junior Developers Should Actually Do
This is where I think a lot of advice goes wrong. The instinct is to tell junior developers to use AI to go faster — generate more code, ship more features, close more tickets. That’s the wrong frame.
The more valuable use of AI as a junior developer is to learn faster. Use it to understand why a piece of code is structured the way it is. Use it to explore trade-offs — “what would happen if I used a queue here instead of a direct call?” Use it to read code that would have taken you an hour to parse in thirty seconds, and then spend that hour understanding it.
Taste accumulates through deliberate attention to quality. AI can accelerate that accumulation if you’re paying attention to the right things.
If you’re using AI to avoid thinking, you’re borrowing against your future competence.
What This Means If You’re Hiring
Look for people who have opinions about software. Not just opinions about tools — opinions about what makes a system elegant versus fragile, what makes code a pleasure to extend versus a trap to fall into.
Ask: tell me about code you’ve read that impressed you. Ask: tell me about a technical decision you made and then regretted. Ask: what’s something in software that most people accept that you think is actually wrong?
These questions surface taste. They’re harder to answer with a course completion certificate.
AI writes code. It writes a lot of it, fast. But the judgment about what to write — the architecture, the trade-offs, the decision to not build something — that’s still a human job.
Creative architects write software. That’s the role worth developing.