On the architecture of autonomous engineering: Why software development belongs in the cloud

AI is changing software development in a more fundamental way than simply making developers faster.

The first generation of AI coding tools still followed the logic of the traditional computer. A developer opened an IDE, asked a question, received a suggestion and decided what happened next.

The emerging generation works differently.

AI agents can inspect repositories, modify multiple files, install dependencies, execute commands, run tests, investigate errors and continue working through a problem over multiple steps.

This changes what a development environment needs to be.

For autonomous software engineering, the laptop is becoming less important as the place where computation happens. It increasingly becomes an interface to a persistent execution environment somewhere else.

For this type of work, that environment increasingly belongs in the cloud.

AI is already becoming part of the development environment

This transition is happening against a broader change in software engineering.

GitHub surveyed 500 US-based developers working in organisations with more than 1,000 employees and found that 92% were already using AI coding tools, either professionally or personally. The same research found that waiting for builds and tests remained one of the most time-consuming activities developers face outside writing code itself.

GitHub: Survey reveals AI’s impact on the developer experience

GitHub's 2023 Octoverse report also showed a broader move towards cloud-native development practices. More than 4.3 million repositories were using Dockerfiles, while infrastructure-as-code, containerisation and Git-based deployment workflows continued to grow.

GitHub: The state of open source and AI in 2023

AI agents therefore arrive in an engineering ecosystem that was already moving towards automation, containers, continuous integration and programmable infrastructure.

Autonomous coding accelerates that movement.

A necessary nuance: local and private AI still matter

It would be a mistake to conclude from this that AI itself belongs in the cloud.

Different workloads create different architectural requirements.

Consider the transcription of a confidential management meeting.

The main challenge is not autonomous execution. It is processing sensitive information.

The same applies to analysing interviews, summarising internal documents, working with confidential organisational knowledge, classifying sensitive information or brainstorming around strategic decisions.

In those situations, local AI or private AI infrastructure can be extremely valuable.

Running inference close to the data can reduce unnecessary data movement. Organisations can maintain greater control over storage, retention, access and processing. Smaller specialised models can sometimes perform these tasks without requiring continuous access to external AI infrastructure.

Private AI can follow the same principle at organisational scale. Models can run inside controlled infrastructure, dedicated environments or private cloud architectures.

These are not inferior versions of cloud AI.

They solve another problem.

The distinction I find most useful is this:

Data-centric AI should often remain close to the data. Execution-centric AI should remain close to the infrastructure it needs to operate.

Transcription, document analysis and confidential brainstorming are largely data-centric.

Autonomous software engineering is increasingly execution-centric.

Why software development is different

An autonomous coding agent does much more than process a prompt.

It may need access to: thousands of repository files, package managers, application dependencies, databases, development servers, test environments, APIs, build pipelines, Git repositories, deployment environments, credentials and secrets.

More importantly, it may need those resources for minutes or hours after the original instruction has been given.

That changes the architecture.

Traditional development environments are organised around the presence of a human developer.

The developer opens the laptop, launches the IDE, starts the application, runs the tests and deploys the software. When the laptop goes to sleep, development stops because the developer stopped working as well.

AI agents weaken that relationship.

You can give an agent a task and allow it to continue investigating, modifying files, compiling code and testing solutions. At that point, tying the execution environment to a laptop becomes increasingly artificial.

The problem is not that modern laptops lack computational power. They are extraordinarily capable machines. The problem is persistence.

A laptop moves between networks. It sleeps. Its battery runs out. Local processes terminate. Development servers disappear.

An autonomous engineering environment should not depend on whether someone's MacBook happens to be open.

The laptop becomes the remote control

The laptop does not disappear from software engineering. Its role changes.

Instead of being both the interface and the execution environment, it increasingly becomes the interface to infrastructure somewhere else.

Gartner describes Cloud Development Environments as remote, ready-to-use cloud-hosted development environments that decouple the development workspace from the physical workstation. They provide developers with consistent access to preconfigured environments containing development tools, repositories and increasingly AI coding assistants.

Gartner: Cloud Development Environments

That distinction becomes considerably more important once the developer is working with autonomous agents.

If execution takes place inside persistent infrastructure, the developer can close the laptop without destroying the state of the work. The agent remains active. Dependencies remain installed. Development servers continue running. Tests can continue. The repository remains available. A developer can reconnect from another computer and continue from exactly the same environment.

Four layers of autonomous engineering

I think of the emerging architecture through four layers.

Model 02: End-to-end workspace pipeline

Volledig scherm

1. The client interface

The local device becomes the control surface. It may still run an editor, terminal or development client, but it does not need to contain the entire engineering environment. The important architectural change is simple: disconnecting the interface should not terminate the work.

2. The persistent execution environment

The repository, runtime and agent operate inside persistent infrastructure. A virtual machine is one straightforward implementation. Google Cloud Compute Engine, for example, provides virtual machines running on Google infrastructure and allows machine capacity to be selected according to workload requirements.

