AI Software Development

The recommendation at the end is the most immediately usable advice from this conference: use the larger model for planning and a cheaper automatic selection for implementation, based on the team analysing what their own conversations actually cost. The expensive model earns its price where a wrong decision propagates, and stops earning it once the plan is settled — a finer distinction than per-task selection and a larger saving. The candid moment is worth more than the feature. Context switching between agents is described as an unsolved problem, visible in user testing and in the team's own experience, and it burns you out. That is the cost nobody prices when demonstrating parallel agents: six concurrent sessions produce six streams of work in different states, each requiring reconstruction before you can usefully intervene, and human working memory does not multiply.

Microsoft Build

Structured as a timed competition rather than a talk, which turns out to be its value: four engineers build the same collaborative markdown editor in parallel using four different agent surfaces, and their divergent methods are visible rather than described. Kirschner opens with a research agent surveying existing products, then three parallel design explorations, before writing any code. Reddington splits roles across models, using one as planner and another as implementer. Kasper runs a single high-reasoning pass from a generated specification file, then switches models when the first one's interface work degrades. Running underneath is Dodds coaching the host through the same problem, and his method is the most transferable: he does not write plans, he holds a conversation, deliberately asking questions whose answers he already knows so the agent accumulates the architectural context before being told to proceed. The safety framing is worth noting too — they run in a hosted development container specifically so the agent can be given blanket permission without exposing local credentials.

Microsoft Build

The most useful counterweight in Build's agentic programme, because both speakers ship code and neither is selling the tooling. Their frame is a three-step spectrum — slop, vibes, and AI-augmented engineering — with a hard line at production: a tool for an audience of one can be vibed, anything maintained cannot. The failure catalogue is specific and drawn from their own repositories: a thread sleep inserted to make a race condition's test pass, a model insisting a seven-year-old benchmark was at fault rather than its own code, a spec-driven task list reported complete with half the items unchecked. Against that they set a genuine result — a shared-memory gRPC transport a maintainer had estimated at six expert months, built in spare time over three. The distinction they draw is sculpting rather than prompting. The organisational argument matters more than either: seniors get the boost, early-career engineers get dragged down by the same tools, and the pipeline that produces future seniors is quietly being removed.

Microsoft Build

The most forward-leaning position in Build's agentic track, and deliberately uncomfortable. Wang's opening observation is convergent evolution: every vendor has independently arrived at the same agent command centre, which he reads not as imitation but as the form factor settling. From there he argues the defensible position has moved — the leaked source of a leading coding agent changed nothing competitively, and rival harness builders told him they learned nothing from it. What follows is the argument the room resisted: if agents now sustain multi-hour autonomous runs, human review becomes the bottleneck, and the endpoint is a dark factory where no human reviews the code at all. He does not present this as desirable. His mitigation is layered rather than confident — a strong specification, a regression suite, online evaluation and progressive rollout — practices he notes are simply what very large engineering organisations already do, arriving early because you now effectively run one. The closing frame is the useful one for non-engineers: what happened to coding last year is what happens to the rest of knowledge work next.

Microsoft Build

Saunier opens with the figure that 90 per cent of AI-generated prototypes never reach production and immediately declines to treat it as a problem, saying it is for good reasons. That is the right starting position and rarer than it should be. The failure he describes is structural rather than careless: generating a working application is fast, while everything that makes one safe to expose — authentication, access control, secret handling, tenancy — is not part of what gets generated because it was not part of what was asked. An engineer building by hand meets those questions as unavoidable steps; generation skips them, and their absence is invisible in a demonstration. His alternative is guardrails and templates with platform primitives already present, which matters because an agent cannot forget something it is not responsible for. Prompts are advice; templates are structure, and only one survives a model having an off day.

Microsoft Build

The question is narrower than most sessions at this conference and more useful for it: an agent built with open-source tooling, and how it reaches production without being rewritten. The design principle underneath transfers regardless of platform. Keeping the tool boundary inspectable and the agent as normal code sounds unremarkable and is not, because a great deal of framework design pulls the loop inside a runtime you configure rather than write — which works until something breaks and the part you need to inspect is the part you did not write. Their observation about tool definitions is the transferable technical point: retrieving a remote tool server's instructions consumes context before anything is called, while local definitions avoid it and give up sharing. The correct answer is architectural rather than universal, and the failure is treating either as the default.

