For the last two decades, the startup world ran on one assumption: speed comes from headcount. Raise a round, hire engineers, hire more engineers, ship faster. The founders who won were usually the ones who could hire the best people fastest and organize them well.
That assumption is now breaking down in real time — and almost nobody has fully adjusted to it yet.
“Most founders I talk to still think ‘AI development’ means chatbots or automation pipelines bolted onto an existing product,” says Sergii Kravtsov, CEO and co-founder of ConnectiveOne and co-founder of Evergreen IT Development, a Kyiv-based AI-first software studio. “That’s not the shift. The shift is that a two- or three-person founding team can now build, test and ship what used to require a fifteen-person engineering org. The constraint used to be people. Now the constraint is whether you know how to organize AI as a system, not as a tool.”
Kravtsov has spent more than a decade on the other side of this problem, building Evergreen into a studio with over 400 delivered projects and products, some of which became category leaders in their niches, before founding ConnectiveOne, an AI-powered omnichannel communication platform now used by market leaders and serving millions of end users. He’s also an alumnus of Y Combinator’s Startup School (advisor track), 1991 Accelerator, and Challenger AI 3.0 — which means he’s watched this shift from both the operator side and the accelerator-cohort side, across hundreds of early-stage teams.
Why “we added AI” isn’t the same as being AI-native
The first thing Kravtsov pushes back on is the idea that installing Copilot or Claude Code across a dev team counts as an AI strategy.
“We tried that too, like everyone else,” he says. “You plug tools into your existing process and get maybe 10–20% faster. That’s roughly where most teams — startups included — are still stuck today. The real gain doesn’t come from adding AI to a process. It comes from rebuilding the process around it.”
For startups specifically, this distinction is existential rather than academic. A funded company with fifteen engineers can absorb a 10–20% productivity gain and barely notice it on the roadmap. A two-person pre-seed team cannot afford to think in those terms at all — for them, the entire question is whether AI changes what’s buildable with the team they actually have, not how much faster their existing team goes.
“An AI-native startup isn’t a company that uses AI tools,” Kravtsov says. “It’s a company where the founding team designed the product, the delivery pipeline and the org chart around the assumption that a small number of people can supervise a much larger amount of AI-driven output. That assumption changes what kind of company you build, who you hire first, and how much capital you actually need before you can prove something works.”
The pattern he sees across founders: adoption without management
Working across dozens of founding teams through Evergreen and the accelerator ecosystem, Kravtsov has landed on a distinction he now repeats in almost every conversation: the difference between AI adoption and AI management.
“AI adoption is when your team has the tools. Subscriptions are bought, everyone has access, some people are excited, some are skeptical. That’s it — that’s where most startups stop,” he explains. “AI management is when those tools operate as a controlled, observable, auditable system inside your actual development lifecycle. You can see which agent did what, at what cost, with what quality outcome, before it ever reaches a human for review.”
This is where a lot of startup AI enthusiasm quietly stalls. Founders roll out tools across the team, see an early productivity bump, then watch it plateau — because nobody built the structure underneath it. Prompts get copy-pasted into Slack. Context resets every session. Nobody can say what a given feature actually cost in tokens, let alone whether the code that came out of it meets the bar the team would hold a human engineer to.
“The mistake isn’t technical, it’s organizational,” Kravtsov says. “Teams run several agents at once without stable rules or quality gates, get chaotic output, and conclude ‘agents aren’t ready.’ Usually the model was fine. The process around it wasn’t.”
What this means for how startups should actually be built now
Kravtsov’s advice to early-stage founders isn’t to hire an AI team or launch a six-month “AI transformation” — a phrase he’s openly critical of. It’s closer to an engineering discipline than a strategic pivot.
Start with one narrow, well-understood process — code review, documentation generation, QA — and give it a single, role-scoped AI agent with clear boundaries, rather than turning a general-purpose assistant loose on everything. Add automated quality gates before anything reaches production, so speed doesn’t come at the cost of a human simply reviewing less carefully because there’s more to review. Only once those two things are stable does it make sense to run multiple agents in parallel — what Kravtsov calls an “agent swarm” — with one person accountable for the whole chain, not a diffuse “AI team.”
“The founders who get this right end up with a completely different kind of leverage,” he says. “Their engineers stop being just the people who write code line by line, and become the people who design the system, define what each agent is allowed to touch, and decide what has to stay strictly human — architecture calls, ambiguous judgment, anything where being wrong is expensive. That’s a more senior job than the one it replaces, not a smaller one.”
Why this matters beyond engineering
Kravtsov is careful to note that the shift isn’t confined to software development. Through his work advising founders and through organizational turnarounds he’s led at insurance and SaaS companies, he’s increasingly focused on what he calls AI Operations — applying the same logic to HR, finance, sales, support and internal management processes, not just to writing code.
“The hidden problem most companies have right now is that they’re still living in the old model — everything held together by people, manual handoffs, endless status updates, waiting on the one person who has context,” he says. “AI doesn’t just compensate for a shortage of developers. It compensates for a shortage of analysts, ops people, support staff — anyone doing knowledge work. But you only get that if you’re willing to ask what the process should look like in the new reality, not just where to bolt AI onto the old one.”
For a startup ecosystem built on scarcity — of capital, of senior engineers, of time before runway runs out — that reframing matters more than almost any other trend currently being discussed on demo day stages. The founders who treat AI as a system to be designed, rather than a tool to be adopted, aren’t just moving faster. They’re operating with a fundamentally different cost structure than the founders who aren’t.
“We’re still early in figuring out what this is actually good for,” Kravtsov says. “But the teams asking the right question right now — not ‘which model should we use,’ but ‘what should our whole company look like if AI is part of the system from day one’ — are the ones who’ll look, in two years, like they had an unfair advantage. They didn’t. They just started rebuilding earlier.”
Sergii Kravtsov is CEO and co-founder of ConnectiveOne and co-founder of Evergreen IT Development, an AI-first IT services company based in Kyiv. He writes and speaks regularly on AI SDLC and AI-native product development.
