Deep inside Amazon Web Services, there is a small team that operates less like a corporate division and more like a startup garage. Velocity Labs, formed in April and led by AWS vice president and distinguished engineer Marc Brooker, has about 35 people, most of them based in Seattle. The team’s existence had not been reported before, and its mission is deliberately different from Amazon’s usual product-oriented machinery. Instead of following a long roadmap, Velocity Labs builds quick prototypes in areas of AI that Amazon believes are underexplored and increasingly important to customers, especially agentic AI—systems that can make decisions and take actions on their own. The group’s approach reflects a larger realization inside Amazon: the open-source community and some competitors are experimenting with new ideas and shipping initial products fast, and AWS needs a place where speed and exploration are valued as much as polish and process. Scientists and engineers work side by side, and they are encouraged to cross boundaries. Engineers do research; scientists write code. It is, Brooker says, an attempt to create organizations better suited to working with a new generation of tools. The team proved its point last month when it went from concept to public release of an open-source AI model in less than a week. That model, Strands Decider 2B, is designed to make quick, narrow decisions inside AI agents—like choosing which tool to use or where to route a request. It is based on Alibaba’s open Qwen model and was released Oct. 1 along with the recipe used to train it. Brooker built the original version on his own GPU at home after another startup unveiled a similar model. He wrote that every line of code was written by an agent, though he tried to make sure the core ideas and insights were his—or at least that he understood them. In the same week, OpenAI announced a similar hosted service, underscoring how quickly the field is moving. For people used to seeing Amazon as a giant, slow-moving machine, Velocity Labs is a reminder that even the largest cloud provider can move with startling speed when it organizes itself around trust, ownership, and a shared sense of curiosity.
That speed is not just a matter of internal culture; it is a response to a profound shift in how software is actually built. Two years ago, Brooker says, most Amazon developers were still writing their code by hand. Today, for the vast majority of the company’s developers, almost all implementation code is generated by AI agents rather than written by humans. That is a massive change in the way software engineers work. Brooker himself used to spend much of his time in a traditional code editor or the command line; now he spends far more time working with agent tools such as Kiro, Kiro Crew, and Anthropic’s Claude Code. He calls it a complete change of tools. Amazon has been rethinking the role of the software developer in this new era, and earlier this year its engineering leaders sent revised guidelines to developers. A letter accompanying those guidelines, written by Michael “Terk” Terkowitz, a vice president and distinguished engineer in Amazon’s stores business, advises engineers to learn AI now and to stay close to their customers and products. The letter is notable because it acknowledges that as Amazon has grown, some engineers and managers have become less connected to the people they serve. The revised guidelines, which Amazon has not published and declined to provide, emphasize measuring engineers and teams by outcomes rather than inputs. Brooker, one of the authors of the accompanying letter, says the company had seen anti-patterns in the industry where people focused on things like how many tokens they were spending or how many lines of code they were committing. Those measures, he argues, do not equate to customer value. Asked whether AI use is part of performance reviews or promotions, Brooker said it is not directly a metric. It could factor in, he said, to the extent that it makes someone a stronger performer. The letter does not dismiss usage metrics entirely—Amazon has found that they correlate well with the outputs that matter and expects that to continue for some time—but it says they must be used with care and judgment.
There is, of course, a human side to all this, and it is not always comfortable. Some Amazon engineers have described feeling pressure to use AI tools, and three developers told The New York Times last year that managers were pushing them to use AI, raising output goals, and becoming less forgiving about deadlines. Some coders said their jobs had begun to resemble warehouse work, with constant monitoring and pressure to move faster. Amazon has set a goal for more than 80 percent of its developers to use AI each week, according to the Financial Times. In May, Amazon shut down an internal leaderboard called KiroRank, which ranked employees by how much they used Kiro, the company’s AI coding tool. The leaderboard was discontinued after the company found that some employees were using the tool excessively just to climb the rankings. Brooker said he did not recall the leaderboard or the details surrounding it, but the episode illustrates a familiar truth about human behavior: when people are measured by a number, they will find ways to game it. The revised guidelines seem designed, at least in part, to move away from that kind of thinking. The message is not that AI use is unimportant, but that it should not become a checkbox or a scoreboard. Engineers are being asked to think about whether and how AI actually helps their customers, rather than simply demonstrating that they used it. The letter acknowledges that today’s AI tools will not help in every situation, and it says that is acceptable as long as engineers can explain why. “If your work does not benefit from current AI tooling, that is a finding, not a failing,” the letter says. An engineer who can explain where AI does not yet help their work is demonstrating the judgment the company is asking for. That is a more nuanced message than the simple “use AI or fall behind” narrative that has dominated much of the industry.
The transition to an AI-driven development process has not been seamless, and Amazon has had to learn some lessons the hard way. In March, the company acknowledged that an engineer who followed inaccurate advice from an AI agent contributed to one of several outages on its retail site, though Amazon disputed a Financial Times report that junior and mid-level engineers would need senior engineers to sign off on AI-assisted changes. Amazon also pushed back on an earlier FT report that a 13-hour disruption to an AWS service in December happened after engineers let its Kiro AI coding tool make changes, and the tool decided to “delete and recreate the environment.” Amazon blamed user error—specifically a misconfigured role—and said it has since added safeguards, including mandatory peer review for production access. These incidents highlight the uncomfortable reality that AI agents can be powerful but unpredictable. They can write code faster than humans, but they can also make confident mistakes that are difficult to catch until something breaks. Amazon’s leadership seems to understand that the answer is not to reject the tools but to build better guardrails around them. The letter’s language about “findings, not failings” is part of that effort. It encourages engineers to be honest about the limitations of AI without fear of punishment. That kind of honesty is essential in a culture that has long prized data and results. If an engineer tries to use AI and it does not work, that is useful information for the entire organization. The goal is not to pretend that AI is a magic solution to every problem, but to understand where it genuinely helps and where it does not. Brooker put it simply: AI is not the right answer for every problem. If the right tool is an AI agent powered by a cutting-edge model, fantastic. But if it is three lines of Python code, that is great too. The judgment to know the difference is what the company wants to cultivate.
Inside Velocity Labs, that judgment is on display every day. The team is part of the agentic AI division led by Swami Sivasubramanian, which has organized much of its work around small teams of six to eight people. Velocity Labs also includes the developers behind Strands, AWS’s open-source toolkit for building AI agents. The model that Velocity Labs released last month, Strands Decider 2B, is a good example of the team’s philosophy. It is not a massive, general-purpose model designed to do everything. Instead, it is a small, specialized model that makes quick, narrow decisions inside AI agents—like which tool to use or where to route a request. That kind of focused approach is increasingly important as companies build more complex agentic systems. Brooker built the original version on his own GPU at home after the startup TypeSafe AI unveiled Jev, a similar decision model, on Sept. 15. He wrote on his blog that every line of code was written by an agent, though he tried to make sure the core ideas and insights were his, or at least that he understood them. The team’s turnaround was less than a week from concept to public release. OpenAI announced a similar hosted service, its Decisions API, the same week, which shows how fast the space is moving. Brooker credits the team’s speed to its small size and a high level of trust. Each person takes ownership of a piece of a project and asks for help when needed. There is no room for bureaucracy or endless meetings. People know what they are responsible for, and they are trusted to do it. Brooker expects Amazon to create more teams like Velocity Labs, though not across the whole company. Not every organization needs to move at that pace, but the ability to move quickly when it matters is valuable. The team’s existence is also a signal to the broader industry that Amazon is serious about agentic AI and wants to be at the cutting edge of innovation, not just a fast follower.
What does all of this mean for the future of work at Amazon? It is a complicated picture. Amazon has cut roughly 30,000 corporate jobs since late 2025, and CEO Andy Jassy has said he expects AI to shrink the company’s corporate workforce over time. At the same time, AWS CEO Matt Garman said in April that Amazon is hiring just as many software developers as it ever had, and an Amazon spokesperson said more than 11,000 interns and early-career software engineers would join the company globally this year. Brooker says he does not think AI changes the number of engineers Amazon needs. Instead, it changes what those engineers do and what they need to be good at. The company wants engineers who take ownership, are curious, and can learn quickly outside their areas of expertise. That is a different profile from the traditional specialist who masters one narrow domain. In a world where AI can generate code, the value of an engineer is not in typing lines of syntax but in understanding the problem, guiding the agent, reviewing the result, and knowing when the machine is wrong. That requires a deep connection to customers and products, which is exactly what the revised guidelines are trying to encourage. It also requires a certain humility—the willingness to say that AI does not help with a particular task and to explain why. Amazon’s leaders are trying to build a culture where that kind of honesty is rewarded, not punished. The broader message is optimistic but grounded: AI will not eliminate the need for human engineers, but it will redefine their role. Engineers will spend less time on the mechanics of coding and more time on judgment, creativity, and understanding. Brooker’s comment about the three lines of Python captures that spirit. Not everything needs an AI agent. Sometimes the simplest solution is the best one. The future of software development is not about replacing humans with machines, but about giving humans better tools and trusting them to use those tools wisely. Velocity Labs is an experiment in exactly that idea, and its early success suggests that Amazon is willing to change not just its technology, but its culture.
