When AI Starts Building the Software

We are currently in a phase where AI tooling is focused primarily on speeding up the individual components of the SDLC. Advanced teams have implemented AI across nearly every stage, from requirements gathering to design, development, testing, and production support. That increasingly creates a “constraint hunting” exercise, where teams continuously look for the next bottleneck limiting feature throughput.

The next evolution will be a reimagining of how we deliver digital products altogether. Instead of a static design-build-deploy construct, the next generation of AI tooling will allow applications to ingest user activity, whether human or machine, identify opportunities, and autonomously build and test features against business value.

Developers then begin to partner with AI not simply to build systems, but to build the systems that build systems.

The truth is that in software engineering, tools, architectures, and capabilities have always been continuously changing. The most effective teams are the ones that learn the fastest. Adaptive teams tend to focus on four things:

Curiosity: Adaptability starts with encouraging people to look beyond their immediate scope. When teams are given space to experiment, they discover new ways forward that rarely surface when it is simply business as usual.

Collaboration: Adaptive organizations break down silos and prioritize lightweight, transparent knowledge-sharing. This allows ideas to move quickly and keeps teams aligned as the pace of change accelerates.

Variation: Adaptability depends on diversity of thought, skills, and approaches. By rewarding novel ideas and solutions, leaders help teams challenge assumptions and uncover better ways of working.

Risk tolerance: Even with high levels of curiosity, collaboration, and variation, people will not experiment if failure feels too costly. Leaders need to make risk manageable, provide clarity around what is safe to test, and treat setbacks as opportunities to learn.

The organizations that thrive through periods of rapid change are rarely the ones that predicted the future perfectly. They are the ones that built teams capable of adapting when the future arrived.

Bad code is hard for machines to read too.

Human judgment and experienced software architecture remain vitally important in constructing systems that are maintainable, extensible, efficient, and resilient. Recent concerns around the growth of “AI slop”, the brittle nature of vibe-coded applications, and the homogenization of visual design are all indicators that judgment, taste, and engineering training still matter.

AI can dramatically reduce the effort required to produce code, but producing code was never the entirety of software engineering. Architecture, tradeoffs, maintainability, security, operability, and understanding what should be built in the first place all require judgment, taste and training. The distance between a vibe-coded application and a production-grade digital product has always been engineering rigor.

As the cost of producing code continues to fall, building the right thing becomes even more important.

One of the core shifts from waterfall to agile was recognizing that the user is the source of truth for what an application should do. Agile development therefore emphasizes iterating software, incorporating user feedback, and continuously evolving the product toward what users actually need.

AI tooling now enables the fastest iteration cycles we have ever seen. That means we shall be able to evolve software faster than ever before, but speed without direction can simply allow teams to move in the wrong direction faster.

UX plays a critical role in grounding that velocity in an understanding of who the user is, what they are trying to accomplish, and what outcomes actually matter. Without that grounding, we risk a meandering series of changes that never truly delights the user or achieves the objectives of the product we are building.

I expect to see a significant blurring of roles.

AI expands the effective skill set of every discipline. Project managers can prototype. Designers can code. Developers can write stories. Engineers can explore user experience ideas. The boundaries between disciplines become much more fluid.

As that happens, the responsibility of each person becomes about more than simply what they personally know how to do. It becomes about how they use those expanded capabilities in partnership with the rest of the team. The goal is ultimately the same: creating teams that are greater than the sum of their parts.