How many engineers do you need now
AI coding tools raise individual output, but they do not replace the need for engineers who can design systems, review generated code and own what ships. Team size still depends on scope, quality requirements and how reliably your engineers use those tools.
Why the question is hard to answer
Output per engineer has increased, but the relationship between tool adoption and headcount reduction is not linear. A team that uses AI tools well can ship features faster. It can also accumulate technical debt faster if no one is reviewing what the model produces. The net effect on required headcount depends on factors that vary by organisation: codebase complexity, regulatory constraints, the ratio of greenfield to maintenance work, and how experienced the engineers are with AI-assisted workflows.
Estimates vary, but the consensus in engineering leadership discussions is that AI tools compress certain tasks, particularly boilerplate generation, test scaffolding and first-draft documentation, without eliminating the coordination, architecture and judgement work that senior engineers do.
What actually changes
The tasks that shrink fastest are the ones with a clear specification and a narrow output: write a function that does X, generate a migration script, produce a unit test for this method. These are real time savings.
What does not shrink at the same rate:
- Deciding what to build and in what order
- Reviewing AI-generated code for correctness, security and maintainability
- Debugging failures in systems the model did not fully understand
- Holding context across a large codebase over months
- Communicating decisions to stakeholders
This is why an AI-native engineer is not simply a faster version of a junior engineer. The gain is real, but it requires the underlying engineering skill to direct it and catch its mistakes. An engineer who cannot review AI-generated code reliably does not save you headcount; they create a review burden for someone else.
A rough way to think about team size
Rather than starting from a headcount target, start from the work:
- List the distinct streams of work that need to run in parallel.
- Identify which require synchronous collaboration and which are independent.
- Estimate the complexity and maintenance surface of each stream.
- Factor in how much of the work is well-specified enough for AI tools to accelerate meaningfully.
A team of three engineers who use AI tools well can often cover what previously required five, on greenfield product work with a clean codebase. On legacy systems with high compliance requirements, the ratio shifts. The tools help less; the judgement requirement stays high.
Where organisations often get this wrong
The most common mistake is reducing headcount based on speed gains in the early phases of a project, when requirements are clear and the codebase is small, and then finding the team is under-resourced once the system grows and edge cases multiply.
A related mistake is treating all engineers as interchangeable once AI tools are in use. The variance between engineers in how well they direct, constrain and verify model output is significant. Two engineers with similar CVs can produce very different results depending on how they work with these tools. See how to assess an engineer's AI ability for what to look for.
What we test for
Miyagami's vetting process is designed around the skills that matter most when teams are small and AI tools are doing a significant share of the output. The fundamentals assessment checks whether an engineer can debug systematically and prioritise under real pressure, without AI assistance. The AI-native assessment then looks at whether they can verify what a model produces, catching wrong logic or hallucinated APIs before they ship. Both sessions score judgement by risk, which is the skill most likely to prevent an AI-assisted team from moving fast in the wrong direction. Full details at how we vet.
Short answers
Do AI tools mean you need fewer engineers?
Sometimes, on well-specified greenfield work, yes. On complex or legacy systems the tools help less and senior judgement stays essential. Headcount reduction that follows tool adoption without accounting for review and maintenance work tends to create problems later.
What is the minimum viable engineering team size for a product startup?
Estimates vary, but two to three engineers who use AI tools well can cover early product development. You need at least one person who can own architecture and review generated code critically. Below that, the review gap becomes a real risk.
How does Miyagami help with team sizing?
Miyagami places full-time senior engineers rather than project teams, so clients add capacity in single-engineer increments. The five-day shortlist timeline means you can respond to scope changes without committing to a large hire before the requirement is confirmed.
