When McLaren Stanley, Senior Principal Engineer at Amazon Stores, says that his team does not write ‘a single line’ of code by hand, it is easy to dismiss this as a grand statement about the automation of developers’ work. In reality, however, this is a starting point for a more important discussion: not about whether artificial intelligence can generate code, but about how it is transforming the entire software development process.
Stanley spoke about this during a meeting with journalists from Central and Eastern Europe. He was not speaking as an AWS spokesperson, but as a practitioner working within the Amazon team, involved, amongst other things, with the technologies behind the Amazon Shopping app. His experience is interesting not because it showcases the most radical use of AI in programming, but because it clearly illustrates the direction in which the entire industry may be heading.
In recent years, discussions about AI in software development have most often centred on tools designed to support individual developers. AI was intended to suggest code snippets, complete functions, assist with testing and documentation, or help find bugs more quickly. It was an add-on to the existing process. In this model, the organisation of work remained essentially the same; it was simply that some tasks were carried out more quickly.
The model Stanley describes goes a step further. In his team, AI is not merely a programmer’s assistant. It is an integral part of the process, around which the way of working is organised. This is what ‘AI-native development’ means: not simply tacked onto the old model, but a complete reorganisation of engineering work so that AI agents can genuinely participate in software development.
The most interesting aspect of the claim that no code is written manually is therefore not the ‘100 per cent’ generated by the agents. What is more important is what had to change around the code. Stanley emphasises that he did not ban the team from manual programming. This way of working emerged naturally. When an engineer made a manual change but failed to update the agent’s context, the system could subsequently overwrite that change. This forced a new approach: rather than correcting a single fragment of the implementation, one must refine the specification, instructions and the way the entire agent system operates.
This shifts the focus of software development. In the traditional model, the programmer worked directly on the code. In the AI-native model, more and more value is created earlier on: in defining requirements, designing the architecture, managing context, preparing tests and creating the conditions under which the agent can generate the correct solution.
Stanley put it very clearly in the interview: rather than trying to fix a specific bug, an engineer tries to create an agent-based system that will be able to fix bugs automatically. This statement clearly illustrates the scale of the change. AI in programming is not simply a faster way of typing. It becomes part of an environment that needs to be designed, monitored and constantly refined.
This does not mean that the engineer’s role is disappearing. Rather, it is the source of their value that is changing. If an agent can write the implementation, humans must better define what is to be built, why, in what architecture, according to which patterns, and under what quality criteria. The programmer is increasingly becoming a designer of the work system: they define the problem, describe the requirements, set up the process, evaluate the result and decide whether the solution actually meets the user’s needs.
This is a significant shift in the required skillset. Knowledge of syntax and the ability to write code by hand are still important, but they are no longer the sole marker of professionalism. System thinking, architecture, the precise formulation of requirements, an understanding of dependencies, the validation of results, test design and context management are becoming increasingly important. In large organisations, where systems have many layers, a long history and numerous dependencies, it is precisely these skills that determine the quality of changes.
Indeed, the greatest value of AI may not lie in code generation itself, but in shortening the phase of understanding the system. Stanley spoke about a network library he had written himself a few years earlier. He hadn’t prepared full documentation at the time, as he was familiar with the design from his own work. When he returned to that code years later, the agent analysed the library and generated development documentation: usage instructions, dependency structure, parameters and requirements. On this basis, a new implementation could be prepared in a matter of hours rather than weeks.
This example is important because it highlights a real problem in enterprise development. In large companies, the challenge is rarely simply writing the code itself. It is often much more difficult to understand how the old system works, why specific decisions were made, what dependencies are hidden within the architecture, and what needs to be preserved during modernisation. If AI can recreate this knowledge, organise it and translate it into a specification, the economics of working on large systems will change.
This is particularly evident in the case of technical debt. Application modernisation, refactoring, migration to newer languages or architectural reorganisation often take a back seat to the ongoing development of features for clients. These tasks are necessary but difficult to justify, as they require the time of experienced engineers, coordination between teams, and do not always deliver an immediate business impact. Stanley said that AI “has radically changed the ROI equation”. Thanks to agents, a small team of experts was able to work on modernising the Amazon Shopping application without holding back the teams developing current product features.
This is one of the most important takeaways for boards, CIOs and CTOs. AI in software development should not be assessed solely in terms of the number of lines of code generated. A far more interesting question is whether it changes the viability of projects that were previously put on hold: modernisation, migration, documenting legacy systems, test automation or reducing technical debt.
But speed does not eliminate risk. On the contrary, if code is produced faster, bugs can also arise more quickly. That is why AI-native development requires a stronger layer of quality control, not a weaker one. Stanley emphasises that his team maintains the same quality threshold that applied to code written by humans. What has changed, however, is the way this is enforced.
Initially, people reviewed the code generated by agents almost as if it had been written by a human. They checked every line, tested changes and assessed the implementation. It soon became apparent, however, that humans were becoming a bottleneck. In response, automated testing, end-to-end testing, static code analysis, compiler feedback and techniques where one model evaluates the work of another have gained greater importance.
This approach, referred to as ‘LLM as judge’, illustrates a new model of control. One agent generates code, whilst another, operating within a different context, checks whether the result meets the specification’s requirements. Humans are still involved in the process, but their role is shifting from manually analysing every line of code to assessing whether the system is building the right solution, whether the tests make sense, whether the requirements are complete, and whether the result meets the client’s needs.
This also offers a more practical perspective on the problem of AI hallucinations. In public debate, these are often discussed as if they were the main barrier to the use of generative models. Stanley proposes a different approach: it is worth treating the agent not as quasi-human intelligence, but as an effective, albeit still naive, pattern-recognition tool. If it receives imprecise instructions, it returns imprecise responses.
The conclusion for businesses is simple, though difficult to implement. The quality of an AI’s work depends not only on the choice of model. It also depends on the quality of documentation, specifications, repositories, architectural standards, tests and the organisational knowledge that the company is able to pass on to the agents. AI does not mask the immaturity of a process. Very often, it reveals it.
Therefore, the biggest barrier to adopting AI in software development may not be the technology itself, but the organisation. It is easy to purchase access to a tool and encourage developers to use it. It is far more difficult to answer questions such as: who is responsible for the quality of the code generated by AI; how is the context passed on to agents documented; what tests are required prior to implementation; how should effectiveness be measured; and whether the system architecture is ready for such a working model.
This is also significant for the IT services market in Central and Eastern Europe. Over the years, the region has built a strong position based on engineering expertise, outsourcing, software houses and technology service centres. However, if the cost of implementation itself begins to fall, a competitive advantage based solely on delivering code will become increasingly difficult to maintain.
This does not spell the end for service providers. Rather, it signifies the need to shift the focus of value creation to a higher level. Clients will need partners who can design architecture tailored to working with AI, draw up sound specifications, implement systematic quality control, integrate agents with enterprise processes, and take responsibility for the security and predictability of results. The ‘we deliver code’ model will have to evolve towards ‘we design the software development process with AI’.
The biggest mistake, therefore, would be to interpret declarations about the end of manual coding as a sign that programmers’ jobs are simply coming to an end. A more accurate interpretation is this: the era in which manually writing code was the most important symbol of an engineer’s value is coming to an end.
Code remains crucial. Without it, there is no product, application or service. But more and more value is created before and around it: in understanding the problem, describing requirements, the quality of the architecture, the testing framework, the control of agents, and the decision as to whether the solution being developed makes business sense.
AI does not make software development simple. It simply redistributes competencies, risks and responsibilities. The programmer of the future may write each line of code by hand less often, but will need to have a better understanding of the system that enables that code to be created safely.
