Klaudia Ciesielska, Brandsit: What skills will become the most important for software engineers over the next few years?
McLaren Stanley, Amazon: We’re already seeing that, as we increasingly use agents to carry out work that engineers used to do directly at their keyboards, the nature of this role is changing. Software engineers no longer write code manually as often as they used to. Increasingly, they are asking agents to do it for them.
This frees up their time, but also requires more systems thinking and design thinking. Higher-level architectural decisions are becoming increasingly important: what to build, how to build it, and how to design the entire system.
In the enterprise environment, over the years, an increasing number of tasks not directly related to software development have hindered engineers’ work. I’m thinking of resolving conflicts when merging code, managing pipelines, or other manual development tasks that were somewhat detached from the actual design and development of software. And yet many people entered this industry precisely to create.
Agent-based development allows engineers to return to higher-level thinking. It gives them the opportunity to test ideas more quickly, validate concepts more rapidly and innovate faster.
I think the discipline of software engineering itself will shift in precisely this direction. Roles will also change. Perhaps product managers and designers will be more directly involved in day-to-day work with agents. In turn, the former division between front-end and back-end may become less formal, as engineers will be able to work more broadly across a greater number of systems.
Previously, this required deep specialisation. Now, part of that specialisation is built into the models and the way the development process is managed. This could free engineers from more repetitive tasks and allow them to focus on the creative innovation that led many of us to choose this industry in the first place.
That’s what excites me the most. At the same time, this field is changing so rapidly that it’s hard to predict exactly what it will look like in a few years’ time. I feel that we’re only just beginning to understand how significant this change could be.
Klaudia: What percentage of the code is generated by AI today, and what percentage is still written by hand in your team?
McLaren Stanley: My team was set up from the ground up as an AI-native development team. This doesn’t apply to the whole of Amazon’s structure, but in my team’s case, we don’t write any code by hand. Not a single line. We rely entirely on agent-based development.
Importantly, I didn’t formally ban the team from writing code manually. I didn’t say, ‘manual coding is not allowed’. It simply became a natural consequence of the process.
At the start, when we were beginning new projects, it would sometimes happen that someone would make a manual change to the code but fail to update the agent with the context of that change. The agent would then often overwrite that change or reapply the pattern that the person had been trying to fix.
This naturally leads to a different way of working. Instead of trying to write a specific implementation yourself or fix a specific bug, you try to create an agent-based system that can fix bugs automatically.
If the agent does something the programmer does not expect, they do not correct it manually in the code. Instead, they either instruct the agent to make the correction and incorporate it into its context, or return to the specification and design phase to update it with the new information.
We usually then update the design specifications and the agent control process so that a similar pattern is detected in future, or to change the way the architecture operates. This naturally shifts interaction with the code from manual writing to working with the agent and the system.
Personally, I haven’t written a single line of code manually over the past year. My team, too, now generates 100 per cent of its code via agents. Other teams at Amazon are at various stages of adoption, but as we were a pioneering team tasked with exploring what could be done with these tools, this is simply how things naturally evolved for us.
Klaudia: How do you ensure the quality and security of AI-generated code?
McLaren Stanley: We use a whole suite of tools for this and are constantly iterating on the process. At the very beginning, there was a lot of human review involved. We’d draw up a design specification and then check it separately for Android and iOS, as we used it to generate code for both platforms.
We would then review the entire code as if it had been written by a human. We’d go through every line on both platforms. Very quickly, however, the human element became a massive bottleneck. On top of that, there were manual tests to confirm whether the app was working and whether a specific change was doing what it was supposed to.
The process naturally pushed us towards a much more agent-driven evaluation and a more automated testing environment. We devote a lot of time to strengthening end-to-end and automated tests to ensure that the application’s core functionality remains intact whilst agents are writing new features.
These include unit tests, agent-driven end-to-end tests, as well as test cases written in human-readable English, which are then executed by an agent.
We also use tools that support various stages of the software development lifecycle. In the new project, we have chosen a language that offers greater safety at the compilation stage, including thread, memory and type safety. We are using Swift instead of Objective-C. As a result, the agent receives much better feedback from the compiler on whether the code it is writing is safe. This enables it to arrive at the correct solution more quickly.
We have also implemented a great deal of static linting – that is, automated code-review tools that guide the developer as they work.
One of the most interesting techniques is the use of an LLM as a tester. One agent writes the code and acts somewhat like a code architect. Other agents write code for Android and iOS. We also have a separate agent in the pipeline that reviews the code. It has a different context to the agent generating the code, but is familiar with the project specification, tests and requirements.
This agent checks whether the code generated by the first agent actually meets the specification requirements. So it works much like a code tester, but in an agent-based form. We deliberately give it a different perspective, a different persona and a different set of context so that it can spot errors or deviations from best practices.
At the same time, we maintain the same quality threshold that we had for code written by humans. We still carry out human reviews, especially at the design stage, when we decide what exactly to build. Amazon takes security, stability and quality very seriously, so we’re not prepared to compromise simply because the code was generated by an agent.
What has changed, rather, is that we have learnt to create a safer environment for the agent. We provide it with feedback earlier in the development cycle, so that it can check more quickly whether its responses are safe, correct and compliant with requirements. This means people don’t have to analyse every line of implementation code. They can focus on higher-level questions: are we building the right thing, are we meeting customers’ needs, and are we heading in the right direction?
Klaudia: What is the biggest misconception people have about AI-generated software development?
McLaren Stanley: There are many, because this field is developing and changing very quickly. Just a year ago, we wouldn’t have been talking about specification-driven development, agent orchestrators or AI-native development. A year and a half ago, ‘vibe coding’ was the big topic.
A good example of a misconception is hallucinations. Many people say: ‘I’m worried that agents will produce incorrect answers.’ And it’s true, that can happen. However, I think of it less as an agent generating a wrong answer, and more as a very naive assistant.
If you give imprecise instructions, you get imprecise answers. Of course, this also changes over time, as models are getting better, bigger and have more context. But fundamentally, it’s important to think about this tool differently.
It’s not about science fiction – that is, AI approaching human intelligence. It’s more about a tool that’s very good at recognising patterns. The more robust and precise the instructions you give it, the better the answers you get.
That’s why I don’t think of it primarily in terms of hallucinations or approaching human intelligence. I think of it in terms of a tool that allows us to make better use of and amplify human expertise, as well as the intention with which we set out to build something for our clients.
For me, then, the metaphor of hallucinations isn’t entirely accurate. The more important question is: how do we use this tool, and how do we ensure it becomes less naive over time? This approach has helped us think about the problem in a more systemic way.
Klaudia: Jeff Bezos recently said at VivaTech in Paris that AI will not lead to mass unemployment and may ultimately create a labour shortage. Do you agree with this view?
McLaren Stanley: I generally agree. You can look at history, at the Industrial Revolution or the advent of the computer. Such changes create new avenues for innovation. They allow people to contribute their imagination and creativity, and also free them up to think at a higher level.
I think the same applies to the AI revolution. Once people learn to use these tools effectively, there will be more opportunities to do new things and bring human creativity to work. Looking at history and at what I see in these tools today, I believe this pattern will continue.
I like the comparison with the Industrial Revolution. The first wave of innovation is the tool itself. In the later stages of the Industrial Revolution, there was a shift from the steam engine to the electric motor. But the real innovation wasn’t just the electric motor itself. It was the fact that it could be made small, and then the whole factory could be reorganised. This made it possible to build things that couldn’t be built before.
As far as I’m concerned, we’re in a similar phase today. We have a new tool that allows us to build and do things in ways that were previously impossible. The next wave of innovation will emerge when people start using these tools to build new solutions, solve new problems, and perhaps even create new industries.
We’re only at the very beginning of this change. We’ve barely scratched the surface of what this innovation might look like. That’s, of course, my personal opinion.
Klaudia: Many companies in Central and Eastern Europe have grown thanks to outsourcing and software development services. Do you think that native AI engineering will change this business model?
McLaren Stanley: It’s hard for me to predict. I think it will certainly have an impact. As companies grow, innovate and draw on the incredible expertise offered by employees in Central and Eastern Europe, they’ll also adopt new tools and bring fresh innovations to this field.
This will change the way we think about it. I expect it will also create new opportunities, although it’s hard for me to speculate exactly what form this will take.
However, I believe there is scope here too for a major wave of innovation.
