AI Software Development

Drawn from a year of engagements with more than a hundred companies, this is the most direct challenge in the season's programme to the assumption that faster code generation produces faster delivery. Mishra and Raja open with external evidence rather than their own: an industry study putting realised velocity gains in the ten to fifteen per cent range, and a controlled experiment in which developers using AI estimated themselves roughly a fifth more productive while measurement showed them a fifth slower. Their diagnosis is that both prevailing working styles fail for opposite reasons. Handing an ambiguous problem to an agent and awaiting a finished result produces a volume of code the developer must nonetheless sign for and cannot confidently review, so it stalls before production. The senior engineer's alternative — decomposing the work personally and inserting AI into narrow slots — keeps the intellectual load exactly where it was, and leaves the surrounding process untouched, so hours saved in editing are consumed by the meetings that process still requires.

AWS re:Invent

The warning that makes this session worth watching is aimed at everyone who thinks this is a procurement problem: traditional development approaches are no longer sufficient, and adding AI tools to an existing process will not help either. The Ericsson account locates the constraint precisely — thousands of engineers across the globe make small-team Agile practice very hard because handovers become unavoidable, and the AI-native claim is that agents can carry context across a handover in a way documents never could. Their four-level maturity model encodes a sequence: context infrastructure before organisational change, and organisational change before the tooling pays off. Skipping the middle step produces individually faster engineers inside unchanged coordination structures. Their governance and culture arguments are unusually direct, and notable mainly for appearing inside a session about a command-line coding agent.

AWS re:Invent

Beach invents a language no model has seen in order to establish something most context-management advice lacks: a controlled baseline. From there he walks the obvious fix — paste the documentation into a rules file — into its own failure, which is that it works while quietly taxing every unrelated request. The corrections that follow are the transferable part. Compress the reference to what the model actually uses. Make the rules prescriptive rather than descriptive, telling the agent when the material applies and how to validate its own output. Then shrink the file to a pointer and fetch documentation at the moment of need, so context cost is paid only when relevant and the reference cannot go stale. His closing habit is the one most likely to outlive the tooling: when an agent visibly struggles, ask it what guidance would have prevented it.

AWS re:Invent

The most concrete attempt this conference season to answer a question the agentic coding sessions mostly leave open: if commit counts and hours saved are the wrong measures, what replaces them? Otto's account is unusually specific about why the obvious alternative fails — summing the small time savings a platform team delivers produces figures exceeding a hundred per cent of a developer's time, and a minute returned is not code in production. Their replacement borrows from Amazon's retail supply chain, where cost to serve measures what it takes to place a package on a doorstep, and applies the same shape to software: total cost divided by units of delivery, with the unit chosen to fit the team. The supporting research is the more quotable finding — across tens of thousands of developers over five years, individual velocity reverts to the team's mean, making team velocity the strongest predictor of both individual output and perceived productivity, which is the empirical case against measuring individuals at all.

AWS re:Invent

The number in this session's title is a triage improvement. The story underneath is that the queue being triaged should never have grown that large, and what fixed the root cause was not AI. The diagnosis is candid: it was easier to obtain an exception than to fix the problem, partly because application teams did not know how to fix certain vulnerabilities — not bad developers, simply not security engineers. That produces a self-reinforcing failure where a better scanner makes things worse, because more findings enter a pipeline limited by developer capability. Average false-positive review time falling from thirty days to thirteen is real and is a faster way to process the symptom. The durable change is a tiered security champions programme whose second tier exists to verify the first, anticipating the incentive that delegation creates.

AWS re:Invent