The way software is created is currently changing as fundamentally as it last did during the transition from handwritten manuscripts to printed books. What was considered impressive autocompletion just a few months ago has now become a paradigm shift: AI agents write, review, debug, and extend code largely autonomously in many projects.

The extent of this transformation can be seen in a statement by Boris Cherny, the creator of Claude Code at Anthropic. At the Sequoia conference AI Ascent 2026 (available in the Sequoia podcast "Training Data"), he reported that he hadn't written a single line of code himself in the current year. Instead, on some days he's responsible for several dozen pull requests, with 150 on a peak day. The model writes, the human reviews and decides. For decision-makers, this means: no longer whether, but how quickly and with what consequences development processes, team structures, and business models will change.

We at mindtwo observe this development from two perspectives: as an agency for custom software development that actively uses agent-based workflows in our own projects, and as a consulting partner for companies that want to future-proof their digital platforms. This article contextualizes what is changing technologically, organizationally, and strategically, and what conclusions decision-makers should draw from it.

From Autocomplete to Autonomous Development

Until just a few years ago, AI-assisted programming was synonymous with line-by-line code completion. Developers typed, the assistant suggested the next line, a tab press accepted the suggestion. Responsibility for architecture, logic, and correctness remained entirely with the human.

With the next generation of large language models, this relationship has shifted. Instead of suggesting individual lines, agents today take on complete tasks: they read a specification, analyze the existing code repository, consistently modify multiple files, run tests, iteratively fix error messages, and open a pull request for review. The human becomes the interface between business requirements and results. They describe the goal, review the implementation, and decide what goes into the main branch.

In practice, this means significant compression: the number of changes a single developer can be responsible for per day increases by an order of magnitude. Where two to three pull requests a day used to be a good rate, several dozen are now realistic, with comparable or higher quality, because tests, linting, and CI checks are already run by the agent before human reviewers even look at the code.

What This Means Technically in Concrete Terms

Three developments are particularly noteworthy:

  • Model quality as a driving factor: The essential leap doesn't come from more elaborate tool stacks, but from each new model release. Anyone building processes today should plan for capabilities to increase substantially at short intervals.
  • Choice of languages and frameworks gains significance and loses it again: Initially, stacks that were heavily represented in the models' training data benefited, such as TypeScript, React, or Laravel. This asymmetry is now becoming smaller. Current models work reliably even with less common languages and can learn new frameworks from documentation.
  • Verification becomes a core competency: When agents write code, the bottleneck shifts from code production to code review. Reliable tests, clear acceptance criteria, and well-structured repositories are no longer optional, but prerequisites for agent-based workflows to scale at all.

Loops and Routines: Software That Builds Itself

One of the most exciting consequences of agent-based development is not one-off tasks, but continuously running loops. Instead of triggering an agent once, a time-controlled task can be formulated: "Check the status of open pull requests every 30 minutes and fix failing CI builds." Or: "Monitor the issue backlog and propose three prioritized tickets for the next iteration daily."

Cherny describes this practice as "loops" and predicts that such continuously running routines represent the next major stage of agent-based development. At Anthropic, this is already being used across the board internally: several Claude instances running in parallel communicate via Slack, coordinate tasks among themselves, and continue working asynchronously, even when the responsible person has long since closed their laptop.

What initially sounds like a gimmick has significant organizational implications. Routine activities that previously tied up human attention (rebasing feature branches, fixing flaky tests, evaluating user feedback, maintaining dependencies) can be delegated to continuously running agents. The freed-up time flows into what algorithms cannot deliver: customer understanding, product strategy, fundamental architectural decisions.

This creates a new type of operational task for companies: maintaining their own agent landscape. Which loops are running? What permissions do they have? How are results documented and verified? Anyone building a future-proof digital platform should incorporate these questions early in the concept phase, ideally in a structured concept workshop, where not only the application itself but also the later operating mode is thought through.

The Transformation of Developer Roles: Generalists Instead of Specialists

With the shift in value creation, roles are also changing. In classic setups, there were clear separations: frontend specialists, backend specialists, DevOps, data analysts, UX designers, product management. Each role had its own tooling, its own language, its own responsibility.

This separation is becoming blurred. When an agent is capable of writing clean CSS, a performant API layer, and a SQL query equally well, generalists benefit—people who understand multiple disciplines and work with the agent as an amplifier. Cherny describes it this way: in the Claude Code team, every member now writes code, including product managers, designers, data analysts, the finance lead, and the user research team. The dividing lines between disciplines are becoming permeable.

This doesn't mean specialists are becoming obsolete. Depth remains valuable, especially where architectural decisions have long-term consequences or where performance, security, and compliance requirements demand detailed understanding. But it does mean that interfaces between disciplines are becoming more permeable and teams can be organized more flatly. A small, broadly positioned group can today achieve results that previously required a team three times as large.

Consequences for Personnel Strategy

For companies, this specifically means: job profiles should focus less on individual frameworks and more on problem understanding, learning speed, and domain-specific knowledge. An accountant who learns to program may become the better author of accounting software than a pure developer without domain expertise, because domain knowledge is harder to acquire than the ability to work with an agent.

The Strategic Dimension: What Happens to Established Business Models?

When writing software becomes orders of magnitude cheaper, the question arises of what this means for the value of products built with software. Will standard software be commodified? Will entire SaaS categories disappear because companies can build their applications faster than they can buy a license? In this context, Cherny speaks half-jokingly of a "Saaspocalypse" and arrives at a nuanced assessment that we share in our consulting practice.

A helpful frame of reference is the "7 Powers" model by strategy researcher Hamilton Helmer (also widely discussed on the Acquired podcast). It distinguishes seven sources of sustainable competitive advantages: scale economies, network effects, counter-positioning, switching costs, brand, cornered resources, and process power. AI shifts these sources to varying degrees.

