Back to the Future of Software Engineering

It famously took 40 years for factories to switch from hydro and steam to electric power and computers initially did not improve office productivity as expected. The commodification of "intelligence" may be the greatest change of all. Coding agents are suddenly viable in 2026, and have found product-market fit, but will today's enterprises manage to adapt their organizations to this new reality? I think they can, and the future of software engineering could be great, but it's going to require a lot of leadership.

I was on the fence about writing this thought experiment because everybody is clearly still figuring this out and I'm sure this article will look quaint very soon. But I also think this is a unique time in history, and leaders should have opinions on it. At a minimum, it will be valuable to look back on.

How We Got Here (Economics)

Despite the end of ZIRP, more abstractions, Stack Overflow, and an exploding international talent pool, the US software engineering labor market grew from 674k in 2002 to 1.7 million in 2019. US companies, terrified of becoming the next Kodak or Blockbuster Video, had an insatiable appetite for software, which kept wages consistently high and attracted lots of people. This had two key side-effects that created a positive feedback loop (which is a bad thing).

1. Bigger teams. Organizations instinctively tried to industrialize development, starting with specialization. More niches (frontend, backend, QA, UX, data, platforms, etc.) created larger teams. Larger, more numerous, and more distributed teams required more internal and external management (primarily Scrum and SAFe) which required even more people. Time was mostly spent in meetings.

2. More complexity. Limited long-term career prospects (in a cost center) and increasing competition forced engineers to invent and/or deploy new things to differentiate themselves. This flood of new tech created a fear-driven "tech treadmill". Engineers needed experience using the most trendy technologies at the top of their resumes at all times to remain employable. Naturally, the baseline complexity of new applications increased and layers of formerly fashionable tech accumulated in the enterprise that were difficult to dislodge.

Incentives that yield more people and more complexity bloated the cost of software engineering. This forced enterprises to buy instead of build, especially after ZIRP ended and US capitalization rules changed, but running a business on SaaS comes with its own set of strategic trade-offs.

Software engineers increasingly needed to choose between working in a quagmire of technologies and heavy processes (while also staying on the treadmill) or integrating/extending the ever-shifting sands of SaaS. Neither of those options was appealing to software engineers, especially the great ones.

It wasn't always this way. My fondest experiences in software engineering were on small teams with simple technology stacks on hard problems with rapid feedback loops. The constraints and expectations may have been different, but the quality of the work, our personal growth, and the value we created were superior to anything I've seen or read about in today's large enterprise projects.

Some organizations were adept at managing software engineering bloat (or did not survive long enough to experience it). However, by 2025, building software in most enterprises likely had grown into a painful and costly experience for all involved. Worse yet, this trend showed no signs of slowing down.

Deus Ex Language Model

December of 2025 marked the moment when these economics started to change, thanks to Claude Code. Agent harnesses and new LLMs with reasoning suddenly became a viable method to do software engineering (and many things related to it such as prototypes, tests, documentation, and so on) with natural language.

Seemingly overnight, software engineering could be high-quality, very fast, and cheap in most contexts. The number of people who could build "real" software (production-grade or not) jumped from 1.7 million software engineers to tens of millions of knowledge workers in the US.

On the demand side, the appetite for software (and modernization of those stubborn old layers) remains high. We may see less demand for user interfaces in the coming years, also because of agents, but the net demand for software is likely to remain strong.

Great Scott! Now What?

In 2026 there are two key questions facing enterprises:

1. How do we optimize this new technology? At first, exquisitely detailed specs were required to improve outcomes but this seems less necessary as models and tools improve. I don't expect this question to be answered any time soon, and enterprises are better off taking an act-sense-respond approach to the situation: use the tools, sand down the rough edges, measure outcomes, but don't get attached and be prepared to switch to new tools quickly as things change.

2. How do we change our organization (people, process) to integrate this new approach? This is much more challenging and where the rest of this article will focus.

"Roads? Where we're going, we don't need roads." - Doc Brown

A natural first instinct is to automate existing processes. This has been shown to only amplify existing traits. In other words, adding a louder speaker system will just make your yacht rock band louder, not play better music. Also, adding automation to specific steps in an existing process will only cause bottlenecks upstream (ideas) and downstream (acceptance).

Instead, I believe enterprises need to rethink current norms from first principles. Questions like:

