Geoffrey HuntleyModify

2026-10-05 20:07:33

It's kind of strange seeing all these discussions about software factories... and the like. It's also strange to see conversations about programming languages or claims that $language is best, as if that will remain true going forward. It's very clear, however, that programming languages will converge toward something, but that 'something' is undefined for now.

What I haven't seen is people really deeply understanding the power of the new substrate that we have. People are still too fixated on what they have now and how systems have been built to rethink fundamentally how much things can change.

To me, a software factory isn't just about process automation; it isn't about automating everything you've got as it is now. It's about using this substrate so you can develop your product while it runs whilst in the product itself.

Everyone (regardless of their discipline or background) in the company should be able to develop the product in the product without having to go to some external vendor supplied tool.

The only tool that exists is your product itself. The product should build the product from the product.

In a future blog post, I'll go further into what it means for the product to develop the product, in the product, but for now I have one simple thing for you to imagine:

Why is software built the way it is now, rather than grown through iterative use of LLMs? What if you could develop your application just by chatting with it? Live and interactive with no compilation steps.

To demonstrate this, I built Jiti, a small kernel for growing a running Lisp application through conversation with an LLM. You ask for a capability, the model writes Lisp, and the application permanently acquires that capability until you ask for that capability to be removed.

The kernel supplies the machinery to inspect, change, execute, and recover a managed Lisp world. Application behavior comes from whatever you decide to add to the application by prompting for those outcomes. With Jiti, you can start from a clean slate or modify an existing application to add more behavior just by prompting it.

The source code is available on GitHub, and I encourage you to run it and play around with it. It is very generic, in the sense that it can do literally anything you want. All you have to do is ask, and it will program that capability into the application.

How it works is relatively simple. At a high level, an OpenAI model receives your request, instructions for operating the application, tool definitions, and observations of its current state. The kernel can ask to inspect the available functions, read a definition, propose new source, or execute an expression.

Once a definition is accepted, it is an ordinary Lisp function. Calling it does not inherently require another inference request. You can call it from Lisp, from another application function, or through the chat interface.

The OpenAI model is used to extend a program, while the running Lisp world holds the resulting functionality.

The agent tool interface has two useful intentions.

• develop_form adds, redefines or removes functionality.
• execute_form calls functionality that exists, including combinations of existing functions.

Both use the same evaluator and transaction machinery. The distinction helps the model choose whether the user is asking to change the application or simply use it.

Suppose I've already asked the application to add uppercase-string and reverse-string. I can then prompt the kernel to uppercase some text and reverse the result. The composition is just Lisp:

(reverse-string (uppercase-string "Hello"))

If I want that combination as a reusable capability, I can prompt it to save that as a function.

(defun shout-backwards (text)
  (reverse-string (uppercase-string text)))

That function joins the catalog with its arguments and source, ready for inspection and later use. A future request can discover it and build on it. The application accumulates an executable vocabulary through use. Lisp already gives us the composition rules; the kernel keeps the evolving definitions available and their managed effects accountable.

Lisp deserves the credit for the interactive programming machinery. Definitions, inspection, conditions, and restarts have been there for decades. It's kind of cool, huh?

To me, the idea that an agent writes source code and then there's a costly compilation phase involving CI/CD is now truly undefined now that we have AI. The only limiting factor will really be people's curiosity about what they can do with this new substrate...

ps. socials

2026-10-02 14:06:40

I sat down with the folks at AI21 Labs for their YAAP podcast at the AI:Engineer World Fair, and we went deep on something I've been chewing on for most of this year: almost every decision in computing for the last forty years was made with a human in the loop, as the reader, the writer, or the operator. What happens when that stops being true?

Here's the gist, written up properly, plus chapter links at the bottom if you want to jump into a specific part of the conversation.

Software doesn't need to be readable by a human. It needs to be explainable to a human.

the economics of AI are cooked, and I still haven't written code by hand in two years

The opening hot take was that AI economics are absolutely cooked because adoption is nowhere near what is needed to achieve ROI on the amount of capital deployed. This is why all the labs are hiring aggressively to staff up professional services organizations around the world right now. Go read Ed Zitron's Where's Your Ed At if you want the long version.

So far, the only reliable ways anyone has found to make money with AI are reselling tokens with a markup (and competing directly against the labs while you do it) or selling the infrastructure around them: sandboxes and the like.

Both things can be true at once. The economics can be cooked, and how I develop software has completely, fundamentally changed. I haven't written code by hand for two years. These models generate code better than most employers can actually hire for.

