I Don't Want to Become a Prompt Engineer Who Forgot How to Engineer

A few days back, I was randomly watching this Matt Pocock video called Software Fundamentals Matter More Than Ever. It was one of those videos you casually click on thinking you will listen to it in the background while eating or scrolling through something else, but midway through it, I found myself sitting quietly and just thinking.

Not because he said something shocking. Not because he gave some grand prediction about AI taking over software engineering. But because of how casually he spoke about engineering.

He could casually quote books , concepts that still matter, old ideas that continue to shape how software is built, and the sort of intuition that only comes from years of deeply understanding systems. It felt effortless. The kind of effortless that only happens when something has become part of how you think.

And I don’t know why, but while watching it I got this strange uncomfortable feeling. I think I’m slowly becoming worse at engineering.

The weird part is that this thought wasn’t exactly new. I think I already knew this somewhere in the back of my mind. Ever since AI coding tools became genuinely good, something quietly changed in how I approached problems. At first, obviously, it felt incredible. Boilerplate disappeared. Bugs that would normally take an hour suddenly took ten minutes. Edge cases, architectural suggestions , there was always help available. You stop staring at blank files. You stop getting stuck as often.

And honestly, why wouldn’t anyone love that?

Software engineering can be frustrating. If something helps reduce friction, naturally we adopt it.

But I think somewhere along the way, my brain slowly learned a dangerous habit. If AI can get the work done anyway, why struggle? I don’t even mean this dramatically. I think this is just how humans work. We optimize effort. If there is an easier path available, we take it. Earlier, when I got stuck, my brain’s instinct was:

okay, let’s figure this out.

Now, if I am being honest, the instinct has quietly become:

let’s ask AI.

Again, I am not trying to do the whole AI bad thing. That conversation is honestly exhausting at this point. I use AI every day. Most developers probably do. It would feel dishonest to pretend otherwise. The problem is not using AI.

The uncomfortable question I keep coming back to is:

what happens if I slowly stop practicing the hard parts of engineering?

Because sometimes the struggle was the learning. I think this is the part that has been bothering me the most lately. The gap between me and genuinely experienced engineers feels larger than before, even though AI supposedly makes everyone faster. Earlier, I used to think the difference between junior and senior engineers was mostly experience or maybe just “years spent coding.”

Now I don’t think that is true. The difference feels more like intuition. Senior engineers understand systems in a way that feels difficult to explain. They can look at architecture and immediately sense where things may break. They understand trade-offs. They understand failure modes. They have spent enough time messing around with systems that they can often reason through things that would completely overwhelm me.

And increasingly, I feel like many of us junior engineers are accidentally outsourcing the exact skill we are supposed to be building. One thing I genuinely envy about experienced engineers is their ability to just… sit with problems.

They break things. Experiment. Read documentation no one else wants to read. Follow weird rabbit holes. Spend hours understanding why something behaves the way it does. There is this willingness to stay confused for longer.

And I think somewhere along the way I lost a bit of that patience. Because now, the answer often appears before the confusion fully develops. Why stay stuck for three hours if AI can explain it in three minutes? It sounds efficient. But lately I keep wondering if efficiency and learning are quietly becoming enemies.

A few weeks after this whole overthinking spiral started, I came across an Anthropic research paper on AI assistance and coding skill formation.

The paper didn’t say:

AI will make engineers dumb.

It didn’t.

In fact, the findings were much more nuanced than that, which somehow made them scarier.

The paper explored how developers learn while using AI assistance, especially when dealing with unfamiliar technologies or concepts. One of the most interesting observations was that developers often felt more productive and more capable while sometimes understanding less deeply. The issue was not necessarily AI helping — the issue was how people used it.

When AI became a tool for reasoning, explanation, critique, or guidance, learning improved.

But when AI became:

“just give me the answer so I can move on”

something changed.

Understanding weakened. Retention weakened.

The scary part for me was how familiar that sounded. Because I think I already knew this was happening to me.

There are moments now where I revisit code written just a few days ago and feel disconnected from it. Sometimes I vaguely know what it does, but not deeply enough to feel ownership over it. Sometimes I know I shipped something functional without necessarily understanding every trade-off involved.

And maybe this is normal. Maybe software has always involved abstraction. Maybe engineers have always leaned on tools.

But still, something feels different.

Sometimes I genuinely feel productive while also quietly feeling less sharp. That feeling is hard to explain. Like my output increased but my confidence somehow reduced. Like I’m shipping more while understanding less. And that contradiction scares me a little.

Maybe I’m overthinking it.

But I also don’t think I’m alone in feeling this.

One thing I miss, and I genuinely don’t know if others feel this too, is what I can only describe as the developer high.

There used to be this strange joy in struggling through things. You would spend hours debugging something that made absolutely no sense. You would question your intelligence at least ten times, convince yourself that maybe computer science was a mistake, open twenty browser tabs, somehow land on a StackOverflow thread from 2013 where someone with a username like darklord420 had faced the exact same issue, try fifteen things that failed, and then suddenly something clicked.

Not only did the bug disappear, but something changed in your understanding. You understood the system slightly better than before. You walked away with intuition. You remembered that struggle, and weirdly enough, that struggle became memory.

I miss that feeling. I miss the confidence that came from thinking:

okay, I suffered through this and now I actually understand it.

Lately, I wonder if we are unintentionally removing too much of that process from engineering. The answer often arrives before the struggle fully begins. You barely have enough time to be confused before a solution appears in front of you. And yes, I understand the counterargument. Faster shipping matters. Productivity matters. Companies are not paying people to romantically suffer through bugs.

But I also think there was something deeply educational hidden inside that suffering. There was joy in figuring things out slowly. There was joy in staying confused. There was joy in watching your own thinking improve. And I think that feeling has reduced for me.

