AI, Constraints, and the Future of Software Engineering

With AI at the centre of the conversation, I have been frequently asked for my thoughts on what it means for the role of Software and Data Engineering.

Public narratives from frontier labs such as OpenAI and Anthropic often emphasise a near-term future in which AI replaces large parts of software engineering. While this trajectory may eventually materialise, the timeline is likely longer and more constrained than these narratives suggest.

What is certain is that software engineering is entering a phase of deep transformation, evolving toward a more AI-orchestrated discipline.

The AI future

AI is not a fad; adoption is increasing, and it is already automating parts of the software development process. Capabilities will continue to improve as models, computing, and training techniques evolve.

The dominant narrative assumes this progress will follow a continuous exponential trajectory. The reality, however, is more nuanced, shaped by a combination of economic and physical constraints.

Tokenomics

Recent frontier models tend to operate with larger context windows, longer outputs, and more complex reasoning processes, resulting in higher token usage per interaction — a form of “tokenflation”.

At present, AI development is heavily subsidised, enabling continued investment in this exploratory phase. Current pricing does not reflect true costs, and as subsidies unwind, token economics will become a first-order constraint and economic rationalisation will become unavoidable: organisations will need to assess whether building more advanced models is justified for a given use case, especially when existing systems already deliver comparable performance on other use cases and would likely consume fewer tokens — we will likely see a fragmentation of usage with more specialised models, once tokenomics come into place.

This effect will be accentuated and moderated by the underlying factors driving the cost of a given token: those related to training and those related to inference.

The cost of training a given model is mainly driven by the compute needed for the training cycle and by data acquisition cost.

On the computing front, the training process, the amount of data fed through, cost of a given compute unit are the key factors affecting the price.

First, those related to the efficiency in the model training process and the amount of data that needs to be processed — Training compute has historically grown by a factor of 4–5x year on year. These are typically driven by more complex processing and by more data being fed into the system. On most data systems, data processing costs increase more than linearly as data size grows and require engineering effort to tame.

Secondly, the cost efficiency of an abstract “Compute Unit” is directly related to the cost of acquiring and operating a data centre. The main drivers of these costs are the cost of purchased GPUs and electricity, and the GPU's cost efficiency per dollar. The purchasing cost of a GPU is this is a direct factor of the negotiation process based on available supply constraints, such as the increase in the price of RAM right now, or the increase in the price of GPU during the COVID Era — most frontier labs have by now locked in multiyear deals to secure some of their supply of GPU capacity, but are also still signing deals and partnership, such as the recently expanded AWS partnership with Open AI to secure a stable supply in the coming years. From one GPU generation to another, R&D and other improvement factors allow for better efficiency, such as Moore’s law — doubling the amount of transistors on an integrated circuit every 2 years, although this has slowed down as transistors are now hitting physical limits. Finally, the cost of energy plays a large role in computing costs, driven by its own energy market, supply, and demand factors, which we will get to in the next section.

Similar to computing, these new models require a specific set of data of a certain quality, and the amount of data required grows with the model's parameter size. Data Acquisition cost will likely grow over time. In the early days of AI, it was fine to develop the first models on freely available data, such as Wikipedia, or on data licensed from books or other materials that had already been produced. In the age of AI we are currently in, this is not enough; data needs to be either generated (through the use of code — for example, traces, or synthetic), or curated specifically to improve these models, often requiring input from experts at a cost of hundreds of euros or dollars per hour, as in the example below.

This explains in part the large investment from Facebook in the likes of ScaleAI — a company specialised in data annotation. This also helps explain why researchers such as Yann LeCun advocate for alternative approaches to scaling, including leveraging richer data modalities such as Video and Audio.

However, token consumption alone is an incomplete measure of cost. What ultimately matters is the cost per successful task. More capable models may consume more tokens per interaction, but they often achieve higher success rates, require fewer retries, and reduce the need for human intervention. As a result, they can be more cost-effective overall despite higher per-call usage.

Approaches such as distillation provide a key counterbalance to rising inference costs. Frontier models can generate high-quality training data and reasoning traces, which are distilled into smaller, more efficient models tailored to specific tasks. These models are significantly cheaper to run while retaining much of the required capability.

In practice, however, frontier models are still often preferred for complex or less well-defined coding tasks, where higher reliability and a stronger first pass reduce the need for retries and extensive validation. As a result, overall token usage is not simply a function of model size, but of how effectively a model can complete a task in fewer iterations.

Supply constraints:

I briefly touched on some of the supply constraints, but they deserve their own section, as they are among the key factors that risk derailing AI’s exponential growth.

Semiconductor supply chains remain globally concentrated and sensitive to industrial and geopolitical disruptions, which can affect the availability and cost of key components such as memory and GPUs.

Electricity production is a key input that directly affects the cost of AI training and inference. It is constrained by local energy markets, including the availability of gas, oil, nuclear power, and renewable sources. Data centres are projected to consume an ever-growing share of global electricity, placing increasing pressure on energy systems. Expanding nuclear energy — particularly through small modular reactors (SMRs) and microreactors — has been proposed as a potential solution, but regulatory hurdles and deployment timelines mean that any meaningful impact will take years.