• Do we need elaborate processes when it probably takes less time to build and ship something than to estimate and plan it?
• Do we need specializations when they could be rolled into automated construction and/or downstream controls?
• Do we need to telephone ideas between "business people" and "technology people" in the form of user stories?
• Should we still distinguish between functional and non-functional requirements in work queues when the tools can be configured to enforce the non-functional requirements automatically?
• What could go wrong when there are no practical limits on building software? How do we prevent foreseeable chaos and burnout?
• How do we prevent the errors of the past and structure work so that people can attain autonomy, mastery, and purpose in this new environment?

There's a lot to think about.

Where Things May Be Headed

I've been paying close attention to how organizations and experts are approaching these challenges. In recent months I've been seeing some clear trends emerge, which I think are probably on the right track.

Continuous Engineering. We have continuous integration and continuous delivery, why not try to eliminate the remaining handoffs and queues related to ideation, implementation, and review? This is what Zed is proposing and I've seen similar ideas elsewhere. I don't think our tools are quite there yet, but soon will be.

Multi-Disciplinary Teams. Originally proposed by Gartner in 2020 (back when "digital" was all the rage), the idea is to have truly multi-disciplinary teams ship software (and other solutions) independently. The liminal space between business and technology is where things tend to fail, so why not eliminate it?

Systems Thinking. AKA "loop engineering." You may have inner loops where you continuously optimize technical quality issues using automation before shipping and outer loops where you continuously improve software products based on automated feedback signals after shipping. It's mostly about designing information flows and queues while ensuring it doesn't all spiral out of control.

AI-Legible Guardrails. Distribute your standards, guidance, policies, and possibly even a representation of your landscape as something that the harness can use to steer outputs. There are several ways to do this, such as skills, hooks, and other kinds of content that ground the agent. The technology is changing, but will always be the easy part. The harder part is how to govern and/or federate these high-impact artifacts and how to verify they are working as models change (which is getting better).

One Vision for the Future

Here's my current caffeine-infused thinking for how to combine these concepts in a new system for software engineering:

The core component of this is the Software Team. This is ideally two people, no more than three, to minimize communication overhead. In the near term it should have one person from a technical background and one person who is not. In the long term, as the process and tools enable people to generalize more, this distinction will be less relevant. These people are responsible for everything related to the system they are building, including managing their feedback loops and support.

This small team independently ideates, implements, and verifies software changes using an agent harness. This should be done together in real time, either with pair programming (an idea that sadly never saw wide adoption) or remotely via a multiplayer agent harness, to maximize creative flow and minimize handoffs.

The team's agent harness consumes guardrails that are centrally distributed and enforce enterprise policies and practices. These may be extended by the team for their specific project, such as design patterns and architecture.

Changes go to a non-production environment where automated signals flow quality issues (such as errors in logs) back to the team. Those changes get promoted to production where product quality signals (such as reliability issues and user feedback) flow back to the team to consider.

The team measures its performance with DORA metrics, which cover both quality and throughput, and business KPIs.

You only need one Software Team for a small system. To scale this up for a larger system that requires multiple Software Teams, one for each bounded component, you would add only a few more elements.

The Product Manager is responsible for ensuring the integrated product is cohesive, guiding the Software Teams working on the components, owning the strategic roadmap, and managing stakeholders.

The System Architect guides the Software Teams on technical cohesiveness, integrated system architecture, and alignment with enterprise technology strategy, platforms, and security/compliance needs. They also configure the Thermostat.

Both the Product Manager and the System Architect are jointly accountable for the DORA metrics and business KPIs of the integrated product, and ensuring long-term usability, ROI, and maintainability.

The Thermostat is an independent autonomous component intended to prevent the system from overheating. It is inspired by this talk which is worth watching. It prevents the slop from getting out of hand by taking multiple software quality measurements and proposing improvements.

If the Thermostat observes that quality levels have dropped below thresholds, then all Software Teams must cool down and revisit their setup. If they don't resolve the issues then the software may not go to production until they are fixed. This is similar to the Andon concept in Lean manufacturing. Unlike other types of gates, this is understood by leadership as non-negotiable because the risks of quality failures at such a potentially large scale are too great for exceptions.

Software Teams will have their own local quality signals, but the Thermostat must be independent of all of them to ensure the collective quality of the integrated system and to tolerate tooling drift between teams. This includes situations where the teams are not using agents for everything, which we must also design for.

Collectively, this is a lean model for high-volume and high-quality software engineering that minimizes handoffs and prevents a slop factory. It's not without risks of course, but how those risks are managed is likely to evolve along with the technology (better models, improved guardrail techniques, self-healing systems, predictive alerts).

