What AI Cannot Ask

A chip can pass every check and still fail.

That sentence may sound strange outside semiconductor design. But after many years in memory architecture, I have seen it happen.

Timing can close. Simulation can pass. A review meeting can end without objection. The report can look clean.

And still, the design can fail — because the wrong question was asked at the beginning, or because a constraint that mattered lived outside the file everyone trusted.

This is why my reflection on AI does not begin with productivity. It begins with a quieter question: when answers become faster, who remains responsible for asking whether the question was right?

The industry is moving toward AI-assisted design.

That is no longer a distant idea. EDA vendors are building AI assistants, optimization engines, and agentic workflows into semiconductor design environments. Some focus on information retrieval and script guidance. Some optimize PPA. Others begin to orchestrate multi-tool workflows across design, verification, and sign-off.

I do not question this direction. I welcome it.

My question is narrower and more uncomfortable: as tools become better at execution, are we also improving the human process that defines the problem?

AI is strongest when the problem is bounded.

Give a tool known inputs, a defined objective, and a measurable optimization target, and it can move with impressive speed.

But architecture often becomes difficult before the objective is clean. The real work is not always solving inside the box. Sometimes it is discovering that the box was drawn around the wrong boundary.

The hardest constraints rarely live in one clean file.

In HBM, chiplet, and heterogeneous integration, a difficult constraint may be distributed across several domains.

A thermal assumption may sit with the package team. A power-integrity margin may depend on TSV distribution. A timing closure result may depend on workload behavior that was not part of the original local model. A mechanical or assembly constraint may appear late enough to make an earlier electrical assumption stale.

In advanced integration, thermal and power integrity are not separate checklist items. They often become cross-domain bottlenecks, where package structure, TSV distribution, workload behavior, timing margin, and physical layout begin to constrain one another.

This is exactly why AI can accelerate many checks, but the architect still has to ask whether the right domains were connected in the first place.

The correct answer to the wrong question.

This is the kind of failure AI will not automatically prevent. In some cases, it may make the failure harder to notice, because the answer looks cleaner than the question deserves.

The model is clean. The physical world is not.

Analog and mixed-signal design taught me a similar lesson.

A model can be clean while the physical world remains untidy. PVT variation, noise coupling, supply droop, layout-dependent parasitics — these are not just parameters. They are reminders that reality always has a texture that the model only approximates.

Judgment is built through friction.

I am not most concerned that AI will replace architects. My deeper concern is quieter.

If AI removes too much of the tedious work too early, young engineers may also lose the slow friction through which judgment is formed.

Traversal was slow. It was sometimes boring. It was often inefficient. But it forced the engineer to see the shape of the problem before receiving the conclusion.

When that path disappears, speed increases. But calibration may not follow.

Three things the architect still owns.

AI will become part of architecture work. I welcome that. But coexistence cannot mean surrendering the parts of the work that carry consequence.