Inside Kilo Speed: How One Engineer Shipped an MVP in His First Week
We're pulling the curtain back on how Kilo engineers ship so fast.
In the traditional engineering model, velocity is often sacrificed at the altar of coordination. Even a simple feature can spend weeks in an asynchronous feedback loop of internal posts and cross-departmental reviews before a single line of code is written. The process is designed for consensus, not speed.
But when software engineer Evgeny Shurakov joined Kilo after a tenure at Automattic, he traded slow-moving consensus for Kilo Speed. By moving from a single-threaded developer mindset to an “Architect Mode”, Evgeny shipped a production-ready MVP in his first week.
Here’s how Evgeny manages that transition to ship at a pace that traditional structures simply can’t match.
From Application to MVP in the Space of Two Weeks
Evgeny’s transition to Kilo Speed was a trial by fire. Following a layoff at Automattic, he applied for Kilo on a weekend, was hired by Wednesday, and started the following Monday—the same day as his first commit. His first demo for Kilo Deploy (a Vercel-like deployment tool for Next.js apps) was ready by Tuesday, with a working MVP by the end of the week.
At many companies, a project of that scale would have spent the first week in discovery. Evgeny spent it getting ready to ship.
“The very first version was super basic,” Evgeny explains. “We didn’t have a GitHub integration yet, so my first iteration was: you paste the Git URL with a token.” This aggressive scoping down is critical to moving quickly. “You come up with a solution that works now, and you can extend it later. You cut the scope to the absolute minimum to get it to a usable state.”
Shifting to “Architect Mode”
One of the most significant changes in Evgeny’s workflow is the transition from writing code to guiding it. He views his role now as more of an architect than a programmer.
“I don’t write as much code now, but I plan things and help AI to write what I have in mind,” Evgeny says. “My job has transitioned more to an ‘Architect Mode’. I plan, I review, and I guide.”
Evgeny’s process can be broken down into three steps:
Information aggregation: He uses Perplexity to search documentation and aggregate technical requirements.
Architectural drafting: He switches to Kilo’s Architect Mode to draft a plan. “I iterate on the draft until it makes sense. If things are wrong or unspecified, things will go wrong once you send the plan to the AI. You have to figure out the plan beforehand.”
Orchestrated execution: Once the plan is solid, he hands it off to Orchestrator Mode to execute the tasks sequentially.
Parallelism: Moving Beyond the Single Thread
In a legacy environment, developers are often “single-threaded”. They work on one branch, wait for a build, or wait for a review. Evgeny uses AI agents to work in parallel. While an Orchestrator session is running in the background (which can take 10–20 minutes to execute a complex plan), he doesn’t sit idle.
“You can easily use that time to do something else. If you have another feature, you start planning it. If you have smaller fixes, you kick off a session with Kilo for Slack,” he says. By the time he finishes a human-centric task, the AI has already generated a pull request for a separate feature.
Automating the Boring Middle
Evgeny has offloaded some of the repetitive administrative tasks—the “connective tissue” of engineering—to automation and agents:
PR creation: “I really don’t like creating pull requests or coming up with commit messages. I have a workflow that checks my changes and creates the PR automatically.”
Acting on feedback: Instead of manually fixing linting errors or making small requested changes, he asks the agent to “Check all comments in this PR and fix those.”
The Multi-Layered Review Process
Shipping fast doesn’t have to mean shipping broken code. Evgeny’s layered code review process is a safety net to catch issues without sacrificing velocity:
Local pass: He runs a Kilo reviewer locally in Code Mode to spot potential logic flaws before committing.
Automated pass: Kilo’s Code Reviews feature scans every PR automatically.
Human pass: A final review from a teammate is mandatory. “Human input is still prioritized for design decisions to ensure we are consistent with existing patterns,” Evgeny notes.
Don’t Be Afraid to Break Things
The core of Kilo Speed is a cultural willingness to trade “perfect” for “now”.
“Some companies take half a year to release a feature because they want to do it right from the first attempt. But you don’t know what’s right until you listen to the users,” Evgeny argues. “We deploy our VS Code extension once or twice a day. Don’t be afraid to break things—just set up alerts so you can fix them immediately.”
Be More Architect
To adopt Evgeny’s workflow, you don’t have to be at a startup that’s gone all in on AI. A lot of the shift is mental:
Stop coding, start planning: Spend 80% of your energy on the discovery document and plan.
Unblock your future self: Brainstorm with humans (or AI) via Slack messages before you reach the implementation phase.
Parallelize your workload: Identify the “one-shot” tasks (boilerplate, tests, PR descriptions) and let a Cloud Agent handle them while you solve the core logic.
Working this way, Evgeny is able to focus on high-value tasks knowing that with a good model, AI can get to 90% of what he needs. “Some things are running in the background while I’m working on other tasks in the foreground,” he explains. “I feel happier because this means I can push more fixes and add more features and improvements for our users.”
Check out part one of this series:
