AI Can Write Code. Who’s Engineering the Solution?

How AI-assisted development is changing the relationship between implementation, architecture and business judgement.

AI in Practice — Lessons from the Field | Article 1 — Henry Rivero

A different era of software development

I've been programming since I was a kid, starting with BASIC in the days of MS-DOS. University introduced me to C, C++, Fortran and Pascal, followed by APL, Visual Basic, Visual C, Java, SQL and, over the years, Perl, Ruby, JavaScript, Python and others.

But I was never particularly drawn to programming for its own sake.

My educational background is in applied mathematics, economics and statistics. I've always been more interested in understanding the problem we're trying to solve, the logic of the solution and how the different elements of a system should be organised.

My architectural thinking developed particularly during the Java era, working with distributed computing, multithreading, message queuing, design patterns, object-oriented design and database architecture.

That didn't mean avoiding the technical depths. Quite the opposite.

Earlier in my career, before moving into the media and advertising industries, I worked on some demanding engineering challenges. These included modifying Java's mathematics libraries to meet precision requirements at an investment bank, designing multithreaded processing cores for wagering systems and developing proxy algorithms for voice applications.

These weren't exercises in programming complexity for its own sake. They were situations where achieving the architectural vision required going deep into the underlying technology, sometimes developing algorithms or capabilities that weren't readily available.

As my career evolved into more senior corporate roles, the scope of my architectural thinking expanded. Rather than focusing primarily on software systems, I increasingly applied the same analytical and architectural principles to technology investments, business transformation and digital programmes spanning multiple companies and markets.

The problems became broader, involving commercial objectives, organisational capabilities, technology ecosystems, investment priorities and the coordination of change across different businesses.

Yet the fundamental approach remained familiar: understand the problem, identify the constraints, design an appropriate solution and organise the components and activities needed to achieve the intended outcome.

Along the way, I've seen programming languages, frameworks and development approaches come and go. Different paradigms have offered different ways of organising software, but many fundamental architectural principles have proved remarkably durable.

Separation of concerns, abstraction, modularity, loose coupling, reliability, maintainability and fitness for purpose remain as relevant today as they were twenty years ago.

Now, generative AI has brought me back into hands-on software development.

And it has raised an interesting question.

If AI is fundamentally changing how we create software, is it also changing how we should engineer it?

AI changes the economics of implementation

I've been exploring this question through the development of AI Monetisation Intelligence (AMI), an initiative investigating how media businesses can better understand and address inefficiencies across the streaming advertising value chain.

The initiative didn't begin with software development.

We started by examining the business problem, developing a proposition, investigating the market and validating our thinking through conversations with industry practitioners. We created conceptual interfaces and mockups to explore what a solution might look like.

Only then did we begin building a prototype.

AI has played two distinct roles throughout this process.

First, it has been a development collaborator: helping with research, exploring technical options, proposing architectures, generating code, debugging and testing.

Second, we're investigating how AI reasoning might become a capability within AMI itself, interpreting evidence from interconnected systems to support operational and commercial decisions.

These are different applications of AI, with different requirements and measures of success.

As a development collaborator, AI has substantially expanded what I can explore and implement without assembling a conventional engineering team.

I can describe a requirement, discuss architectural alternatives, have AI produce an implementation, evaluate the result and iterate.

This doesn't mean I can simply delegate the technical work and assume the outcome will be correct. Understanding the implementation remains important, particularly when its behaviour, performance or underlying assumptions matter to the solution.

What has changed is the amount of effort required to translate ideas into something we can examine and test.

I can concentrate more on the problem and architecture, while spending time on implementation details where they genuinely matter.

But there's an important distinction.

The ability to translate an idea into functioning software doesn't necessarily establish that we're engineering the right solution.

And our experience with AMI has provided a particularly interesting example of why that matters.

When commercial viability shapes the architecture

One early AMI discussion concerned the cost of analysing operational information at the volumes a media business might generate.

An approach could look promising in a small demonstration yet become difficult to justify commercially as usage increased. Before pursuing it further, I wanted to understand whether its resource requirements would be compatible with a viable service.

That question changed the architectural discussion. We revisited our assumptions and the technical options worth exploring. Diagnostic capability remained important, but we needed to consider it alongside operating cost and the value of the decisions it might support.

Our controlled prototype allows us to explore those trade-offs. It hasn't established reliability or economic viability at commercial scale.

The significant lesson was that a commercial viability question changed the direction of the technical work.

Recognising that connection required looking beyond the immediate development task, considering the business we hoped to build and allowing those considerations to shape the design.

Architecture is about knowing where to focus