What changes is how you think about spend. The thing we're all going to discover over the next year is where we actually need frontier intelligence and where we don't. Frontier intelligence is expensive, and you don't need it for every single task.

• The models have been good enough for at least a year. There was a real jump from Sonnet 3.5 to the Opus 4-ish range; since then it's been marginal. The hype and hysteria around alignment and security change, but the capability mostly hasn't. These models have always known how to drive Kali and Burp Suite.
• Personally, I run a mix of GPT 6.1 sol on no or low reasoning, and GLM/Kimi. I use programming languages that let me get away with that (more on that below).
• Find the right model for the task, then buy those tokens wherever they're cheapest. Take an open-weights model like GLM, run it on Baseten, and it costs a fraction as much.
• If you're a company, check for zero data retention. At home? Just get your tokens cheap. There was a time when Z.ai's yearly GLM plan was $300 AUD a year, compared with $300 a month for the big labs' plans. Some of the smartest engineers I know bought twenty of them and ripped with concurrency.

It's not about the model anymore. It's about how you use the model.

the last forty years of computing were designed around humans

Why does a computer have a console? Because we used to have mainframe operators. A whole lot of what we consider "how computers work" is really "how computers were made legible to people."

Back in March I took a detour, picked OCaml back up because it has an effect system built in, and started playing with unikernels via MirageOS.

Most applications run on an operating system. What if the application was the operating system — a very thin one, with almost no overhead? Most software gets breached either through an exploit in the OS layer or through the app layer as a foothold into the OS. Delete the OS layer, and you delete that class of problem.

I ended up rebuilding essentially Erlang as a distributed operating system. Is that a dead end? Maybe. Sometimes these experiments are. But knowing what's possible, and where it works and where it doesn't, lets you rethink the last forty years and ask a better question: can we delete instead of build?

Humans aren't operating machines anymore either. You hand a Docker container to a Kubernetes cluster and an operator control loop manages it. Once the human is out of the loop, the design decisions that existed for the human are up for renegotiation.

I truly think Unikernels are going to come back into fashion hard over the next couple of years for security reasons. All the friction... that existed when architecting an application with this design no longer exists.

readable vs explainable

People are still saying, very loudly, that code should be readable so that humans can understand it. I no longer think that's the goal.

Try this for fun: go play with Haskell this weekend. It doesn't matter if you've never touched it. The LLMs know it. There's a lot of dogma out there about things being hard to learn. Well, they're now false. Learning things like Nix and Haskell used to be pushing shit uphill and unachievable in a single sitting. But now the LLM knows it's easy.

Below, you'll find a function that I have deliberately obfuscated....

f :: String -> String
f = g . h
  where
    h []     = []
    h (x:xs) = h xs ++ [x]
    g x =
      let (y, z) = p x
      in if y then z else g z
    p []       = (True, [])
    p [x]      = (True, [x])
    p (x:y:xs)
      | x > y     = let (a, b) = p (x:xs) in (False, y:b)
      | otherwise = let (a, b) = p (y:xs) in (a, x:b)

Right now you're probably looking at the code and going... What the actual ... is this?

Now copy that function into an LLM and prompt it to "explain this function to me as if you were explaining it to my son or daughter but in Python as a reference."

All of a sudden it becomes accessible. It reads like Python.

This Haskell turns a string into its letters in alphabetical order. It does that in two steps: flip the string backwards, then keep bubbling letters into order until nothing moves.

def flip(letters):
    """Put the string backwards. 'cat' becomes 'tac'."""
    if letters == "":
        return ""
    first = letters[0]
    rest = letters[1:]
    return flip(rest) + first

def one_pass(letters):
    """
    Walk the letters once.
    Whenever a bigger letter is sitting in front of a smaller one,
    slide the smaller one forward.
    Also report whether anything moved.
    """
    if len(letters) <= 1:
        return True, letters  # already tidy

    first = letters[0]
    second = letters[1]
    rest = letters[2:]

    if first > second:
        # smaller one goes in front; keep comparing the bigger one
        moved, after = one_pass(first + rest)
        return False, second + after
    else:
        # these two are fine; check the rest
        moved, after = one_pass(second + rest)
        return moved, first + after

def tidy_up(letters):
    """Keep doing one pass until a whole pass changes nothing."""
    done, letters = one_pass(letters)
    if done:
        return letters
    return tidy_up(letters)

