Insights from 30+ startup CTOs on how AI is reshaping the engineering function
We spoke to more than 30 CTOs across the Indian startup ecosystem about how AI is playing out inside engineering teams. The unanimous take is that the engineering role is transitioning to a different set of skills focused on deciding what is worth building, giving the model enough context to act, and knowing whether the result is good enough to ship.
The engineer’s role is expanding from producing code to turning an ambiguous business problem into a well-scoped workflow, directing AI through the build process, and taking responsibility for the outcome. This is why startup CTOs now place greater weight on product thinking, system design, and judgment when evaluating potential hires.
The advantage is also shifting away from model access alone. It is accruing to teams that have built the surrounding system containing codebases with clear boundaries, contextual documentation, budgets for experimentation, and review practices that keep quality and ownership intact. These are the conditions that determine whether AI output can compound into useful engineering capacity or create more work to manage.
This shift is clearly visible in agents moving into production. Startup tech teams are actively delegating meaningful workflows to agents at different levels of autonomy. The next challenge is designing the judgment, observability, and safeguards that let these agents take on more responsibility while keeping people accountable for the decisions that matter.
This report looks at how engineering leaders in the Indian startup ecosystem are navigating the transition to decide where AI spend is going, how teams are measuring ROI, which skills and structures are changing, and what it takes to run agents reliably in production.
State of AI in Engineering: Inside Indian Startup Tech Teams
Section 1 of 3
Section 2 of 3
Section 3 of 3
Section 1 of 3
Section 2 of 3
Section 3 of 3
State of AI in Engineering:
Inside Indian Startup Tech Teams
| Answer | Share |
|---|---|
| Under $5k | 41% |
| $5k–$20k | 27% |
| $20k–$50k | 18% |
| $50k–$100k | 14% |
| Over $100k | 0% |
| We are not tracking this yet | 0% |
The AI budget for most teams remains below $20K per month. 68% of CTOs want to tie AI investments to clear, near-term value and actively manage the cost of adoption. The 32% spending over $20K on AI points to a different stage where teams have moved beyond experimentation and found use cases substantial enough to scale across functions.
This divide is, therefore, about conviction in use cases and operating maturity. It comes down to which startups have identified repeatable value, and can scale it while keeping the economics under control.
Under $50/dev
$50–$150/dev
$150–$500/dev
| Answer | Share |
|---|---|
| Under $50/dev | 41% |
| $150–$500/dev | 36% |
| $50–$150/dev | 23% |
| Over $500/dev | 0% |
| We have no idea | 0% |
Spend per developer serves as a useful signal of AI’s economic footprint among engineering teams in Indian startups. AI spend per developer is polarized with 41% of CTOs spending under $50 per developer each month, while 36% spend $150–$500. This data suggests teams tend to settle into one of two models:
Crucially, low spend does not always equal low adoption. It can reflect smaller models, better workflow design, negotiated tooling costs, or teams using AI selectively where it has the highest return.
| Answer | Share |
|---|---|
| Centralized budget, I control all of it | 61% |
| No formal governance in place yet | 17% |
| Developer/team member level budget with approval for extra usage | 13% |
| Team level budgets, each team decides | 4% |
| Allocated per project | 4% |
61% of CTOs at Indian startups retain control of AI spending. As teams explore different tools and workflows, this central ownership can be one way for leaders to build a shared picture of what is useful, where needs overlap, and which investments deserve continued support.
This visibility has benefits beyond cost control as well. Experimentation needs room for iteration, including attempts that do not immediately pay off. A centrally managed budget gives CTOs a way to support that learning curve within an overall spending envelope, without expecting every team to establish a dedicated business case from the outset. The opportunity is to make exploration sustainable and give engineers room to discover what works, then use those lessons to optimize for costs.
When we gave engineers real headroom instead of a shared, rationed team quota, they pushed the tools harder, tried new workflows, and found capabilities they'd never have discovered otherwise. The second we moved everyone to a tighter team plan to control cost, that exploration just stopped and people went back to the same three prompts they already trusted.
| Answer | Share |
|---|---|
| Coding copilots (Cursor, Claude Code or Codex) | 77% |
| Inference and API calls to OpenAI, Anthropic, Gemini etc. | 59% |
| Agentic workflow tools like Claude Cowork, n8n or Zapier AI | 27% |
| Internal model hosting and GPU infrastructure | 14% |
| AI-native SaaS tools like Databricks, Figma, Granola, etc | 9% |
| Vibe coding tools (Replit, Emergent, Lovable, V0, etc) | 5% |
| Spread roughly across all of the above | 0% |
Coding copilots and inference/API calls are the two most frequently cited AI cost drivers. The spending emphasis is on bringing AI capabilities into the engineering work teams already do in their codebases. Copilots and direct model access give teams considerable scope to decide where and how AI fits into their work. That explains why far fewer CTOs identify AI-native SaaS tools (9%) or vibe-coding platforms (5%) as major costs.
This is where context and documentation also become part of the economics. The more structured the context you give models, the fewer tokens you waste on wrong output, duplicated code, and rework. That turns documentation into a budget lever rather than busywork.
But most documentation covers the what behind your codebase instead of the why. A model reading your codebase cannot work out the decisions you already considered and rejected. So it will confidently propose an approach the team ruled out two years ago, and you end up paying to generate it, review it, and reject it again. Documenting the why gives models the essential context behind your decisions, like why you picked one caching approach over another, why you chose a particular database, when to trip a circuit breaker, and more.
Tactical advice
Rather than flatten a large codebase into one giant context, which is both ineffective and expensive, one CTO recommended building documentation in layers:
Legacy systems are the harder case because the logic lives in senior engineers' heads. So they rely on AI to interview these engineers and document their responses explaining the architectural decisions and edge cases.
| Answer | Share |
|---|---|
| Cycle time and PR velocity | 43% |
| Volume of code or features shipped | 43% |
| Business outcomes like revenue or support deflection | 30% |
| Engineers self-reporting productivity gains | 26% |
| We are not measuring it yet | 22% |
Cycle time and volume shipped are both throughput metrics engineering has always owned. However, 30% of teams are now measuring productivity through business outcomes like revenue or support deflection. When execution was the bottleneck, shipping volume was a fair proxy for impact because building was the hard part. AI has moved the bottleneck to make shipping more the baseline expectation. That explains why the metrics for engineering are moving toward business outcomes.
The challenge here is the fairly complex process of measuring what's moving the needle for the business. Cost was instrumented on day one, but attributing ROI is still a big unknown without a clean framework, which is why 22% are not measuring impact yet. Until that exists, a few directional signals are doing the work:
mean of 5
| Answer | Share |
|---|---|
| 2 | 10% |
| 3 | 35% |
| 4 | 30% |
| 5 | 25% |
Startup CTOs are broadly confident that AI is creating value. A concrete framework for tracking ROI, however, is still emerging because AI work is difficult to attribute cleanly. That’s because a single coding-agent session can move between planning, implementation, testing, and triage, with the same tokens supporting several steps in a workflow.
The CTOs we spoke to described a two-level approach to measuring ROI:
The clear picture is that confidence comes from seeing both sides: AI spend is understood and under control, while the work it enables is moving in the right direction.
State of AI in Engineering:
Inside Indian Startup Tech Teams
Documentation is now mostly AI generated
Code review takes longer now because AI generates more to review
Sprint planning has changed, we scope differently when AI accelerates execution
Code review is faster because AI pre-reviews before humans see it
Standups feel less relevant, work moves faster than daily check-ins
Rituals have not changed much, just the output volume has
| Answer | Share |
|---|---|
| Documentation is now mostly AI generated | 57% |
| Code review takes longer now because AI generates more to review | 46% |
| Sprint planning has changed, we scope differently when AI accelerates execution | 43% |
| Code review is faster because AI pre-reviews before humans see it | 32% |
| Standups feel less relevant, work moves faster than daily check-ins | 18% |
| Rituals have not changed much, just the output volume has | 18% |
Our State of AI Adoption in Indian Startups research concluded that 72% of engineering teams have scaled AI use for documentation to total adoption, an insight that many CTOs reaffirmed.
However, the latest data indicates how AI cuts both ways when it comes to code review where 46% of CTOs believe reviewing AI-generated code takes longer and 32% believe AI speeds up the review process. There's a visible divide in how teams use AI for reviewing code, depending on where they set the quality bar and how much they lean on AI within this process.
Our data also captures a drastic change in the pace of work for the engineering function, evident by the fact that 43% of CTOs have reframed their approach to scoping and sprint planning. As AI compresses the time it takes to turn a defined task into working code, it’s clear that teams can no longer plan sprints around the same assumptions about capacity and execution time.
| Answer | Share |
|---|---|
| Maintaining code quality and long-term system ownership | 57% |
| Getting engineers to use AI tools effectively | 43% |
| Right-sizing the team as productivity per engineer grows | 25% |
| Spreading AI adoption beyond the engineering team | 25% |
| Preserving engineering culture as the way of working changes | 25% |
Engineering teams can now ship more code than ever before. But while AI can produce useful output quickly, getting there still depends on the engineer’s ability to provide context, judge the result, and integrate it into a codebase that other people can maintain. For 57% of startup CTOs, the concern is developing shared ways of working that help AI-generated output become part of the team’s collective knowledge.
But an even harder problem is AI adoption itself. 43% of CTOs believe getting engineers to use AI tools effectively is one of the biggest organizational challenges. Our State of AI Adoption Survey points to a few reasons why. In the current state of the models, engineers still need to provide substantial context, frame problems carefully, and review output that can vary in quality. Teams are still developing these practices, which makes effective adoption harder to standardize.
Tactical advice
A K-shaped org is the structural answer for maintaining code quality and ownership:
The hardest work of complex debugging, platform design, and production reliability concentrates further among the strongest engineers, while routine building spreads to everyone else. Quality holds because the guardrails are built once by the people best equipped to build them, and adoption spreads because everyone else works inside those guardrails by default.
mean of 5
| Answer | Share |
|---|---|
| 3 | 50% |
| 4 | 35% |
| 5 | 15% |
| Answer | Share |
|---|---|
| Yes, we have changed our hiring bar and criteria | 34% |
| Yes, we have meaningfully restructured the team | 28% |
| Small tweaks but nothing structural yet | 28% |
| We are planning to change but haven't yet | 10% |
| No change so far | 0% |
CTOs are divided in their approach to structuring the tech team in response to AI. 28% of them are making structural changes to adapt the way they work with AI (by embracing one-engineer pods), and another 28% are only making minor adjustments. But a third of startup CTOs have changed the hiring bar completely to make their teams AI-native right from the hiring door. This shows up most clearly in the skills they hire for and how they evaluate candidates today.
Tactical advice
The concept of a one-engineer pod relies on a single engineer to own an entire business metric and work with product, design, and business stakeholders to deliver on the planned outcomes. AI makes this model more viable by taking on more of the execution work, allowing a single engineer to cover more of the build cycle.
Instead of writing code from scratch, the engineer architects the solution, translates the business problem into a plan, hunts for edge cases, and reviews the output through plan–review–code–test loops. The result is a shift in the engineer's role from producing code to directing and validating the work needed to move a business metric.
82%: Stronger product thinking in engineers
46%: Prompt engineering and AI system design
29%: Ability to evaluate and test AI outputs
7%: The bar has not really changed
0%: ML and model fine-tuning
| Answer | Share |
|---|---|
| Stronger product thinking in engineers | 82% |
| Prompt engineering and AI system design | 46% |
| Ability to evaluate and test AI outputs | 29% |
| The bar has not really changed | 7% |
| ML and model fine-tuning | 0% |
Product thinking has now become the most crucial skill for engineering hires. CTOs want to see how well an engineer understands the product and thinks from the user's lens. When AI can build almost anything asked of it, the scarce skill is knowing what problems to solve and how.
Beyond product thinking, a candidate's ability to navigate AI models and extract usable output is another decisive skill. Two engineers with the same tools can produce very different results depending on how they frame the problem.
Ultimately, CTOs in Indian startups want adaptability and judgment to steer AI well. Many of them now test candidates on a real problem from their own backlog, asking them to solve it in an AI harness.
More emphasis on system design and architecture thinking
Candidates are expected to code with AI tools, not without them
Evaluating how well they scope and break down problems for AI
We now test for agentic system design specifically
Honestly, our process has not changed much yet
Stronger focus on context engineering and prompt quality
Moving towards automated or AI-assisted interview stages
| Answer | Share |
|---|---|
| More emphasis on system design and architecture thinking | 79% |
| Candidates are expected to code with AI tools, not without them | 64% |
| Evaluating how well they scope and break down problems for AI | 36% |
| We now test for agentic system design specifically | 18% |
| Honestly, our process has not changed much yet | 18% |
| Stronger focus on context engineering and prompt quality | 11% |
| Moving towards automated or AI-assisted interview stages | 4% |
The skillset has evolved and so have the evaluation parameters. CTOs overwhelmingly want to assess what candidates can achieve with AI tools, right from scoping and planning to building and evaluating. System design and architecture thinking are the most important evaluation criteria, pointing to a stark break from the decade-old practice of asking candidates to write algorithms from memory.
We hand a candidate a real, unsolved problem straight from our own backlog, give them five minutes to set context, and just watch. Do they ask the right clarifying questions before touching the AI harness, or do they start prompting blind? That's where you actually see judgment to understand whether they can scope a fuzzy problem into something an agent can execute, and whether they know when the output is actually right instead of just plausible.
14%say it is too early to tell.
| Answer | Share |
|---|---|
| Flat, AI absorbed what would have been new hires | 52% |
| Growing, AI keeps creating more things to build | 17% |
| Shrinking, AI is replacing headcount we'd otherwise have | 17% |
| Too early to tell | 14% |
There's an equal split between engineering teams that are growing and shrinking in the wake of AI. But 52% of CTOs say AI absorbed hires they would otherwise have made. This reinforces the findings from our State of AI Adoption research about the engineering headcount changing in shape where generalist roles are being reduced in favor of specialists while hiring for AI-specific skills increase in demand.
Hiring fewer juniors because AI fills that gap
Redefining what juniors do rather than cutting them
Actually hiring more juniors to leverage AI tools
No change to junior hiring so far
| Answer | Share |
|---|---|
| Hiring fewer juniors because AI fills that gap | 35% |
| Redefining what juniors do rather than cutting them | 31% |
| Actually hiring more juniors to leverage AI tools | 23% |
| No change to junior hiring so far | 12% |
Junior engineering roles are evolving, but there is no clear consensus on what they should look like. 35% of CTOs are hiring for fewer junior roles, 31% are redefining the role, and 23% are hiring more. The spread suggests that teams are testing different ways to combine AI with early-career engineering work.
AI can take on some of the implementation tasks through which juniors traditionally built experience. At the same time, it can give them faster feedback and access to guidance that helps them work across a broader part of the development process. The open question is how juniors will build the judgment that comes from making decisions, debugging failures, and seeing how software behaves in practice.
For startups, the emerging junior role may place less emphasis on producing routine code and more on learning to frame problems, evaluate AI output, understand the product, and take ownership of small but complete pieces of work.
State of AI in Engineering:
Inside Indian Startup Tech Teams
81% agents are in production with a mix of human oversight and running autonomously
Agents are in production but with human oversight
Running agents fully unsupervised in production
Piloting or testing in staging environments
Still exploring
| Answer | Share |
|---|---|
| Agents are in production but with human oversight | 46% |
| Running agents fully unsupervised in production | 35% |
| Piloting or testing in staging environments | 12% |
| Still exploring | 8% |
AI agents are moving beyond the traditional human-in-the-loop model. While 46% of CTOs are running agents with human oversight, over a third (35%) say their agents are operating fully unsupervised in production.
This shows a meaningful shift in how teams are thinking about delegation. Agents are no longer being used only to prepare work for a person to approve. For a growing share of startup tech teams, agents can now own defined workflows from start to finish.
| Answer | Share |
|---|---|
| Hallucinations / edge cases and wrong outputs reaching users | 56% |
| Model behavior drifting over time | 30% |
| Inconsistent and non-deterministic behavior | 30% |
| Failures when orchestrating multiple agents | 26% |
| Unpredictable latency and cost spikes | 22% |
For CTOs, agent reliability is primarily a question of what the user experiences. 56% cite hallucinations, edge cases, and wrong outputs reaching users as their biggest challenge, well ahead of model drift, nondeterminism, and orchestration failures. The concern is whether an agent produces a correct, consistent, and trustworthy result. Reliability is therefore becoming a product quality question as much as a systems question.
You can't prompt your way out of hallucination. You can tell the model not to make things up, add a guardrail phrase to the system prompt, and so. But it's still a probabilistic system. The only thing that actually holds is a runtime boundary that physically stops the agent from touching data or systems it shouldn't, combined with a golden dataset you re-run on every deployment so you catch the model drifting before a customer does.
70%: Humans are in the loop at key decision points
15%: Humans review after (sampling, error cases)
15%: Still figuring out the right balance
0%: Fully autonomous with no human checkpoints
| Answer | Share |
|---|---|
| Humans are in the loop at key decision points | 70% |
| Humans review after (sampling, error cases) | 15% |
| Still figuring out the right balance | 15% |
| Fully autonomous with no human checkpoints | 0% |
Tech teams are designing autonomy around the consequences of a decision. Agents can move independently through defined parts of a workflow, while people remain responsible for decisions that require judgment, accountability, or a higher standard of reliability. In that sense, an agent can be unsupervised during execution while still operating within a human-designed system of controls.
Not formally addressed yet
Controls on PII and sensitive data access
Audit trails for all agent actions
Protection against prompt injection attacks
Regulatory guardrails for RBI, IRDAI or similar
| Answer | Share |
|---|---|
| Not formally addressed yet | 42% |
| Controls on PII and sensitive data access | 38% |
| Audit trails for all agent actions | 38% |
| Protection against prompt injection attacks | 19% |
| Regulatory guardrails for RBI, IRDAI or similar | 15% |
While eight in ten CTOs run agents in production, 42% are yet to establish a formal security posture for these agents. Their current setup borrows from the pre-AI compliance playbook, like PII gating to restrict what an agent can read and audit trails to document agent actions.
Teams are building guardrails around the agent’s permissions and visibility first to define what it can access, what it can do, and how its actions can be reviewed. As agents take on more consequential work, security will also need to account for how they interpret instructions, respond to adversarial inputs, and operate within regulatory boundaries.
| Answer | Share |
|---|---|
| Full visibility: logs, traces and evals in place | 42% |
| Partial monitoring but no evaluation framework yet | 42% |
| Basic logging only | 12% |
| We are largely flying blind | 4% |
Most teams have some visibility into their AI systems, but fewer have a complete way to evaluate what they see. Our data makes it clear that observability is developing in layers. Nearly half the CTOs (42%) have established systems for complete visibility over agents in production. The other half (54%) is in the process of putting these frameworks in place for monitoring changes in their agent's behavior.
Teams are first making agent behavior visible, then building the ability to assess whether that behavior is correct, consistent, and changing over time. As model drift and nondeterminism become more prominent reliability concerns, understanding whether an agent should have taken a specific action is the deeper challenge.
| Answer | Share |
|---|---|
| Built new tooling and API layers from scratch | 36% |
| Minimal changes, it was already modular | 32% |
| Still working on it | 16% |
| Significant refactoring of legacy code | 8% |
| Haven't started yet | 8% |
36% of CTOs have built new tooling and API layers from scratch for AI agents. But a third of these engineering teams achieved agent-readiness quickly because they had already done the architecture work by building clean module boundaries and real API layers.
Access control is a critical factor for running agents in production. Agents combine autonomy with direct access to data. But you do not have to rebuild an older system. A common approach is to have the agent build a small MCP layer over the existing ERP and APIs, with guardrails around it.