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 where people are going, sending their thanks. Like, don't thank me; thank yourself. You invest in yourself, and because you did, you just got promoted to a vice president role.
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.
For somewhere in the next six months, you're going to have to start having some hard conversations. You'll have to start putting your employees on a vitality curve and ranking them. And naturally, competent employees who have been using AI will be ahead of competent engineers who haven't.

At this stage, some software developers are not going to make it, and that's okay. You can't lead a horse to water and make them drink. It's their choice. You need to put yourself as a manager first and role model the new performance baseline.
If you don't want this to happen to your team or members of your team, 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 be able to explain how it works under the hood.

start here
in video form
You see, you're not a senior software engineer in 2026 unless you can rebuild Claude code. 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 terrible. 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?
I've never seen this before in my career: 28-30 year olds who refuse to use AI coding tools.
— Ivan Burazin (@ivanburazin) March 5, 2026
You show them what they can do augmented (not replaced) with AI and you see in their eyes that they have no damn clue of what's happening.
You can't work with these people anymore. Time…
You know how ants leave the colony before they die?
— Theo - t3.gg (@theo) October 8, 2026
Developers make posts like this before AI makes them unemployed. https://t.co/7JhSdn8WaQ
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 true 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, something you've been curious about 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 is lacking curious and 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.
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 the majority of software authored in that company 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 skills 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 towards AI. I get it. The labs ripped off society's commons, and I don't like it, but it's happened. You should sniff out these perspectives when interviewing a candidate and filter them out as part of your behavioral questioning.
- 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. What you're doing here is doing a baseline curiosity test. 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.
- ideal
- Tangible and demonstrable experience with AI. They should have a whole bunch of side projects that they have built. 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.
- If you walk away from the interview and learn something about AI you didn't know, you should hire that person 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 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 that identify candidates 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, because you need to put your best foot forward to identify, attract, and hire the best talent out there in 2026.
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. socials
🗞️ if your team is too busy doing their 'normal job' to experiment with AI, you're preparing them to be replacedhttps://t.co/k27fch9xVa
— geoff (@GeoffreyHuntley) October 9, 2026
In this post, I guess this's the last time I'll say it. AI use is no longer optional if you wish to be employed. What follows is advice for… pic.twitter.com/3MIUXut2Nm



