Why Systems Thinking Takes Center Stage in the Age of AI

I've spent the last year or so building software and tools using AI chats. The workflow often looked like this:

Prompt to give context and the goal. Have a conversation. Generate some outputs and start testing code little-by-little. Pasting in bugs. Opening chats to understand software packages I needed to learn more deeply. Getting things close and then coding in the missing points or cleaning up overly-complex code. Days later and many different chat windows, a working prototype emerges.

However, things have changed over this time period.

Models now have become "thinking" models. Outputs are no longer quick responses but a prompt-and-wait interaction has emerged. Claude Code and other command-line interface (CLI) agent tools have emerged and morphed. Context windows for these models has increased.

The result is my original workflow has become more irrelevant. I'm slowly noticing that these tools spend more time talking to themselves than me. So, a bad prompt or a vague description can cost time (and even move the responses into the wrong direction). A different workflow is needed.

Over the last year, ideas related to "spec-driven development" have gained traction. What this really means is managing what the AI coding agents build. Keeping them on track towards a specific goal. And, that's where systems thinking comes into play.

Some cases to prove the point.

Claude Code now implements a Plan feature and regularly asks you questions to clarify tasks. After clarifying objectives, it generates a task list to meet the specifications of the user.

Google takes it a further step. The new Conducter extension to the Gemini-CLI agent system. Conductor interacts with the user to generate specs as well as a plan. A plan that has phases of development and tasks lists. The result is a phase-based, plan with hierarchical specifications. A method very similar to the Systems Engineering practices put into place by NASA.

So, in other words, the thinking has shifted from prompting and vibe coding to a more systematic process. Processes often seen in large companies and organizations.

From vibe coding to systems

Vibe coding emerged under an assumption. An assumption that prompting an AI chatbot or agent, alone, can generate a working product. However, after giving some time for the hype train to slow down, holes appeared in this assumption.

Primarily, the total lack of understanding the code can lead to unmaintainable code. Endless loops of troubleshooting became a time-sink for more mature code bases. More so, the working code often worked only in ideal conditions, often ignoring edge cases and a wholistic viewpoint.

By the end of 2025, tools began moving into methods involving planning up-front, defining requirements, breaking down tasks, executing, and testing. Essentially, the systems engineering process.

Quoting NASA, the masters of systems engineering:

Systems engineering is the art and science of developing an operable system capable of meeting requirements within often opposed constraints. --NASA Systems Engineering Handbook

I've gone through that handbook years ago and have followed these agentic tools as they've developed, and I can tell you:

These tools are getting closer to a real process, but it is still up to you to setup a real system for coding with AI tools.

This leads me to two different methods to approach this.

Systems Thinking and Systems Engineering

One is a mindset. The other is a process.

Systems Thinking focuses on taking a holistic view of how components work together. Systems Engineering is a process for building reliable, complex systems.

Both have their place. Both are complementary.

One can start with Systems Thinking to get into the right mindset. And, it goes well beyond just general, rules-of-thumb; it gives you mental tools to actually analyze systems that often have surprising behaviors. This will help you designing your system and seeing how it behaves.

Systems Engineering is more about how to make things in an organized way. This is what the newest updates to Claude Code, Gemini-CLI, and OpenCode are about. These updates are about using documentation during development to guide towards a specific goal. More so, these artifacts morph as the project matures. These are the same themes and processes outlined in the NASA Systems Engineering Handbook: technical requirements, input documentation, output documentation from a development effort (that is subsequently used in later stages).

Agentic coding has now gone from using phrases like "vibe" to phrases like "artifacts". It is maturing quickly.

The interesting thing about the stage we are at: no one has really figured it out. Everyone has their own methods and opinions, but there is no convergence yet. So, it is a great time to explore this.

Some recent work by others

I'll briefly cover some of the work that takes into account this systems engineering approach. Although, they do not label it as such, these efforts follow similar mindsets of those in Systems Engineering.

A game developer creates a management system

Everyone using agentic coding tools knows that context comes at a premium. It is something that must be managed carefully, especially in large code bases. One such scenario involves game development. In a paper published end-of-February 2026, an independent game developer created a system using Claude Code that can work with a 100,000-line code base.

Here, the author created 3 specific agents that worked hierarchically. The first-tier agent relies on an extensive markdown file in the root of the project (i.e. CLAUDE.md for Claude Code users). It serves as the context holder. The second-tier composed of an agent factory, where domain-expert agents are produced. In the third-tier, an agent can be called to gather context from a MCP server housing much of the documentation of the project.

What's amazing about this example is not really the methods. It's the fact that the author is not a professional in software or AI. Instead, this person is a chemist doing development on the side. It points to the fact that this new, systems-level approach to development opens the door to people coming from outside of software development.

Agents OS framework

This is a framework setup by a YouTuber, Brian Casel. Brian pushed for spec-driven development back in 2025 on his channel. At that time, Claude Code was still new, missing many of the planning features it has today. So, he filled the gap with Agent OS.

Agent OS provided a set of instructions and code to implement much of the planning steps missing in these tools at the time. However, now, these tools have caught up. In fact, now, you could make an argument that framework became obsolete. However, Brian adapted and released a new, lighter version to leverage these new developments in Claude Code.

This example shows us that the field is rapidly moving towards this spec-driven development. It also serves as another example of a netizen offering a cutting-edge approach, which should give us all hope in making a dent in the new world of AI.

These last two examples highlight efforts to push towards a "plan before you build" mentality. One that differs greatly from the vibe-coding mentality. These approaches are systematic. They involve precise, extensive documentation that is updated and used by CLI Agent tools. These serve as living and morphing artifacts used by agents to guide their coding efforts.

The future software development is starting to look more like NASA and aerospace...

Coming up...

I am working on building a system around AI-assisted coding for myself. I'll share the journey and thinking as I go along. That way community members can learn along with me and get inspired to build out their own systems. Systems that work for their own purposes.

In the process, I'll also be reviewing the latest and greatest efforts by others striving for the same.

Be sure to subscribe to join this journey.