Quick Answer: In the Agoda AI Developer Report 2026, covering developers in India and six Southeast Asian countries, 53% said they already use AI agents in selected production workflows or broadly across their organisation. Only 38% said their codebase was mostly or fully ready for fully autonomous agents. That fifteen-point gap is the most useful number in the report, because it describes teams running agents against code that cannot safely take them.
The gap, and why it is not a scandal
It would be easy to read 53% against 38% as recklessness. It is not, quite. The report, conducted with Macramé Consulting across Indonesia, Malaysia, Thailand, the Philippines, Singapore, Vietnam and India, also found that organisations are held back by cost, codebase readiness and the need for human approval on higher-risk changes.
In other words, teams are running agents and keeping a human in front of anything that matters. The gap is not people being careless. It is people compensating for an unready codebase with review effort, which works until the volume of generated code outgrows the number of people available to read it.
That is the thing to watch on your own team. The constraint moves. It starts as “can the agent write this” and becomes “can anyone check this fast enough”.
What makes a codebase ready
The survey does not define readiness, so here is a working definition from delivery experience. An agent can operate safely where a careful new joiner could, which means four things are true.
- The tests mean something. If the suite passes on a broken build, an agent has no feedback signal and neither do you. This is the single biggest determinant.
- Boundaries are explicit. Modules with clear interfaces contain the blast radius of a wrong change. A codebase where everything reaches into everything cannot be worked on safely by anyone, machine or otherwise.
- The build is reproducible. If it only compiles on one engineer’s laptop, the agent cannot verify its own work.
- Intent is written down somewhere. Not exhaustive documentation. Enough that the reason a thing is odd is recoverable, because the odd things are where generated code causes damage.
Read that list honestly and you will notice it is the same list that makes a codebase pleasant for humans. Agent readiness is mostly just maintenance debt under a newer name, which we went into in technical debt reduction via AI.
The seniority split is the uncomfortable finding
From the same report: 49% of junior developers said they felt less secure about their career prospects because of AI. Among respondents at CTO or vice president of engineering level, that figure was 17%.
A three-fold difference in anxiety between the people writing code and the people deciding how it gets written is worth sitting with. Both groups are reasoning from where they stand, and both are partly right. The work most exposed to generation is the work juniors have traditionally been given to learn on.
Respondents named system architecture and design, AI literacy and agent orchestration as the skills becoming more important. That is a coherent answer, and it carries an awkward implication: those are not entry-level skills. If the ladder’s bottom rung is the part being automated, somebody has to deliberately rebuild a way up. We looked at the hiring side of this in IT hiring in FY27.
A sequence that works
If you are somewhere in that 53%, or about to be, the order matters more than the tooling.
- Measure your review capacity first. How many pull requests can your team genuinely review per week, not merge. That number is your real throughput ceiling, and agents do not raise it.
- Fix the test suite before expanding agent scope. Every hour here pays back twice, because it serves the humans too.
- Start the agent where mistakes are cheap and visible. Test generation, migrations with good coverage, dependency work. Not the payment path.
- Write the approval rule down. Which changes merge on green, which need a named reviewer. Decide before the volume arrives, not during.
- Give juniors the architecture work early. If the traditional apprenticeship is being automated, the replacement has to be deliberate.
Where this turns into a codebase problem rather than a process one, that is the kind of modernisation our AI-enabled app development practice handles, usually starting with the test suite rather than the agent.
What the number does not tell you
Two caveats worth stating. The survey covers India alongside six Southeast Asian markets and does not break India out separately in the coverage, so treat 53% as a regional figure rather than an Indian one. And it is a developer survey, which measures what developers report rather than what shipped. Self-reported adoption tends to run ahead of production reality.
Even allowing for both, the shape holds: adoption is ahead of readiness, and the gap is being absorbed by human review. That is a workable position this year. It is not a durable one.
Sources
- Agoda AI Developer Report 2026, conducted with Macramé Consulting – adoption, codebase readiness and seniority figures.
- Hotel News Resource, “Developer Survey Finds AI Adoption Growing Faster Than Enterprise Readiness Across Southeast Asia and India”, 29 September 2026 – summary of the report’s findings and country coverage.
Frequently asked questions
How many developers are actually using AI agents in production?
In the Agoda AI Developer Report 2026, 53% of respondents across India and six Southeast Asian markets said they use AI agents in selected production workflows or broadly across their organisation.
What does it mean for a codebase to be ready for AI agents?
In practice: a test suite that fails when something is broken, explicit module boundaries that limit the blast radius of a wrong change, a reproducible build so the agent can verify its own work, and enough written-down intent that unusual decisions are recoverable. Only 38% of surveyed developers said their codebase was mostly or fully ready.
Should we let agents merge code without review?
Not as a default. The survey found human approval is still required for higher-risk deployments across the region. A workable rule is to allow merges on green for low-blast-radius work such as tests and dependency updates, and require a named reviewer everywhere else.
Are junior developer jobs at risk?
49% of junior developers in the survey felt less secure about their prospects, against 17% of CTO and VP of engineering respondents. The specific risk is that the routine work juniors traditionally learn on is the work most exposed to generation, so teams need to hand architecture and review experience to juniors earlier than they used to.
Which skills does the report say are becoming more important?
Respondents named system architecture and design, AI literacy, and agent orchestration.
