Something actually new?

There’s finally been a big leap forward in coding tech unlocked by AI — not just “it’s doing some work for me”, but “we couldn’t do this before”. What’s new are a few smart systems that let coders control fleets of dozens of coding bots, all working in tandem, to swarm over a list of tasks and to deliver entire features, or even entire sets of features, just from a plain-English description of the strategic goal to be accomplished.

This isn’t a tutorial, this is just trying to understand that something cool is happening, and maybe we can figure out what it means, and where it’s going.

The breakthrough here came from using two familiar ideas in interesting new ways. The first idea is orchestration. Just like cloud computing got massively more powerful when it became routine for coders to be able to control entire fleets of servers, the ability to reliably configure and control entire fleets of coding bots unlocks a much higher scale of capability than any one person could have by chatting with a bot on their own.

The second big idea is resilience. Just like systems got more capable when designers started to assume that components like hard drives would fail, or that networks would lose connection, today’s coders are aware of the worst shortcoming of using LLMs: sometimes they create garbage code. This tendency used to be the biggest shortcoming about using LLMs to create code, but by designing for failure, testing outputs, and iterating rapidly, codeless systems enable a huge advancement in the ultimate reliability of the output code.

The codeless approach also addresses the other huge objection that many coders have to using LLMs for coding. The most common direct objection to using AI tools to assist in coding hasn’t just been the broken code — it’s been the many valid social and ethical concerns around the vendors who build the platforms. But codeless systems are open source, non-commercial, and free to deploy, while making it trivial to swap in alternatives for every part of the stack, including using open source or local options for all or part of the LLM workload. This isn’t software being sold by a Big AI vendor; these are tools being created by independent hackers in the community.

The ultimate result is the ability to create software at scale without directly writing any code, simply by providing strategic direction to a fleet of coding bots. Call it “codeless” software.

Codeless in 10 points

If you’re looking for a quick bullet-point summary, here’s something skimmable:

1. "Codeless" is a way to describe a new way of orchestrating large numbers of AI coding bots to build software at scale, controlled by a plain-English strategic plan for the bots to follow.
2. In this approach, you don't write code directly. Instead, you write a plan for the end result or product that you want, and the system directs your bots to build code to deliver that product. (Codeless abstracts away directly writing code just like "serverless" abstracted away directly managing servers.)
3. This codeless approach is credible because it emerged organically from influential coders who don't work for the Big AI companies, and independent devs are already starting to make it easier and more approachable. It's not a pitch from a big company trying to sell a product, and in fact, codeless tools make it easy to swap out one LLM for another.
4. Today, codeless tools themselves don't cost anything. The systems are entirely open source, though setting them up can be complicated and take some time. Actually running enough bots to generate all that code gets expensive quickly if you use cutting-edge commercial LLMs, but mixing in some lower-cost open tools can help defray costs. We can also expect that, as this approach gains momentum, more polished paid versions of the tools will emerge.
5. Many coders didn't like using LLMs to generate code because they hallucinate. Codeless systems assume that the code they generate will be broken sometimes, and handle that failure. Just like other resilient systems assume that hard drives will fail, or that network connections will be unreliable, codeless systems are designed to handle unreliable code.
6. This has nothing to do with the "no code" hype from years ago, because it's not locked-in to one commercial vendor or one proprietary platform. And codeless projects can be designed to output code that will run on any regular infrastructure, including your existing systems.
7. Codeless changes power dynamics. People and teams who adopt a codeless approach have the potential to build a lot more under their own control. And those codeless makers won't necessarily have to ask for permission or resources in order to start creating. Putting this power in the hands of those individuals might have huge implications over time, as people realize that they may not have to raise funding or seek out sponsors to build the things that they imagine.
8. The management and creation interfaces for codeless systems are radically more accessible than many other platforms because they're often controlled by simple plain text Markdown files. This means it's likely that some of the most effective or successful codeless creators could end up being people who have had roles like product managers, designers, or systems architects, not just developers.
9. Codeless approaches are probably not a great way to take over a big legacy codebase, since they rely on accurately describing an entire problem, which can often be difficult to completely capture. And coding bots may lack sufficient context to understand legacy codebases, especially since LLMs are sometimes weaker with legacy technologies.
10. In many prior evolutions of coding, abstractions let coders work at higher levels, closer to the problem they were trying to solve. Low-level languages saved coders from having to write assembly language; high-level languages kept coders from having to write code to manage memory. Codeless systems abstract away directly writing code, continuing the long history of letting developers focus more on the problem to be solved than on manually creating every part of the code.