def f(text):
    return tidy_up(flip(text))

That's the shift. The artifact doesn't need to be optimized for a human to read cold. It needs to be something a model can explain to a human on demand.

types are back pressure

If you want a codebase that agents can maintain, you'll notice something quickly: a Rust codebase is far more maintainable with agents than a Python one. Types are a form of verification. They provide back pressure: compiler errors that the LLM picks up and fixes automatically, every loop.

Think of it as a continuum of power. Up one end, Haskell is even stricter than Rust. At the other end, you've got Ruby, Python, PHP, and Perl, where types were never a first-class citizen and are hard to bolt on after the fact.

This is also why I can get away with cheaper models. Pick a language that does the verification for you, and you need less intelligence to stay on the rails.

programming languages move at the speed of human learning

Languages evolve through committees, and the pace of language development has been deliberately slowed to match the rate at which humans can learn new concepts.

I remember when monads arrived in .NET — LINQ in 3.5, championed by Erik Meijer. We're talking about SelectMany, flat map, to be blunt. It took an easy five to eight years before people were comfortable with it. Now it's everywhere in every programming language.

Or look at Python 2 to 3. It's been about fifteen years, and there are still wounds. The lesson the industry took was "you must not break users," so nobody makes breaking changes.

But what happens if the language designer ships a skills pack alongside the breaking change, and the agent just does the migration?

If humans aren't the target audience, we don't have to dumb down the language for adoption, and the LLMs have the entire corpus of programming language theory — what can we do with that?

There are maybe ten or twelve truly great applied programming language designers in the world, and most of them have specialized their careers in human accessibility.

It's going to take people on the fringe of comp sci (the ones who were told, "you can't do that, nobody will learn it") to hear that this is now false. You can take research that's twenty years old, put it together, and the LLM will do it for you.

I've been collecting other nerds who are thinking along the same lines. No results to show yet. We're all just playing with this new substrate.

languages are fungible now

Consider being a CTO before AI...

"We need to hire a Ruby person. Over here it's .NET, so that's a separate team. And the company we acquired is Java."

The end business impact is that you are maintaining three teams, or teams of teams, on tribal ideology about programming languages.

Now you can run loops to port from one language to the next. A founder in the medical space in Australia had an old ASP.NET Web Forms app on IIS. Terrible, terrible, terrible; I've done it, I know. I challenged him to run some loops himself, then go back to his team the next morning without telling them and ask for an estimate on the rewrite. They said years. A week later the migration was done. He did it all himself and completely mogged his engineering team.

Porting is easy when the end result is easy to verify. Stealing an idea from a Go library and wanting it in Rust is easy now, and has been for at least a year.

It is provably true that languages are fungible, and it makes no business sense to carry so many of them in your business today.

Operating systems went through a convergence event: AIX, Solaris, HP-UX and IRIX all collapsed into Mac, Linux and Windows. I expect programming languages to converge the same way: down to a couple of gilded languages, or something new rises from the dust.

the V8 hot rod

The usual objection to a new programming language is adoption. But you don't necessarily need adoption now when deciding whether to use a language, now that we have AI. Like, what libraries exist in this ecosystem don't factor into my decision to create a new project these days.

If you'd built some sick V8 hot rod and everyone else was on a horse, would you care whether they adopted it? "Yeah, enjoy that horse, mate."

That's why this area is interesting. Not "is there a faster programming language," but: can we incorporate more ideas from verification into our languages, stop optimizing for humans, and start optimizing for agents? Is there a way to go faster? I don't know yet. I guess we'll have to find out.

what I'm building in the meantime

Since January, I've been talking about Loom and the idea of a software factory, something that optimizes a whole business function. It's on GitHub, it's not really usable, and it's not intended to be; it's research.

Software factories are very, very hard to do right now. For the last six months, my view has been that we need one of: better models, better programming languages, or a revival of some old computer science techniques like simulators.

Ultimately, I want to replace GitHub. I want to bring back something like Phabricator, the engineering system that predates GitHub and came out of Facebook's early days. Google has Piper and Rosie for large-scale refactoring. Meta has EdenFS, Mononoke and Sapling. If GitHub is the only thing you've seen, it seems fine. It's not good enough. I think Git is somewhat end-of-life; I really wish people would stop trying to extend Git's lifespan.

So right now I've got loops running that are rebuilding a source control system where:

