For most of the history of software, an application existed because enough people wanted it to pay for the time it took to build. A tool that only one person needed usually didn’t get written, unless that person happened to be a programmer with a lot of spare evenings. Everyone else adapted to whatever the market offered.

That has changed. With modern LLM coding tools, a person with a clear picture of the application they want can build it, even if they will be its only user. I think of it as custom software on demand: not a product with a market, but a tool made for one person’s way of working. I’ve been building software this way for most of this year, and I think it is one of the more important things these tools make possible.

High-level programming languages exist so that an engineer can communicate, not to the computer, but to engineers who follow them. Computers are happy processing machine instructions, or assembly if we want to be generous. Every abstraction above that line — named variables, functions, modules, types, patterns, comments, documentation — exists not because the machine requires it, but because the humans reading and writing the code do. We state this as a readability principle, usually in the context of writing clear names and keeping functions short. This is a point that, in a rush to deliver features, engineers often forget, and non-engineers often don’t understand. But I think the idea reaches further than most people take it, and the failure mode when you miss it has never been more consequential than it is right now, in the age of AI.

Boris Cherny, the creator of Claude Code, said something recently that matched my own experience: “I don’t prompt Claude anymore… my job is to write loops.” Peter Steinberger put it more bluntly: “You should be designing loops that prompt your agents.”

I’ve been building LLM-powered pipelines on top of Spring Integration for a while, and those two lines named what I had been doing without quite realizing it. My time had stopped going into prompts. It was going into the loops around them.

I’ve spent the last few weeks building a documentary video generation pipeline. A topic goes in (say: “Sankebetsu brown bear incident 1915 Hokkaido”) and a finished mp4 comes out (a ten-minute narrated documentary, 27 scenes, original visuals, voiced by a documentary-grade TTS), all running on a homelab cluster.

Between those two endpoints sits a chain of eight passes that hand off to each other. Several fan out to “do N things in parallel and aggregate.” Several produce artifacts measured in MB per scene that should not be shoved through a message broker. A few are the right place to put a human in the loop, where one minute of editorial review saves hours of GPU time downstream.

Three Production Apps, Zero Code: What Keip Actually Looks Like in Practice#

In the past month I shipped three integration apps to my home cluster: a Spanish translator that replies in audio, a health tracking bot I can query from any room in my house, and a camera alert system that decides for itself what’s worth telling me about. Each one took under an hour to have running. None of them required me to write a single line of application code.

Running local AI inference on AMD Instinct MI60 GPUs - a budget-friendly path to 70B parameter models at home.

Overview#

The AMD Instinct MI60 is a datacenter GPU from 2018 that remains surprisingly capable for local AI workloads. With 32GB of HBM2 memory per card, a dual-MI60 setup provides 64GB of VRAM, enough to run 70B parameter models with quantization.

This section documents my setup: hardware modifications for cooling, software configuration for ROCm and vLLM, and the workflows that make it practical for daily use.

In Part 1 of this series, I set up Claude Code against local LLMs on dual MI60 GPUs and watched it scaffold a Flask application from scratch. Small tasks worked. Complex ones did not. I ended with three ideas I wanted to test: running a dense model, trying Claude Code’s agent teams feature, and building a persistent memory layer for coding sessions.

I started the experiment that mattered most: giving a local LLM a project with real scope and seeing what happened. I ran the same project against two different models. The results were instructive, and not in the direction I expected.

Enterprise Integration Patterns Aren’t Dead; They’re Running on Kubernetes and Orchestrating AI#

Keip is a Kubernetes operator for Enterprise Integration Patterns. Gregor Hohpe and Bobby Woolf documented these patterns in 2003: content-based routers, message transformers, splitters, aggregators, dead letter channels. Spring Integration has implemented them for years, but deploying Spring Integration on Kubernetes has always been harder than it should be. Keip fixes that. It turns integration routes into native Kubernetes resources, and I use it to run an LLM-powered media analysis pipeline on my home cluster.

I have been running local LLMs on dual AMD MI60 GPUs for over a year, and recently pointed Claude Code at them to see how close I could get to frontier-quality agentic coding on my own hardware. I wanted to know: how close can local models actually get to Anthropic’s Claude for building real software?

This is the first post in a series documenting that experiment. Future posts will cover specific agentic coding sessions, hardware and model setup, and the tools I am building to close the gap.

Every health app wants to coach you, but none of them know you. They do not know your baseline. They do not know that your blood pressure spikes after certain meals, or that your ketones tank when you are stressed. They offer generic advice based on population averages and call it personalized.

So I built my own. It runs on my infrastructure, stores everything in a time-series database I control, and uses Claude to understand what I am eating, estimate the macros, and give me context on every measurement I log. Not generic advice. Insights based on my data.