if your team is too busy doing their 'normal job' to experiment with AI, you're preparing them to be replaced
When Ralph was published last year, I sat on it. People who have been reading this blog for a while know this. I first came across the idea of loop engineering in early January last year, sat on it for four months, and then started writing a lot, begging people to pay attention.
When Ralph and Loop Engineering went viral earlier this year, almost a year later, it really weighed heavily on me. Life's been pretty good lately, but it wasn't always historically, so I took some time off. I spent six months traveling around the world with no income, and I delivered the talk below almost 17 times in various cities.
Our profession is at a crossroads, and this is the last time I'll say it.
Usage of AI in the profession of software engineeering is no longer optional.
If your employer has banned the use of AI, you should quit and find a company that is already going through an AI transformation.
If you're at a company going through an AI transformation, I understand you'll have mixed feelings about this. You might not like it. But please understand that this is the new normal. Artisanal handwritten code is only possible for retired tech executives and as a hobby at home, but it's no longer a way to make money.
You really have two choices as an employee.
You can push against the grain and refuse to use AI, but that's just self-harm. You trade time and skill for money. The tastes and desires in the employment market have moved on.
From my position, I have a clear view of what's going on.
Every morning, I wake up to either a WhatsApp message or a LinkedIn DM from people who are going somewhere, sending their thanks. Like, don't thank me; thank yourself. You invested in yourself, and because you did, you just got promoted to a vice president role. You did all the work.
Hi Geoffrey. I wanted to drop you a message to just share what a profound impact Ralph’ing had had on me and the company i work for. I first heard of it back in Jan 2026 on social media and thought it was an outrageous concept, the idea of letting this clumsy persona rip through my codebase, so i just ignored it. My biggest frustration with AI has always been it never bought exactly what I wanted to life, it would get the first parts right, then it starts cutting corners, and I end up with a real mess at the end. That was until when I watched sonnet 5 loop through and churn out a product in about 6 hours, so for whatever reason I decided to come to your blog and read about Ralph directly - and I’d totally misundertood it. It took quite a bit of experimenting, however im now at a place where I’m literally delivering paid for dev worth 100K + for 3K in sonnet tokens in brownfield projects. Im re-platforming entire stacks in about 2 weeks that we used to pay contractors half a million for - the game has totally changed, and the inplications are both amazing and terrifying at the same time. Anyway, just wanted to say thank you, because at least for me and the company I work for, you publishing the Ralph paper has forever changed the game, and I hope that one day I’ll get to buy you a drink to say thank you. All the best.
So it's time to address the elephant in the room: people managers.
If your team is too busy doing their new job to experiment with AI, you're preparing them to be replaced. Maybe you're okay with this, but hopefully you're not, because it should weigh heavily on you if you truly care about your team.
Sometime in the next six months, you're going to have to start having some hard conversations about moving people on from your company. You should already be putting your employees on a vitality curve and ranking them. Naturally, competent employees who have been using AI will be ahead of competent engineers who haven't.
If you don't want this to happen to your team's members, start by carving out time for professional development. The most concrete task I can recommend is for software developers to build their own agent, learn the magic tricks behind Claude Code, and explain how it works under the hood.
You see, you're not a senior software engineer in 2026 unless you can rebuild Claude Code (the most basic of agents). Senior software engineers are senior by definition because they can mentor and teach the incoming generation. There's a lot to teach about the craft of software engineering; there's a lot of information and experience about software failures and how software should be designed, colloquially known as taste, that the incoming generation will need to be mentored in, but you won't earn their respect if you have an attitude that AI is evil and should be avoided. If you can't earn the respect of the incoming generation because of your poor attitude, what value do you bring, and why should an employer keep you employed?
interviewing as an employee in 2026
If you're interviewing as an employee in 2026, understand that there is a narrative that it's hard to get a job and it's pretty tough out there. This is true if your expertise is limited to typing code into an IDE, but it is not if you have provable expertise in AI.
If you've got something to show, like a talk, an open-source project, or anything tangibly demonstrable that you've been curious about the transformation in our industry and have been investing in yourself, you should be able to land a job in a couple of days in this market, as it's cooking right now.
Please understand that your edge right now is understanding the possibilities and being curious. The world lacks curious, ambitious people. That's your edge; that's your alpha. Position yourself as that, and be way more ambitious than you are right now. You need to think bigger.
At whichever company you end up at, be an ambassador for AI across your team and organization (and by that I don't mean you should be a maximal AI glazer). I mean, share what works, experiment, and help others through this transition. Generally, just raise the bar for everyone around you and be a good human.
being a hiring manager in 2026
It's been almost two years since my oh-fuck moment. Since then, we've seen the rise of "model-first" companies where most of the software is generated by computers, not humans.
This means that two years have passed, and those who have been curious and invested in themselves have one hell of an edge over someone just getting started today.
One of the most fundamental questions I’ve been pondering on over this last year is “how do you identify skilled operators” aka “how do we even hire software engineers now now that LLMs can smash leetcode?”
I propose the following categories and buckets as a crude ruler on top of your standard software engineering knowledge tests.
- unacceptable
- A poor attitude toward willingness to use AI. I get it. The labs ripped off society's commons, and I don't like it either, but it has happened. You should sniff out these perspectives when interviewing a candidate and filter candidates out through behavioral questions.
- Any form of deceptive behavior. If they're using AI in the interview process to deceive, that's an instant no-hire because deceptive behavior is unacceptable.
- No tangible, demonstrable experience with AI.
- acceptable
- You should be able to pull them over to a whiteboard and ask, at a high level, how a coding agent works under the hood. This is a baseline curiosity test to see whether they've been paying attention and developing their skills over the last couple of years. You want to understand whether they know what a context window is, how tokenization works, and how inference works from a systems-design perspective. If their knowledge depth taps out and all they can do is talk about skill packs, then pass on the candidate. Employers should prioritize producers, and producers know the baseline underlying data structures and system design of how an agent works because that knowledge lets them automate a business function. If they don't have this knowledge, they're just a consumer, so you should likely pass on them until you find someone with producer knowledge.
- ideal
- Tangible and demonstrable experience with AI. They should have a whole bunch of side projects they have built; this may seem unfair, and I agree. Before AI, this was an unfair standard, but these subscriptions have been available to everyone. They're subsidized, and everyone I know who understands what's going on has so many cool things they're dying to show people.
- When you ask the question about what coding harness they use, like, there are only really two acceptable answers. One is that all coding harnesses are fungible, and they use whatever they can to get tokens the cheapest, or their eyes light up and go, I use my own. Do you want to see it? Do you want to nerd about it? Like, here, I'll show you. This is the modern age of the age-old interview question: "Tell me about your home lab"
- If you walk away from the interview and learn something about AI you didn't know, you should hire that person on the spot before someone else does. This is the modern age of the age-old interview question, "What happens when you type google.com into your browser's address box and press enter?" but with an AI twist.
- If they lead people, they should be able to go really, really deep on the processes that failed because of a company's AI adoption. They should also cite examples of what they personally changed within their organization to enable AI adoption. You should background-check these stories to ensure people aren't telling porkies.
There's something else that I need to put forward. Your existing hiring pools may need to be wiped because your current interviewers may lack the expertise to differentiate between these categories. For example, if someone has a poor attitude toward AI and no provable experience with AI, and they're not in the ideal category, remove them from your interviewer pool (and/or company), because you need to put your best foot forward to identify, attract, and hire the best talent out there in 2026.
Remember, the candidate is also interviewing you. They know what's going on, and they want to ensure that choosing you as an employer de-risks their lives.
ps. Watch this podcast with Bill Gates and internalize it
https://www.nytimes.com/2026/09/29/opinion/ezra-klein-podcast-bill-gates.html
Well, Jevons is just a referral to the fact that parts of the economy are subject to demand elasticity. And yes, in the case of software, if you’re, say, three times as fast and there is still some role that only humans can perform, then as you lower the cost, you induce demand. So it’s fair to say that the equilibrium today so far for software is not a loss of employment.
When we invented radial tires that lasted four times as long, for some weird reason, people didn’t drive four times as much. And factories that make tires employ a quarter of as many people. When you replace people in Amazon warehouses with robots, people don’t buy more because of that.
So anybody who’s numeric can say to themselves: What portion of the economy is subject to demand elasticity, and what are those tasks that will still be human-necessary?
As soon as you’ve completed the entire task, it doesn’t matter that there’s demand elasticity. That goes into the token budget. It doesn’t go into the human salary budget.
The cost for some of these things is so much less than the cost of the human labor, and so as you cross reliability thresholds, both with white-collar and humanoid robots, you destroy jobs and you leave no high ground.
Innovation in the past — you have a tractor. Fine. Let’s build Disneyland and employ a lot of people there. You don’t have that in the broad economy. The people who say there will be net additional jobs, I don’t understand what they’re thinking.
pps. some extra data for engineering managers
AI is no longer optional. Every leader we interviewed said, one way or another, that refusing to use AI is now disqualifying; the comparison we heard more than once was refusing to use an IDE. The gains are real. Organisations told us about three times the output per engineer, a six-month project delivered in two, an incident diagnosed in seven minutes that would once have taken four hours. What changes most is what's possible. The default answer to a new idea is no longer "no", it's "let me check", and work that used to die at the bottom of the backlog now gets done.
From https://www.lookahead.com.au/reports/ai-engineering-2026/lookahead-state-of-ai-engineering-2026.pdf
‼️ ppps. socials.
Can you please boost and share this blog post with someone you think needs to hear it? It is both the most and the least we can do. We can't force a horse to drink, but we can tell horses that water exists, and that they need water to be employed in 2026...