Losing significance:

  • Switching costs: When an agent is capable of automatically transferring data models, workflows, and integrations between platforms, the binding effect of proprietary data formats melts away. Providers whose lock-in was primarily based on migration effort must increasingly write off this advantage.
  • Process power: Software whose value primarily lay in cleanly mapping a complex business process can now be replicated more quickly. Anyone who doesn't continuously develop domain depth, data quality, and user experience here comes under pressure.

Remaining significant, partially more important:

  • Network effects: Platforms whose value grows with the number of participants are not vulnerable to AI. A model doesn't help replicate the installed base.
  • Scale economies: Anyone operating infrastructure, sales, or compliance apparatus at a scale that competitors cannot replicate in the short term retains their advantage.
  • Cornered resources: Data, licenses, patents, or regulatory approvals that cannot be arbitrarily multiplied tend to gain in value because the complementary product is cheaper to build.
  • Brand and trust: When creating a functional competitor is technically possible at any time, users and customers increasingly decide based on whom they trust. A question of strategic brand presence and conception, not pure implementation.

What This Means for Companies

For established providers, this creates a dual task: on the one hand, actively expanding their own advantages that are not vulnerable to AI (networks, data holdings, brand positioning) and on the other hand, rebuilding their own organization so that it uses agent-based development internally before younger competitors do so from the ground up.

For newly starting companies, the situation is more favorable than ever: with a small, well-coordinated team, products can be built that can match in functionality and maturity what established competitors deploy triple-digit developer numbers for. The barriers to entry in many markets are falling, and accordingly, significantly more serious challengers can be expected.

The Printing Press Analogy: Democratization of Software Development

If you're looking for a historical parallel to what is currently happening, you quickly arrive at printing with movable type. Cherny draws exactly this line in the conversation, and it holds. Before 1440, reading and writing in Europe was an activity of a small minority, often anchored in church or court; from a global perspective, according to Our World in Data, only about ten percent of the adult world population could read and write as late as 1820. By the year 1500, triggered by the printing press, an estimated 15 to 20 million printed books were produced in Europe, the price per work fell by an order of magnitude. Over the following centuries, literacy rose continuously. Today it stands according to UNESCO at 88 percent among those over 15 years old worldwide, and even 93 percent among youth.

The analogy isn't perfect, but it helps to gauge the extent: when the barrier to creating one's own software drops from "requires several years of specialized training" to "can be described in natural language," then software creation transforms from an expert practice to a broadly available cultural technique. This not only shifts business models but also changes who even appears as a client, co-creator, or user. Cherny illustrates this with a pointed image: the best person to write accounting software may no longer be a developer, but an experienced accountant, because domain knowledge is what's truly scarce.

Important here: democratization doesn't replace professional development. Even after the invention of the printing press, professional authorship, publishing, and editing remained. They became more differentiated and valuable because more content was produced at all. Translated, this means: sophisticated platforms, security-critical applications, complex integrations, and thoughtful user experiences remain the domain of experienced teams. What's changing is the proportion of simple and medium-complexity applications that emerge without professional guidance.

Standardized Interfaces: The Unobtrusive Lever

A technical development that often lags behind the more spectacular demos in public discussion is the standardization of interfaces between agents and tools. The Model Context Protocol (MCP) introduced by Anthropic, which is now under governance of the Linux Foundation, has become the de facto standard within a year and is supported by all major model providers.

MCP Architecture

Practically, this means: a once-defined connection to a third-party system (CRM, ticketing, database, internal API) works with different models, different clients, different applications. For companies, this significantly reduces the effort to productively integrate agents into existing IT landscapes. Anyone designing platforms today should consider such standardized connections from the start, rather than adding them retrospectively.

What Decision-Makers Should Do Now

From these observations, some practical recommendations can be derived that apply regardless of the specific industry:

  1. Honestly evaluate your own development processes. Where in your own value chain is code written, reviewed, deployed? Which of these steps are already agent-capable today, which are not because tests are missing, repositories are confusing, or documentation is outdated?
  2. Start with manageable use cases. Internal tools, repetitive tasks, data pipelines: these are classic entry areas where agent-based development quickly delivers value without jeopardizing critical systems.
  3. Expand verification layers. Reliable automated tests, clear code review processes, and traceable logs are prerequisites for agent-based work to scale and remain auditable.
  4. Adapt personnel strategy. Generalists with domain knowledge, good reviewers, architectural competence, and product understanding gain importance. Training, internships, and new career paths should reflect this.
  5. Rethink strategic positioning. Which of your own competitive advantages are vulnerable to AI, which are not? Where is investment worthwhile in network, data, or brand, where rather in operational efficiency?
  6. Plan architecture for the future. Standardized interfaces, clean API designs, clear data models. Everything that makes your own platform more easily accessible to agents pays off multiple times.

Outlook: Software as a Cultural Technique

We are at the beginning of a shift whose pace will probably increase significantly. Cherny put it pointedly in his presentation: in a year, Claude Code itself might consist of only a hundred lines of code because the model makes most of today's tool layer obsolete. Whether it happens exactly like this remains to be seen. The direction is clear.

For companies, this is not a question of "whether." Anyone building digital products in the coming years will work agent-based, if only because the speed and cost difference to the classic approach becomes too large to ignore. The strategically more interesting question is: what role does your own company want to play in this shift? Provider who develops their own products faster and more differentiated? Platform that makes tools and data available to third parties? Consultant who guides others through the transformation?

We at mindtwo support our clients in answering these questions in a well-founded manner: from strategic conception to technical implementation of custom web applications to establishing agent-based development processes in existing teams. For anyone looking for the right time to seriously engage with these topics: it is now.

Further Sources