What does software look like when coders stop coding?

As we’ve been saying for some time, for people who actually make and understand technology, the majority AI view is that LLMs are just useful technologies that have their purposes, but we shouldn’t go overboard with all of the absurd hype. We’re seeing new examples of the deep moral failings and social harms of the Big AI companies every day.

Despite this, coders still haven’t completely written off the potential of LLMs. A big reason why coders are generally more optimistic about AI than writers or photographers is because, in creative spaces, AI smothers the human part of the process. But in coding, AI takes over the drudgery, and lets coders focus on the most human and expressive parts.

The shame, then, is that much of the adoption of AI for coding has been in top-down mandates at companies. Rather than enabling innovation, it’s been in deployments designed to undermine their workers’ job security. And, as we’ve seen, this has worked. It’s no wonder that a lot of the research on enterprise use of AI for coding has shown little to no increase in productivity; obviously productivity improvements have not been the goal, much of the time.

Codeless tech has the potential to change that. Putting the power of orchestrating a fleet of coding bots in the hands of a smart and talented coder (or designer! or product manager! or writer! or…) upends a lot of the hierarchy about who’s able to call the shots on what gets created. The size of your nights-and-weekends project might be a lot bigger, the ambitions of your side gig could be a lot more grand.

It’s still early, of course. The bots themselves are expensive as hell if you’re running the latest versions of Claude Code for all of them. Getting this stuff running is hard; you’re bouncing between obscure references to Gas Town on Steve Yegge’s Github, and a bunch of smart posts on Simon Willison’s blog, and sifting through YouTube videos about Ralph Wiggum to see if they’re about the Simpsons or the software.

It’s gonna be like that for a while, a little bit of a mess. But that’s a lot better than Enterprise Certified Cloud AI Engineer, Level II, minimum 11 years LLM experience required. If history is any guide, the entire first wave of implementations will be discarded in favor of more elegant and/or powerful second versions, once we know what we actually want. Build one to throw away. I mean, that’s kind of the spirit of the whole codeless thing, isn’t it?

This could all still sputter out, too. Maybe it’s another fad. I don’t love seeing some of the folks working on codeless tools pivot into asking folks to buy memecoins to support their expensive coding bot habits. The Big AI companies are gonna try to kill it or co-opt it, because tools that reduce the switching cost between LLMs to zero must terrify them.

But for the first time in a long time, this thing feels a little different. It’s emerging organically from people who don’t work for trillion dollar companies. It’s starting out janky and broken and interesting, instead of shiny and polished in a soulless live stream featuring five dudes wearing vests. This is tech made for people who like making things, not tech made for people who are trying to appease financiers. It’s for inventors, not investors.

I truly, genuinely, don’t care if you call it “codeless”; it just needs a name that we can hang on it so people know wtf we’re talking about. I worked backwards from “what could we write on a whiteboard, and everyone would know what we were talking about?” If you point at the diagrams and say, “The legacy code is complicated, so we’re going to do that as usual, but the client apps and mobile are all new, so we could just do those codeless and see how it goes”, people would just sort of nod along and know what you meant, at least vaguely. If you’ve got a better name, have at it.

In the meantime, though, start hacking away. Make something more ambitious than you could do on your own. Sneak an army of bots into work. Build something that you would have needed funding for before, but don’t now. Build something that somebody has made a horrible proprietary version of, and release it for free. Share your Markdown files!

Maybe the distance from idea to app just got a little bit shorter? We're about to find out.