How Norepo Was Built: From the 'Up Arrow' in a Chat to a Fleet of Agents
Norepo was born not from a neat idea but from dumb routine: press up arrow, Enter, 'keep working' — and repeat. The co-creator's story of how a tool for their own projects became a platform.
Operon Editorial, Team ·
Norepo was born not from a neat idea, and not even from "pain" in the usual sense. It was born from dumb routine. Claude already wrote code decently, but working with it turned into an endless loop: press the up arrow, Enter, send "keep working" — and around again. Structure was missing, and there was no way to explain the whole project's context to the AI. Out of that irritation grew the tool now called Operon. We spoke with its co-creator, Sasha Shinov, about how it really happened — no gloss.
Not "move to AI" but be ready for it
The first thought everything started from was this: modern development shouldn't "move to AI" but be ready to. "We call it AI-friendly projects — when the code is structured from the start so the AI can fully grasp the context," Shinov explains.
Next came the first version of Operon. The test was telling: on it, they rebuilt a large product from scratch in a week — and threw away the previous version with its pile of legacy. After that the team started doing everything through Operon, and the thought quickly arose that the tool was useful far beyond one team.
Two ideas, one product
Norepo grew from two different ideas. One was Kirill's: today you can and should make an AI version of every specialist — a manager, an SEO specialist, a tester, a developer. The other was Sasha's, narrower and more concrete: a tool that ships current projects faster and cheaper and erases the line between business and development. A direct channel between an idea and its realization.
The first version was almost homemade — a plain communication channel between Claude Code and Kirill through a Telegram chat. It ran on a laptop, not around the clock, far from ideal. Step by step it grew and eventually became a system that does what the entrepreneur wants — without developers and without installing Claude Code on the user's device.
That's when the roles settled. Kirill took on the product: wrote specs, proposed features, became product owner. Sasha solved technical problems and endlessly rewrote prompts. The pricing and economics they worked out together — and, in Shinov's words, still do. "Today there are no competitive products made once, frozen and stopped, to then only be sold," he says.
Why a board, not a builder
When the question of form arose, the temptation to make a "site constructor" was there, but the team deliberately went another way. "This is how serious, living teams work," says Shinov. "Operon does what companies sometimes pour millions of dollars a year into and thousands of people work on."
The key idea wasn't to make yet another tool for the developer — there are plenty. It was to give the entrepreneur a channel: take their expertise and idea, provide infrastructure and compute, and turn it into a working product without hiring and without trying to learn programming. "You just talk to Operon and get a result — as if you were talking to a manager who figures out who on the team does what," Shinov describes. That's why agents work through branches and pull requests with mandatory review: not a pose, but how modern teams are built — with Operon or without. What an agent that takes a task and drives it to a PR even is, we covered separately: what is an AI dev agent.
Claude as the brains, but not as a lock
Inside Operon sits Claude — a deliberate choice, but not a lifelong tie. "In fact Claude is just the brains of our development; a big system is built around it, and it can be swapped for other solutions if needed. But today nobody writes code better than Anthropic's models," Shinov says, noting that this is his assessment.
From this follows the container architecture: you can't keep everything in one container on one subscription — users must be isolated from each other. So the "brains" are shared, but everyone has their own workspace.
What had to be rebuilt
The first version of the product was arranged differently from today: a large spec was chopped by a planner into stages and executed in one long session. "That only suited the start, and not even ideally," Shinov recalls. "We fairly quickly moved to atomic tasks and planning via the board."
The most telling pivot is the onboarding story. At first they wanted to let users install the task-solver on their own device and built a complex, detailed onboarding. Practice killed the idea: for a non-programmer, installation took a couple of hours, and even then under supervision. In the end they dropped the approach entirely — now everything runs fully on Operon's infrastructure. "There were incredibly many mistakes, every day, impossible to remember them all," Shinov says honestly. "We just used the tool and keep using it; it changes daily."
The hardest part — the reviewer
Asked about the hardest technical task, Shinov answers without drama: the tester-reviewer. "It's still not fully solved — largely because I really want to make it genuinely good."
Here he recalls his programming teacher: "You need to be twice as smart to find all the bugs in code and fix them as to just write that code — so never write code at the limit of your intelligence." There was a grain of truth in the joke, and on the reviewer it shows in full. Why acceptance becomes the main bottleneck of agent-driven development we covered separately: a review checklist for an AI agent's work.
Iteration and an honest storm
There's no glossy "thought it up and it worked" story here. "Almost nothing worked the first time — everything came out on the second or tenth try," Shinov says. "And what was good yesterday is bad today. Most often the prompts for setting and solving tasks get rewritten."
Asked whether there was a moment it seemed it wouldn't fly, he answers honestly: "I'm on waves with this product — my opinion on that literally storms." That's perhaps the truest description of how a living product gets made.
The moment they said "others will use this"
The point after which Operon stopped being an internal tool turned out to be prosaic. "When we started connecting the first test users, we had to find and fix a mass of things," Shinov says. "And 'others will use this' we said exactly when we bolted on the payment system."
A distinct feature is dogfooding: the team builds Operon with Operon itself. "Being the developer of a tool you use is very convenient: you just take it and fix it if needed. The most dangerous thing here is forgetting that other users don't have that option." The tempo changed too: after Claude Code entered the work, there weren't fewer tasks but an order of magnitude more. "The hardest thing is keeping it all in focus and doing everything in parallel at once."
What's ahead
Shinov states the plans soberly and to the point: finish the tester-reviewer and gradually cover all the roles, "so Operon needs no one but the product's author." The horizon, though, isn't fixed hard — it will be defined by users' experience and requests. "We'll rely on the data." What a project's start on the platform looks like from the user's side is in the guide how to start a project in Norepo.
Bottom line
- Norepo grew not from a neat idea but from the routine of working with AI and the wish to give it structure.
- Two ideas assembled the product — "an AI version of every specialist" and "a direct channel from idea to realization."
- The form chosen was not a builder's but a living team's: a board, agents, branches, pull requests, review.
- The hardest part is the reviewer; the most honest part is that the product changes daily and is made through iteration.
Start free: 2 tasks a week, no card — norepo.ai. See how it works for a founder on the founders page.