Easter weekend has come and gone in a blitz, and seemingly, so has this challenge. As a reminder for those coming here for the first time:

This was, no doubt, an interesting self-imposed challenge, and I was happy to see people from different corners of the internet stumble upon it.

It was also a challenge, that I’ve failed. I’ve debated whether or not to completely scrub this from my blog, but ultimately decided that I would not contribute to the File Drawer problem within research, and publish my findings regardless of their result.

In the days leading up to Easter, I really dreaded writing this blog post, because I felt the guilt of facing all the people that followed this journey and shamefully admitting that I couldn’t keep up the contract.

Vainly, I thought of many excuses that would still make me look good and not lose face, but I’ll be honest: I failed this challenge, I took the easy happy path, and using AI feels good.

… or does it?

Gentlemen, a short look back to the past…

Setting the ground rules for this challenge, I mentioned that I will take copious surveys around a couple of metrics to judge how this challenge is impacting my work output and satisfaction. These metrics were Satisfaction with Software Engineering as a craft, Fatigue (cognitive load), Number of PRs merged, and Confidence in released features.

This is by no means an empirical result, because it relies of my sparse self-reporting, but there are some interesting findings, even within this sparse data:

The challenge started strong, and I was suprised at the headwinds I was facing when trying to get any meaningful work done without Claude Code. It was mental pain, but it was fun.

At around the 13-14 day mark, the challenge completely fell apart. Due to workload, I leaned back onto agentic coding to fill in the gap. I thought I could get away with peppered use of AI agents here and there and then go back to the challenge once my workload reduced. This wasn’t the case, and even minuscule AI use caused a slippery slope back into the habit of coding ‘agentically’ 100% of the time.

The silver lining about this, however, is that this relapse (lmao) means we can contrast my experience with and without AI.

Metric              No AI   With AI      Δ  Verdict
─────────────────────────────────────────────────────────────────────────────────
Satisfaction          6.6       3.0   -3.6  ▼ Worse
Fatigue               7.2       8.0   +0.8  ▲ Worse (marginally)
PRs/period            0.4       9.0   +8.6  ▲ Better
Confidence            8.2       4.0   -4.2  ▼ Worse

Verbalising this data, we can pretty much say:

I delivered more work that I was less confident about, making me more miserable in the process

Looking at each of these metrics individually:

AI is making me more productive

I am closing more tickets, I am working at a faster rate, and while I haven’t tracked this, it doesn’t seem like I’m introducing more regressions or new bugs (for now).

AI is making me hate Software Engineering

This industrialisation of my SWE tasks is draining any sort of joy I’ve had for the craft. If Agentic coding fails, it’s incredibly frustrating to untangle and debug, and even if it succeeds, finishing a task via Claude Code leaves me… quite frankly… numb. There’s no dopamine reward at the end, since I’ve outsourced the squeezing of my brain-sponge for brain-juices to Anthropic.

AI is increasing my impostor syndrome

I’ve always struggled to have confidence in the code I wrote. I would only have confidence in the patterns I’d use if I saw them used elsewhere. AI kinda supercharged this impostor syndrome, because I can always reach for Claude to interrogate the “Bell Curve of code implementations”.

When I wrote code by hand, I was more confident in it, and my abilities to pick the correct patterns.

Fatigue quantitatively unchanged, qualitatively different

Initial fatigue when starting this challenge was related to having to re-activate my atrophied coding neural pathways, fatigue towards the end of this challenge was more related to context switching.

Conclusion

This challenge was quite intense, and even emotionally so. I expected a very straightforward progression from struggling to clean my mind’s cobwebs initially, a period of frustration and ultimately, deliverance. What I found was frustration, guilt, yielding to temptation, disappointment in self.

Even though I’ve technically failed this 40 day AI fast, I think it exposed stuff about myself that I wasn’t really taking seriously, namely how closely intertwined my self-image is to programming, and the learned helplessness that these tools imbue into their users.

Starting this challenge, I was sure that I would emerge from it and declare myself saved from the bondage of AI. I was sure that I would renounce the use of AI tools for good, and proudly proclaim my newfound wisdom and virtue to the world. Now, I’m not so sure.

It almost feels like writing a journal entry detailing some sort of relapse on the road to an addiction I’m trying to break. It felt like something I knew I shouldn’t do, but was too tempting not to indulge in. I felt my brain freed up from thinking about hard problems, and able to just scroll the internet while the agents did the work for me.

After a couple of days, I was rationalising this “relapse” as “aid” during a time of many conflicting deadlines. I can clearly say now, this was probably a false belief, and that it probably took me more time to complete tasks due to the amount of fragmentation my attention was subject to.

You can juggle multiple agents at the same time, but tbf, this isn’t what I became an engineer for. During my first job, I made a promise to myself that I will not go down the Engineering Manager career path, and that I will stick to an IC role, despite potential headwinds pushing me back onto the managerial path.

These past couple of weeks, instead of honing my craft, sharpening my saw, and (re-)building up the mental resilience to be able to spend continuous periods of time in front of frustrating problems, I instead spent my time keeping an army of coding agents on task, refreshing their context with implementation details they’ve compacted away, and responding to the slew of notifications reminding me that “Claude needs your attention”.

This is exactly what a Reverse Centaur is, instead of the Coding agents empowering me, I was empowering them, by using my fuzzy human abilities to compensate for their shortcomings:

Start with what a reverse centaur is. In automation theory, a “centaur” is a person who is assisted by a machine. You’re a human head being carried around on a tireless robot body. Driving a car makes you a centaur, and so does using autocomplete. And obviously, a reverse centaur is machine head on a human body, a person who is serving as a squishy meat appendage for an uncaring machine. Like an Amazon delivery driver, who sits in a cabin surrounded by AI cameras, that monitor the driver’s eyes and take points off if the driver looks in a proscribed direction, and monitors the driver’s mouth because singing isn’t allowed on the job, and rats the driver out to the boss if they don’t make quota. The driver is in that van because the van can’t drive itself and can’t get a parcel from the curb to your porch. The driver is a peripheral for a van, and the van drives the driver, at superhuman speed, demanding superhuman endurance. But the driver is human, so the van doesn’t just use the driver. The van uses the driver up. – Cory Doctorow

This isn’t fun, maybe I’m just a scrub that doesn’t know how to challenge himself with coding agents, but I derived a certain amount of feel good brain juice chemicals from getting into the flow state of coding, and the chemical-induced rush of completing hard tasks. Maybe Software Engineering will be a dead career, who knows? I can definitely see the market being oversupplied with grads, and coding agents becoming stronger. Maybe this push will make me look to other career paths. Who knows?

Regardless, we’re back on track now, and will push through with the final 14 days of this challenge.

Article argues that we should value maintainers as guardians, and that maintaining is an unappreciated job, because if maintaining is done right, nothing happens.

A big part of the skill in building software is understanding what’s possible and what isn’t, and having at least a rough idea of how those things can be accomplished.

At some point, I will release my post on why I think, regardless of LLM-assisted coding (but even more because of LLM-assisted coding), taste is one of the most important skills a Software Engineer can hone.