Growing as an engineer in a world of AI
Growing as an engineer in a world of AI
Published Jun 13, 2026<br>•<br>24 min read
Table of Contents
Context
My first years
What about now?
Learning of bygone eras
AI comes into the picture
Ok, and so what?
Ok, I’m a graduate, how do I actually grow in this environment?
Use AI as a learning accelerator, not as a cheat
Keep your hands on the keyboard
Read the books that built the discipline
Learn Unix properly
Write documentation as a learning tool
Call out explicitly what you wrote vs what AI wrote
Have conversations that matter
Lean into what AI can’t do
This isn’t just on graduates
How does this play out in future?
Appendix A: What this means for hiring and teams
Context
There’s a lot of buzz that AI means companies only want seniors now. That there’s no room<br>left for early career engineers. I don’t think that’s true. The thing actually worth<br>worrying about isn’t whether you’ll get hired, it’s whether you keep learning in a world of<br>AI, now that it removes the friction where that learning used to happen. And that,<br>thankfully, is a choice you get to make.
Early career engineers will have to adapt but that has always been the case. It’s normal.<br>Is this a bigger jump? Perhaps. Should they, and their more seasoned colleagues, be paying<br>close attention? Yes.
A couple of posts ago, I said I<br>wanted to write about how graduate engineers grow when AI writes most of the code. I’m<br>writing this post as someone who has hired and developed graduate engineers, as someone<br>who learned to code, maintain servers, networks, and storage systems, the hard/old way,<br>and currently as a heavy AI user.
I don’t have all the answers here but I want to at least try to offer my perspective.
My first years
My first few years were rough. Stack Overflow wasn’t even a thing. There were no mentors<br>in the weeds with me, no daily standup, no weekly 1:1, no pile of books beyond the ones I<br>bought with my own money (I love books, so that part was a treat). Learning meant<br>apropos, man, and reading whatever codebases I could find online. I still remember<br>(fondly, I think?) the beauty and the horror of qmail’s. It was slow going. People might<br>say it gave me grit and perseverance. Nah, I had plenty of that already. Mostly I just<br>feel like I lost a lot of time for not much in return.
What about now?
I’ve spent the past 10 years hiring, onboarding, mentoring, coaching, annoying, sometimes<br>pissing off, energising, and celebrating a bunch of engineers. The ones who did really<br>well early and grew like crazy didn’t get there because they had Stack Overflow handy, or<br>could spin up a cloud server faster than I could set up Visual Studio with Emacs<br>keybindings. They had a few traits in common: exceptional communication, perseverance in<br>spades, lots of curiosity, and extreme ownership. And, last but not least, they could<br>learn fast . Really fast .
Learning of bygone eras
The model of becoming an engineer that I was brought up with, was built on friction. You’d<br>read documentation that didn’t quite make sense, try something, watch it break, read the<br>error message, try again. You’d spend an afternoon understanding why your database query<br>was slow before someone on your team would laugh and tell you why. And later on, I saw<br>many who got it by reading someone on Stack Overflow that explained the missing index. It<br>was annoying you had to put up with so much failure and reading, but it was also what made<br>you learn.
I don’t think all that friction was really necessary, but the discovery, and also the thrill of<br>the hunt for the answer, was what made it all worth it (once something clicked). I read<br>printed man pages, printed manuals of HP-UX, printed code for hundreds of *nix tools. I<br>read some of those multiple times.
I’m no expert in learning but I think curiosity, mixed with repetition, is where a<br>surprising amount of skill formation actually happens.
It seems that all of that kinda has a name:<br>desirable difficulties. I’m sure<br>I’m murdering the research but in effect these are conditions that make learning feel<br>slower and harder in the moment but stick far better over time. Spacing things<br>out. Mixing problems up. And if you add the<br>generation effect (you remember<br>something dramatically better when you produce the answer yourself than when you read a<br>perfectly good one handed to you) you end up with a nice recipe for learning.
If you read up on the above concepts, I think you’ll end up with the same realisation I<br>had: a lot of the time, the struggle is the actual learning. And the struggle, funnily<br>enough, is exactly the part AI is so very good at taking away from you.
AI comes into the picture
AI eliminates most of the friction or struggle I mentioned above. Ask Claude to fix a slow<br>query and you get the answer in seconds, with an explanation if you want one.
This is where early career engineers might go wrong. They ask for the solution and they<br>think the solution was the outcome they...