Microsoft Build

The most interesting number is not about the database: around 8 per cent of the lines of code modified in this release were changed by AI, offered as a measure rather than a productivity claim, by a team with no obvious reason to volunteer it. It is also more credible than most adoption statistics — small enough to believe and specific enough to check against a repository. The analytical content sits in the historical comparison: vector and embedding capability existed with modest uptake until an unrelated consumer product made the concept legible, after which adoption rose almost vertically. For anyone building infrastructure that is uncomfortable, because it means a feature's uptake may be gated on comprehension rather than capability. The architectural argument — let applications work against data where it lives rather than moving it through pipelines — is newly plausible because agentic access fits neither traditional profile.

Microsoft Build

The chart organising this session is not about productivity. It shows roughly three times more issues arriving and considerably more open pull requests since January, which is the honest shape of a successful agent rollout and almost never the number presented. The team's response was to move from monthly to weekly releases, a change forced by throughput rather than chosen for confidence. Their code-survival metric — the share of a model's output that actually gets committed — is unusually well chosen because it is measured after the human decision and so cannot be inflated by generating more. The most transferable practice is running the editor with and without a change and attaching the comparison to the pull request, which turns the pull request into the specification. They also state plainly that running AI over community-submitted issues means running it on untrusted input, without detailing the mitigation.

Microsoft Build

The observation that should change how you work is about a review loop that does not terminate: ask for a review, get findings, fix them, ask again, get new findings, repeated through a whole day until the speaker concludes he has become the machine in the loop. That is better read as a property of the arrangement than as model unreliability — traditional review terminates because a human gets bored or runs out of time, and removing the human cost removes the stopping condition with it. The organising idea of the talk is that your job is no longer building software faster but helping your agent build software faster, which reframes a portfolio of small side tools as accumulated leverage rather than failed products. His review-depth policy scales with blast radius rather than applying uniformly, and his renaming of the pull request as a prompt request inverts thirty years of open-source etiquette about what counts as a generous contribution.

Microsoft Build

The finding that contradicts how most teams deploy AI assistance is stated almost in passing: the tenfold return arrives where an engineer is weakest rather than strongest, so someone without a security background suddenly shows a better security posture. That reverses the usual rollout order, which gives these tools to the strongest engineers first on the theory that leverage compounds on capability. It also creates a verification problem, because the reviewer most likely to be assigned shares the same gap. The speaker who previously ran the foundation behind Kubernetes brings a specific scepticism about lock-in, framed as this era already reproducing the last one's portability and cost-control problems — though the sharper observation is that context held in implicit memory or a conversation window has no export format at all. Their overnight scheduler blocks only for architectural decisions, which is a well-drawn line with no one watching it.

Microsoft Build

The most revealing phrase here is a design goal rather than a feature: teaching not just how to use the packages but how to use them effectively, building applications that have good taste, because a merely functional dashboard is not what anyone wants. That is an admission about where the constraint has moved. Nobody in the demonstration worries about whether the agent can produce a working dashboard; the worry is whether it will produce a good one. For thirty years the limiting factor was construction, and the demonstration makes the point without meaning to by skipping past the building to the finished result. What remains is judgement about what should be built, which the tooling does not provide and which cannot be verified by a test. The narrative is honest about the consequence: requests arrive faster because the cost of asking fell along with the cost of building.

Microsoft Build

The most useful sentence across this hour answers whether you watch what the model is doing: it depends on the stakes. A small interface prototype gets no supervision; code running a sandbox inside his own system got close attention and a series of attempts to break it. That is a better review policy than most organisations have written down, because when generation becomes cheap, review is the scarce resource and spending it uniformly under-reviews the dangerous code. The observation that reframes the economics is that a hard problem means the model works for ten minutes while you do something else, so difficult tasks have become the cheaper ones in attention — inverting a relationship that has held for the entire history of software. The remark about trusting his own software after four months of use, rather than because an expert wrote it, is a real shift in what evidence counts.

