A bank API team deploying several times an hour says Claude Code is for analysis, not code

Where they drew the line is more useful than the verdict itself. Analysis, telemetry visualisation and kickstarting a task are all jobs where a human reads the output before anything reaches a customer ^[8]. Domain logic in a brownfield banking API is the other kind of job, and the team's argument for keeping it human is about unwritten constraints rather than syntax ^[9].

Consider what the team carries. Four developers and one product leader ^[4] own account APIs that take around 100 million requests a day on the most central endpoints ^[5]. Flatten that and it is roughly 1,160 requests a second, sustained, before any peak ^[1]. The bank behind those APIs has about 1.2 million customers in a country of five million people ^[6], somewhere near a quarter of the population ^[2]. Soderbom's description of the failure mode is not abstract: get it wrong and "we are newspaper headlines pretty fast" ^[7].

That is also why the cadence claim lands differently here than in a vendor deck. This is a team that already put mob programming on everything, including documentation and analysis, explicitly to spread domain knowledge and remove silos ^[17]. The tacit context an agent is missing is the same context the team spends its whole working day circulating between five people. A model joins that room only through the transcript, and there is no transcript.

The refusal of outside pull requests reads as an architectural decision rather than a cultural preference ^[10]. A team that will not accept an asynchronous patch from another human team has already answered the question about accepting one from a coding agent, because the artifact and the integration path are identical. Their onboarding runs on the same principle in reverse: shadow the mob, contribute to production on day one ^[11].

Discount it appropriately. This is one team, self-reported, in a conversation with an editor who had interviewed them a year earlier, when their line was that AI-generated code was not fast for them ^[16]. The published research paper is about how to introduce pair programming into a company, not about model output quality ^[12]. Nobody puts a number on the "subpar" code. What survives the discount is the criterion they use instead of code review taste: not good code versus bad code, but code that is easy to change, with high cohesion, low coupling and TDD following from that goal ^[14]. A generator that cannot see the constraints a change will hit cannot optimise for changeability, and speed of production is not a proxy for it.