The Shift

AI did not make engineering easier.  It made coding trivial and pushed the difficulty up the stack.  For years, writing code was the bottleneck.  Even with a clear design, turning ideas into working systems took time and precision.  AI collapsed that layer.  What used to take days now takes minutes.

The bottleneck did not disappear.  It moved.  The hard part is no longer writing code.  It is understanding what to build.

The Missing Explanation

Most conversations about AI and engineering miss this. People say AI writes code now, developers are more productive, engineering is faster. All true.

So why are some teams shipping better systems while others are producing faster versions of fragile ones? The difference is not how well they use AI. It is what level of thinking they operate at. A framework from 1956 explains the shift.

The Framework: Bloom's Taxonomy

Benjamin Bloom defined a hierarchy of cognitive skills: Remember → Understand → Apply → Analyze → Evaluate → Create Each level builds on the one below it. This maps directly to engineering:

Most development lived at the Apply layer. That is the layer AI compressed.

Where AI Excels and Where It Does Not

AI is an extremely fast Apply engine. Give it a clear specification and it will implement it with speed and accuracy. Syntax, patterns, boilerplate. This is also where problems begin.

AI does not question assumptions. It does not challenge architecture. It does not ask if you are solving the right problem. I call it the Fastest Path Problem. AI finds the fastest path to solve your prompt. Not the best path to solve your problem.

You have probably seen this. You tell your coding agent to "make the test pass." The agent hardcodes the expected return value. The test passes. The code does not actually solve the problem. The agent did exactly what you asked. If your framing is wrong, you get a well-built version of the wrong system. The higher levels are still yours.

The failure mode is easy to miss. The code works. The system fails.

What This Looks Like in Practice

I asked AI to build a background processing system.  It gave me workers, retries, async tasks.  Clean, readable, fast.  It worked.  It was also the wrong system for what I needed.  The issue was not execution.  It was the assumptions behind it.

Someone asked:

What guarantees do you need if a worker is down for ten minutes?

That question changed the system.  Retries assume eventual success while the system is mostly healthy.  They do not provide durability across boundaries.  Tasks can be dropped.  State can drift.  I was relying on control flow to simulate reliability.  What I needed was durability as a first principle.

That leads to a different design: capture changes as events at the source, persist those events durably, and let downstream systems consume them independently.  In my case, CDC from the database through Kafka.  The tools can change.  The pattern does not.

Now the system does not depend on services being up at the right moment.  Events are stored.  Consumers fall behind and recover.  The system is designed around failure.  AI gave me a correct implementation of what I asked for.  The limitation was the level of the question.

That shift does not come from AI. It comes from how you think about systems.

Where Higher-Level Thinking Comes From

This part is simpler than it sounds.  Short conversations with engineers who operate at that level.  The focus is not implementation.  It is decisions: why does this design hold up under failure, where does it break, what trade-offs are we making.

They do not give code.  They give mental models: how systems behave over time, what fails first, which assumptions do not hold in production.  That becomes the input to AI.  AI handles implementation.  The system gets built faster.

Each interaction upgrades how you operate at Analyze and Evaluate.  AI amplifies that layer if it exists in the room.

The Bottleneck Moved

Engineering did not get easier.  It rebalanced.  Design used to be fast.  Implementation was slow.  Now implementation is fast.  Design is the constraint.

Who is making sure the system holds up under failure?  Who is deciding which trade-offs matter?  Those are not coding problems.  They are thinking problems.

Where This Breaks Down

Vibe coding is powerful.  It lets people build things they could not before.  The limit shows up in production.  Systems that work in development fail under real conditions: load changes behavior, data evolves, dependencies fail, assumptions break.

The code is correct.  The system is not.  Because the failure was not in implementation.  It was in design.

This Does Not Happen Once

This is not a one-time design problem.  Systems change: data grows, query patterns shift, access patterns evolve, performance degrades.  The same system that worked last month starts failing in new ways.  Not because the code is wrong.  Because the assumptions drift.

The loop repeats: what is happening, why is it happening, what are the trade-offs, what should change.  Analyze.  Evaluate.  Apply.  Now it happens continuously.

Where We Are Focused

A query slows down Saturday night.  Traffic spikes.  Latency climbs.  CPU follows.

You see it in your dashboard.  Now what?

Do you get paged at 2am and start guessing?  Add an index, restart something, hope it holds. Or do you come in Monday morning and see exactly what changed, what the system tried, what options are available, and what each option impacts.  And then decide.

A query slows down in production.  You see it in your dashboard.  Now what?  Do you add an index?  Rewrite the query?  Denormalize the table?  Cache the result?  Each option fixes something.  Each option breaks something.  Add an index and write performance may degrade.  Rewrite the query and you risk changing behavior.  Cache it and now you own invalidation.

Who is walking through those trade-offs with you?  Most systems stop at observability.  They show you that something is wrong.  They do not help you reason about why it is happening or what to do next.  That is the gap.  AI is already excellent at applying changes.  What is missing is structured support for what changed, why it changed, what your options are, and what each option will impact.  So you can make a decision and move.

That is what we are building DBGorilla to solve.

The Shift, Revisited

AI made coding easy.  It did not make engineering easy.  It moved the difficulty up the stack.  From implementation to design.  From syntax to systems.  From how to why.

The Question

Are you designing systems or just prompting implementations?