Not disappeared. Just become quieter.

Around this same time, I stumbled upon an essay by Susam Pal called Twenty-Five Years of Computing. I genuinely think it is one of the most beautiful things I have read about computers in a long time.

Please read it if you have time:

https://susam.net/twenty-five-years-of-computing.html

The essay is not dramatic. It does not scream about the future of AI or the death of software engineering. It simply reflects on a long relationship with computing. The curiosity. The joy of tinkering. The excitement of figuring things out. The weird rabbit holes computers take you down. The patience required to build intuition over years.

And while reading it, I had this thought sitting in the back of my mind:

are we even giving ourselves enough time to build that kind of relationship with computing anymore?

Or are we just becoming extremely good at shipping things?

Because if I am being honest, a lot of engineering lately feels transactional. Ticket in. Ticket out. Faster delivery. Faster iteration. Faster everything. There is very little space to sit with curiosity. Very little space to wander. Very little space to open something just because you want to understand how it works.

And maybe this sounds nostalgic in a weird way, especially coming from someone who has not even been in the industry for decades. But I think younger engineers are entering software during a very strange time. We are learning engineering in the middle of layoffs. In the middle of constant anxiety. In the middle of AI changing expectations every few months.

In the middle of hearing things like:

junior engineers are cooked

or

AI will replace entry-level developers

or

if you are not 10x productive you are falling behind.

Even if none of those statements are fully true, hearing them repeatedly changes something psychologically. You start feeling rushed. Like you constantly need to prove yourself.

Like slowing down to deeply understand something feels irresponsible because everyone else is shipping faster. And I genuinely think this changes how people learn. Because fear optimizes for survival. Not mastery.

You stop asking:

how do I deeply understand this?

And start asking:

how do I keep up?

And honestly, I get it. I feel it too.

Sometimes it feels like software engineering itself is changing in front of us. The thing that once felt like the holy grail of this profession — logic building, problem solving, slowly developing intuition — increasingly feels secondary. Sometimes it feels like coding itself is becoming less valuable than knowing how to ask better questions.

And maybe that is partly true. But I also think if you listen carefully to what experienced engineers keep saying, the message is strangely consistent.

Coding was never the hardest part. Understanding systems was. Architecture was. Tradeoffs were. Knowing why something exists was. Knowing why one decision matters more than another was.

Matt Pocock’s video reminded me of this again:

https://www.youtube.com/watch?v=v4F1gFy-hqg

He talks about software fundamentals mattering more than ever, and honestly, the more I think about it, the more I agree.

Because if AI can increasingly write code, then maybe writing code itself stops being the differentiator.

Maybe the differentiator becomes:

Can you reason through systems? Can you debug weird problems? Can you understand architecture? Can you understand trade-offs? Can you spot nonsense when AI confidently says nonsense? Can you think?

And weirdly enough, this also reminded me of something else I had been reading about recently — the Lindy Effect. The basic idea is simple: things that survive for long periods tend to survive even longer.

Which probably means Java is not disappearing anytime soon. SQL is definitely not disappearing.

Databases. Networking. Distributed systems. Operating systems. System design. Programming fundamentals.

All these things people call “boring” are probably still going to matter when most hype cycles disappear. And honestly, I think this is where my head is at right now.

I don’t want to become someone who got really good at prompting but slowly forgot how to engineer. I don’t want my brain to stop trying. I don’t want the first instinct to always become:

let AI figure it out.

I still want to understand things. Maybe slower. Maybe imperfectly. But deeply.

And so over the next few months — and realistically, probably years — I want to intentionally go back to fundamentals.

Not in some dramatic anti-AI way. I am not deleting tools. I am not suddenly becoming someone who writes everything from scratch to prove a point. That sounds exhausting.

But I do want to rebuild the muscle of thinking deeply. I want to properly learn distributed systems, databases, networking, system design, programming language internals, architectures, and the kinds of things that felt “too theoretical” earlier.

I want to read books again. Which is funny because I think I genuinely lost the skill of reading technical books somewhere along the way.

And interestingly, I recently came across a post on using AI to actually learn technical books better instead of replacing the learning process altogether. The workflow was surprisingly simple:

You use NotebookLM to create audio overviews before reading.

Then read deeply.

Then use AI for active recall.

Question yourself.

Build memory.

Actually understand.

And for the first time in a while, that felt hopeful.

Because maybe the answer is not:

stop using AI.

Maybe the answer is:

learn how to use AI without outsourcing your thinking.

So that is what I want to try. I will probably get things wrong. I will probably have terrible takes. I will probably change opinions halfway through. That is okay.

I think learning publicly should include confusion too. So I’m planning to document all of this here — the books, the systems, the confusion, the rabbit holes, the workflows, the things that fail, the moments where something suddenly clicks.

Through blogs. LinkedIn. Maybe Twitter/X. Maybe Instagram too if I can somehow make distributed systems aesthetic .

Mostly because I have a feeling I’m not the only junior engineer feeling this strange anxiety right now. That feeling of becoming faster while quietly wondering:

but am I actually becoming better?

And maybe we figure this out together. Because if software engineering is still ultimately about understanding systems deeply, then maybe we should try becoming the people who are actually good at that.

Not just the ones good at prompting.

Things worth reading/watching if this resonated

Matt Pocock — Software Fundamentals Matter More Than Ever
https://www.youtube.com/watch?v=v4F1gFy-hqg

Anthropic — AI Assistance and Coding Skill Formation
https://www.anthropic.com/research/AI-assistance-coding-skills

Susam Pal — Twenty-Five Years of Computing
https://susam.net/twenty-five-years-of-computing.html

And if you’re trying to not become a prompt engineer who forgot how to engineer too, maybe come learn with me.