I can describe the car I want. It should be safe, comfortable, reliable, and quick enough to overtake without hesitation. It should carry my family and their luggage. It should stop when I press the brake.

My intent is clear. How much of the engineering have I actually specified?

Imagine giving a capable software engineer an AI factory. It can manufacture a car from a written description, revise it in minutes, and run whatever tests the engineer requests. The cost of turning instructions into machinery has almost disappeared.

The engineer asks for strong brakes, good handling, airbags, and a dependable engine. The factory produces a car. It accelerates smoothly, takes a corner, and stops within the requested distance on a dry test track. Every test passes.

Then a brake engineer asks: “Does it still stop after twenty minutes descending a mountain with five passengers and a full boot?”

The software engineer pauses. They thought “strong brakes” covered that.

Stopping once and stopping repeatedly under heat and load are different demands. A person outside automotive engineering might never think to distinguish them. They know the result they want. They lack some of the knowledge needed to describe the conditions under which that result must hold.

That missing knowledge sits inside the requirements, before anyone starts building.

“Safe” contains questions about collisions, visibility, traction, and what happens when a component fails. “Reliable” contains questions about wear, temperature, maintenance, and years of use. Each ordinary word conceals decisions that specialists have learned to recognize.

We encounter a finished car with those decisions already made. Much of its engineering is invisible precisely because it works. Driving it every day gives us familiarity with the experience, while leaving much of the reasoning behind it out of view.

The same problem appears when we ask AI to build software. “Save my work” sounds complete until we ask what should happen if the connection drops halfway through. “Retry the request” sounds sensible until the first attempt succeeded and only the response was lost. Someone has to recognize these possibilities and decide what acceptable behavior looks like.

AI can help uncover them. It can ask questions, propose requirements, and supply knowledge the person making the request does not have. In doing so, it takes on part of the engineering judgment. We still need grounds for trusting the choices it makes.

Returning to the car: if the factory chooses the braking requirements and designs the test track, a passing result tells us that its choices agree with one another. We still have to find out whether they hold on the mountain.

Expertise helps us choose better questions and more revealing tests. It also helps us notice when a reassuring result leaves something important unexamined. An experienced engineer knows where to look for trouble and which assumptions deserve scrutiny.

Even that knowledge has limits. Some requirements become clear only through prototypes, use, and failure. A specification develops as we learn what the thing must endure. Testing the car on actual roads can change our understanding of what we should have asked the factory to build.

This is why I am cautious about the promise that we will only need to describe our intent. Describing intent is already a substantial part of engineering. It requires discovering constraints, making tradeoffs, and recognizing the difference between a convincing demonstration and enough evidence to trust the result.

As building becomes cheaper, we can explore more possibilities and learn faster. The value of knowing what to question, what to test, and when to revise our requirements remains.

Knowing how to drive a car doesn’t mean knowing how to build one. A factory that accepts plain English makes that gap easier to cross. We still have to cross it.