The AI Tool Ecosystem

Choosing the right tools

For Software Development, the toolset and the primary way to use it has been pretty much stable since the late '90s or so. You have an IDE or an editor system to write, compile and test your code. That's combined with scripts and other tools to, for instance, run, test, or manage the running system.

Key concepts related to the current state of affairs are depicted below. Regardless of which tool you use, you prompt, attach context, and some kind of agent processes the request and produces the output.

Agentic harnesses

One way to think about this field is in terms of agentic harnesses: the coordination layer that wraps around a language model and determines how it interacts with your codebase, your workflow, and other agents. The harness is what turns a raw LLM into a development tool. Some harnesses are minimal, a prompt and a file reader. Some are opinionated, a full workflow with gates and artifacts. The choice of harness shapes the developer experience more than the choice of underlying model.

Opinionated vs unopinionated tools (generic vs specialized)

Nowadays the AI tools are much more than the generic ChatGPT prompt in the browser we all began with, even though the primary interface is still the prompt.

The primary groups of AI tools in our craft:

One of the issues with plugging AI capabilities into our craft is actually the unopinionated nature of the tools. They offer you the power of the LLMs, but they don't tell you how to use it. Yes, there are capabilities like tools (retrieval, file access, API calls) and features like agent mode, but they don't tell you when to use them, how to structure your prompts, how to manage the context, how to integrate with your workflow.

I summarize these distinct tool groups in the table below to compare them with the agentic coordination and context framework proposed in this book.

Another way to look at this is in stages: whatever 'agentic framework' you use to coordinate and delegate the work, different kinds of tools and capabilities match certain stages of that flow. This is depicted below.

CLI-based agentic coders

Claude Code, Codex CLI, Opencode, and Copilot CLI are general-purpose LLM frontend engines built on a command line interface. They have artifacts for subagents, different modes (edit/plan), and so forth, and use the same context and configuration management approach as their IDE-integrated counterparts: basic instruction files, skills, prompts, and whatnot.

Calling them CLIs to somebody who thinks that means ps | awk rather than a nethack-like window is perhaps a bit misleading. These CLIs are not flow-based (text flowing in your terminal) but use colors and organize the windowing to keep the current screen in focus, with the ability to scroll just parts of the window.

IDE-integrated assistants

Copilot and Cursor fill a similar role: they accelerate coding within a stage. The developer might use Cursor during the Engineering gate for day-to-day work, while the framework handles the broader lifecycle around them. Copilot has evolved from inline autocomplete to full agent mode that can plan multi-step edits and create PRs, but it remains a coding accelerator, not a delivery governance framework.

Prompt-to-app generators

Lovable, v0, and Bolt.new solve a completely different problem for a completely different audience. They produce demos; this framework produces governed deliveries. There is no integration point between them.

These tools are extraordinarily effective at time-to-first-demo, and they are reshaping expectations about how fast software should appear. But every one of them hits a "technical cliff": authentication, security, performance, testing, team collaboration, and long-term maintenance are your problem. The demo is free; production is not.

This matters because these tools set the pace expectations that professional delivery teams are measured against.

Spec-driven toolkits

GitHub's Spec Kit shares the conviction that specifications should precede code, but differs in scope and enforcement. Spec Kit plans per-project with advisory checklists; the governed approach plans per-story with enforced approval gates and machine-readable schemas tied to backlog items.

Context engineering layers

GSD fights context rot through task-level isolation: each task gets a fresh 200k-token subagent context. The governed approach fights context rot through role-level isolation: each stage is a separate agent invocation with defined inputs. Both work; they optimize for different things.

GSD optimizes for solo throughput with minimal ceremony. Its creator's philosophy: "I'm not a 50-person software company. I don't want to play enterprise theater." That resonates for good reason, and my roguelike project (the thread running through this book) was built entirely with GSD. It works, and it works well. Most software is not built by large teams with compliance requirements. For a solo developer or a small team shipping a product, GSD's lightweight phases with optional verification give you structure without the overhead of mandatory gates, formal artifacts, and human checkpoint ceremonies. The ceremony has a real cost: configuration effort, context overhead, and slower iteration cycles. If your project doesn't need traceability or multi-team coordination, that cost buys you nothing.

The governed approach earns its overhead when the work must be auditable, when multiple people need to understand what was built and why, and when the cost of an undetected defect outweighs the cost of a gate. This is not a hierarchy where governed is "better"; it's a spectrum where the right choice depends on your context.

Agent memory systems

Beads provides persistent, queryable work state across sessions, a Git-native issue tracker designed so agents can wake up, ask "what's next?", and resume work. The governed pipeline's task-tracking layer serves a similar function but is inseparable from its gate model: state and workflow are unified in a purpose-built artifact store, versioned in Git alongside the code.

Token economy

The Generative AI models, especially the larger ones, are expensive to run. The hardware that runs them is nothing short of the things referred to as supercomputers just a few years ago. So the slowness you'll see - a simple prompt might take minutes to complete, is not due to business of the service, but the immense calculations required to produce the response tokens.

Comparing token efficiency by approach or tool would be an interesting exercise, but is beyond the scope of this book. Anyway, I argue that keeping tasks small (my key thesis!), having clear separations of concerns and well-defined inputs and outputs, and avoiding unnecessary back-and-forth with the model are the best ways to keep token costs down. In practice this means opening fewer files (like e.g. via Compacted Indexes), having clear task definitions that don't require multiple rounds of clarification, and using the model's output as directly as possible without needing to reprocess it too much are effective techniques not only to save money, but make your agents run smoother and faster.

Choosing what fits

What I've described throughout this book is not a product. It's an agentic SDD workflow, pieced together from available tools: shareable, version-controlled task artifacts; multiple developer intervention points; and automatic quality control with a feedback loop. As of this writing, none of this exists as an off-the-shelf product you can install and run.

So how do you actually choose? Four questions determine your starting point:

Your answers map to the table below:

You'll know it's time to move to the next row when you start seeing things like the same error happening again, an agent keeps spilling output that makes a mess of somebody else's work or totally disregards your 100kB carefully crafted AGENTS.md, or a reviewer can't tell why something was built a certain way (or why it was done in the first place).

I could go on, but these kinds of signals are just the Universe telling you that you need more structure.

A few rules of thumb that apply regardless of team size:

This kind of rather strict and multi-stage governance is really only necessary when you have multiple people working on the same codebase, when you need to be able to trace decisions and changes, and when the cost of a defect is high enough to justify the overhead.