Beyond generation, the strain that data centres place on the power grid must also be considered. Upgrading transmission and distribution infrastructure, managing peak loads, and ensuring grid stability all require significant time and capital. Data centre capacity itself is also a limiting factor, with many planned facilities delayed due to power and infrastructure constraints. Given the long lead times involved, any meaningful expansion will take time to materialise.

Improvements in compute efficiency provide a partial counterbalance to these constraints. Advances in model architectures, training techniques, and inference optimisation — such as quantisation, pruning, and more efficient attention — reduce the compute required per task. Hardware and software improvements further increase performance per dollar and utilisation, even as Moore’s Law slows. However, these gains are typically outpaced by growing demand: larger context windows, multimodal inputs, and more complex reasoning continue to drive total compute requirements upward. In practice, efficiency improvements reduce unit costs, but rarely constrain overall demand.

Data is an equally important constraint on the continued improvement of AI systems. Early progress relied on large volumes of readily available text, much of which has now been exhaustively utilised, making further gains increasingly dependent on higher-quality, more specialised data. This shifts data from an abundant resource to a costly, operationally complex input: organisations must actively generate and curate datasets using synthetic data, model-produced reasoning traces, and expert annotation. These approaches introduce high costs and scaling challenges, particularly in domains that require expertise. As a result, progress is less constrained by the quantity of data than by its quality, relevance, and the cost of producing it — improvements in data generation help, but do not remove the underlying limitation.

These constraints, however, are being met with significant capital investment. Governments and private actors are accelerating the build-out of data centres, specialised hardware, and energy infrastructure. While this does not eliminate constraints, it suggests that growth will be uneven rather than stalled, and potentially delayed compared to expectations.

An evolution in the engineering roles

As we shift from the magical phase of AI to its industrial phase, new considerations arise. Software Engineering isn’t going away anytime soon, but it will transition from being a coder to an AI orchestrator.

This phase brings as many opportunities as risks from disruption. It requires a transformation and evolution in how most engineers will need to interact with their jobs, and in the expectations placed on them. Highly capable engineers will leverage their skills to become more efficient, while less capable engineers will be displaced, as most webmasters from the original dotcom boom have been displaced by innovations in standalone site-building tools.

The particularity of this transformation is that it puts pressure on two axes simultaneously; engineers need to become both more technical and more business/product-oriented.

Technical Shift

It may sound counterintuitive, but as AI takes on more of the coding itself, engineers will need to become more technical, not less. Current AI systems are effective at producing large volumes of code — much of it boilerplate, and of uneven quality. While some outputs are correct and useful, others are incomplete, brittle, or subtly flawed. Critically, these systems do not reliably design architectures, select appropriate design patterns, or reason through the trade-offs that shape a system over time. They lack a deep understanding of how a product is expected to evolve and what should be built when.

As a result, AI-generated code can default to solutions that “work” in the short term but are suboptimal in the long run. It may introduce shortcuts, incomplete implementations, or simplistic approaches that fail to account for edge cases, scalability, and maintainability. Designing robust systems still requires human engineers to make deliberate decisions about structure, constraints, and long-term trade-offs.

This shifts the skill set required of engineers. Beyond writing code, they must be able to architect systems and codebases, build effective harnesses and guardrails around AI-generated outputs, and understand how to structure and optimise context to get better results. They need to develop stronger capabilities in monitoring and evaluating these systems, reviewing AI-generated code critically, and engaging with AI tools in a way that resembles a technical dialogue — questioning assumptions, challenging design decisions, and steering outputs toward production-grade quality.

Historically, these capabilities have been concentrated among senior engineers. Going forward, they will need to be more broadly distributed, as a new generation of “AI orchestrators” develops the technical judgment required to guide, constrain, and elevate AI-assisted development.

Product Shift

As AI reduces coding as a primary bottleneck, engineers' roles shift toward decision-making. Faster development cycles mean that more choices — about what to build, how to prioritise, and how to scope features — must be made continuously.

This requires engineers to develop not only deeper technical judgment, but also a stronger understanding of product context and business objectives. They need the context, knowledge, and agency to make informed decisions throughout the development process, rather than simply executing predefined tasks.

In this sense, the advantage long associated with “10x engineers” becomes more broadly relevant: a deep understanding of product requirements, the ability to anticipate future needs, and the judgment to make effective trade-offs during development.

A promising future?

AI acts as a force multiplier for those who can use it effectively. It increases efficiency across the development process and enables solving classes of problems that were previously impractical with traditional approaches or simple heuristics.

However, this leverage is unevenly distributed. Engineers who can structure problems, guide AI systems, and evaluate outputs critically will see significant gains in productivity and impact. Those who rely primarily on implementation may find that many of the tasks they previously performed are increasingly automated — either by AI itself, by non-engineering stakeholders, or by more capable engineers operating as AI orchestrators.

Historically, only a minority of engineers have operated at the level required to fully leverage these capabilities — combining strong technical foundations with product intuition, system thinking, and effective communication. As AI systems improve, these skills become more central rather than less.

As a result, AI is likely to increase the dispersion of outcomes within the engineering profession, amplifying the impact of highly effective practitioners while placing greater pressure on others to adapt.