Let Your Software Write Its Own Code - Rafal Cymerys<br>Rafal<br>Cymerys<br>I got into computers because they let me build anything I could dream of.<br>I never got enough of it - these days I work across open source and AI to give people the power to tackle the challenges that matter most: how we stay healthy, how we learn, and how we make smart decisions.<br>[email protected]LinkedInGitHub

© 2026 Rafal Cymerys<br>← WritingLet Your Software Write Its Own Code<br>Jul 2026 · 5 min read

A QA engineer walks into a bar. Orders 1 beer. Orders 0 beers. Orders 999999 beets. Orders -1 beers. Orders a lizard. Orders NULL beers. Orders asdfjkl; beers. Orders 1.5 beers.<br>Then a customer walks in and asks where the bathroom is. The bar bursts into flames. (source)

You probably know this joke. It's a surprisingly accurate description of our reality.

We build our bars for what we can anticipate, and then users arrive with everything else.<br>The startup answer to this has always been: ship early, learn fast, iterate. Get real users in front of the product as soon as possible so you discover the bathroom questions before you figure out how to serve a lizard at a bar.

That's a good advice. I've followed it for many years. It surfaces problems sooner, but it doesn't make them go away. You still end up spending a lot of your energy building narrow solutions to specific complaints, adding another import handler, another configuration screen, fixing another edge case that someone found in production. Your test suite keeps expanding. The customers keep surprising it anyway.

What I find interesting, and what I've recently spent a lot of time working on, is a totally different approach to this problem. What if AI coding tools could lend a hand?

But first, a distinction worth making carefully.

We're missing the more interesting part of AI coding

There's a lot of hype right now around AI and code. Copilot, Cursor, Claude Code - tools that help developers build software faster, fix small bugs automatically, and find their way around a large codebase easier. They are great, and I use them daily.

But enough has been said on that.

What I find personally more fascinating is an entirely different flavor of the AI coding concept: what happens when the AI agent inside your product can write code at runtime, in production. And instead of helping you build another iteration of your product, help your users use it.

These are two completely different ideas that are currently getting lumped together under "AI and code". The first is a productivity story, whereas the second one is a combination of product design and architecture. It's easy to miss it, as it sits outside the normal frame of how we think about building software products. The implications are also totally different: different risks, different infrastructure, and a fundamentally higher ceiling on what your product can actually do.

The industry has a name for the first concept. I'm not sure we have a clean name for the second yes. The closes I've found is runtime code generation: the ability of an LLM, embedded inside a running application, to write and execute code on behalf of a user in response to something the developer has never anticipated. I believe it's a bigger opportunity than it sounds like, and one of the most under appreciated product decisions a team building with AI can make right now.

Why software always disappoints someone

Developers build for what they anticipate. Users arrive with everything else.

The gap between these two things always fails with a loud "bang!". It fails with an error message, a disabled button, a "this format isn't supported" modal. The user hits the wall, shrugs, and works around it. The developer hears about it, adds it to the backlog, and eventually ships another configuration screen, another import handler, another option in a dropdown that covers the known cases and none of the unknown ones. Then the cycle starts again.

What's remarkable is how normalized this is. Both sides have accepted it. Users expect software to say "sorry, can't do that". Developers expect to spent a significant portion of their time building narrow solutions to specific complaints rather than addressing the underlying problem.

We can distinguish two major failure modes:

The unanticipated problem. The developer never saw it coming. A user uploads a file in a format that wasn't in the spec. They ask a question nobody designed for. The tool has no path for this. The user simply cannot proceed.

The unreliably solvable problem. The developer saw it coming, but couldn't write logic flexible enough to handle it. Parsing files where the schema is unknown until the file arrives. Transforming data that varies enough between sources that an algorithm breaks on real inputs. The application either crashes or produces output that's questionable at best.

Both failures have the same root cause. The logic was written before the specific problem arrived.

A timeless example: importing a...