A Week in the Life

There's a lot left to discuss but I want to try to keep this short. Instead of handling every possible topic, here is a week-in-the-life picture of what a Software Team might be like.

The Software Team has two members:

• Marty has worked with the company for five years in business operations. He has very limited software experience, but understands the domain well and is eager to use software to have a bigger positive impact on the company.
• Doc is a former Software Developer in Test (QA expert) who worked in IT for ten years on various projects, but never had a great sense for how his work mattered in the company.

Marty and Doc have complementary skill sets but that's not enough to start building. They both must go through a training program, which explains the tools, responsibilities, and how success is measured, before becoming a Software Team.

Monday: Marty and Doc meet in the morning to brainstorm what they plan to build that week. They ideate "on paper" using a design thinking approach. They take breaks to do independent research, tinkering, and feedback-seeking then meet up again in the afternoon to agree on which solutions to pursue.

Tuesday: Marty and Doc sit at a desk together (or remotely in their multiplayer harness) and "pair program" to plan, implement, and review software changes executed by their agents. Most review is automated but the higher-risk changes receive extra scrutiny. This work is intense and requires frequent breaks, but by the end of the day there are multiple iterations of solutions in a development environment. Their agents work overnight testing the changes.

Wednesday: Marty and Doc again work synchronously to iterate and refine their work, this time with an eye toward what is ready to ship or not. Some items are polished for a production release, others are discarded or put back on the queue for next week. Their agents work overnight again, polishing the changes for release.

Thursday: Marty and Doc asynchronously work on the production release. They ensure all quality signals from non-production are handled and ship everything before lunch. In the afternoon, Marty communicates with stakeholders and Doc monitors the production telemetry.

Friday: Marty and Doc independently do their own research, training, feedback-seeking, reflecting, cooling off, and preparing ideas for Monday's design thinking session. In a larger setting, they may also meet with their Product Manager, System Architect, or other Software Teams to align on new harness configurations or roadmaps.

Saturday and Sunday: Agents are identifying and executing low-risk maintenance tasks and gathering signals from production to inform Marty and Doc's decisions on Monday.

With enough maturity, Marty and Doc could plausibly ship more in one week than a typical Scrum team can ship in a month. And that's with only having "hands on keyboard" for two or three days of the week. Due to cognitive load, it's probably not sustainable or wise to build this way every day. The remaining two or three days are reserved for collaboration, reflection, slack, tuning the system, and mastery.

Marty and Doc both have direct line-of-sight into the impact of their work and more insight into, appreciation for, and interest in each other's areas of expertise. Over time they become the connected generalists that the future requires in this new way of working.

Takeaways

This was a thought experiment, and a topical one at that. I don't think mature technology exists for all of this to work out of the box yet, but it may very soon. If this approach or something like it emerges, the new economics, experience, and potential of software engineering will make the curent way of doing it a bad memory.

Before you power up the flux capacitor, here are some strategic things to consider in your organization.

Address employment fears directly. People have every reason to worry about getting replaced by AI. That doesn't need to happen, even if we need to abandon the current norms and roles. When software engineering costs collapse, the work that was never worth funding becomes viable. We have an opportunity to reduce toil, eliminate perverse incentives, and empower many more people to do great things if we build the right systems around the new capabilities. People won't get left behind when there are more, smaller teams doing much more than ever before.

Optimize platforms. If your hosting and shared services are not self-service, they will quickly become the bottleneck. Platforms have many failure modes to consider, which may be a post for another day, but they should be a priority because of the change in scale. Focus on automation, metrics, policy enforcement, and feedback loops from consumers. If you neglect platforms, then people will likely create their own out of frustration.

Design for Conway's Law. Any time you tinker with a sociotechnical system, you must work with, not against, Conway's Law. The Thermostat exists because teams will naturally drift. Rotate people in and out of Software Teams to keep them aligned to the system components and not personal agendas.

Use the tools. When there are no clear best practices, the best thing you can do is build your own intuition. Use multiple agent harnesses. Try different models. Experiment with new platforms focused on these ideas. It will help you sort through the many inevitable hype cycles.

Prepare for rapid change. We are probably in the early stages of how this generation of AI will transform software engineering and enterprises in general. Nobody has this figured out and the models, tools, and norms are all likely to see continuous change. That's always true in IT but this time it's extreme. Design your organizations to handle this gracefully, even at the expense of a little fragmentation, to avoid getting locked into a specific vendor or approach.

The future could be a bright one if we are up to the challenge.