https://tidyfirst.substack.com/p/augmented-coding-beyond-the...

I remember he first posted 2+ years ago, back when people first realized ChatGPT might be useful for coding, that "90% of my skills are now worthless and the remaining 10% are worth 1000x"

https://tidyfirst.substack.com/p/90-of-my-skills-are-now-wor...

Clearly AI programming allows you to quickly close feedback loops. I don't think everything needs a comprehensive set of unit tests though.

But if people can go back and understand the core concept of XP (which again is about feedback loops to me) and take advantage of LLM-based agent systems to create those tight closed feedback loops, then that will be an advance for software engineering.

Yet, the most unexpected thing happened this year on my team of 4 senior/staff-level developers:

Instead of "splintering/pairing off with AI" individually even further, we wound up quadrupling (mobbing) full-time on our biggest project to date. That meant four developers, synchronously, plus Claude Code typing for us, working on one task at a time.

That was one of the most fun, laser-focused and weirdly effective way of combining our XP practice with people and AI.

Funny how some of it is now day-to-day, and other parts of it would be considered extremely weird.

If you pair program with someone else on your team, you both learn what the other is thinking. You both become more familiar with what the code is doing, and why it's doing it.

If you "pair program" with an AI, anything it learned, it forgets as soon as the prompt is closed.

So don't think that's what he's talking about here. He's talking about XP, with humans, just like in the 1990s. There may be some AI in there too, but that's not where the XP part comes from.

TDD is useful in some situations, yep totally. Pair programming is useful in some situations, yes. Continuous integration; yes, much of the time. Frequent feedback; yes, sometimes, for some types of work which doesn't require deep focus...

It just doesn't work as a blanket 'XP' paradigm because you rarely need all these parts all the time, at the same time. IMO, this is why Extreme Programming lacks gumption as a concept. It feels like a bunch of good ideas thrown together. If there was some kind of synergy between those ideas and practices, the concept of XP would be more important.

As it stands today, everyone is implementing maybe 1 or 2 aspects of XP, but almost nobody is implementing ALL of XP... So nobody can claim that they're adhering to XP.

This is not the same as as 'Agile' because with Agile; the vast majority of big companies are implementing maybe 90% of agile practices, with 70% fidelity... This consistency is enough for companies to identify themselves as 'Agile'. I've worked for many companies which implemented ALL of the Agile practices but not one of them actually implemented them exactly as taught in the Agile Manifesto. I think the closest one I worked for was maybe 90% of the way there; they even followed the story point system exactly and used a packet of cards with numbers on them to allow people to vote during Sprint Planning meetings... but anyway, pretty much all the companies/projects I worked for identified themselves 'Agile' because all the practices fit into a single paradigm and there was value in adopting all of them. After a while, it became easier for project managers to just say "Let's switch to Agile" instead of saying "Let's time-box our development work into short increments, with a planning meeting, refinement meeting and retrospective meeting for each 2-week increment."

For production code I do pretty much all of these, always - at least insofar as it is possible (e.g. willing pairing partner).

Im curious to know under which scenarios you think im doing something wrong. Coz I dont think i am.

This excellent writeup by David Olson gives both the history and the correct understanding; The Myth of the 'Waterfall' SDLC - http://www.bawiki.com/wiki/Waterfall.html

In that case, I don't believe companies follow either. I've never seen anything as principled (in any form) practiced anywhere.

Companies claiming to do Agile were usually doing some rituals and cosplaying as agile. I don't believe I've ever seen a company doing "waterfall" or anything resembling what your link describes either.

They mostly do chaos-driven development.

No, Waterfall was not agile, it was the diagram from Royce but not what he recommended from his paper (which tore down that diagram). What Royce added to that diagram (fundamentally, just common sense with feedback loops) was closer to agile, though. Royce himself never called anything Waterfall, but what was termed Waterfall was the bad process he tore apart.