Software and AI - Plotting vs. Pantsing

Software and AI - Plotting vs. Pantsing<br>18 July, 2026 - #ai

I've been wondering why people seem to love AI for their work, while others hate it. My curiosity revolves around usage of AI in the work itself, setting aside social, economic and environmental concerns. The source of the divide might partly be how AI affects the way we build understanding of software and problem domains.

Fiction writing, like software, requires managing many details in a coherent way. There are two styles of fiction writing: plotters ("planners", "architects") who work through their ideas ahead of time, and pantsers ("gardeners") who write by the "seat of their pants." Authors use both of these at different times but might favor one or the other. To avoid the misinterpretation that people only fit into one category or another, I'll refer to the behavior of these approaches as "plotting" and "pantsing."

Plotting in fiction writing is worldbuilding, writing character guides, and outlining the major story beats and arc before starting to write. Pantsing would be taking a few interesting characters and a setting, and just starting to write, figuring where the story ends up as you go.

These two approaches seem to mirror some software practices and approaches. My goal isn't to promote or denigrate either style, but rather to use this as a framework to think about software engineering and how it impacts AI usage.

Software "Plotting" and "Pantsing"

"Plotting" would be thinking through and developing a solution before any code is written. "Pantsing" would be treating the code as a main artifact and using that to think through the solution.

It's not perfect, but plotting emphasizes a top-down analytical form of construction, whereas pantsing focuses on creating from bottom-up synthesis.

The difference is how code is treated and where understanding lives. In plotting, code is an expression of the design, whereas in pantsing, it is the design.

For some people like myself, writing the code helps us build our understanding of the problem. Telling someone to have an AI write all the code isn't "taking away our work," it's taking away our understanding. When people talk about AI stealing the joy of their craft, this might be why, which would explain some of the divide in AI adoption.

Delegation versus Assistance

This seems to explain why AI usage differs in ease and usefulness. AI usage terminology seems quite blurry, so I'll define what I mean while using the umbrella term "AI" for these systems. The distinction doesn't split neatly between "agents" and inline editing or chat systems.

For plotting versus pantsing, the divide would be the autonomy and granularity with which AI updates artifacts. "Delegates" would be an AI which is given a goal and allowed to autonomously perform edits on the work products. "Assistants" would encompass the rest of work in which the human maintains control.

This would suggest that delegates support plotting, while assistants support pantsing. A delegate goes from high level specifications directly to a shipped product. An assistant collaborates with the human, such as for autocomplete, research, or code review. It's not important whether these happen with agents or a chat interface, but how their end products get used.

With definitions set up, how does this apply?

Real Life Application

Initially I thought plotting and pantsing might appeal to specific domains, but it seems to align with different types of work and levels of knowledge of the system.

Working in Existing Code

Many software developers work on projects that they themselves didn't write. Few programmers write main() and developers tenure on projects tends to be very short. It's also not uncommon to find a team with no original product authors left, but the business case for the software didn't leave. In this environment, the only way to learn how the software works might be to read the code and tests. This sounds straightforward, but mature systems surviving evolutionary development often have vestigial constraints and requirements. When dealing with older code, you need to learn the current system state. This gets worse when dealing with millions of lines of code and with intercommunicating and disparate systems, such as microservices created by different teams.

I've been a fresh face on existing codebases many times. There are often portions where human memory or departures result in unmaintained code whose design decisions or desired architecture are lost to time. That weird acronym that makes no sense? Yeah, its meaning is lost to time. For extremely large programs (>1 million lines of code), it's impossible to maintain a full understanding of the whole system. If you take a software engineer and parachute them into this system, they're starting from zero and running mostly in pantsing mode. The system is a pile of unknowns.

What's the architecture?

How is CI/CD set up?

What checks...