I have always regarded architecture as more than the structural organisation of software components.

It involves understanding the intended purpose of a system, its operating environment, dependencies, constraints and the trade-offs required to make it viable.

Some of the most consequential architectural decisions may barely be visible in the code.

Others may depend on understanding an algorithm or technical mechanism in considerable depth.

The important skill is recognising which level of detail matters to the problem.

Domain expertise brings another set of considerations. As AMI evolves, we need to consider how that expertise can remain consistent, be validated and be maintained over time.

Those questions affect intellectual property, future investment and organisational responsibility, as well as the software design.

An apparently technical choice can therefore have consequences extending well beyond implementation.

Similarly, when considering how far AMI should go in recommending corrective actions, we had to revisit the proposition itself.

Identifying a monetisation problem across interconnected systems is one thing. Prescribing detailed changes to the internal configuration of an individual advertising platform is another.

The latter potentially changes the expertise required, the evidence needed to support a recommendation and the responsibilities we assume towards customers.

Again, the decision affects implementation, but its origins are largely commercial and operational.

Good architecture requires the ability to move between levels of abstraction, from business objectives to technical implementation, while understanding how decisions at one level affect the others.

What does the research tell us?

Our experience is one perspective. Research into AI-assisted development suggests that the broader picture is more complicated than either unqualified enthusiasm or scepticism.

A 2023 controlled experiment involving GitHub Copilot found that developers using AI assistance completed a JavaScript programming task approximately 56% faster than those without it. That demonstrated a substantial productivity benefit for the task studied, but not necessarily for complex software engineering projects.

In contrast, METR's 2025 research found that experienced open-source developers working on established repositories took approximately 19% longer to complete tasks using the AI tools available at the time.

Its February 2026 follow-up suggested that more recent tools were likely providing greater benefits, but methodological and participation issues prevented researchers from reliably establishing the magnitude of those improvements.

These studies aren't directly comparable, but they illustrate why productivity claims need context.

Research into maintainability is similarly nuanced. A 2026 study published in Empirical Software Engineering found faster initial development among AI-assisted participants in an observational comparison, but its subsequent randomised evaluation did not establish a statistically significant difference in the maintainability outcomes examined.

The experiment involved tools used in 2024, making generalisation to today's more capable coding agents difficult.

Google's 2025 DORA research offers another relevant perspective. Based on responses from nearly 5,000 technology professionals, it characterises AI primarily as an amplifier of existing organisational capabilities, potentially strengthening effective development practices while magnifying weaknesses in less effective ones.

That observation resonates with our experience.

AI can accelerate implementation, but the value of that acceleration depends on the decisions and processes directing it.

However, there's another development we need to acknowledge.

AI is becoming an architectural collaborator

It would be misleading to characterise modern AI as merely a code generator.

Increasingly capable development agents can analyse repositories, propose designs, decompose requirements, generate tests, review implementations and maintain architectural constraints across substantial development efforts.

In February 2026, OpenAI described an experimental development workflow in which coding agents generated an entire codebase, including tests and development tooling. Architectural rules were enforced through mechanically checked dependency constraints and structural tests.

The experience also highlighted the importance of making architectural knowledge accessible to agents and encoding engineering constraints in ways they could verify. (OpenAI, Harness Engineering)

Anthropic's March 2026 engineering account similarly explored how to structure long-running autonomous development, using planning, implementation and evaluation processes to support more complex tasks. (Anthropic, Harness Design for Long-Running Application Development)

These are vendor-reported experiences rather than universal evidence of what autonomous development can achieve. Nevertheless, they demonstrate that AI's contribution can extend well beyond implementing human-authored designs.

I find this encouraging.

It suggests that AI can increasingly participate in the architectural process, not simply execute its outcomes.

But it doesn't eliminate the question of whether the process considers the appropriate constraints.

An agent may design an elegant software architecture, enforce dependency rules and produce comprehensive tests.

Yet those achievements don't automatically establish whether the proposed solution is commercially viable, whether it requires expertise the organisation doesn't possess, whether its knowledge can be maintained or whether its capabilities align with what customers actually need.

Of course, AI can reason about these questions too.

The issue isn't that such judgement must always come from a human.

It's whether the development process has sufficient context, appropriate expertise and effective mechanisms for evaluating decisions against the wider objectives of the undertaking.

In our AMI work, my interventions have often introduced considerations beyond the immediate development task.

Sometimes those considerations concern business economics or functional scope. Other times they involve questioning technical assumptions, algorithms, component responsibilities or the adequacy of evidence.

