AI can write the code now. For a lot of developers, that should be unsettling.
For twenty years, the thing that made you valuable was that you could build the thing. You knew the language, you knew the framework, you could turn a problem into working software faster and cleaner than the person next to you. Coding experience was the moat. It was what you got hired for and what you got paid for.
That moat is draining. Not gone, but draining.
I want to be careful here, because it is easy to take this too far. You still need real software engineering experience, and in some ways you need more of it than before. Someone has to decide whether the code the AI just wrote is any good. Someone has to catch the security hole, the performance trap, the design decision that looks fine today and hurts in six months. A developer who leans on AI without the fundamentals underneath them gets exposed fast, usually at the worst possible time. Engineering skill is not going anywhere. It is table stakes.
But table stakes is the point. When everyone at the table can produce working code, producing working code stops being the thing that separates people.
What the AI can't do
So what is left? Ask what the AI can't do. It can't tell you what is worth building. It doesn't know your customer, your business, or the weird edge case that only shows up for your biggest account. It doesn't know the regulation that makes the obvious solution illegal, or the reason the last team tried this exact thing and it blew up. That knowledge doesn't live in the codebase or the ticket. It lives in the domain.
That is the line now. An average developer takes the ticket and builds exactly what it says, correctly. A great developer knows enough about the business to notice the ticket is wrong, and says so before writing a line.
The gap between those two used to be small, because building the thing was slow enough that someone usually caught a bad direction before it shipped. AI erased that buffer. Now the average developer can build the wrong thing faster and more confidently than ever, and you find out a sprint too late. The friction that used to protect you is gone.
Why domain knowledge is so hard to teach
Here is the problem. Domain knowledge is the hardest thing to teach.
You can teach someone a new language in a few weeks. You cannot hand someone a spec and expect them to understand your business. It is tacit. It lives in conversations, in customer complaints, in the history of decisions nobody bothered to write down. Most companies do not even try to teach it. They hand a new hire, or an offshore team, a ticket and a repo and then wonder why the work keeps missing the point.
The developers who pick it up fast all have one thing in common. They got close to the "why." Not the ticket, the reason behind the ticket.
If you lead a team, that is your lever. Put developers near the customer and the problem, not just the task. Make understanding the business part of the job instead of a bonus nobody has time for. When someone restates a requirement in their own words before they build, reward it. When someone says "give me a day to understand this before I commit," that is not slow, that is the exact instinct you want. This is the whole idea behind Product Driven: developers who think like product owners, who care whether the customer got what they needed and not just whether the code shipped.
AI is also the best way to teach it
Here is the turn. The same technology that commoditized coding is the best domain-learning tool a developer has ever had.
A new engineer used to spend weeks piecing together how an unfamiliar industry works. Now they can ask, and get the terminology, the major players, the common edge cases, and the regulations in an afternoon. At Full Scale we lean into this hard. We train our developers to use AI not just to write code but to ramp up on a client's business quickly, because getting to real understanding in days instead of months is worth more than any autocomplete.
There is a trap, though, and it is a serious one. AI will confidently explain a domain it only half understands. It will hand you a plausible answer about your industry that is subtly, expensively wrong. A developer with real domain grounding catches that. A developer using AI as their domain expert does not, and now you have two layers of confident wrongness stacked on each other.
So AI accelerates domain learning only for the developer who stays the judge. It does not replace the judgment. It gets you to the point of judgment faster, and then the human still has to be right.
The takeaway
None of this means experience stopped mattering. It means experience alone stopped being enough.
The developers who pull ahead from here are the ones who pair real engineering skill with a real understanding of the business they are building for. AI raised the value of that second half. If you run a team, the highest-leverage move you can make right now is not buying more AI tools. It is teaching your developers your business. That is the part the machine can't do for you, and it is what turns an average developer into a great one.