Claude Code Framework Wars

SUBSTACK.COM

… on the myriad ways to use AI agents

The industry direction of travel is moving away from AI augmenting our existing engineering practices, to the agentic model, where tools like Claude Code have autonomy, with the human operator taking on the higher-level roles of project manager, designer, and software architect.

However, these AI agents are not effective ‘out of the box’. This blog post argues that you should treat these tools as a framework, a set of rules, guidance, and ultimately choices which you need to make.

This blog post does a really good job of outlining some of the framework decisions you need to make, and how some well-known agentic frameworks reflect these different choices.

If you are jumping into agentic software development, this is a worth a read.

Spec-driven development with AI: Get started with a new open source toolkit

GITHUB.BLOG

When I first started using AI tools for software development I primarily used them for small tasks, ones that I could reliably describe in a few sentences. In order to tackle a more complex task, I’d break it down into steps, prompting the AI to undertake each in turn. However, I soon realised that if I invested a bit more time in creating a detailed specification (often in markdown), I could hand much more complex tasks to the AI assistant. This is a pattern that many others have discovered and follow.

Harper Reed described a similar approach in his blog post earlier this year. Well worth a read.

As AI tools have become more sophisticated, moving from assistants to agents, the creation of a clear specification that allows the agent to operate autonomously on more complex tasks has become ever-more important.

This recently release open source project from GitHub is a whole framework for creating specifications, in an agentic-agnostic fashion (i.e. it works wth Copilot, Claude, Devin etc). They provide a structured approach to writing specifications, implementation plans and task breakdowns.

“We’re moving from “code is the source of truth” to “intent is the source of truth.” With AI the specification becomes the source of truth and determines what gets built.”

I think this is a useful addition to our toolkit and will help guide people towards practices that help them get the most from these tools.

I ran Claude in a loop for three months, and it created a genz programming language called cursed

GHUNTLEY.COM

What do you do if you tell Claude Code to “Produce me a Gen-Z compiler, and you can implement anything you like.”? You get Cursed!

Yes, you can give Claude Code a high-level and somewhat ambiguous task, and it will happily work away at it for months. You can see the end result on the Cursed website.

Writing Code Is Easy. Reading It Isn’t.

IDIALLO.COM

When reviewing code, you don’t just read it for the sake of a line-by-line understanding, you read it to build a mental model of the software system (or at least part of it). To do this properly takes time. I don’t think this is new to any of us, however, in an LLM-powered world, things are different.

As the author states:

“When an LLM can produce an infinite amount of code or text, it tempts us to skip the reading.”

and

“This is why the real bottleneck in software development isn’t writing, it’s understanding.”

I’m not entirely sure I agree with this statement. However, I do very much believe that if we can create an infinite amount of code, quickly, with minimal cost, we will find a great many bottlenecks elsewhere in the system. Our own understanding of what the LLM has created is certainly one of them.