Sachin Gupta
Technical Leader at eBay
San Jose, California, United States
Actions
I am a senior backend and platform engineer at eBay with over 15 years of experience building and modernizing enterprise systems. I work on large scale billing and financial platforms that demand high reliability, strong security, and precise data correctness. I spend most of my time modernizing legacy architectures, designing cloud ready services, and building APIs and pipelines that hold up under heavy traffic and real world failure modes.
Lately, I have been integrating AI into engineering workflows, focusing on diagnostics, observability, testing, and automation that help teams move faster without sacrificing safety.
On stage, I share field tested patterns and mistakes to avoid, from migrations and cutovers to incident driven design and operational readiness. My goal is to give engineers practical takeaways they can apply immediately when building and modernizing systems at scale.
Area of Expertise
Topics
Your Coding Agent Is Creating Review Debt
Coding agents ship PRs faster than humans can trust them. The gap is filling up with a debt nobody is measuring — and it's about to swallow your engineering velocity.
Every team in 2026 measures coding agents the same way: PR count, lines of code, cycle time, developer NPS. None of those see the real cost — bloated diffs, weak tests, ambiguous rationale, ownership sprawl, and human reviewers spending more time verifying AI code than they used to spend writing their own.
This talk introduces ReviewDebt: a practical framework for scoring every pull request on the hidden review burden it creates. The scoring is deterministic — diff size, test-coverage delta, ownership spread, generated-code smells, evidence and rationale gaps — so the number is defensible in a real engineering review. We'll walk three real PRs side-by-side (clean human PR, high-debt AI PR, refactored AI PR), watch the scoring play out signal by signal, and look at a 90-day dashboard from a production backend org where review debt climbs in lockstep with AI-PR share.
By the end you'll have:
A working definition of review debt and the deterministic signals that compose it
A scoring rubric you can adapt to your team's review standards on day one
The dashboard view that turns "are coding agents working for us?" into a number your VP of Engineering can act on
2026 won't be the year teams decide whether to adopt coding agents. It'll be the year they decide whether they can trust, review, and govern the code those agents produce.
How to Test a Confidential Agent Before Production
Most efforts to secure AI agents focus on infrastructure: encrypted memory, execution environments, attestation. But even inside a confidential runtime the agent can behave unsafely, selecting wrong tools, fabricating parameters, accessing data outside its scope, or following tool sequences that violate policy. These are application layer trust failures that need application layer testing.
This session presents a three layer evaluation framework built in Java with LangChain4j. Layer one is policy compliance: mock the LLM and verify the agent selects only approved tools with valid parameters. Layer two is judge based answer safety: a second model scores whether responses are grounded in results and free of filtered data. Layer three is trajectory validation: assert the exact tool sequence, because in regulated environments the path matters as much as the destination.
We build all three live in a JUnit suite, define golden datasets encoding expected sequences and forbidden tools, and wire it into CI that fails the build when behavior drifts outside policy. Attendees leave with a JUnit template for agent trust evaluation and a CI pattern making agent safety a build time gate.
Agents Need Feature Flags
Most AI teams ship behavior changes to 100% of users on every deploy — no canary, no segment, no kill switch. Web teams stopped doing this in 2012. AI teams are about to learn why.
Feature flags are table stakes in software engineering. In agent systems they're almost nonexistent — prompts, tool access, model selection, memory policy, and autonomy level all change globally the moment you ship. That's why your "small" prompt tweak just broke 12% of your users and you found out from a Discord screenshot.
This talk walks the feature-flag patterns agents specifically need — beyond the standard boolean-toggle. We'll cover segment-targeted prompt variants, per-tool access flags, model-routing flags, autonomy-level flags (suggest vs. auto-approve vs. auto-execute), memory-policy flags, and the kill switch every agent system should have on day one but almost none do. The demo is live: a real agent on stage handling a real conversation while flags are flipped from a dashboard — tool access revoked mid-call, autonomy downgraded mid-call, and the money shot, a kill switch that stops a misbehaving agent mid-sentence in front of the audience.
You'll leave with:
A taxonomy of the six flag types agents need that web apps don't
A middleware pattern that drops between any agent loop and any flag backend you already use (Unleash, Flipt, LaunchDarkly, or homegrown)
A rollout playbook for shipping agent changes the way you ship anything else that touches real users
If your agent platform doesn't have a kill switch, this talk pays for itself in one deploy.
Tactical DDD Without Over Engineering: When Simple Is the Smartest Design
Somewhere along the way, applying tactical DDD started to mean adding patterns whether the problem needed them or not. Teams implement domain events for CRUD applications, build saga orchestration for workflows with two steps, and introduce event stores for systems that will never need temporal queries. The result is often the same: a system that is harder to understand, slower to deliver, and more expensive to maintain than the simpler alternative would have been.
This talk makes the case for minimal viable DDD, applying just enough tactical patterns to get the design benefits without paying unnecessary architectural cost.
We will start with an honest inventory of tactical DDD patterns and ask a question that is not asked often enough: what does each pattern actually cost? Not in lines of code, but in conceptual overhead, operational complexity, onboarding time, debugging difficulty, and long term maintenance burden. Event sourcing gives you a complete audit trail and temporal queries, but it also introduces eventual consistency, event versioning, and a very different operational model. CQRS gives you independent read and write optimization, but it also brings synchronization complexity and a larger codebase. Every pattern has a price, and that price should be justified by the problem.
The core of the talk is a decision framework built around a simple question: do I actually need this pattern? We will walk through five tactical patterns, Aggregates, Value Objects, Domain Events, CQRS, and Event Sourcing, and for each one I will show the level of complexity where the pattern begins to earn its cost. Below that threshold, I will show the simpler alternative that delivers most of the benefit with much less overhead.
We will examine real before and after examples of systems that improved by removing unnecessary tactical patterns. An event sourced system replaced by a simple audit log table. A saga based workflow simplified into a transaction. A CQRS design collapsed into a single model because the read and write sides never meaningfully diverged.
This is not an anti DDD talk. It is a pro DDD talk that argues the most sophisticated thing you can do is choose the simplest design that solves your actual problem. Strategic DDD, including bounded contexts, context mapping, and ubiquitous language, is often worth the investment. Tactical patterns should be earned, not assumed.
You will leave with a practical checklist for evaluating whether a pattern is pulling its weight in your system, and the confidence to simplify when the answer is no.
Tool Contracts for AI Agents: versioned, validated, and governed tool access
A Java based pattern that forces AI agents to call tools through versioned contracts. The platform validates contract id, version, scopes, and schema before execution. Demo includes mismatch, version drift, and schema denial.
From OpenAPI Spec to MCP Server
Most teams already have hundreds of internal APIs described in OpenAPI, but very few have the time or budget to hand build MCP servers for all of them. In this session, I will show how to take a real OpenAPI 3.1 specification and generate a working MCP server using open source tooling. The generated server includes Streamable HTTP transport, tool discovery, and typed input validation, giving agents a discoverable, invocable interface without writing MCP specific code.
The demo, however, is only the starting point. The core of the talk explains how OpenAPI operations map to MCP tools, how request and response schemas become typed tool inputs and outputs, and how HTTP failures can be translated into structured MCP errors that agents can handle programmatically. From there, we will examine the practical issues that make generated servers fail in production, including pagination, file uploads, polymorphic responses, auth propagation, and tool name collisions.
I will also show the tuning needed to make these servers dependable in real environments, including naming cleanup, schema refinement, auth handling, and guardrails for agent usability. The session concludes with a Spring Boot Gradle plugin that fits into an existing CI pipeline and a decision matrix for choosing which APIs are the best candidates for conversion first. Attendees will leave with a repeatable pipeline, a working example, and a clear framework for scaling MCP adoption across large API portfolios.
Microservice Cognitive Index for Deploy Diagnosis and Change Impact
Modern cloud native systems often span hundreds of microservices, thousands of endpoints, and fragmented telemetry across logs, traces, metrics, deployments, and service catalogs. Even with strong observability, engineers still struggle to answer two high impact questions fast: why did this deployment fail, and if I change this service or API, what breaks.
This industry session presents an AI powered Microservice Cognitive Index, an intelligence layer on top of existing observability. It builds a canonical evidence graph by ingesting telemetry, deriving runtime topology from traces, clustering incident signatures from normalized logs, correlating regressions with deployments, and propagating change impact through dependency and contract signals. It combines graph based reasoning with machine learning and large language models to summarize evidence, rank likely causes, and explain blast radius with confidence. Unlike chat with logs approaches, it enforces tool grounded answers with evidence references, confidence scoring, and refusal policies when data is incomplete or confounded, making results auditable and safer for operations.
WeAreDevelopers World Congress 2026 - North America Sessionize Event Upcoming
Explore DDD 2026 Sessionize Event Upcoming
TailscaleUp 2026 Sessionize Event Upcoming
PlatformCon 2026 Sessionize Event
DeveloperWeek New York 2026 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top