That doesn't demonstrate an inherent limitation of AI. It may reflect how we've structured our collaboration, the context available to the model and the questions we've asked it to address.

A different workflow, with explicit architectural objectives and independent review, might produce different results.

This is something worth continuing to explore.

The faster we can build, the more deliberately we should decide

One consequence of AI-assisted development particularly interests me.

Traditional software development imposed substantial implementation costs.

An architectural decision that required several weeks of engineering effort naturally encouraged some consideration before committing resources.

AI changes that equation.

We can generate implementations, explore alternatives and test ideas much more quickly.

That makes architectural experimentation considerably more accessible.

It also means we can implement questionable decisions just as quickly.

However, not all architectural decisions carry the same consequences.

Some are increasingly inexpensive to reverse. A particular implementation approach can be tested, rejected and replaced with relatively little effort.

Others create commitments that remain difficult or expensive to change.

Data semantics, security boundaries, integrations, operational dependencies, ownership of knowledge and customer expectations can have consequences extending well beyond the codebase.

That suggests a more useful approach than simply insisting on more architectural planning.

Use AI to accelerate experimentation where decisions are reversible, while applying greater scrutiny to decisions that create significant technical, commercial or organisational commitments.

Our AMI discussion illustrates this distinction.

Exploring alternatives is relatively inexpensive in a controlled prototype.

Building a commercial service around an economically unsustainable design would be a much more consequential mistake.

This leads me to a working hypothesis:

As AI reduces the cost of implementation, architectural judgement becomes increasingly important in determining where that implementation effort should be directed.

Not necessarily because every decision becomes more difficult, but because technical possibilities are becoming easier to pursue.

The challenge increasingly involves choosing which possibilities are worth pursuing.

Who should be engineering the solution?

Does this mean every AI-assisted development project requires an experienced software architect?

I don't think so.

The expertise required depends on the problem, the complexity of the system and the consequences of getting it wrong.

A personal productivity application may need little formal architectural oversight.

A business application integrating several operational systems will require greater attention to data integrity, security, dependencies and maintainability.

A commercially deployed platform supporting revenue-critical operations demands considerably more engineering and operational discipline.

And that expertise doesn't necessarily need to reside in one person.

Different projects will benefit from different combinations of domain specialists, software engineers, architects, product leaders and commercial expertise.

AI can contribute across these disciplines.

My own background combines hands-on software development and specialised algorithmic engineering with experience in architecture, technology investment, commercial strategy and business transformation across multiple organisations and markets.

That combination shapes how I approach AMI, but it isn't a universal template for guiding AI-assisted development.

The essential requirement is that the development process brings together the perspectives necessary to make appropriate decisions for the system being built.

And importantly, that those perspectives are applied at the right moments.

An architectural review that focuses exclusively on code quality may miss a fundamental commercial problem.

A business review that ignores architectural constraints may produce an attractive proposition that cannot be delivered reliably or economically.

Neither perspective is sufficient by itself.

Engineering the solution, not simply generating the code

After several decades of watching software development technologies evolve, I regard AI-assisted development as one of the most consequential changes yet.

It significantly expands what individuals and small teams can explore and build.

It allows people with architectural, analytical and domain expertise to participate more directly in implementation.

And it opens opportunities to evaluate alternative approaches much more quickly than traditional development methods allowed.

But our experience developing AMI has also reinforced something familiar.

Good software engineering has never been simply about producing code.

It's about understanding the problem, designing an appropriate solution, evaluating trade-offs and ensuring the result is fit for its intended purpose.

Sometimes that requires stepping back to consider the commercial rationale, operating environment or architectural direction.

Sometimes it requires going deep into the technical implementation, challenging an algorithm or developing a new approach to overcome a constraint.

And sometimes the architecture extends beyond software altogether, shaping how organisations invest in technology, develop capabilities and coordinate transformation.

Good engineering involves knowing which level of abstraction matters to the problem, when to engage with it and how decisions at different levels connect.

AI is increasingly capable of contributing at all those levels.

The challenge is to organise that contribution effectively.

In practical terms, one discipline I would advocate is to periodically interrupt development momentum and revisit a few fundamental questions:

Are we still solving the problem we originally set out to address? Are our architectural decisions consistent with the intended business outcome? Have new technical, economic or operational constraints emerged? And do we have sufficient evidence to justify the next development commitment?

These questions are not new.

What is new is the speed at which we can implement decisions before asking them.

AI is changing the relationship between thinking about software and implementing it. The opportunity is not simply to build more software, faster, but to combine that speed with the breadth and depth of judgement needed to build better solutions.

And that's where I believe some of the greatest value of AI-assisted development lies.