AWS Community Day CEE: when coding accelerates, the bottleneck moves elsewhere. We think we know where.

The keynote: uneven impact, and where the bottleneck goes

Liam Greenamyre, Principal Product Manager at AWS, opened with The (Hype-Free) AI SDLC, as of September 2026, and the first slide asked the right question: why does the impact of AI feel so uneven? His answer was that in a typical week you experience all three at once, a wild success, a frustrating failure and a mundane improvement, and one slide put five "you are here" markers on the hype curve simultaneously. That is the most honest description of the state of the art we have heard from a main stage.

The wild success was the Bun rewrite: roughly half a million lines of code re-written in Rust in eleven days, with up to sixty-four agents running in parallel, against a counterfactual he put on the slide in the team's own words: three engineers for a year, which we never would have done. The frustrating failure got equal time: the same question asked three ways, a five percent improvement, then no effect, then one percent, ending with the line every one of us has typed: "I gave up and moved on to another task."

Then the sentence this whole note hangs on, quoted from the slide: "When coding accelerates, the bottlenecks move elsewhere." And, one slide later, that they may be upstream.

Before the speed, the conditions. Context as code, so that what a developer knows is written where the agent can read it, because, as another slide put it, the full set of context is not always visible to you. Document the codebase. Write down the tenets and the decision points, so the model does not have to guess what you would have decided. Make tasks verifiable. Transform runtime errors into compiler errors. Shorten build times. Write good evaluation rubrics. None of this is new engineering advice. What is new is its price: an agent working without it produces confident code in the wrong direction, and setting up those conditions is real work, as is specifying a task well.

Then the working style. Prompt-driven development was said out loud as the default, not a novelty: start from a vague idea and let the model keep asking until the bright idea is clear. "Grill me" is as popular in that room as in ours. Adversarial agents, one to build and one to attack. And a slide we liked for its bluntness: "Goal: let your agents bash their heads against the wall", paired with its warning, that agents really, really want to complete your task and are willing to take shortcuts to do it. That pairing is why the phrase at the top of my page reads limited blast radius: let them bash, but bound what a wrong answer can break. And the constraint that decides the pace of all of it, quoted: "Inner development loop speed is your primary constraint." We know. Our own loop runs a local Docker build before anything is pushed to DEV, and it is the slowest honest step we have.

The part we liked most cut against the whole industry, us included. Measure impact, not activity. More code is not more profit. The example was an AI code reviewer with a guardrail written on the slide, "human review requirements don't change", and a win stated without inflation: a few hours a week across the team. That is what a real number looks like.

Where we think the bottleneck moves

Here is our own reflection, and it is written as ours. We run ATAILA Coder on our own models, with a harness that keeps the agent inside the rules of the repository, and the honest observation is that the writing of code is not where our customers' time goes any more. It goes to where the keynote pointed: the drive to production is still very complicated. Taking an application that works on a laptop and landing it in a real environment, its landing zone, its four environments, its promotion from DEV to UAT to PROD with a record of who approved what, is the slow part now. That is the reason ATAILA Factory and the Release Manager exist, and hearing the bottleneck named from the main stage by the vendor whose tooling accelerates the other end was the moment of the morning for us. The same goes for the last line in my notebook: accelerate code reviews. When code is cheap, review is the constraint, and review is a judgment problem, not a typing problem.

The workshop: the seam is the model provider

The session we had circled for a week was Arnaud Jean's ninety-minute hands-on, Create Your Own Role-Playing Game with Agentic AI using Strands Agents: a game master orchestrating specialised agents, a dice service exposed as a tool over MCP, two agents talking to each other over A2A, a retrieval step over the rulebook, and a typed JSON contract so a browser UI can render the result. Small enough to read in an afternoon, complete enough to be honest.

We went for the model-provider abstraction, not the game, and the abstraction delivered. Strands Agents is an open-source SDK under Apache-2.0, and its provider layer is one object: it decides whether inference happens in a cloud region or on our own GPUs, and everything above it, tools, memory, the two protocols, the UI, stays where it is. By early afternoon the finished game was running in our own datacentre on our own hardware, on an isolated network with no route to the internet at all. Moving the inference was a configuration change, not a port. The full account, with what broke and how, is on privateai.blog.

