I recommend giving this book by Steve Yegge and Gene Kim a good skim even if not a thorough read. I found its best parts to be their advice about the day-to-day approach a software developer can take with respect to coding assistants (Part 3 of the book). But should you even invest time in learning a tool that changes every few months? The book claims that the principles which they recommend here will be relevant even if models and tools keep improving (more on this later). Towards the end they cite an economist, Matt Beane, whose research regarding warehouse automation showed that ground-level workers who adopted new automation technologies usually gained valuable tacit knowledge and skills. This helped them grow faster in their career, including through roles and titles that didn’t even exist before the advent of that automation! Another strong point of view emphasized throughout the book (that I’m not yet convinced of) is that programmers are now “head chefs”: they have to manage a team of coding agents and can no longer be expected to work on a single task at a time! Since both authors are experienced and reputed professionals in the field of software, the book features interviews with other technology leaders and economists, and also links to quite a few good talks and articles regarding AI assisted coding. These references alone are worth dipping into it!
The book tries to cover all aspects of AI assisted coding (up to organizational transformation) but comes across as superficial at places. After reading it, I was not particularly more enlightened about the fundamental strengths/weaknesses of an “LLM” or “GPT” as regards to generating code. They admit upfront that there’s going to be no maths or linear algebra in this book. But there are so many instances of “AI will” and “AI can” in wildly varying contexts that you begin to doubt whether you’ve understood the essence of this technology at all! At one place the authors caution us against anthropomorphizing these assistants, and insist that you use them like tireless workers who never complain no matter how tedious or repetitive your requests are. But that message could get lost in the rest of their verbiage.
I also found the descriptions of multi-agent orchestration and organizational adoption to be lacking in details (or perhaps I couldn’t grasp them properly). I wish the book had explored in more depth the impact on workflows of specific roles like Frontend Engineer, Backend Engineer, Principal Engineer etc. Instead they resort one too many a time to the many side projects of the authors, one of which has to do with tools for book writing – hardly representative of the software industry at large!
FAAFO and Optionality
Inside this book is a useful equation, drawn from the world of finance:
Option Value = (N * K * Sigma)/T
Here, Option Value is a measure of how many future courses of action you can possibly take (higher the better).
And:
N → The no. of parallel modules that are being worked on within a project.
K → The (average?) no. of parallel experiments possible within a module.
Sigma → A measure of uncertainty. Ranges from 1 to Infinity. Higher implies more uncertain.
T → (Average?) Time per experiment.
It’s obvious that AI reduces T (time per experiment) dramatically. So that automatically implies your Option Value goes up, and even more so in situations of high uncertainty (high Sigma). Let’s keep aside for a moment whether AI code is “Better”. This increase in speed should benefit us directly. Since AI code assistants are also extreme generalists, they enable a single person or team to work Autonomously, reducing the need for cross-functional collaboration. This lets you attempt more Ambitious projects (observable in the trivial case of weekend side projects that get done in hours). The authors’ FAAFO mnemonic ties all these together: Fast, Ambitious, Autonomous, Optionality (the other F stands for Fun, which I’ll ignore as it’s not relevant for professional contexts).
But remember that there’s no “B for Better” in FAAFO! If we assume that you’re satisfied (even if not particularly happy) with AI code, you still need to keep a close watch on it. There’s a detailed chapter with anecdotal evidence on how AI generated code can go horribly wrong. A timely reference to the concept of “jagged frontier” and its background here, is the kind of stuff that makes this book worthwhile – but again one wishes there had been a more detailed explanation of this concept. And there’s also a discussion of a recent industry survey (DORA 2024) where it emerged that reliability actually dropped after adoption of AI! To address these, the book recommends not losing sight of the following age old engineering practices: Modularity, fast feedback loops, and exercising good judgment. How much new Option Value you gain depends entirely on those three conceptual guardrails. In their words, “Taking your hard won engineering discipline and applying it at greater intensity”. For a given project, if you are able to keep an optimally high N (no. of modules), optimally high K (experiments per module), in such a way that AI code does not veer off the quality bar, you stand to gain most from the reduction in T (time per experiment). To quote, “The main value of going faster is the extent to which it multiplies the value in the other dimensions of FAAFO”.
The numerous practical tips presented in the book can probably be seen as ways to implement these guardrails in your day-to-day software development process (Part 3 in the book, as I mentioned earlier). Given that AI can accomplish certain inner-loop tasks in seconds or minutes, how do you ratchet up all the rest of your quality controls around this new reality? How best to decompose tasks? What granularity of work to hand over to AI? When to intervene? How often to check back? The context window of AI’s gets a good amount of discussion here. They encourage you to think of delegating tasks along the lines of Andy Grove’s High Output Management. In brief, you delegate based on: Task novelty, Past experience, Skill level, Task size and impact, Frequency of reporting. But the maturity of the AI for a particular task is something you can only gauge through practice and a lot of trial-and-error.
A big downside of the book is that the many great pieces of info are sprawled across its verbose, stretched out length (hence my suggestion to skim). To be fair, the book is targeted at people who are programmers or tech-adjacent, but may have never played with coding assistants. So there’s a lot of introductory and motivating material about the overall landscape. It seems to be designed as a leisurely read and not an executive summary. There’s an Appendix and a Glossary at the end which are very handy. And I made my own Notes when reading it.