We Should Revisit Literate Programming in the Agent Era

SILLY.BUSINESS

The ever-growing power, and usage, of AI is causing many of us to re-think how we approach software development. How can we adapt our patterns and practices to fully capitalise on this new technology?

This blog post ponders whether Literate Programming will have a surge in adoption as a result of agentic AI.

“Literate programming is the idea that code should be intermingled with prose such that an uninformed reader could read a code base as a narrative, and come away with an understanding of how it works and what it does.”

This might sound like a slightly odd or cumbersome practice, but it is popular in certain fields - for example Jupyter notebooks within the Data Science community.

The blog post describes a technique where the ‘literate’ parts of a program capture the prompts, or models intent, which is interspersed with the code. It also help ensure that the documentation includes architecture, constraints and all the context needed to make an AI agent truly effective.

The author’s core claim is that literate programming failed because humans had to maintain the prose — but AI can maintain it automatically, making the approach finally practical.

Personally I am unsure about the value of this practice. I agree that we will likely start optimising our codebases for consumption by AI agents (and we already are), but the literate programming approach feels over-complicated and verbose. While agents do benefit from supporting documentation (e.g. within AGENTS.md), that captures concepts that are not directly represented in code - for the most part, they can gain most of the context they need from the code itself. That is why they are so much more powerful than us!

While I am not sure I agree with this author, it was a really interesting post.

Will Claude Code ruin our team?

JUSTINJACKSON.CA

In this post Jackson shares some thoughts about how Agentic AI is changing team dynamics. Tools like Claude Code are empowering everyone, not just software engineers, resulting in an odd situation where everyone believes they can do each others jobs.

This isn’t just theoretical, a brief survey of his friends shows that this is starting to play out:

“I think you’re correct here. We’re already seeing it — mainly around PMs wanting to write code.”

This is also influencing hiring:

“Where you really see the impact on jobs with us is in the people we’re no longer hiring: specialists. In this new era, generalists win.”

The whole industry feels like a snowglobe at the moment, it’s just been given a long hard shake. It’s going to be a while until the flakes settle.

I built a programming language using Claude Code

ANKURSETHIS.COM

Ankur has created his own language called Cutlet, without writing a single line of code. Looking at the git history, it only took him a few weeks. It’s strange that we live in a world where this doesn’t even feel all that impressive anymore.

The more interesting thing about this experiment is why Ankur wrote his own language. His day job involves front-end development, with lots of HTML / CSS, where AI agents struggle. He wanted to experience using agents in an environment where they can really fly. Along the way he learnt some important lessons, sharing the four key skills he believes are important for working with agents:

• Understanding which problems can be solved effectively using LLMs, which ones need a human in the loop, and which ones should be handled entirely by humans.
• Communicating your intent clearly and defining criteria for success.
• Creating an environment in which the LLM can do its best work.
• Monitoring and optimizing the agentic loop so the agent can work efficiently.

These are great lessons, and it is well worth reading his post where he dives into the details of each.

CodeSpeak - a next-generation programming language powered by LLMs

CODESPEAK.DEV

I’ve seen a few people speculating that the prevalent use of AI for writing code will result in the creation of new languages targeted specifically at AI. Our current crop of languages (Python, Rust, JavaScript et al) are designed with humans in mind, and our slow moving brains.

When I saw CodeSpeak I thought that perhaps this was an AI-first language. It isn’t.

It’s another implementation of the Specification Driver Development (SDD) pattern, and approach which is growing in popularity.

What I find interesting with CodeSpeak is their angle - that using a specification-driven approach will significantly compress your codebase (by up to 10x). My previous experience with SDD, specifically SpecKit, was quite the opposite, approximately double the amount of markdown text versus generated code.

The CodeSpeak websites has a few examples, and once again, I am skeptical. They have successfully compressed the code into smaller specifications, but the way they do this relies on the inherent knowledge of the LLM when generating code from spec. For example, you can specify “Standard WEBVTT signature per W3C spec”. Is that reliable? unambiguous? will the results change with different models?

Having said that, I don’t want to be too dismissive. As models become more powerful, so too will SDD is an approach. We are going to be spending much more of our time writing specifications in the future, regardless of what tool or methodology we adopt.

Grief and the AI Split

LMORCHARD.COM

If you’ve been reading this newsletter for a while, you’ll know that I have included a number of articles recently that reflect a growing sadness about the direction of travel of the industry. People mourning the loss as we move from human-crafted code to prompting and reviewing. This article talks through similar themes, but strikes a more optimistic tone.

One really interesting observation this blog post makes is that AI is exposing a divide that has always existed in the software development community - the “craft-lovers and the make-it-go” people. A split that Peter wrote about last month where he introduced the idea of Builders and Thinkers. The additional point this post makes is that this difference has almost been invisible, Builders and Thinkers working together, using the same tools and techniques.