• contents are encrypted;
• agents get a claim, which provides a materialized view of the repository;
• that means real ACLs. Share a sub-path with a contractor, much like Windows file permissions, instead of "the Git repo has everything."

It's a distributed system, so I'm building it in Rust and building the simulator first, then driving the agent to validate everything through the simulator. That has kept the agent on the rails remarkably well.

chapters

• 0:55 — the economics of AI are cooked
• 2:30 — where you actually need frontier intelligence
• 4:30 — get your tokens cheap
• 5:31 — Loom and software factories
• 7:01 — rebuilding source control; Git is end of life
• 8:31 — simulator-first development
• 9:00 — OCaml, unikernels and forty years of human-centric computing
• 10:50 — readable vs explainable
• 13:30 — types as back pressure
• 14:30 — languages designed by committee
• 16:00 — languages are fungible
• 19:30 — the V8 hot rod
• 20:30 — optimise for agents, not humans

Keep curious.

2026-10-02 12:38:26

One of the original promises of a personal computer was that the computer would be personal. It's kind of strange to think that, now in 2026, it has taken circa 40 years for this to actually become true.

You see, over the last 40 years, someone was either a software developer, also known as a programmer, and in that case they were able to make a computer personal. If you didn't have these skills, you were given an interface, and your ability to personalize the computer or software was limited to what the interface could do.

Something strange is happening in game development circles right now. With AI, everyone is a game developer. It doesn't matter whether someone has the skills of a software developer or a game developer; they can express what they want, and a couple of loops later, they have outcomes.

Yet, why is it that at most corporates right now, the responsibility to develop software is a named role or job function?

One of my hottest takes right now is that 2026 and 2027 are all about enabling others in your organization to contribute to and develop software, and if your corporate roadmap doesn't have this on the agenda, you're missing the mark. If you aren't aligned with making this happen, then you're self-sabotaging your career.

Corporate is full of dogma about how things should be done, the processes, and who's responsible for getting things done. This needs to be completely rethought from first principles, including who is responsible for these activities and what that entails.

Everyone is now a software developer. The craft has been commoditized, but access to do the craft within corporate has not. Agile assumed writing software was the costly, scarce activity, so it optimized the loop around human authorship by a select few.

If you still have software engineers within your company writing code by hand and outright rejecting AI, you should be setting the stage for tough career conversations with that person within the next six months, because they have failed the curiosity test.

It's easy to get political about the commoditization of our profession, and I see engineers that I respect lean into the argument that labs have stolen intellectual property, etc., but it's been two years now...

There is a big pool of juniors who are available, are cheaper, and are more AI-native that can be hired. There's never been a market for free-range organic software; it's always been about more, cheaper and sooner.

If you're looking to get ahead as a software engineer or business leader, my strongest recommendation is to enable the commoditization of access so everyone can write software within your business.

ps. There is no reason software quality should dip in your organization because of AI adoption. These days, when I hear someone say that, I just think...

"Wow, you're truly over-indexing on the quality of humans that were available to hire in the general labor market. These LLMs generate better code than 99% of companies could hire for. Things have changed. Why can't you see this? Please put your family unit and yourself first."

Our job as software engineers now is to engineer systems, including safety controls, that let everyone ship to production — safely.

2026-09-27 16:34:40

This is the eighteen-month recap: the talk I gave on day two of AI Engineer Singapore. A lot has happened since the six-month recap in Melbourne. The recording is below, followed by an edited transcript with the slides.

Welcome back. For those who were at the party here last night, he actually came on for a couple of sets and DJed as well. So who is Geoffrey Huntley?

He's an independent AI researcher known for doing unhinged things with AI. He's the person behind the Ralph loop, which is now incorporated in many, many tools that are used today.

Hello everyone. As confident as I might seem about these topics, I must say this is quite a provocative title. I don't know. So when you're listening to this, I want you to reflect upon it. Maybe I'm right, maybe I'm wrong.

It's a provocative title because I'm saying that software development now costs less than minimum wage. There was a time when, if you wanted to do photography, you had to buy specialized tools. But now everyone's got an iPhone, and everyone's a photographer. Think about that. Things have changed.

With that disclaimer out of the way: I do not work for anyone. I am completely independent. I do not represent anyone. So this is going to get spicy. Let's do it animal style.

It's been roughly a year and a half since I published the technique of allocating memory in a particular way. If you wrap the tool calls around another loop, it's just a loop. But there's a lot of science in the context engineering needed to actually achieve these outcomes, and it's quite disruptive. Here I was giving this talk about how everything has changed, and this was a week before Atlassian did their layoffs.