Three lessons we did not expect:

• The first thing that broke was not the model. It was the request shape: the SDK sends an empty tools array for an agent with no tools, and one of our serving versions rejects that outright. Ten lines fixed it. That is the real lesson of a hybrid swap: the surprises sit in the plumbing, not in the intelligence.
• Tool-call fidelity is the number that matters, and almost nobody measures it. Our small local model happily narrated dice rolls it never made, and once announced a character that was never written to the database. The large model on our cluster did the same task exactly. Same code, same prompts, different truthfulness. We now have a small harness that counts tool calls and compares what the model says with what the tools returned; that harness, not a benchmark score, is what runs on the next agent workload.
• Pin your versions. The workshop's own steps stopped working mid-week because an upstream dependency had moved a major version. Two import lines, one breakage, ninety minutes of shared confusion in a room full of people who knew better.

And the part that contradicts us, as we promised to publish: local is not automatically good enough. The easy version of our own pitch, put a model on your own hardware and you are done, was disproved by a dice roll. A small model on-premises invented results that a larger one did not. The seam works; what sits on each side of it has to be measured, per use case, before anyone trusts it. That is a harder sentence than the one on our homepage, and a truer one.

The afternoon: the routing question is not only ours

At 14:00 in the Akvárium, György Márk Varga of Shiwaforce gave One Endpoint, Every Model: Building an Adaptive LLM Gateway on AWS, and it was the session that answered our first question. He built a gateway that puts many models behind one endpoint and lets a small learning router choose among them, with the code public. The routing rule, in the words of his slide: every request rolls a number inside each model's range and divides it by what that model costs; highest wins, so one that is nearly as good but far cheaper beats an expensive one. Nothing hard-coded, and every decision is written to a log with its reason: greedy, exploring, or sampled. His live console over 532 questions read 1.31 dollars saved, zero failed answers, and "80% cheaper than always-biggest".

Two design rules from his slides go straight into our own gateway work. The first: "route between conversations, never inside one." The prompt cache wants you to stay put and the router wants you to move; switch mid-conversation and the warm prefix is gone, so you pay to write it again on the new model. Obvious once said, and we had not said it. The second is an accounting trap he showed live: a cached answer came back in 124 milliseconds instead of 4,087, and cost nothing, while the response header still claimed the original fraction of a cent, because the proxy replays the cached answer with its original usage attached. If your cost dashboard reads headers, it is lying to you about your cheapest requests.

One line of his sits closest to us, and it could be read against us: "Is routing what you sell? For almost everyone it is plumbing. Nobody buys your product because of how you pick a model." He is right, for a product company. It is also exactly why routing belongs in the platform underneath the product rather than in every product, and, in our case, the platform is the product. His closing rule we adopt as written: build only the real gap, one component where no setting can express what you need, held to the same production standard as the rest.

We have mirrored his repository into our own GitLab to read it properly. What the code confirms is the thing we came for: a candidate model is just a deployment with a cost per token attached, so an endpoint on our own GPUs drops into the same choice set as any cloud model. The routing question is being asked and answered by other people, on the same day, in the same city, and they are arriving at the same shape: choose per conversation, by quality and cost, and keep a record of why.

What we take home

• The bottleneck has moved to the path to production. Cheap code, expensive delivery. The Release Manager is the product we should have been describing this way all along.
• Measure tool-call fidelity, not benchmark scores. A model that narrates what it did not do is worse than a slower one that does it.
• Route between conversations, never inside one. And do not trust a cost header on a cached answer.
• Per-use-case routing is a market expectation now. Others are building it, with a logged reason per decision; the question is no longer whether, but how well and how auditable.
• The plumbing breaks first. Request shapes, dependency versions, empty arrays. Budget for it.
• Measure impact, not activity, with a bounded blast radius for anything an agent is allowed to do.

We sat in three rooms across one day, and it was worth the ticket twice over.