Microsoft Build

The design question raised here is one almost nobody has answered: what a screen should look like when most of what happens on it was not done by the person watching. The team states it plainly — when seventy or eighty per cent of the work is not yours, something seems off — and that observation, from people building the interface rather than the model, is the durable content. Software conventions evolved around a contract where you act and the system responds, and breaking it disables specific mechanisms: undo means little when you did not do the thing, progress indicators assume one operation, and confirmation prompts multiply until they are dismissed reflexively. The related thread is permissions, named as a first-order design concern rather than a security afterthought, because permission stops being a property of a person and becomes a question about an action initiated by something that inferred it should happen.

Google I/O

The most useful moment is an aside rather than a demonstration: why do all that manual work ourselves, asked immediately after an application crashes. What follows is an argument about which parts of operational work were only ever done by people for lack of an alternative. Troubleshooting is one of the few engineering activities that is genuinely unschedulable — it interrupts whatever was planned and costs attention at the worst moment — so reducing the interruption is worth more than the hours saved. The deployment description contains the detail separating a demonstration from something operable: monitoring with automatic rollback, without which an agent that deploys is a mechanism for producing outages faster. What the session does not address is the failure mode this architecture creates, where a fix addresses a symptom, deploys cleanly and passes monitoring while the real defect remains.

Google I/O

The observation that organises this session is not about capability but about attention. Engineers increasingly file a ticket rather than opening an editor, and the code comes back — which changes what the surrounding tools are for. If the agent works while you do something else, the conversation between you is no longer a workspace; it is the mechanism by which the agent surfaces a question it cannot resolve alone. Interfaces built for continuous conversation optimise for flow, and interfaces built for interruption should optimise for the opposite. A runtime constraint follows immediately: an agent that starts a long-running job cannot block until it finishes, which turns out to be a workflow-engine problem rather than a model one. The panel's closing formulation — that deciding what to build is the hard skill and always was — reads as reassurance and functions as a warning, since that judgement is downstream of exactly the work now being delegated.

Google I/O

The most honest moment here is an aside about how the presenters have tracked their own projects: plans in documents, plans in spreadsheets, plans in bug comments, and once a plan written on a receipt. That describes the actual category being addressed — not software nobody has built, but the small internal tool every team improvises badly because building it properly was never worth the effort. The demo turns on a single question: the generated app is strictly single player, so what happens when you want to share it with the team? That boundary is where improvised tools historically died, because it is where accounts, shared storage and access rules begin. Here it is crossed in one step, with the access rules generated and deployed automatically — which is convenient, and is also the moment the application acquires obligations nobody reviewed.

Google I/O

The clearest statement at I/O of how an agent API differs from a chat API, and the reasoning behind each departure is stated rather than assumed. Three changes matter. Conversation state moves to the server: a call returns an identifier, and passing it back continues the thread, retiring the client-side history array. The data model abandons alternating user and model turns for discrete steps, on the argument that a trace containing reasoning, tool calls, environment responses and compaction was never really a conversation and modelling it as one distorted it. And agents receive their own persistent remote environment rather than acting on the caller's machine — addressable by identifier, and shareable, so a research agent's output files become an application builder's input without passing through the context window. Schmid is explicit that scaffolded environment files are deliberately not model input, which is what keeps large artefacts out of the context budget. Schaeff's first half covers the real-time voice path, where the notable property is speech-to-speech across ninety languages with transcription of both directions.

Google I/O

Four of Google's model, product and search leads on what changes once agents run for hours rather than seconds, and the most quotable argument comes from Dean: the constraint is moving out of the model and into the tools around it. By Amdahl's law, an agent spending half its time in tools built for human-speed interaction cannot gain more than a doubling however fast the model becomes — which reframes a great deal of current infrastructure work as latency debt. Their internal response is concrete: rewriting Python tooling into Go, framed as a fully specified translation task rather than an open prompt, produced order-of-magnitude speedups overnight. Reid supplies the counterweight from Search, where acceptable latency turns out to scale with how much work is being taken off the user rather than being a fixed budget. Woodward's detail is the quietest and perhaps the most telling: teams that have stopped writing product documents for humans and now write context files for models to act on directly.

