A condensed, opinionated read on two days of talks — the coding agents, memory layers, defect-severity frameworks, and team-shape questions that should actually change how we work next quarter.
Across keynotes, panels, and breakouts, the same seven ideas surfaced again and again. The detailed session notes below are just evidence for these claims.
Anush's argument: the bottleneck has moved from writing code to guiding AI and deciding what to build. He calls the new metric Intent Velocity — the time from idea to production.
He framed engineers' future as a "K-shaped" split. Going up the curve: systems thinking, judgment, problem framing. Going down: language-specific syntax skills and manual implementation. The transformation timeline has compressed from decade cycles to months — sometimes weeks.
The real-world examples are striking. A GPU instruction translation problem that historically took 4–5 years and ~300 engineers was prototyped by agents in 48 hours. AMD's tokenizer — about 200k lines of code that speeds up LLM inference — was written by AI. The point isn't the headcount math; it's that parallelism is now the default: run many agents simultaneously rather than queueing work through one human.
Marc's frame: the future of agentic AI isn't constrained by raw capability — it's constrained by defect rate. And defect rate has two independent axes: frequency × severity.
He drew the 2×2: high-frequency / high-impact defects make a system unusable; high-frequency / low-impact gives you "slop" (summaries, low-stakes drafts); low-frequency / high-impact is the dangerous category — powerful but with hidden failure modes; low-frequency / low-impact is the target state for mass adoption. Most teams are improving frequency but not severity.
His symbolic-AI investments are notable: Hydro (Rust framework for correct distributed systems), Cedar (policy language for authorization), Kiro (spec-driven coding agent), and auto-formalization work that converts natural-language policies into mathematically precise specifications. The argument: agents need formal scaffolding, not just better models.
Universal panel consensus, with productive nuance: coding is being commoditized; thinking, taste, and judgment are not. The entire SDLC — writing, testing, deploying — is being automated. The interesting questions are about who does the judging.
The most striking number from the panel: the population of "builders" expanding from ~50M developers to potentially 1–2 billion knowledge workers who can now produce working software. Junior engineers, paradoxically, now get exposed to full system complexity immediately — a steeper curve but faster growth.
Their critical-skill stack, in order of importance: (1) critical thinking — to debug AI outputs; (2) taste — to judge good vs bad; (3) truth-seeking — and crucially, "AI becomes dangerous when it's 90% right"; (4) continuous learning; (5) communication. The winning profile is generalist + deep domain expertise. The "manager" title may disappear — everyone manages agents, everyone owns outcomes.
Andrew's mental model: software is Lego bricks — AI + non-AI (APIs, DBs, auth, UI). More bricks → exponentially more combinations. The job of AI agents is to assemble them.
His most-debated claim: teams stuck at ~80% AI-assisted have humans as the review bottleneck. Teams that go to ~100% AI hit a step-function in speed. He freely admits this isn't a universal — if you're writing flight software, write it by hand — but for typical work, the last 20% of human review is where speed dies.
A second-order claim, equally important: once coding speeds up 10–100×, new bottlenecks appear — product management, design, legal/compliance, marketing, sales. The old "1 PM per 5–8 engineers" ratio is collapsing toward 1:1 or fully merged roles. Team size is collapsing too — 2–10 cross-functional generalists.
The "AI-native engineer profile": AI leverage + systems awareness + product thinking. And — relevant to anyone working with code — "fresh context" is now critical infrastructure. Agents will happily call deprecated APIs they were trained on. Without injected fresh context, you get confidently wrong code.
Marc's team partners directly with companies like Cursor, Augment, and Cognition before launches — because the model and the prompt harness around it must be tuned together. They behave like one product.
GPT-5.5 was a deliberate bet on token efficiency: fewer thinking tokens, shorter outputs, same or better accuracy. This isn't a model-team vanity metric — it's directly a cost and latency lever for anyone serving the model in production.
Two more behaviors the team explicitly tuned for. First, narration during tool-call sequences — when an agent is making 20–30 calls in a row, narrating builds developer trust even when it doesn't change correctness. Second, a new "tool search" primitive in the Responses API: instead of stuffing every tool into context, the model dynamically selects which to load at inference time.
What's still brittle: ambiguous intent from non-technical users (vibe coding), and tool selection when the catalog of tools is large. The next unlock he flagged: multi-hour autonomous runs with no human interruption.
On the startup side, the data is striking — teams of 5–10 reaching tens of millions in ARR. He used the phrase "swarm recruiting": a few exceptional people outperform volume hires. Engineering, product, and design lanes are blurring. Fastest-growing sectors: legal (Harvey) and healthcare (Abridge, Ambience) — both characterized by unstructured data + expensive talent.
Eli's argument: without a memory layer, agents rebuild context from scratch every session. That means hallucinations, repeated mistakes, and token costs that accumulate silently.
He laid out a clean three-part taxonomy: short-term memory (within a session, semantic-hashed for fast lookup); long-term procedural memory (solutions to recurring problems); and long-term episodic/semantic memory (past conversations, knowledge bases, tool logs). Each plays a different role and needs different storage.
The data-layer challenge for agents is particularly worth flagging: a single agent typically needs relational, vector, graph, spatial, JSON, and time-series data. Naively that's 4–6 databases stitched together — operational overhead nightmare. Oracle's pitch is a converged engine with on-the-fly vector embeddings, but the architectural point holds regardless of vendor: fewer, more capable data stores.
The mental model he pushed — "the Three Musketeers": Context Engineering (purpose-driven prompts, avoid bloat), Memory Engineering (durable retrieval across sessions, teams, orgs), and the Agent Loop (assemble context → invoke LLM → iterate → extract learnings → write back to memory).
Paige's framing: Gemini 3 is natively multimodal — video, images, audio, text, code in and out. The 3.1 Live model can hold a conversation, share screen, and accept video input, which matters for robotics and AR more than for typical SaaS work.
The model ladder is now wider than it was a year ago. Pro for largest tasks. Flash as the everyday workhorse (used internally across Google products). 3.1 Flash Lite for performance-critical paths. Nano on-device. The new Gemma 4 open family ships in four sizes — 2B / 4B / 26B MoE / 31B dense — under an Apache license. The 2B fits on a phone; the 4B runs on a laptop.
The most interesting piece in this section was Gemma 4's performance-per-size curve. Gemma punches above its weight, which means the right question is no longer "frontier or nothing" — it's "where does a fine-tuned small open model beat a generic frontier API at a tenth the cost?"
Three stages, ~50 exhibitors, four food stations, and a sponsor lounge spread across one of San Francisco's old waterfront sheds. The 401–403 zone (Oracle, Actian, AMD) sat directly across from Stage 1 — convenient if you wanted to chat with a speaker right after their talk.
The exhibitor list reads like a map of where the agent stack is being assembled: data layers (Chroma, Qdrant, Neo4j, Redis, Snowflake), reliability (Datadog, CircleCI, Temporal), agent frameworks (LangChain, CopilotKit, CrewAI), code tools (Cursor, JetBrains, CodeRabbit, Sonar), and a long tail of newer names worth watching.
The Cursor team frames AI coding as three eras. Tab completion (next-event prediction over your shoulder). Agentic coding (AI in the driver's seat, you steer). Agent systems (teams of agents kicked off in the background, doing increasingly autonomous tasks). We're transitioning from era two to era three right now.
The enterprise data they shared: over 60% of code lines in Cursor's enterprise deployments are changed by AI in some form (as of March). That number reframes the code-review conversation entirely — you can't manually review what AI is producing at that volume.
Cursor's internal workflow is a planner agent that delegates to worker agents, which then push to git. Different from a feature-branch team, similar to one in spirit. The headline anecdote: they ran a system of agents uninterrupted for one week — it generated ~3 million lines of code and built a working browser from scratch.
Ankit's framing is honest: code is cheaper to build than ever, but infrastructure is expensive to run. Every enterprise is now building several flavors of agent — customer-facing support, internal copilots, custom workflows on top of platforms like Databricks — and the operational question is harder than the model question.
The "multiverse" framing came from cataloguing the variants: agents built on frameworks (LangChain, LlamaIndex), agents built on platforms, agents that are the platform. Each has different deployment, observability, and cost characteristics. Treating "agent" as one thing in our planning is going to mislead us.
Tushar's opening was an honest admission: post-December he and his team got "addicted" to running agents constantly. Productive. But also: they were running them with permissive permissions, on laptops full of credentials, just to skip the safety friction.
The argument: model-driven safety is a layer, but it shouldn't be the first layer. Cloud's auto-mode is a step forward — but it's still asking the model to refuse. Docker's stance is to put containment at the root: a new micro-VM layer that runs across Mac, Linux, Windows. The agent runs inside the VM boundary, policy applies outside, and even potential prompt injections happen outside the trust boundary.
The dev experience matters: they showed terminal use (a new spx command that wraps any agent), and editor integration (Zed + Codex via ACP, all sandboxed). The principle: don't make safety a friction tax that engineers route around.
rm -rf.Brandon's frame: when he learned to code, the unit of work was the line of code and expertise lived in syntax. Today the unit of work is the prompt. Expertise lives in three places — specification, review, and orchestration.
Specification means knowing what you're actually asking the agent to do and being able to articulate it clearly. Review is reading code you didn't write, looking for security and correctness issues, getting comfortable with that. Orchestration is stitching working systems together that survive contact with reality, not just the ideal academic environment.
His teaching method is project-first ("learning by project") and the Replit team is leaning into a buildathon format — students ship working software in an afternoon. Things that took him nine months at the start of his career now take 48 hours.
CodeRabbit's pitch is the structural mirror of Cursor's. If AI is now writing 60%+ of enterprise code, then AI also needs to be doing first-pass review — because human reviewers can't keep up at that throughput, and human reviewers fatigue.
The framing that resonated: "Every change is a hypothesis until proven." That's a deeply scientific frame for software — and it transfers cleanly to anything experiment-shaped. Every feature added, every model retrained, every threshold changed is a hypothesis about the world.
Tom's opening analogy: the current LLM moment looks like the 90s web. Anyone can spin up a website that works. Then you try to deploy it in the enterprise and the whole SDLC isn't ready. The tooling, the processes, the infrastructure are catching up.
The Carnegie Mellon study he cited is sobering: when teams adopt Cursor and similar tools, productivity does spike 3–5× initially. But static-analysis findings rise. Code complexity rises. And by around month three, the team is slowing down again — fixing bugs in code they don't fully understand. The output compounds; the problems compound faster.
His distinction matters: LLMs naturally produce code at a certain quality level — fine for prototypes and internal tooling, not yet fine for long-lived mission-critical applications. If you're shipping a 50k-LOC internal app you'll maintain for six months, current tools are great. If you're shipping a system that'll run for years against adversarial users, the SDLC has to wrap the model with stricter quality gates.
Paul's session was the conference's most direct pushback on hype. His thesis: coding was never the bottleneck. Productivity is the product of five things, and speeding up coding alone gets you maybe 10% of the win — the DX study and others bear this out.
He cited a 2025 study that "95% of companies got nothing out of their AI initiatives." Not because the models are bad — because organizational capability lags model capability. And he flagged quality as the bigger emerging problem: a 50% defect rate on agent-shipped code is structurally bad, and Simon Willison's "Challenger disaster" framing — fully autonomous agents shoving things into production without human gates — is the failure mode to worry about.
His core point on quality: we don't yet have a good shared definition of "good." Pass-at-N benchmarks measure correctness on isolated tasks but say nothing about long-term maintainability, security posture, or operational behavior. Agentic engineering as a discipline is partly about building that definition.
Diamond's frame is operational: most companies are currently running one or two agents in production. The interesting question is what happens when that number is 100 — agents doing finance reconciliations, support triage, deployment gating, security review, data quality, expense reporting.
That world needs the same things software always needed at scale: observability, tracing, evaluation, and graceful failure. But the primitives are different. Agent traces span tool calls, model calls, and downstream side-effects. Errors are often semantic rather than syntactic ("the agent did the wrong thing correctly"). Evaluation has to be continuous, not just at release.
Andrew's closing-day session was the practical capstone: route different parts of a task to different models. A cheap fast model for triage and routing. A frontier model for the actual hard reasoning step. Often a smaller, specialized model for the last-mile cleanup.
The math is straightforward once you stop treating "the model" as one decision. A pipeline that uses Haiku-class for 80% of the work and Opus-class for 20% can match the quality of an Opus-everywhere approach at a fraction of the cost. The engineering challenge isn't the routing — it's having good evals to verify the cheaper paths haven't degraded quality.
Emma McGrattan, CTO of Actian, framed it most directly — but it was the through-line of the entire two days. Every keynote, panel, and breakout was about the same shift: from can it work? to can it work every time, at our scale, under our constraints?
Regulatory pressure, latency reality, and data residency are no longer edge-case concerns — they're shaping where the agent stack lives (cloud vs. on-prem vs. edge) and how it's built. The action items below all flow from that same shift.
Before any agent queries our datasets, find the silent NULLs, the ambiguous columns, and the joins nobody documented. Joe Reis was right.
Owner: TBDFrequency × severity, per AWS framing. We classify agent tasks by what happens when they fail — not just by accuracy.
Owner: TBDPer Andrew Ng — push past the 80% ceiling on one low-risk workflow (probably eval-harness generation or dataset docs). Measure the speed gain.
Owner: TBDShort-term + procedural + episodic. Whether Oracle, a vector store + Postgres, or something simpler — the goal is to stop paying token costs on every restart.
Owner: TBDFor any multi-tool agent we run, see if dynamic tool selection reduces context size and improves selection quality.
Owner: TBDPer Docker. Stop running agents with full developer creds on bare metal. Pilot a containerized runtime before the first incident, not after.
Owner: TBDPer Zencoder. Inventory the model calls we're making. Identify the steps where a smaller, cheaper model would do the job. Build the eval to prove it.
Owner: TBDPer AMD. Idea-to-production, not PRs-per-week. Pick three workflows where we can measure this honestly over a quarter.
Owner: TBD