Oops. You see, the unit economics of business have forever changed. I want you to really understand how big this is. If you do not believe this is true, you need to stop speaking with other developers. You need to speak with founders. You need to speak with business leaders. You need to get a little more curious about what this means and get ahead of what this means for business.

What does it mean when everyone is a software developer? For no particular reason at all, Cursor was at the same meetup. This isn't a plug for Cursor, but I want to call something out at this meetup. Here's Roslyn, and there were other people like Roslyn. They're designers. They're product managers. And they're having the time of their damn lives. There weren't any software engineers up there giving talks.

That's because they're now being enabled to become software developers. For the first time ever, it's like an iPhone in their hands. They can just get stuff done. They can take photos. They can develop software. Whatever is in their wildest dreams, they can do.

I've been traveling around the world for the last three months. I think I've given this talk 17 times now in different cities, including Auckland. In Auckland, I decided to go on a side quest to Hobbiton from The Lord of the Rings.

My tour guide asked, "Geoff, what do you do?" and I'm like, "I do AI. Please don't judge me." Next thing you know, his eyes lit up, and he goes, "Geoff, how good is AI? How good is AI?"

What does it mean when your tour guide is token-maxing?

2026-07-24 00:40:16

If I wind back time to November 2024, it was apparent to me back then that our profession would change. To be frank, in the last six months our profession has changed more than it has in the last 30 years. Software authoring has been commoditised. Everyone is now a software developer, but being a software developer does not mean that they're an engineer.

The word engineer is used trivially in our profession, but in other industries the word engineer means failures are unacceptable.

Now I'm a little bit old and crusty these days; I turn 44 next week, and I've seen some absolutely horrible codebases, but if I'm to be honest, I can remember some of the first code that I wrote, and I have regrets. If you caught my talk at the AI Engineer World Fair, one of the things I shared was some deep concerns that we are entering into another Eternal September. You see, we didn't create enough software engineers after the 2000s dot-com implosion to properly support an apprenticeship model of learning in our industry.

It's now twenty-six years since that event, and now that everyone can create software, we've got some hard questions to solve. But whilst many things have changed, the job of software engineers is to produce experiences without defects.

So I've been pondering how we are going to fix this predicament.

Here's my hypothesis:

1. The discipline/techniques of formal verification and deterministic system testing are about to cross the chasm. There's a whole lot of brownfield software out there that's been written over the last 30 years that is being affected by the infinite software crisis (“how do we do code review now?” / “the volume of code/change is too high”) all at once.
2. Not enough skilled practitioners in the discipline/techniques of formal verification and deterministic system testing exist.
3. Whilst the costs of building a simulator for a project (new or retrofitting an existing project) are significantly cheaper now, there are entire categories and classes of problems that will not surface unless you emulate a deterministic computer (which provides a forceful way to make anything deterministic).
4. Antithesis, when used in conjunction with adversarial code reviews by an LLM and with language analyzers driven by pre-commit hooks, will be a key component in software factories that enables people/agents to deliver reliable software without the burden of having to learn this specialized knowledge.

Creation is now near-free. Verification/understanding is not, yet. It's time to engineer away the slop.

2026-06-27 05:01:22

Some personal hot takes from AI: Engineer Miami follows...

1. Software development is a dead-end profession because anyone can be a software developer now.

2. Anyone can use Cursor or any other tool and generate code. Being a coder and being a software engineer are different.

3. Computers used to be gated; now everyone has the power to make computers malleable. Everyone is a software developer now, but that does not mean they are software engineers

4. If you cannot demonstrate how a coding agent works, you are just a consumer and have imposed an artificial glass ceiling on your career as a software engineer.

5. If you are curious, you will have a job. If you have not been curious in the last two years, you are replaceable.

6. SaaS per-seat economics may become unstable as customers need fewer people to achieve results, prompting founders to think about new unit economics

7. Most companies will take two or three years (or more!) to figure out AI transformation.

8. Some companies are already building AI native teams of five to ten people who can build with the grain of AI

9. There will be an explosion in the number of software developers. Software development is now essentially free, and tokens are cheaper than humans

10. Not enough engineers know what it means to be a product engineer

11. JIRA ticket monkeys are cooked

12. If your company has banned AI, you should quit that company

13. AI is more like a musical instrument than just a tool. Play with it, make discoveries, build intuition, learn where AI is good and where it fails