Google Cloud Compute Engine documentation

Inside such an environment, repositories, package managers, development tools and agents can remain available independently from the developer laptop. Persistent processes can keep an agent running while the developer disconnects.

3. The canonical software state

The cloud environment should not become an uncontrolled alternative to normal software governance. Git remains the canonical source of truth. AI agents can create branches, commit changes and submit work through the same engineering process used by human developers. That becomes increasingly important as agents gain autonomy. More autonomy should increase the importance of traceability, not reduce it.

4. Event-driven deployment

Once the agent pushes code into the repository, automated infrastructure can take over. Vercel, for example, can automatically create deployments when commits or branches are pushed to a connected Git repository. Preview deployments allow changes to be tested before they reach production.

Vercel: Deploying Git repositories

The development cycle gradually becomes: instruction → agent → code → test → repository → preview → review → production. The developer remains responsible for intent, architecture and judgement. More of the execution becomes infrastructural.

Local versus cloud is the wrong comparison

Once we separate workloads, the architecture becomes much clearer.

The future will therefore probably be hybrid. A company can process sensitive conversations locally while allowing an engineering agent to operate inside an isolated cloud workspace. There is no contradiction. The workloads are different.

Security is an architecture, not a location

The original local-versus-cloud discussion is also too simplistic when applied to security.

Cloud infrastructure is not automatically secure. Local infrastructure is not automatically insecure. Security depends on identity, network architecture, encryption, access controls, secrets management, patching, logging and operational discipline.

Moving engineering environments into centrally controlled cloud infrastructure can nevertheless create useful security properties. Source code does not necessarily need to be copied across every developer endpoint. Access can be managed centrally. Infrastructure can be segmented. Credentials can be controlled more systematically.

Google Cloud, for example, encrypts customer content stored at rest by default. Its documentation states that stored data uses the AES algorithm, with AES-256 used by default at the storage layer.

Google Cloud: Default encryption at rest

But the significant advantage is not that "cloud equals secure". It is that infrastructure can be designed and governed centrally. For another threat model, such as ensuring that confidential interview recordings never leave an organisation's controlled environment, local or private AI may provide the more appropriate security architecture. Security follows the workload too.

Persistent does not have to mean permanently running

There is another misconception around cloud development environments. Persistence does not necessarily mean paying for compute 24 hours a day.

The state of an environment and its active compute lifecycle can be separated.

Google Cloud supports instance schedules that automatically start and stop virtual machines according to recurring schedules. Their documentation explicitly positions this as a way to run workloads only during useful periods and optimise infrastructure costs.

Google Cloud: Scheduling VM instances to start and stop

A development environment could therefore start during working hours, stop when unused and preserve its disk state between sessions.

More sophisticated systems can go further. Compute can be provisioned according to the work being performed. A lightweight task might need modest resources. A large build, repository-wide analysis or group of parallel agents might temporarily require considerably more. That elasticity becomes particularly interesting as AI changes the ratio between human developers and active computational workers.

From one developer, one laptop to one developer, many agents

Traditional software development implicitly assumes a one-to-one relationship: one developer, one development machine, one active development session.

Agentic engineering breaks that assumption. A developer may delegate one task to an agent while investigating another problem personally. Another agent can work on tests. A third can analyse a separate branch. The developer increasingly coordinates several streams of execution.

At that point, putting every process on the same laptop starts to resemble running an entire company from a single desktop computer.

Cloud infrastructure allows the unit of development to change: from one developer → one machine, towards one developer → multiple agents → multiple isolated execution environments. This is where the architectural implications of AI become larger than the productivity implications.

The autonomous engineering workspace

Software development has repeatedly moved towards higher levels of abstraction. Physical servers became virtual machines. Infrastructure configuration became infrastructure as code. Manual deployment became continuous deployment. Applications moved from local machines towards distributed cloud infrastructure.

AI introduces another abstraction. Developers increasingly specify intent while agents perform larger parts of the execution.

Once agents can work autonomously for meaningful periods of time, their environment becomes infrastructure in its own right. It needs persistence, identity, isolation, version control, observability, compute, network access, secrets, and deployment connectivity. And it needs to continue operating when the human closes a laptop.

That is why I believe autonomous software engineering will become predominantly cloud-native.

The future is hybrid

This does not make local AI less interesting. I expect the opposite.

As organisations deploy more AI, they will become more selective about where computation happens. Sensitive information processing may increasingly happen locally. Internal knowledge may remain inside controlled private environments. Specialised models may run on-device or on organisational infrastructure.

Meanwhile, autonomous systems that need access to repositories, builds, databases, CI/CD pipelines and deployment environments will benefit from persistent cloud execution. The architecture becomes distributed according to the nature of intelligence being performed.

For software development, however, the direction seems increasingly clear. The physical laptop remains important, but it becomes less like the factory and more like its control room. The engineering system continues somewhere else. And once AI agents are capable of working after the screen closes, that distinction becomes fundamental.