What if an underwriter who knows exactly which risk factors deserve a second look, and has zero ability to write a line of code, could get a working quoting tool built without ever routing that judgement through someone who turns it into engineering terms first?
I build KaryoSpace with Claude Code in a loop that already looks half-autonomous. I describe what I want, sometimes in a couple of rough sentences typed from my phone. The agent refines it, asks the right questions, builds it, tests it, deploys it, and emails me when it's live. My job has shifted from writing code to having ideas and judging results.
But I can do that because I already have some technical vocabulary to reach for, even when I'm being lazy about it. Someone with a real idea and none of that vocabulary is locked out of this loop entirely, no matter how good the idea is. That's the gap this thought is actually about.
Picture a system of its own, not a feature bolted onto one app. Installed on your own machine, or run on a server somewhere, it doesn't matter which. Inside it, a board that looks like Jira: rows of cards, one per feature. You type the idea for a feature you want, in your own words, the way you'd describe it to a colleague rather than to a compiler. It joins the board marked open.
Behind that board, a loop is always running, and it doesn't work the ask alone. It hands each open card to a set of councils: an architect council for how it should be structured, a business council for whether it's the right thing to build at all, a UI/UX council for how it should feel to use, a testing council for how to know it actually works. Each council argues its own angle, the loop reconciles them into one approach, and that approach gets built, tested, and deployed the way I already work with Claude Code today. When a card clears validation, its status flips to done, and the idea typed in plain words is now a feature actually running.
The part I keep coming back to is what happens after done. You reply on that same card. Not right, try again. Close, but call the button something else. The reply reopens the card and sends it back through the same councils. No new ticket, no separate channel, just a conversation attached to the thing it's actually about.
The scarce input to software is becoming the idea and the judgement of whether the result is right, and neither of those needs technical vocabulary. An underwriter knows exactly which answers on a form should trigger an instant quote and which should stop and wait for a human, without knowing what a rules engine is. The councils exist to carry the translation both ways, plain language in, working software out, so the vocabulary gap stops being the reason a good idea never gets built.
The build-test-deploy loop itself isn't the hard part. I'm already living a slower version of it, the session logs for KaryoSpace show ideas going in as two-line asks and coming out as deployed features, sometimes the same evening. But every one of those asks came from me, already knowing roughly what I wanted and how to say it in terms an engineer would recognise. That's the honest gap between what I've actually seen work and what I'm describing here. One technical person directing one loop, I've watched that work. Multiple councils arguing out an ask from someone with no technical vocabulary, and that same person judging the result, isn't something I or anyone I know of has actually tried.
The pieces mostly exist, just separately, and mostly for the technical-user case. A loop that keeps running without anyone kicking it off by hand. A model that can build, test, and deploy once it understands the ask. Models arguing different sides of a decision is already how some code review and red-team setups work. Nobody's put those pieces behind a board built for someone who's never had to phrase a technical ask in their life.
The reply-on-the-card mechanic answers the judgement problem for after something's built and wrong. It doesn't answer the moment before anything's built, when the councils hit a real ambiguity that only the person who typed the card can resolve, should a borderline combination of risk factors auto-decline or route to a human for review, and that question has to reach the underwriter in exactly those words, not in a way that assumes they know what a rules engine is. I don't yet know how a council decides it's genuinely stuck and needs to ask, versus when it should just pick a reasonable default and let the reply-on-the-card loop catch it later.
There's also no sense yet of when to stop trying. Every round of councils arguing and a loop rebuilding costs real tokens, and a system with no limit on how many rounds are reasonable before a card comes back flagged as stuck, instead of quietly retrying forever, is a machine for turning money into stuck cards.
And the access question gets sharper, not smaller, once the person typing the card doesn't have to understand what they're asking for technically. Pointed at my own backlog, a bad ask is just a bad ask, I'd catch it myself. Handed to someone who can't evaluate the technical shape of what they're requesting, the same guardrails I wrote about for KaryoSpace need to sit in front of every council, checking what's being asked before any of them spends a token acting on it.
Not the full set of councils, and not anyone else's board, that's further out than one post can promise. First, the board itself, pointed at my own cards, with a single loop behind it instead of a full council setup, the same narrower version I already build for KaryoSpace day to day. If a week of that goes well, the real test isn't opening it up generally, it's handing one card to someone who isn't technical at all and seeing whether the reply-on-the-card loop works without me translating anything in the middle.
If you've built something like this, or you can see why serving a non-technical ask is harder than I think, I'd genuinely like to hear the argument.
This is a Thought, an idea in progress rather than a finished system. The engineering behind KaryoSpace is at karyospace.com/blog#engineering
Do share your thoughts with me on this blog post: sumanakkisetty@gmail.com
Thanks for reaching out. We'll get back to you shortly.