- Kamalakannan Nandagopal of Postman said coding agents shine inside one project but lose their footing across many connected services.
- His team built a service map where every entry is tied to real code or production traces, and he said stale maps cost developer trust.
Kamalakannan Nandagopal, a staff engineer at Postman, argued on the AI Engineer show that coding agents work well inside one project but struggle across a company's many connected services. His team's answer was a shared map of how those services call each other. Every entry on it is tied to real code or live traffic.
What was said
Nandagopal described how agents moved from autocomplete to fully autonomous workflows. He said they excel at new projects and at fixes within a single project. Production is different. Postman's system is split across 115 microservices, several environments and hundreds of repos.
He said documentation helps but is costly to maintain. He cited research that documentation written and kept only by language models degrades over time. Agent memory, he added, stays stuck with one person.
His team concluded that in a system of many services, the APIs (the defined ways services talk to each other) hold the context. They mapped every service, every endpoint, the exact line of code behind it, and the calls between them, down to databases and caches. One rule governed the map: "every single data point that landed on the context graph always had to be grounded down in a hard truth." That truth is either a line of code or a trace from production.
He gave an example of what goes wrong without it. A developer ships a freeform JSON field with a note to define its shape later. Two weeks on, the field carries 15 attributes from several services, and nobody knows its shape. In his evals, agents using the graph found the right API better than agents using code search alone.
Why it matters
Our reading: the agent's weak spot is knowing the system, not typing code. For managers buying or rolling out coding agents, a fair question is what the agent can actually see about your services. Model choice is only one part of that.
Upkeep is the hidden cost. Nandagopal said "any delays in syncing your context graph with the ground truth creates gap in the result." He added that gaps cost developer trust and then usage. A map that nobody maintains is worse than none, because people stop relying on it.
The other side
This is a vendor talk, and Postman offers these capabilities as early access. The excerpts show clear gains only for API discovery, where the graph beat plain code search. Evidence for the harder redesign case is not in the excerpts.
The talk also does not test whether a better model would close the gap. Nandagopal noted a small difference between two setups he named Postman and Claude, and did not dig into it. So "map, not model" is our inference, not his claim.
He also conceded the map is incomplete. His team still wants to add why each API and data model exists, and what the business does with them.
Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.
The conversation this talking point comes from
- AI Engineer: We Mapped 115 Microservices for Our Coding Agents — Kamalakannan Nandagopal, Postman (2026-10-08)
