Two non-engineers rebuilt a 550K-line system using AI agents
Vibe coding gets credit for landing pages and MVPs. It rarely gets credit for production systems serving thousands of users. Alexey Evdokimov and his COO, Sergey Lipchanskiy, just made a case for changing that reputation.
Neither of them is a professional programmer. Together, they rebuilt their company’s largest legacy platform: the public website, CMS, CRM, and the full automation stack for managing training participants and payments. The old system was 550,000 lines of code written manually over ten years. The new one is 450,000 lines. A new major feature now takes half a day instead of ten.
Here is the process that got them there.
The Context Problem (and Why Most People Get It Backwards)
The first mistake Evdokimov made was treating the agent like a pipeline: feed in the legacy code, get out the new code. Clean, linear, predictable. It produced non-shippable features.
The real insight is that the quality of AI-assisted development is largely determined by the diversity of context the agent can access. In this project, that context went well beyond legacy code, documentation, and the database schema:
- The agent had permission to query a local copy of the legacy database directly.
- It could browse the old site’s pages on its own.
- When integrating an unfamiliar domain (like an accounting system), Evdokimov simply asked the agent what additional context sources would help, then chose the ones that made sense.
- Web search was used explicitly when needed. Coding agents do not search the web by default; you have to ask.
That said, pointing the agent at every available source at once backfires. A context window 60% full of exploration noise performs worse than one 15% full of curated signal. One guide to coding agents calls this the dumb zone: too much context causes the agent to drift toward complicated or wrong solutions, or to solve problems that do not apply. The discipline of deciding what goes to the agent and when is what context engineering actually means in practice.
Loops as the Core Quality Mechanism
An AI agent does not get things right on the first try. What it does is let you spin feedback loops fast. Ethan Mollick’s concept of the Jagged Frontier captures this well: an agent will handle a dozen useful details you never asked for and miss an obvious mismatch in the same task.
Evdokimov’s workflow used three types of loops:
- Fully automated short loops: one agent writes code, a second reviews it, the first fixes the findings, and the cycle repeats with no human involved.
- Human-gated loops: the agent pauses at defined checkpoints and waits for input. The human’s questions and reactions correct the direction.
- Long loops spanning months: a human initiates each iteration manually, usually to validate large chunks of functionality at once.
The typical workflow for a single feature followed a consistent pattern. First, the agent derived a feature spec from the legacy docs and code, asking questions throughout. That spec then lived next to the code and stayed in sync through development and maintenance. Implementation followed: the agent explored the codebase and database, refined the spec, wrote code, tested, reviewed, and built. The human’s role was to answer questions and accept or reject decisions.
The old system had almost no documentation beyond stale user stories. The new one has 270,000 lines of markdown. The agent maintains roughly 80% of it as a byproduct of making code changes, so it is not just an outdated record. The specs generated from the legacy code seeded the remaining 15%.
✅ The Third Loop: Revalidating What Already Works
This is the part of the process most people skip, and it is what Evdokimov argues made the difference between a glitchy prototype and a system in production serving real users.
An agent works on one task or goal at a time. The whole product, with all the ways its features have to agree with each other, only exists in your head. So the process needs a loop one level above any single feature: a validation pass that revisits already-built functionality in bulk, usually from a completely different angle each time.
At least a third of the total project time went to these iterations.
The prompts that kick off each iteration fall into two types:
- Directing: You set the angle. Example: Look at how the product table is implemented and make all the other similar lists in the admin panel match it in functionality, display, and link behavior. Or: Check all registration scenarios for potential errors; any error must produce a meaningful message.
- Delegating: You hand the angle to the agent. Example: Investigate possible problems with the metadata of all public pages and propose a validation plan. The word investigate switches a coding agent from depth-first to breadth-first search. Don’t narrow the goal too early. In the metadata example, the agent surfaced social network preview issues and mismatches between og-attributes and page SEO titles that the original prompt never mentioned.
Neither type requires a detailed backlog. The only inputs are your angle of view and your answers to the agent’s questions. From one high-level prompt, the agent runs a series of checks. Then you sort the findings: which become tasks, which can wait, and which do not apply.
What Actually Changes Without Developers
The AI takes on most of the concrete work: coding, code review, writing specifications, and various forms of testing. End-to-end UI testing was handled almost entirely by agents running Playwright. But the cognitive effort saved on reading code and specs has two clear places to go.
First, the agent almost always gets something wrong during implementation. Even with adversarial code review baked into the harness, your own sanity checks of intermediate results are not optional. That means reading the summary of every spec written and every code-level finding the agent flags. You review why a decision was made, what was rejected, how it fits with similar functionality. Skip this, and defects multiply faster than they get fixed.
Second, the agent almost always gets something wrong in solution design. Early in a project it will overcomplicate some areas and miss what actually matters in others. With a legacy rebuild, this risk takes a specific form: the agent may simply adopt the legacy system’s architectural decisions without questioning them. The process must include the agent’s critical assessment of decisions it reverse-engineered from the old code, along with discussions where why is it done this way? is directed at the agent and what do we need this for? is directed at you.
The Checklist for Non-Engineers Building Large Systems
Evdokimov closes with a set of criteria for whether this process applies to your situation. It’s worth quoting directly:
- A large body of context with plenty of code in it. A legacy system works. Several open-source projects that together cover most of the required functionality may work as well.
- A few months between project start and production. This process is not suited for an MVP in a week.
- Technical literacy. You do not need to understand every line the agent writes. But you need to understand how code is organized in general, and the basics of design, testing, and deployment.
On process, the key departures from traditional development are these:
- Give the agent access to a broad range of context beyond the code, and ask it what else could help.
- Make the agent keep documentation in sync with the code throughout the project.
- Reserve at least a third of project time for bulk validation and rework passes.
- Do not force the process for managing human developers onto agentic development. Even where waterfall would be the right call with humans (a legacy rebuild is the textbook example), with AI it is better to run many iterations of unusually large scope.
The outcome here was real: a legacy platform rebuilt by two non-engineers, now in production. The process is documented in detail in Evdokimov’s Substack post covering the numbers and the engineering specifics of the rebuild itself.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
