Recently, I attended an unconference called “The Future of Software Engineering” hosted by Thoughtworks. This post is a reflection on the key themes I found important and I formed a clear perspective around. Thanks to everyone at the event for the exchanges.

Software factories

The holy grail is a self-evolving system where a feature request is magically built in the existing system. Side-effects aside, whether and when we will reach this target remains to be seen. We’re certainly on path towards the target with teams who get a sense of this future reality in parts of their processes.

As teams work on codifying steps of the development process, we’re seeing more and more proof points for reusable workflows that accelerate release cycles. A single bug or feature request can now be designed, coded, and verified in an agentic loop, if supported with the right tools, platform, and guardrails. Teams that have well-engineered systems and high engineering rigour benefit the most. It’s all about low build times enabling fast iteration, modular architecture making code changes cheap and simple, and high test coverage enabling continuous delivery to users.

Better models enable multi-hour execution for increasing scope, triggering the move of agents from the local developer machines to micro VMs that host them. Leading teams can reverse-engineer existing code, design a replacement and the needed guardrails, and build loops that will eventually result in a running system that passes all checks. This approach accelerates migrations and codebase modernization. Guardrails also become more autonomous with highly specialized background agents that compensate for lower quality code generated by coding agents and that protect invariants or stability of the system. Examples include agents that refactor code, apply reliability patterns, write missing tests, reorganize test suites to reduce execution time, etc.

The key question remains where the developers are in this process. For the foreseeable time, they will build and operate the backbone that builds the system (thus the name software factory) and set the constraints under which the system is allowed to evolve. Depending on business needs and appetite for risk, teams can choose from a set of hand-off points where human interaction and sign-off is explicitly required:

  • idea->plan: explicit decision whether to act on the idea or feature request with focus on keeping the scope of the product and key user journeys in place.
  • plan->execute: humans review plans or specification, increasing the likelihood of understanding the system. After approval, the system takes over implementation, verification, and more.
  • change request->deploy: final pass code review, if required by regulatory needs.
  • incident->remediation: the on-call person takes a decision on remediation making the needed trade-offs taking their business knowledge and current state of the system into account.

These handoff points are not entirely new, yet these points seem to be a good anchor for explicitly keeping the software delivery in check. Each of the steps is prone to benefit from further automation supporting the decision making process. For change request analysis, the person can be provided with a measure of risk of the changes, a summary of the changes can be automatically tested against the specification or regulatory guardrails. To speed up incident response, the on-call person can receive an automatically collected summary of the state of the system and changes around the time of incident.

“You build it, you run it” vs. “They build it, you run it”

The “You build it, you run it” approach has promoted healthy practices in teams and increased reliability of the supported systems. With citizen developers (non-engineers who build apps with AI assistance) getting abilities to build applications, it’s tempting to drift back to “They build it, you run it”, placing the burden of ownership and operations on an existing engineering team.

A question arises how we can avoid creating a culture of throwing AI-generated apps over the fence, just to be operated by experts who never wrote a single line in any of these apps? Training citizen developers to have intuition on software and security risks is going to pay off in general. Yet, requiring everyone to acquire a baseline set of skills of software engineers is not the only path. Typically, it’s platforms that separate concerns, offering user-level abstractions that run on top of a solid foundation.

This foundation essentially needs to operate itself and be self-healing in terms of known failure modes, beyond simply recycling unhealthy compute nodes. For example, for applications with databases, it’s possible to add automatic volume increase to avoid running out of space or adding an index to speed up expensive queries. Effectively, the idea is to make these failure modes disappear (in most cases), reducing the burden on the user to know about these concerns from the get go and by setting healthy constraints (e.g. increase disk space max. n times). Existing vibe coding solutions from vendors typically fall short when it comes to accessing data and APIs from production systems. Usually, this leads to static data being embedded in applications, resulting in bypassing access control for data or public leaks in the worst case. The platform can and should ship with mechanisms protecting users, setting the right access and data guardrails.

The challenge remains on what the starting point of the citizen developer journey is. Developers start with a repo or clone an existing template with scaffolding. Citizen developers require to be guided through the creation process from the very first prompt they write. On top, this needs to happen with as little friction as possible so that they (and the agent) do not look for workaround. Defining tight constraints enables a progressive build out of the platform and sets clear expectations to the user on what’s possible for them to build, be it a static website, a data visualization dashboard, or a simple tool with limited access to data from internal systems.

Will we still need IDEs?

Traditional IDEs ship with tools that help navigate the code base and perform deterministic code transformation. Yet, popular plugins from coding agent providers reduce the role of the IDE to a mere terminal/chat window and rendering of large change sets. Thus, it’s easy and common to skip IDEs completely, favoring the popular coding CLIs where reviewing large plans/specs and preparing prompts is a very barebones and basic experience that surprisingly works well enough.

As IDE users migrate off to CLIs, the question is what features could help slow down this trend. The incumbent IDEs are clearly missing out on:

  • exposing access to deterministic IDE tools for transformation and refactoring, lowering the token bills
  • access to the IDE environment for compilation, running tests, reducing failure rate in coding loops
  • annotating agent output with feedback (visual and text) to increase accuracy in prompting
  • native support for agent skills with support for verification and (back)testing
  • multi-session orchestration to avoid conflicting changes done by agents in parallel
  • coding session insights with usage statistics and view of agent traces

Some of these features are already available via tools (e.g. codeburn, agentsview, kit), but bundling them into a (new) product is highly likely to improve the agentic engineering experience. Coding agents also ship with OpenTelemetry support, containing telemetry signals that can be captured and visualized. Visualizing agent session telemetry comes with new challenges related to data privacy as traditional observability tools are designed to provide broad access to application telemetry, rather than offering access to user-level data.

Growing gaps

It’s well known that agentic engineering amplifies both the bad and good practices in teams. Teams that ship in fast cycles will likely continuously widen the gap between themselves and their peers who are slow to adapt. It’s impressive to hear from new startups that invested in codifying processes early on and how they’re benefiting from the acceleration that agentic engineering offers.

Small companies benefit first as it’s much easier for one team member to build the set of guardrails in code and shared skills. Growing from this early base helps accelerate delivery at increased consistency.

Existing companies face the risk of increasing fragmentation on process and tech stack, reinforcing status quo (e.g. adopting microservice architectures with a high degree of freedom of choice for the tech stack and lack of platform support and/or application level SDKs). Common approaches are encouraging the build out of shared skill marketplaces and shared tooling that supports the engineering process, yet the fate of these efforts highly depends on organisational structures and culture of re-use.

A future where developer platform teams step up by one layer and provide a unified process of building software is likely. However, working styles and practices differ significantly on individual level, often being part of one’s identity and skill differentiation. Forcing large groups of engineers to adopt the same structure can become too constraining and limit innovation, even if sufficient extension points for customization are provided.

Summary

During the event, we discussed many proof points for future timelines, yet many questions still remain open. While it’s clearer where human judgement will be most needed when agentic engineering takes off and crunches through product backlogs, it’s less clear what organisational structures and shapes of teams will prevail or correlate with successful outcomes. Unclear terms reveal how young the discipline is with the added level of complexity of social media hyping up names, without triggering prior discussions on these amongst practitioners with decades of engineering expertise.

The future is certainly exciting and requires leadership from practitioners to influence and help understand trade-offs along the journey we’re on.