LLD and HLD in the Age of AI: Judgment Over Recall

Artificial intelligence is not making Low-Level Design (LLD) or High-Level Design (HLD) irrelevant. It is making the ability to reproduce designs from memory a weaker signal, while judgment, code reading, and ownership become more valuable.

For years, engineering interviews have asked candidates to draw familiar architectures, explain design patterns, and solve standard problems on a whiteboard. But an LLM can now generate an architecture, implement a pattern, write tests, and explain the resulting code.

The more useful question is no longer simply: Can you build this?

It is: Should this be built at all?

When coding becomes cheap

AI is lowering the cost of producing software.

When a feature required three weeks of engineering work, teams naturally discussed whether it was worth building. When a first version can be generated in a day, the temptation becomes: “Why not build it?”

But software can be cheap to create and expensive to own.

It still needs to be understood, monitored, secured, upgraded, and debugged. Even if agents eventually perform much of that work, someone must define correct behaviour and take responsibility when something goes wrong.

Every new service, abstraction, and dependency becomes another thing the organisation must carry. More code does not necessarily mean a better product. Sometimes it simply means more liability.

Judgment becomes the scarce skill

When implementation becomes easier, scoping becomes more important.

The right solution might be a new service. It might also be a database change, a small script, a process improvement, or no change at all. This is why the problem must remain more important than the tool.

Engineers need to ask:

• What problem are we actually solving?
• Who experiences it?
• What happens if we do nothing?
• What is the simplest acceptable solution?
• Will this solution still make sense two years from now?

These are not primarily coding questions. They are judgment questions.

AI can produce a sophisticated solution to a simple problem. It can introduce abstractions before they are needed and optimise for extensibility that may never matter. The output may look impressive while making the system harder to understand.

A capable engineer must be able to look at that output and say, “This is technically valid, but it is wrong for this problem.”

Design interviews should test recognition, not recall

LLD, HLD, SOLID, and design patterns still matter. They exist because software must remain understandable and maintainable as it grows.

What matters less is remembering their names under pressure.

I do not particularly care whether an engineer can define the Strategy pattern from memory. I care whether they can recognise duplicated behaviour, reason towards a better abstraction, investigate the available approaches, and understand the trade-offs.

The useful process is:

Recognise the problem, find the relevant concept, understand it, and decide whether it belongs in the solution.

That final decision is important. Knowing that a pattern exists does not mean it should be used. Design patterns are thinking tools, not trophies.

Instead of asking candidates to reproduce textbook architectures, interviews could present unfamiliar production situations:

• Customers are receiving stale data.
• A database is suddenly overloaded.
• Payments are occasionally duplicated.
• A deployment succeeds, but the application becomes slower.

What would the candidate investigate first? What assumptions are they making? What information do they need? How would they verify that a change fixed the problem?

That conversation reveals far more than a memorised diagram.

Code reading matters more

As AI writes more code, engineers will spend more time understanding and evaluating code.

Production systems contain history, workarounds, undocumented business rules, and decisions made by people who may no longer be available. An ugly-looking block of code may be protecting the system from a problem nobody remembers.

A good engineer must understand that context before changing it. This is part of the intuition engineers develop by operating real systems, not by memorising ideal architectures.

AI can generate ten implementations when only one is needed. It can solve the wrong problem efficiently. Someone still needs to recognise unnecessary complexity and say:

“This is too complicated.”

“A script is enough.”

“We are solving the wrong problem.”

Or, most importantly: “We do not need to build this.”

Production changes your thinking

Production experience develops a kind of judgment that is difficult to test through theoretical questions.

It teaches you that software is not finished when a pull request is merged. A harmless-looking query can overload a database. A one-line change can cause an outage. A strange workaround may exist because someone previously encountered the exact failure you are about to recreate.

It also teaches you that not every problem deserves a permanent system. Sometimes a SQL query, shell command, or short script is the responsible solution.

AI makes permanent solutions to temporary problems easier to create. Engineers must become better at resisting that temptation.

The engineer’s role is changing

AI does not eliminate the need for LLD or HLD. It changes what expertise looks like.

The engineer increasingly becomes the person who:

• decides what should be built,
• gives AI the right context and constraints,
• evaluates what it produces,
• understands the consequences,
• and owns the outcome.

This requires architecture knowledge, but it also requires product thinking, operational experience, curiosity, and the confidence to challenge an apparently correct solution.

The strongest engineer may no longer be the person who writes the most code. It may be the person who prevents the most unnecessary code from being written.

LLD and HLD are not becoming things of the past. Memorising and reproducing them might be.

The scarce skill is moving from implementation to judgment, from producing code to understanding consequences, and from solving every problem to knowing which problems are worth solving.