For decades, programming has primarily been associated with writing code. However, writing code has always been just one part of software engineering. First comes understanding the problem: what needs to be solved, why, and what success looks like. The next step is to turn these requirements into technical decisions and then into working software. Then come testing, deployment, scaling and maintenance.
Software engineers are at the heart of this process, turning ambiguous problems into sustainable software solutions.
Generative AI is changing the economics of this process because the constraints of writing code and implementation speed are no longer the same as they once were. Today, a developer can express an intention in natural language and receive a functioning implementation within seconds, minutes or hours. An AI assistant can generate boilerplate code, write tests, explain unfamiliar code, suggest refactoring, produce documentation and explore alternative implementations. And this change is real. It is no longer a limited experiment conducted in isolation on carefully controlled tasks.
This raises a more important question than “Can AI write code?” If producing code is no longer a scarce resource in software development, what becomes valuable?
Both practice and the research literature are providing increasing evidence that AI does not eliminate the need for engineering work. Instead, it changes where human effort is required. As code generation becomes faster and cheaper, the importance of other activities increases understanding and framing the problem, providing context, evaluating alternatives, validating results, integrating systems and taking responsibility for what is deployed.
This leads me to my central hypothesis: AI reduces the marginal cost of producing software, but not the cost of making good engineering decisions in proportion to this reduction.
If this hypothesis is correct, the impact of AI will extend beyond cheaper software. It may also alter the perceived value of engineering, making problem understanding, judgement, architectural thinking, verification and accountability more important.
The productivity argument for AI is compelling. Once a developer knows what needs to be built, an AI assistant can eliminate a significant amount of menial work. Service scaffolding, adapters, DTOs, repetitive transformations, documentation, test foundations, and familiar implementation patterns can be produced much faster. The engineer knows where they need to go - AI helps them get there faster.
However, software development is rarely just about creating the next piece of code.
Even if a generated implementation is syntactically correct, readable and executable, it may still be unsuitable for the system in which it is intended to operate. Whether generated code looks plausible or runs successfully cannot be used to determine its correctness, security, maintainability, or fitness for a particular context.
This creates an important asymmetry. While AI makes code generation cheaper, it does not make understanding the system cheaper. In some cases, it can even make understanding more expensive.
The easier it becomes to generate code, the more code there may be to review, analyse, maintain, and eventually debug. That is why the engineering bottleneck may gradually move from generation to evaluation.
Compilation does not equal understanding. Syntactic correctness does not equal sound engineering. Code review cannot simply become faster visual scanning just because the code was produced by a trusted tool.
It is useful to distinguish between the different ways AI participates in software development.
1. Acceleration
In this scenario, the engineer has a clear idea of the desired outcome and uses AI primarily to implement it more quickly.
This is the least transformative form of AI use, as the core engineering decisions remain the responsibility of the human operator, with AI primarily accelerating their implementation.
2. Exploration
In this case, the engineer understands the problem, but is unsure which solution is best.
AI can generate alternatives, compare different approaches and reveal parts of the design space that would otherwise remain unexplored.
Instead of asking:
“Write this function.”
the question becomes:
“What are the possible ways to solve this problem, and what are the trade-offs between them?”
This may be a more valuable use of AI than simple code completion. However, it introduces a new requirement: someone still needs to be able to evaluate the alternatives.
3. Delegation
The engineer begins to delegate when they no longer specify the solution themselves and increasingly delegate the decision.
Instead of saying:
“Implement this architecture.”
the instruction becomes:
“Determine the most appropriate architecture for this service.”
Increasingly autonomous systems can analyse requirements, modify code, run tests, respond to failures and continue iterating. Agent-assisted software development is evolving in this direction, moving from generating isolated software artefacts to coordinating larger parts of the software lifecycle.
However, autonomy does not eliminate the engineering problem. It shifts it further upstream.
While agents with different roles can coordinate design, programming, testing and documentation, their effectiveness remains constrained by model errors, limited context, incomplete validation and the need for human judgement.
This introduces a different kind of risk.
The bigger risk is not the code generated by AI. It is an AI-generated decision for which nobody is accountable.
If AI makes code generation much faster, generating more code is not necessarily the answer.
The limiting factor becomes how quickly we can determine whether the generated result is good.
This alters the role of feedback.
A traditional development cycle can be simplified as follows:
Understanding → Design → Code → Test → Review → Deploy
AI is increasingly taking over the creation of code.
The future development cycle may look like this:
Intent → Generate → Test → Analyse → Repair → Retest → Review → Deploy
In this model, tests, static analysis tools, security analysis tools, simulations and observability tools are not just final checkpoints at the end of the development process. Instead, they form the basis of feedback infrastructure for AI-assisted generation.
Research into LLM-based code generation that uses feedback from tests and static analysis supports this approach. Machine-checkable feedback can help models identify and resolve a significant proportion of the issues they detect. However, repeated repair does not guarantee that all defects will disappear, and it can introduce new changes itself.
This is why expert review and defence in depth remain necessary.
The implication is significant: when generation becomes inexpensive, feedback must be faster than generation.
Otherwise, AI will simply increase the amount of code entering a verification queue that humans cannot process effectively.
The engineering challenge therefore shifts from:
“How quickly can we produce code?”
to:
“How quickly can we determine whether this code deserves to exist?”
When code can be easily generated, the focus shifts towards the context in which that code must operate.
If everyone has roughly the same ability to generate a REST API endpoint, write a SQL query, implement a standard algorithm or create a conventional service abstraction, these capabilities become less distinctive.
AI-generated implementation is becoming increasingly commoditised. Context is not.
While an AI model may be aware of hundreds of ways to implement a transaction, it does not automatically recognise which invariants must never be violated in a particular system.
It may recognise standard payment patterns, but it does not automatically understand the undocumented assumptions embedded in a specific payment process.
While it can generate a solution to a performance problem, it may not know which latency characteristics are critical to the business, which operational constraints matter, or which legacy integration would be dangerous to change.
This is precisely why domain and system knowledge are becoming increasingly important.
Specialised research on code generation already demonstrates the value of adapting models to specific libraries, representations and domains, rather than relying entirely on generic generation. For organisations, this means that architectural knowledge, domain expertise, historical decisions, operational experience and high-quality internal documentation can all be considered strategic assets for AI-assisted engineering.
The model can generate. However, it is the organisation that provides the context that determines what should be generated.
In some software systems, an incorrect implementation is an inconvenience. In others, it can affect money, security, customer trust, regulatory obligations or the ability of the platform to operate correctly under load.
For companies operating complex platforms, including sports betting platforms and player and account management systems, this distinction is important.
Code generated by an advanced model is not necessarily safe.
Research on AI-assisted development has identified issues involving vulnerable code, confidential information, code provenance, licensing, hallucinated advice and developers accepting code they do not fully understand. Key safeguards include manual review, testing, trusted sources, and established security tooling.
The important point is not that AI is uniquely insecure.
Software written by humans is insecure, too. The difference is scale.
When code becomes dramatically cheaper to produce, an organisation can produce much more of it. This makes verification, testing, security analysis, observability and disciplined deployment more important, not less.
AI security is not a property of the model. It is a property of the system.
It depends on the model, the data, the instructions, the tools, the generated output, the review process, the deployment process and the individuals accountable for the outcome.
AI can prepare. Teams must still verify.
There is a tendency to view the adoption of AI as a procurement decision.
Buy an AI assistant. Give developers access. Measure productivity.
However, tools do not create value in isolation.
Research on AI adoption in software engineering consistently highlights workflow compatibility, organisational policies, training, access, confidence in the results, culture and available resources as key factors in determining its actual use.
The same model can be highly effective in one workflow and problematic in another.
A developer using AI for boilerplate code, for example, may experience significant acceleration. However, a developer using it for an unfamiliar architectural change may spend more time correcting and validating the result than they would have spent solving the problem manually.
Successful adoption is therefore not primarily about maximising AI usage. It is about understanding where AI can genuinely create leverage in the engineering process.
The relevant question is not:
“How much code does AI generate?”
It is:
“What does AI enable the engineering organisation to do better?”
The honest answer is that no one knows exactly how far automation will go.
The literature does not support the simple conclusion that the role of software engineers will remain unchanged or disappear entirely. A clearer pattern emerges routine implementation is increasingly assisted, while problem formulation, validation, integration, domain knowledge, communication and responsible judgement are becoming more important.
This distinction is important.
A role can change radically without disappearing.
Calculators did not eliminate mathematics. Similarly, compilers did not eliminate programming. Higher-level programming languages have not eliminated the need for software engineers.
Every abstraction removes certain forms of manual work while increasing the importance of other forms of reasoning.
AI may represent another step in this process, potentially on a much larger scale.
An engineer whose primary value lies in translating a well-understood specification into routine code is more vulnerable to automation.
However, an engineer who understands the business problem, architecture, constraints, failure modes and consequences are harder to replace.
Not because they can write code faster.
Because they can exercise better judgement.
If implementation becomes cheaper, the nature of engineering value will change.
The software engineer of the future will increasingly need to be:
These roles are not substitutes for technical skills.
Rather, they are technical skills expressed at a higher level of abstraction.
In reality, they are capabilities that good software engineering has always required. AI simply changes their relative importance.
If AI-assisted development becomes part of normal engineering practice, organisations will need to raise the standard for what counts as “done”.
Generated code should not automatically be considered completed work.
A stronger definition of “done” might include an understanding of the requirements, clearly articulated design decisions, a review of the generated code, meaningful tests, an assessment of security risks, an understanding of dependencies and production behaviour, and clearly assigned accountability.
The metrics also need to change.
The number of lines of generated code is an ineffective measure of engineering value. The same is true of the raw acceptance rate of AI suggestions.
More meaningful measures include defects and vulnerabilities, review effort, failed changes, lead time from change to deployment, maintainability, incidents, recovery time and, ultimately, customer outcomes.
AI should not be primarily evaluated based on how much human activity it replaces.
Rather, it should be evaluated based on whether the resulting engineering system produces better outcomes.
At Delasport, therefore, the interesting question is not simply how much code AI can generate.
Rather, it is about where faster generation can create genuine engineering leverage without lowering the standard of what we are willing to deploy.
In a complex software platform, implementation is only one part of the problem.
We still need to understand the domain.
We still need to think about architecture.
We still need to protect invariants.
We still need to test failure modes.
Security and regulatory compliance must also be considered.
We need to understand what happens in production.
Ultimately, someone must take responsibility for the outcome.
This changes how AI should be used.
The aim should not be to replace engineering judgement with generated output.
Rather, it should be to enhance engineering judgement.
Use AI to reduce the cost of producing the first version.
Let it explore alternatives.
Let it automate repetitive tasks.
Let it participate in feedback loops.
At the same time, we should raise the standard of the decisions people make and the systems they are responsible for.
In the future, engineers will not necessarily be the people who produce the most code.
Rather, they will be the individuals who can determine what needs to be built, which solution is appropriate, how to verify its effectiveness, and the level of risk the organisation is willing to accept.
This is why the future of software engineering is not just about writing less code.
It is about taking responsibility for what we build.
This is because, when code becomes cheap, engineering judgement becomes more valuable.
