AI Is Not Just Writing Code. It Is Rebuilding the Computer Around Us

The next software revolution is bigger than autocomplete

For several years, the most visible use of artificial intelligence in software engineering was a grey suggestion appearing after a programmer typed a few characters. That was useful, but it did not fundamentally change the shape of the computer.

Now the boundary is moving. AI systems can inspect a repository, plan a change, edit several files, run tests and submit a pull request for review. AI-first browsers can navigate websites and complete multi-step tasks. Operating systems are exposing local models as shared capabilities that any application can call. The important shift is from software that waits for precise clicks to software that can interpret an objective and assemble the steps needed to reach it.

From code assistant to engineering agent

GitHub's coding agent illustrates the change. A developer can assign it an issue, after which it creates an isolated environment, examines the codebase, makes commits, runs available checks and opens a draft pull request. This is not an independent artificial engineer. GitHub itself describes the strongest use cases as low-to-medium complexity work in well-tested repositories, and its safeguards still require human review before sensitive workflows run.

That distinction matters. Generating a plausible function is easy compared with understanding why a product exists, which trade-offs customers will tolerate, how an old dependency behaves under load, or what failure would be unacceptable. AI can increasingly perform the mechanics of an engineering task, but humans still define the intent, constraints and evidence that make the result trustworthy.

The browser is becoming a programmable worker

The same transition is happening above the application layer. Traditional browsers display pages and leave the user to move information between them. Agentic browsers such as Opera Neon and Perplexity Comet are designed to interpret a request, work across tabs, compare sources, fill forms and perform actions inside an authenticated browsing session.

This is more consequential than adding a chatbot to a sidebar. The browser already sits between people and much of the world's software. If it can reliably operate interfaces, it becomes a universal automation layer for services that were never designed to communicate with one another. A small business could ask one agent to compare suppliers, reconcile an invoice and update an internal system without commissioning three separate integrations.

Yet this power creates a new security problem. Web pages contain untrusted instructions. An agent that can read a page and also send email, access accounts or make purchases may confuse malicious content with its user's command. The industry therefore needs permission boundaries, visible action logs, confirmation for irreversible steps and strong isolation between browsing context and privileged tools.

Is AI creating a new operating system?

Not in the conventional sense, at least not yet. There is no mature general-purpose operating system designed and maintained entirely by AI. What is emerging is more interesting: AI is becoming an orchestration layer across the operating system.

Microsoft Foundry on Windows, for example, gives developers access to local models and AI APIs across CPUs, GPUs and NPUs. Applications can use shared on-device capabilities for tasks such as speech, search, image enhancement and model inference, without sending every interaction to a cloud service. In this model, the operating system still manages files, processes, memory and hardware, while AI helps translate human intent into actions across those resources.

The long-term interface may therefore be neither an app grid nor a command line. A user could describe an outcome, then an agent would select local or cloud models, call applications and tools, request approval where necessary, and preserve an auditable record of what it changed.

Where the industry can push the boundaries

The largest opportunity is not to produce the same software with fewer people. It is to attempt work that teams previously could not justify.

• Explore more designs: Teams can generate and test several implementations before committing to one, turning software design into a faster experimental discipline.
• Modernize neglected systems: Agents can map old code, propose incremental migrations, generate characterization tests and document behavior that exists only in the source.
• Make testing adversarial: One agent can build a feature while another searches for edge cases, security weaknesses, accessibility failures and performance regressions.
• Create tools for tiny audiences: Internal software for a ten-person team, a local charity or a specialist researcher may become economical when prototypes take hours instead of weeks.
• Connect research to products: Scientists and domain experts can express rules, simulations and data pipelines in natural language, while engineers concentrate on validation, architecture and scale.

The uncomfortable evidence

AI does not automatically make every programmer faster. In a controlled 2025 study, METR found that experienced open-source developers working in repositories they knew took 19 percent longer with the AI tools available at the time, even though they believed the tools had accelerated them. A 2026 follow-up found signs that newer tools may provide speedups, but selection effects made the estimate unreliable.

DORA's broader research reaches a similarly useful conclusion: AI acts as an amplifier. Strong teams with clear goals, fast feedback, reliable platforms and good engineering practices can gain more leverage. Disorganized teams may simply generate defects, review queues and technical debt faster.

There is also a skills dilemma. If junior engineers delegate every difficult step, they may produce more code while learning less about the systems they will later be expected to supervise. The answer is not to ban AI. It is to use it in ways that preserve reasoning: ask developers to predict behavior, inspect diffs, explain failures and own the final decision.

The engineering organization built for AI

Companies seeking real benefit should treat AI adoption as a systems redesign, not a software-license purchase. Repositories need executable tests, clear architecture notes, small tasks, reproducible environments and measurable quality gates. Agents should receive the minimum permissions necessary, and their changes should be traceable to prompts, models, tool calls and human approvals.

Productivity should be measured at the outcome level: lead time, escaped defects, reliability, customer value and recovery time. Counting generated lines of code rewards precisely the wrong behavior. In an AI-rich organization, deleting unnecessary code may be more valuable than generating thousands of new lines.

The real boundary is ambition

AI will write an increasing share of routine code. But the deeper transformation is that software itself is becoming more adaptive, conversational and capable of action. Browsers are turning into workers, operating systems are becoming model platforms, and repositories are becoming environments where humans supervise fleets of specialized agents.

The winners will not be the companies that remove humans from engineering fastest. They will be the ones that use machine speed to ask better questions, test more possibilities and build products that were previously beyond the reach of their time, budget or team size, while keeping human judgment firmly attached to every consequential decision.