Dev tool companies use AI

2 hours ago 1

I joined Kilo Code just a few weeks ago, and as someone working in growth, I'm obsessed with understanding user behavior, so I wanted to understand: “How does our own team use the product we're building?” – Job (Growth Team)

What was an idea in the morning, turned into a GitHub issue before lunch and a shipped feature in the afternoon. The culture at Kilo Code is that everyone ships daily, from engineering to DevRel to growth – Ewa (DevRel Team)

As the newest members of the team we combined our forces and investigated how the team used Kilo Code to build Kilo Code. Enjoy!

For context: Kilo is on a speedrun. In under 5 months, we've hit 220K+ downloads, consistently rank #1 on OpenRouter, and recently crossed 1 trillion monthly tokens.

Like any team building production systems for hundreds of thousands of users, we don't just "vibe code" features and hope for the best. We do have guidelines when it comes to using AI to write code:

Tests and admin panels: Go wild with AI-generated code
User-facing features: Review every single line the AI writes
Core business logic (payments/LLM): Write it yourself, no exceptions
When in doubt: Just write it manually

We see AI as an enabler and not as a scapegoat. It can never be an excuse to ship lower-quality code, and any code written by AI is held to the same standards as our team. In short, when you ship code, that code needs to be high quality, improve the codebase overall, and follow the best practices. We asked some of our engineers to share how they recently used Kilo Code, and distilled some tips and viewpoints for developers and teams looking to code with AI:

Don’t vibe whole features
Think small
Limit context
Iterate, Iterate, Iterate

Brian, a senior engineer, learned this lesson the hard way. Like many developers experimenting with AI agents, he's experienced the frustration of watching working code get randomly refactored, naming conventions destroyed, and bugs introduced.

"I'm wary of going full vibe code mode," Brian explains. "You can give a feature and say 'build this, go vibe it out.' Usually it doesn't pan out that well."

Instead, Brian treats AI like he's pair programming with an eager junior developer:

"I write a ticket for a very eager very junior software engineer, and think about how I would describe the problem to them. I set the project plan in my mind, break it down into pretty small steps and limit the scope."

As Brian puts it:

"I'm still laying out how I would do it... but it's much faster than I can type the stuff myself."

Rather than asking for entire features, request individual functions or components. Here's an example Brian used:

I've added a route to get stripe invoices for an org by id to @/src/app/api/organizations/[id]/invoices/route.ts - can you add a hook in @/src/app/api/organizations/hooks.ts and a widget in @/src/components/organizations/OrganizationDashboard.tsx to show links to the invoice pdfs, as well as the price of each invoice. Sort invoices by most recent.

Notice how this prompt references specific files and asks for a focused addition rather than "build an invoice system." With this prompt he was building a new feature for Kilo Code for Teams that will be released soon. You can sign up to join the waitlist to be first to try it:

Kilo Code for Teams - join the waitlist!

AI agents perform best when working with a constrained context. Too many files can lead to confusion and inconsistent implementations. Brian typically references 3-4 files tops in his workflow.

When building a feature, Brian uses an iterative approach. In the example below, he’s building controls for teams to limit the number of API calls that each teammate is allowed daily.

First, modify the UI:

Then, create the backend route:

Finally, integrate in the frontend:

While new models release frequently, constantly switching disrupts your workflow. Each model has its quirks and strengths. Pick one that works well for you and stick with it, most of the time you ship faster with a consistent workflow and model use. Brian’s favorite is Claude Sonnet 4.

A contrary take coming from our engineer Chris (whom you might know as the engineer, who codes with his voice). His philosophy on writing code is the polar opposite of Brian, so we’re highlighting some of his vibe wisdoms. He likes to break down his process into goal-oriented features.

“ I was working on a personal project over the weekend, and I realized that every time Kilo ran the localhost server, either using Python or Node, it would get stuck because it doesn't know how long the process should take to run.” —Chris

Long running commands such as

npm run devpython3 -m http.server 8080

need to stay active in the background, otherwise they result in a timeout error. To Chris this was a frustrating experience, since the conversation flow with the agent was broken. This is how his new feature idea was born:

“I wonder if there would be a way of teaching Kilo to understand long-running commands and pass in a new parameter so it could just run the command in the background”

He prompted Kilo Code to build the feature. Once the feature was vibe coded Chris was left with the final critical step - integrating it into the existing code base. This is his checklist to ensure that the code is well-tested and no spaghetti code is injected into the main directory:

Validate type safety for all new interfaces
Verify data protocols and message schemas
Review business logic including algorithms and calculations
Assess UI usability and accessibility
Confirm integration compatibility with existing systems
Ensure proper edge case handling
Ensure all tests pass with comprehensive coverage
Validate accessibility compliance and inclusive design
Test cross-platform and cross-browser compatibility
Memory and resource leak testing

According to Chris a feature is ready only when all core functionality requirements are addressed, user flows are intuitive, and system integration maintains existing functionality. For a final pass you can launch a new Kilo session and give it this prompt: