Why Experience Still Beats Knowledge in AI-Assisted Engineering

Six weeks ago, my brother went to an Anthropic event in London. Then he called me: “I built a working prototype in two days. This is crazy.”

I asked him to push his code to github and to share it. He asked: “What do you mean? How do I do that?

The first commit made me smile when I saw he committed a failed curl command.

And nonetheless, he is right, “this is crazy”. He had a working prototype without even knowing what a terminal was.
We are going through a fascinating revolution.

The economics behind that revolution are shifting fast.

The cost of prototyping has been massively reduced. Some already think that code is going to become disposable as the cost of writing keeps getting cheaper. We, engineers, often want to rebuild everything from scratch. Whether in a new programming language (eg Rust/Golang) or with new patterns and libraries. This is definitely easier today than a decade ago and the cost of doing so went down.

However, while AI gives you knowledge, it cannot give you judgment. Judgment is what makes you pause before adding a cache layer because you’ve felt what a cache invalidation bug looks like at 2am. Judgment is recognizing you’re over-engineering before the codebase makes it obvious.
This is the gap. Non-engineers using AI don’t know the questions they aren’t asking. And AI — however capable — can only answer what it’s asked.

Think about what you actually get when you hire a junior engineer. You spend months transferring context - the unwritten rules, the past mistakes, the reasons. It’s painful. But that investment compounds. They grow, develop taste, become senior, eventually lead.

With LLM, at least today, you have to transfer the context over and over. They don’t learn on your specific use case, it does not grow. It does not accumulate judgment from your codebase, your incidents, your specific constraints.

However the model, it is not capable of becoming your senior engineer. The trap is not incompetence - it’s misplaced trust. You would not hand over unsupervised access to your production database to a junior engineer after a few weeks of never growing. And interesting engouh, we are seeing people spinning up armies of agents with full access to their system.

And while product stakeholders can now share their vision and help polish the product without competing for engineering resources; let’s not confuse “prototype” with “production-ready” software.

Today my brother’s prototype works and he wanted to go live using the family business data warehouse. That is where I had to draw a line to make sure we would not leak the business data (sales, customers, products, etc.).

If you’re a software engineer: your value isn’t writing code faster. It’s knowing which questions to ask before the code is written. It’s providing clarity. It’s to understanding the tradeoffs.
If you’re a product stakeholder: prototype freely. But find an engineer before you ship.