![\"\"](\"https://storage.ghost.io/c/06/e5/06e5d12b-0328-469d-a0d0-3a0f0ba34c46/content/images/icon/A-black-and-white--low-angle-digital-illustration-in-a-symbolic-traditional-tattoo-art-style.--A-bald--light-skinned-man-with-a-bushy-beard--prominent-eyebrows--and-a-friendly-expression-wears-denim-overalls--2--c4421c9b-5f3c-40dc-838c-40b5235ce4e8.jpg\"){kind=icon}
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?
\nYAAP | Your Code Doesn't Need to Be Readable Anymore
\nYAAP by AI21 Labs — "Your Code Doesn't Need to Be Readable Anymore" (21 minutes)
\nHere's the gist, written up properly, plus chapter links at the bottom if you want to jump into a specific part of the conversation.
\n\n\nSoftware doesn't need to be readable by a human. It needs to be explainable to a human.
\n
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.
\nSo 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.
\nBoth 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.
\nWhat 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.
\nIt's not about the model anymore. It's about how you use the model.
\nWhy 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."
\nBack 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.
\nMost 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.
\nI 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?
\nHumans 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.
\nI 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.
\nPeople are still saying, very loudly, that code should be readable so that humans can understand it. I no longer think that's the goal.
\nTry 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.
\nBelow, you'll find a function that I have deliberately obfuscated....
\ng . h\n where\n h [] = []\n h (x:xs) = h xs ++ [x]\n g x =\n let (y, z) = p x\n in if y then z else g z\n p [] = (True, [])\n p [x] = (True, [x])\n p (x:y:xs)\n | x > y = let (a, b) = p (x:xs) in (False, y:b)\n | otherwise = let (a, b) = p (y:xs) in (a, x:b)\nRight now you're probably looking at the code and going... What the actual ... is this?
\nNow 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."
\nAll of a sudden it becomes accessible. It reads like Python.
\n\n\nThis 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.
\n
\n """Put the string backwards. 'cat' becomes 'tac'."""\n \n return \n = \n = \n return + \n\n\n """\n Walk the letters once.\n Whenever a bigger letter is sitting in front of a smaller one,\n slide the smaller one forward.\n Also report whether anything moved.\n """\n \n return True, # already tidy\n\n = \n = \n = \n\n \n # smaller one goes in front; keep comparing the bigger one\n , = \n return False, + \n \n # these two are fine; check the rest\n , = \n return , + \n\n\n """Keep doing one pass until a whole pass changes nothing."""\n , = \n \n return \n return \n\n\n return \nThat'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.
\nIf 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.
\nThink 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.
\nThis 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.
\nLanguages evolve through committees, and the pace of language development has been deliberately slowed to match the rate at which humans can learn new concepts.
\nI 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.
\nBut what happens if the language designer ships a skills pack alongside the breaking change, and the agent just does the migration?
\n\n\nIf 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?
\n
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.
\nIt'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.
\nI'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.
\n\n\nIf coding agents will write most of our code, what happens with our communities and sense of ergonomics? How does it impact our compilers and tools? https://t.co/DaYCSHFUBY
\n— José Valim (@josevalim) September 24, 2026
\n
Highly recommend reading this article. Programming language authors who build their languages around agent-first rather than human-first will get ahead. Those who don't will fall behind and end up like Solaris.
\nConsider being a CTO before AI...
\n\n\n"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."
\n
The end business impact is that you are maintaining three teams, or teams of teams, on tribal ideology about programming languages.
\nNow 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.
\nPorting 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.
\nCan a LLM convert C, to ASM to specs and then to a working Z/80 Speccy tape? Yes.
\n✨Daniel Joyce used the techniques described in this post to port ls to rust via an objdump. You can see the code here: https://github.com/DanielJoyce/ls-rs. Keen, to see more examples - get in contact if you ship something! Damien Guard nerd sniped me and other folks wanted
\n
![\"\"](\"https://storage.ghost.io/c/06/e5/06e5d12b-0328-469d-a0d0-3a0f0ba34c46/content/images/thumbnail/bafkreiftzmpb7bbkej76rac3kuijg2mcuyjxxhtnqdie5qq6rbrc45v2iu-1-a7544c4e-6d21-416a-898f-997162311d6f.jpg\")
It is provably true that languages are fungible, and it makes no business sense to carry so many of them in your business today.
\nOperating 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.
\nThe 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.
\nwhat is the point of libraries now that you can just generate them?
\nIt’s a meme as accurate as time. The problem is that our digital infrastructure depends upon just some random guy in Nebraska. Open-source, by design, is not financially sustainable. Finding reliable, well-defined funding sources is exceptionally challenging. As projects grow in size, many maintainers burn out and
\n![\"\"](\"https://storage.ghost.io/c/06/e5/06e5d12b-0328-469d-a0d0-3a0f0ba34c46/content/images/icon/A-black-and-white--low-angle-digital-illustration-in-a-symbolic-traditional-tattoo-art-style.--A-bald--light-skinned-man-with-a-bushy-beard--prominent-eyebrows--and-a-friendly-expression-wears-denim-overalls--2--c23bc14e-360c-4106-9896-e25298235b65.jpg\"){kind=icon}
![\"\"](\"https://storage.ghost.io/c/06/e5/06e5d12b-0328-469d-a0d0-3a0f0ba34c46/content/images/thumbnail/A-symbolic-traditional-tattoo-art-print-of-a-software-library-in-vibrant-retro-colors-with-complex-ornamental-details.-Creative-light-art-is-used-to-achieve-an-abstract-pattern-with-complimentary-colors--balance-36436c4b-e2ea-4613-85eb-539cecd7bc7d.jpg\")
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."
\nThat'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.
\nSince 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.
\nSoftware 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.
\nUltimately, 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.
\nSo right now I've got loops running that are rebuilding a source control system where:
\nIt'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.
\nKeep curious.
\n", "content_markdown": "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?\n\n[YAAP | Your Code Doesn't Need to Be Readable Anymore](https://www.youtube.com/watch?v=vrCE5m2MRys)\n\nYAAP by AI21 Labs — \"Your Code Doesn't Need to Be Readable Anymore\" (21 minutes)\n\nHere's the gist, written up properly, plus chapter links at the bottom if you want to jump into a specific part of the conversation.\n\n> Software doesn't need to be readable by a human. It needs to be explainable to a human.\n\n## the economics of AI are cooked, and I still haven't written code by hand in two years\n\nThe 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](https://www.wheresyoured.at/?ref=ghuntley.com) if you want the long version.\n\nSo 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.\n\nBoth 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.\n\nWhat 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.\n\n- 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.\n- 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).\n- 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.\n- 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.\n\nIt's not about the model anymore. It's about how you use the model.\n\n## the last forty years of computing were designed around humans\n\nWhy 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.\"\n\nBack 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](https://mirage.io/?ref=ghuntley.com).\n\nMost 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.\n\nI 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?**\n\nHumans 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.\n\nI 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.\n\n## readable vs explainable\n\nPeople are still saying, very loudly, that code should be readable so that humans can understand it. I no longer think that's the goal.\n\nTry 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.\n\nBelow, you'll find a function that I have deliberately obfuscated....\n\n```haskell\nf :: String -> String\nf = g . h\n where\n h [] = []\n h (x:xs) = h xs ++ [x]\n g x =\n let (y, z) = p x\n in if y then z else g z\n p [] = (True, [])\n p [x] = (True, [x])\n p (x:y:xs)\n | x > y = let (a, b) = p (x:xs) in (False, y:b)\n | otherwise = let (a, b) = p (y:xs) in (a, x:b)\n```\n\nRight now you're probably looking at the code and going... What the actual ... is this?\n\nNow 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.\"*\n\nAll of a sudden it becomes accessible. It reads like Python.\n\n> 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.\n\n```python\ndef flip(letters):\n \"\"\"Put the string backwards. 'cat' becomes 'tac'.\"\"\"\n if letters == \"\":\n return \"\"\n first = letters[0]\n rest = letters[1:]\n return flip(rest) + first\n\ndef one_pass(letters):\n \"\"\"\n Walk the letters once.\n Whenever a bigger letter is sitting in front of a smaller one,\n slide the smaller one forward.\n Also report whether anything moved.\n \"\"\"\n if len(letters) <= 1:\n return True, letters # already tidy\n\n first = letters[0]\n second = letters[1]\n rest = letters[2:]\n\n if first > second:\n # smaller one goes in front; keep comparing the bigger one\n moved, after = one_pass(first + rest)\n return False, second + after\n else:\n # these two are fine; check the rest\n moved, after = one_pass(second + rest)\n return moved, first + after\n\ndef tidy_up(letters):\n \"\"\"Keep doing one pass until a whole pass changes nothing.\"\"\"\n done, letters = one_pass(letters)\n if done:\n return letters\n return tidy_up(letters)\n\ndef f(text):\n return tidy_up(flip(text))\n```\n\nThat'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.\n\n## types are back pressure\n\nIf 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](https://ghuntley.com/pressure/): compiler errors that the LLM picks up and fixes automatically, every loop.\n\nThink 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.\n\nThis 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.\n\n## programming languages move at the speed of human learning\n\nLanguages evolve through committees, and the pace of language development has been deliberately slowed to match the rate at which humans can learn new concepts.\n\nI 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.\n\nOr 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.\n\nBut what happens if the language designer ships a skills pack alongside the breaking change, and the agent just does the migration?\n\n> 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?\n\nThere 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**.\n\nIt'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.\n\nI'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.\n\n> If coding agents will write most of our code, what happens with our communities and sense of ergonomics? How does it impact our compilers and tools? [https://t.co/DaYCSHFUBY](https://t.co/DaYCSHFUBY?ref=ghuntley.com)\n>\n> — José Valim (@josevalim) [September 24, 2026](https://x.com/josevalim/status/2103133294317445290?ref_src=twsrc%5Etfw&ref=ghuntley.com)\n\nHighly recommend reading this article. Programming language authors who build their languages around agent-first rather than human-first will get ahead. Those who don't will fall behind and end up like Solaris.\n\n## languages are fungible now\n\nConsider being a CTO before AI...\n\n> \"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.\"\n\nThe end business impact is that you are maintaining three teams, or teams of teams, on tribal ideology about programming languages.\n\nNow you can [run loops](https://ghuntley.com/loop/) 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.\n\nPorting 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.\n\n[Can a LLM convert C, to ASM to specs and then to a working Z/80 Speccy tape? Yes.](https://ghuntley.com/z80)\n\n✨Daniel Joyce used the techniques described in this post to port ls to rust via an objdump. You can see the code here: https://github.com/DanielJoyce/ls-rs. Keen, to see more examples - get in contact if you ship something! Damien Guard nerd sniped me and other folks wanted\n\nGeoffrey Huntley Geoffrey Huntley\n\n\n\nIt is provably true that languages are fungible, and it makes no business sense to carry so many of them in your business today.\n\nOperating 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.\n\n## the V8 hot rod\n\nThe 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.\n\n[what is the point of libraries now that you can just generate them?](https://ghuntley.com/libraries)\n\nIt’s a meme as accurate as time. The problem is that our digital infrastructure depends upon just some random guy in Nebraska. Open-source, by design, is not financially sustainable. Finding reliable, well-defined funding sources is exceptionally challenging. As projects grow in size, many maintainers burn out and\n\nGeoffrey Huntley Geoffrey Huntley\n\n\n\nIf 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.\"\n\nThat'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.\n\n## what I'm building in the meantime\n\nSince 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.\n\nSoftware 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.\n\nUltimately, 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.\n\nSo right now I've got loops running that are rebuilding a source control system where:\n\n- contents are encrypted;\n- agents get a claim, which provides a materialized view of the repository;\n- that means real ACLs. Share a sub-path with a contractor, much like Windows file permissions, instead of \"the Git repo has everything.\"\n\nIt'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.\n\n## chapters\n\n- [0:55](https://www.youtube.com/watch?v=vrCE5m2MRys&t=55s&ref=ghuntley.com) — the economics of AI are cooked\n- [2:30](https://www.youtube.com/watch?v=vrCE5m2MRys&t=150s&ref=ghuntley.com) — where you actually need frontier intelligence\n- [4:30](https://www.youtube.com/watch?v=vrCE5m2MRys&t=270s&ref=ghuntley.com) — get your tokens cheap\n- [5:31](https://www.youtube.com/watch?v=vrCE5m2MRys&t=331s&ref=ghuntley.com) — Loom and software factories\n- [7:01](https://www.youtube.com/watch?v=vrCE5m2MRys&t=421s&ref=ghuntley.com) — rebuilding source control; Git is end of life\n- [8:31](https://www.youtube.com/watch?v=vrCE5m2MRys&t=511s&ref=ghuntley.com) — simulator-first development\n- [9:00](https://www.youtube.com/watch?v=vrCE5m2MRys&t=540s&ref=ghuntley.com) — OCaml, unikernels and forty years of human-centric computing\n- [10:50](https://www.youtube.com/watch?v=vrCE5m2MRys&t=650s&ref=ghuntley.com) — readable vs explainable\n- [13:30](https://www.youtube.com/watch?v=vrCE5m2MRys&t=810s&ref=ghuntley.com) — types as back pressure\n- [14:30](https://www.youtube.com/watch?v=vrCE5m2MRys&t=870s&ref=ghuntley.com) — languages designed by committee\n- [16:00](https://www.youtube.com/watch?v=vrCE5m2MRys&t=960s&ref=ghuntley.com) — languages are fungible\n- [19:30](https://www.youtube.com/watch?v=vrCE5m2MRys&t=1170s&ref=ghuntley.com) — the V8 hot rod\n- [20:30](https://www.youtube.com/watch?v=vrCE5m2MRys&t=1230s&ref=ghuntley.com) — optimise for agents, not humans\n\nKeep curious.\n", "dateCreated": "2026-10-02T08:58:34.290726633+00:00", "date_created": "2026-10-02T06:06:40+00:00", "date_modified": "2026-10-02T06:06:40+00:00", "date_published": "2026-10-02T06:06:40+00:00", "description": "Forty years of computing was designed around humans as the reader, writer and operator. On AI21's YAAP podcast I argued that's no longer a design goal, and what that means for programming languages.", "external_url": "https://ghuntley.com/readable/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/ghuntley-com/2026/10/2026-10-02-software-doesn-t-need-to-be-readable-anymore-it-needs-to-be.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/ghuntley-com/2026/10/2026-10-02-software-doesn-t-need-to-be-readable-anymore-it-needs-to-be.md" }, "id": "urn:aggr:item:02ee3a8af37d0bd9f255f700b7fc06f2564c4bdf", "isBasedOn": { "@id": "https://ghuntley.com/readable/" }, "mainEntity": { "@id": "https://ghuntley.com/readable/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/ghuntley-com/2026-10-02-software-doesn-t-need-to-be-readable-anymore-it-needs-to-be/#webpage" }, "author": [ { "@type": "Person", "name": "Geoffrey Huntley" } ], "dateModified": "2026-10-02T06:06:40+00:00", "datePublished": "2026-10-02T06:06:40+00:00", "headline": "software doesn't need to be readable anymore. it needs to be explainable.", "timeRequired": "PT12M", "url": "https://ghuntley.com/readable/", "wordCount": 2502 }, "name": "Archived snapshot: software doesn't need to be readable anymore. it needs to be explainable.", "preview": null, "reading_minutes": 12, "replicated_at": null, "source": "ghuntley-com", "source_name": "Geoffrey Huntley", "summary": "Forty years of computing was designed around humans as the reader, writer and operator. On AI21's YAAP podcast I argued that's no longer a design goal, and what that means for programming languages.", "tags": [ "ai" ], "temporalCoverage": "2026-10-02T08:58:34.290726633+00:00", "title": "software doesn't need to be readable anymore. it needs to be explainable.", "url": "https://aggr.aymericbeaumet.com/items/ghuntley-com/2026-10-02-software-doesn-t-need-to-be-readable-anymore-it-needs-to-be/", "word_count": 2502 }