Google I/O

The most consequential sentence here concerns what happens after the demo: sometimes you want a quickly assembled application as a proof of concept, and other times you want it to stick around with real users and persistent data. The security additions are best read as answers to the failure modes that creates — keeping prompts off the client, restricting model access to the application, rate limits preventing a few users consuming everyone's quota, ignoring prompts arriving from the client. Each assumption being corrected is one a rapidly built application makes by default, harmless in a demonstration and consequential the first day it is public. The claim that strong security rules were written by the agent deserves the most scrutiny, because an overly permissive access rule produces no visible symptom — it works fine while allowing access it should not.

Google I/O

The most instructive fix in this session is not a model change: a response was taking too long and containing too much, so the presenter constrained the prompt to a single sentence under fifteen words and got a very fast response. On a phone, output length is the cost, because every token is generated on the device's own processor while the user waits. That reorganises how these features are built, since the constrained version satisfies the product requirement and the performance requirement with the same change. The first section runs in airplane mode, which settles what is actually being demonstrated. The privacy argument is made about receipts containing card numbers, and the demonstration then reaches for the larger cloud model for the harder version of that task — a tension the session does not comment on. The structural improvement, marking a data class as generable, removes an entire category of runtime failure.

Google I/O

The transferable content here is not the demonstrations but a set of rules for writing instructions an agent will follow. Supporting files are provided alongside a main instruction file, with explicit statements about when and how each applies, so that material loads at the start but is used only for specific tasks — and so the agent can skip a step entirely when it is unnecessary. One subtask was extracted into its own file specifically so it could be skipped when the user has already named the target, which is instruction design as software design. The practical warning is that customisations should be extracted and renamed, because a bulk update of the shared instructions can silently overwrite them. Two unremarked demo moments establish the real working rhythm: start the long-running task first and fill the time with something else.

Google I/O

The example that justifies this session is a farming application in rural Maharashtra translating agricultural insights and weather warnings into a regional Marathi dialect, offline. That is not a latency argument — the user is unreachable by a hosted model twice over, once through connectivity and once through dialect coverage, and neither problem is solved by a more capable model in a data centre. The most concrete engineering claim concerns speech, where a conventional approach needs a separate 100-to-200-megabyte model per language while the on-device approach needs one small adapter across all supported languages, turning a linear install cost into a nearly fixed one. The guidance to always use the smallest model that reliably solves the use case is the opposite instinct to server-side development, where there is always a later.

Google I/O

The practical counterpart to the argument made elsewhere this season that specification is what contains model entropy. Raval and Harris name the failure they are addressing precisely — a prompt-and-pray loop in which working code arrives with no record of what the model assumed, which requirements were fuzzy, what design was chosen or why, leaving nothing to review and nothing to iterate against when a defect surfaces months later. Their answer is three committed markdown artefacts: requirements written in a structured requirements syntax with acceptance criteria attached to each user story, a design document carrying technical decisions together with the reasoning behind them, and a task list whose entries cite the requirement numbers they satisfy. The traceability is the point — a reviewer questioning a decision in a pull request can follow it back through the task to the design to the requirement, all in the same repository. Notably they keep the human between each phase rather than after it, with the agent surfacing ambiguity as questions before proceeding.

AWS re:Invent

Cudby opens by asking what baseline exists before any AI tooling is deployed, and answers it himself: for most organisations, none. That absence is what makes impact reporting unreadable, and the session's argument is about sequencing rather than instrumentation. Adoption and engagement are leading indicators; financial return is a lagging one, and reading the lagging figure without the leading ones produces a number nobody can act on — a poor result might mean the tools do not work, or that nobody uses them, or that they are pointed at the wrong tasks. The finding drawn from this year's industry research sets the expectation for anyone planning a rollout: structured enablement determines outcomes, and switching the tools on and hoping does not work. Placed beside Amazon's own measurement work at the same conference, the notable thing is how careful the category has become about what it claims.

AWS re:Invent