DEV Community

Cover image for Machines Can Only Build What Someone Already Imagined
Ekong Ikpe
Ekong Ikpe

Posted on

Machines Can Only Build What Someone Already Imagined

When a prompt describing what you need is submitted, an AI fills in forty lines of clean, working code. You run it. It works. You ship it.

At that point, reality is obvious: writing correct code is no longer the hard part.

While preparing this article, my assistant wrote "syntax is dead" πŸ˜‚ But let's be clear β€” syntax isn't dead. You still need to understand what the code does, debug it when it breaks, and know when the AI is confidently wrong to a reasonable extent.

So what's changed that separates a junior developer from a senior one?


The Real Difference Has Always Been There

Junior developers most often learn syntax, patterns, and rules.

  • They focus on how to make the code work.
  • Essential work β€” and the part AI keeps getting better at.

Mid-level developers learn system boundaries and best practices.

  • They think about scaling, not just "okay, it works."
  • They focus on clean, modular, maintainable code.
  • AI is already decent at this too.

Senior developers learn failure modes, trade-offs, and the edges of what we currently understand.

  • They focus on what shouldn't be built.
  • Where the system will break.
  • How to use proven patterns instead of general abstraction.
  • What nobody has thought of yet β€” not just scaling.

A senior is a problem solver, not just a builder.

That last part is still human territory.


The Machine Has a Ceiling

AI models are sophisticated pattern matchers. They've read essentially all the public code ever written, and they recombine those patterns in ways that look like magic.

But they can only work with what has already been imagined, written, and modeled. They're also subject to steering, depending heavily on the captain's cognitive exposure. πŸ€”

What you cannot conceive, you cannot touch.

Sometimes we call the unknown "supernatural" β€” not because it's magic, but because it sits outside our current model of reality. Once we understand something well enough to explain it, build it, and predict how it behaves, we stop calling it magic and start calling it engineering.

Imagination comes before all of that.

  • A machine operates on what has been modeled.
  • A human goes further by imagining what hasn't been modeled yet.

This is a major, uncomfortable advantage humans still hold β€” for now.


What This Looks Like in Practice

The senior developer isn't the one who writes the most elegant function. The AI will win that contest more often than not.

The senior developer is the one who looks at a seemingly perfectly working program and asks:

"This works great on the happy path. But what happens when the default becomes impractical? What does this mean in the real world when an unforeseen circumstance appears? Does the AI understand that not all failures are technical? That a 'security breach' might actually be an internal process leak, not an exploitable code bug? What if this 'simple' feature suddenly needs to handle a thousand times more traffic?"

Sure, you can prompt an AI to list race conditions, retry storms, and cascading failures. But it takes a human to know which of those failures your specific business will actually hit, based on tribal knowledge and messy real-world constraints.

Those questions aren't syntax. They come from holding a mental model of how the whole system behaves when reality stops matching the happy path.

You can't Google the answer because it may not have been documented yet β€” the internet has no knowledge of the solution yet.

AI can generate the code that works. It can't generate the paranoia that comes from watching systems fail in ways nobody predicted.


The Real Skill Never Changed

  • Knowing what you don't know β€” spotting the hidden assumptions in a requirement before they bite you.
  • Drawing boundaries β€” knowing where your system ends and the messy real world begins.
  • Imagining failure β€” race conditions, retry storms, cascading failures. Not syntax errors β€” thinking errors.
  • Choosing trade-offs β€” every decision has a downside; seniors pick the failure mode the team can actually survive.
  • Separating want from need β€” knowing the difference between what was asked for and what will actually solve the problem.

You don't learn to be a senior as much as you live the life of a senior.


The Interview Question That Matters

Stop asking seniors to reverse a linked list. The AI does that faster, with fewer bugs.

Ask this instead:

"What's the difference between knowledge and intelligence?
If two people are asked to navigate a city, one has memorized the map, and the other has actually driven the streets. When a sudden road closure happens, who gets you to the destination? The map tells you what should be there. Experience tells you where the potholes are."
Is provenance the same model for writing and for source code? If not, what's actually being verified in each case?

That's the senior's job. Knowing what or who merits trust. Not writing code β€” deciding what code should exist, where it should live, how it fails when reality refuses to cooperate, and when not to use an agent.


The Bottom Line

Syntax is still the language we build with. Fluency still matters. Reading, challenging, and fixing generated code still matters.

But syntax is not the ceiling of your value. It's the floor.

The senior developer of this era keeps asking the questions that sit outside the current model β€” the ones the machine hasn't seen, the ones that require imagining a failure that hasn't happened yet.

We are optimizing machines to win at chess, while the real world is playing poker with incomplete information.

The leverage has moved up the stack. Whether we move up with it β€” that's the "yet."

Top comments (6)

Collapse
 
leob profile image
leob • Edited

"A senior is a problem solver, not just a builder. That last part is still human territory."

I've made the word "still" bold - I think AI will soon be able to do this too, it's even capable of it right now already - I've seen plenty of examples where AI tools were able to identify obscure and complex edge cases (race conditions, security issues, performance/scalability issues) which would even elude most senior engineers.

Also, the distinction between the junior, mid level and senior skills/capabilities is more fluid and gradual than it might seem, it's somewhat arbitrary ...

I think the role of the human dev is going to end up being 'high level orchestrator' and 'final quality control' - and, being an intermediate between the 'business side' (domain knowledge) and the 'tech side' - as long as business users aren't yet completely vibe-coding their systems, that will remain to be valuable.

No, I forgot one crucial point: in the end there's still gonna be a human who's being held responsible, because you can't hold "AI" responsible - the buck stops with the human ... whether that's an enviable position to be in is another question ;-)

I think that a developer (whether you call him/her junior, senior, or mid level, I don't really care that much) who wants to be around in a few years from now should posses these 'core skills':

  • understand the fundamentals ('architecture', web fundamentals, databases, security, performance)

  • be proficient with a variety of AI tools, and be able to 'orchestrate' them to achieve stated outcomes

  • and be able to communicate with 'the business' and effectively assume final responsibility for systems quality/availability (coz AI, by definition, cannot do that)

Collapse
 
edmundsparrow profile image
Ekong Ikpe

​Happy you said "most seniors," That "high-level orchestrator" role you mentioned is the new senior. The leverage just shifted from writing the logic to deciding which realities matter.

LLMs catch obscure race conditions or theoretical security bugs because those failure modes exist in historical training data, the AI acts like a senior engineer who has read every post-mortem ever written.
​Where I think the boundary remains is contextual relevance vs. pattern matching.

​The AI spots the technical potholes; the senior knows which potholes are worth swerving around based on unwritten business context that isn't in any prompt or codebase.

Collapse
 
leob profile image
leob

Yeah it's ultimately down to doing the things AI can't really do, only humans can - primarily, deciding what makes sense and what doesn't, and taking the final responsibility (because AI can't be held responsible, only humans can) ...

Thread Thread
 
edmundsparrow profile image
Ekong Ikpe • Edited

That role is a lot of responsibility πŸ™Œ
Knowing what Machines don't know.

Thread Thread
 
leob profile image
leob

We'll still need people, unless we let 'the bots' and AI take over control completely - heaven forbid!

Thread Thread
 
edmundsparrow profile image
Ekong Ikpe

🀣
The intelligence is artificial, humans own "Intelligence" 🀷. Wanna stress test? πŸ€“