Update 2026-05-11: Added Daniel Euchar’s blog, Matt Pocock’s skills and Vlad Khononov’s modularity plugin. Add reference to Mario Zechner. Downplaying the Compound Engineering plugin.
Update 2026-04-11: Added Ivett Ördög’s video, and sections on specific topics: TDD and testing, harnesses and guardrails, spec-driven development, and reviewing AI output.
I’ve been experimenting with coding with AI intensely for the past 13 months. Along the way, some things I read stayed with me and I would recommend them to anyone on this learning journey. These are some of my favorites; I’m only including choice representatives from each category, to keep this post short.
Personal workflows
It’s always fascinating to read about talented individuals’ personal work habits. Here are a few favorites out of many.
- Shrivu Shankar’s AI Can’t Read Your Docs contains a mix of advice on what works and what doesn’t, especially related to “how do I teach AI how I like to work”
- Boris Tane’s How I Use Claude Code explains how to focus on planning a programming task, which is one of my favorite strategies for levelling up with agentic AI.
- Ivett Ördög’s Managing Cognitive Load in the Age of AI (video) explains her favorite tricks.
- Habit Hooks are a mix of deterministic trigger and markdown instructions
- RefaktTS, a CLI refactoring tool for agents
- Approved Scenarios, an important testing pattern, similar to test mini-languages
Team and company workflows
- Daniel Euchar’s Ship Features With AI — Without Losing the Plot is my favorite summary of how to introduce AI in a team. It respects’s Thoughtworks’ traditional Sensible Default Practices, especially proceed in small steps.
- Ryan Lopopolo’s Harness Engineering focuses on how to guide the AI with lints, and explains the extremely important idea of “garbage collection”: an ongoing process to simplify and reduce the size of the codebase.
- Kieran Klaassen’s Guide To Compound Engineering used to be my go-to resource, until I found that it tries to do too much too automatically. The concept of compounding is gold; the actual implementation is a great source of ideas, but I don’t recommend it as the primary way to introduce AI coding in a company.
Pattern languages
Emily Bache recently argued that, given that traditional TDD katas are no match for AI coding assistants, we should study patterns instead. She has a very good point, though I think that finding existing open source codebases and making them safe to operate with AI is also a very good exercise.
Here are the only two coding-with-AI pattern collections I know
- Lada Kesseler and others publish the Augmented Coding Patterns: a very high quality collection. One of my favorites here is Approved Fixtures
- Simon Willison’s Agentic Engineering Patterns is a recent addition and is growing fast.
Book
Not many books on this subject; of the ones I read, this one is the only one I like:
- Uberto Barbini’s Process Over Magic: Beyond Vibe Coding is a good all-around starting point. I like how Uberto explains how AI is a tool he uses daily and would never want to give up, while at the same time keeping a healthy skeptical attitude, knowing that AI always makes mistakes, sometimes big ones.
Theories
- Birgitta Böckeler’s Understanding Spec-Driven Development brings clarity on a technique that is implemented in dozens of frameworks, but has surprisingly little written about. Among the three kinds of SDD she identifies is spec-as-source: an approach where the spec is the ground truth and code is derived from it, making the codebase essentially ephemeral.
- Chad Fowler’s blog on what he calls the Phoenix Architecture is a detailed treatment of exactly that idea: spec-as-source taken to its logical extreme. It’s unclear what the limits of applicability are; I can’t find tangible evidence of it being applied at scale, besides a POC library and the claims from the StrongDM team
Specific topics
DDD
Some skills I saw about DDD, focus on the technicalities of Value Objects and Entities. Surely these are important, but even more fundamental is paying attention to the domain language. DDD is about communication, and working with AI is also about communication. Building a precise vocabulary helps, because it makes our conversations, and our code, more concise and precise.
Matt Pocock’s Skills plugin contains the weirdly named “grill-me-with-docs” skill, that can be used to build a vocabulary from scratch, or to revise a task description against an existing one.
TDD and testing in general
- Ivett Ördög’s video on Approved Scenarios and Approved Logs
- Julias Shaw’s article on why specs without tests are next to useless. “Encoding specifications into automated tests that actually enforce the contract. […], most developers outside the extreme programming crowd don’t realize they need to”. THIS
- Ross Cox’s famous presentation on testing in Go is very much applicable to any other language, and arrives at similar conclusions as Ivett Ördög’s
- It turns out it’s easy to get AI to follow (its own version of) TDD: just tell it to “use red/green TDD”, as Simon Willison reports. It’s a different version of TDD where the AI writes a bunch of tests first, then checks that they fail, then makes them pass, whereas the original TDD calls for writing a test at a time. Also, the AI will usually forget the refactoring part. All the same, it’s a very useful technique
Architectural design
Architectural design is essential, in general, and it becomes even more important when working with AI, because AI does not care about the maintainability of our code, unless we direct it specifically to do something about it. Now, modularity is often praised, but is rarely explained well. It’s not enough to say “improve my code”: we should explain clearly what we consider “better”.
- Matt Pocock’s Skills plugin contains the Improve Codebase Architecture skill, based on John Ousterhout’s theory of modular design: modules should be “deep”, eg their interface should be narrow, and hide extensive content
- Vlad Khononov’s Modularity plugin contains skills for analyzing existing architectures, and designing new ones; it is based on Vlad’s own theory of balanced coupling, explained in his book.
- One of Kent Beck’s takes on software design is that duplicated code can hint at missing abstractions. His prompt is wonderfully simple and effective: “run the copy/paste detector over the whole rust codebase to see if there are missing abstractions”.
Harnesses and guardrails
- Birgitta Böckeler’s article on Harness Engineering explains the concept and its nuances
- Ben O’Mahony’s article on Hardening Codebases for Agentic Coding gives good tips for Python codebases; it’s straightorward to extend this to other languages
Spec Driven Development
- Birgitta Böckeler’s article on Understanding Spec-Driven Development
Reviewing AI output
- Kieran Klaassen of Compound Engineering fame writes that he stopped reading code, and his code reviews got better
- Simon Willison’s Linear Walkthrough get the AI to write a report about the code it’s written.
- A counterpoint by Mario Zechner: Read every line of code, from the video recording of his presentation at AI Engineer 2026
Finally…
Ivett’s recommendation is gold: Never use a prompt from anyone else, unless you have reviewed that prompt