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, ignoring social, economic and environmental concerns. The source of the divide might 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 help ensure the project runs correctly?
- Who depends on this code and how will I know if I broke something?
Once you've developed an understanding of the systems on which you're assigned, you can plot changes usually in a straightforward way. Some systems have strong conventions, which helps enforce standard data flows and workflows. However, this isn't true for bespoke software, or in-house expertise, where you need to come up to speed with the vernacular. Coming up to speed often starts with little changes to get familiar with the workflows. Then you expand what you do as your understanding of the workflows expands. Knowledge gets retained and spread through the team as you work on different things.
In existing systems, constraints often necessitate pantsing until you're up to speed. New contributors also discover additional constraints or help sharpen the product by codifying unclear design elements they run across. When AI delegates get used for work, little or no shared understanding of the system gets built.
When I hear "AI isn't improving efficiency for developers," this is where my mind goes. If you don't know the current state of the program, or the current problem itself, it's difficult to delegate work. Using "delegate" CLI-based AI to go from spec to output doesn't help with the underlying problem. When you're lost, the bottleneck to delegation is understanding. You can go into planning mode and then iterate a bunch trying to get an understanding of the systems you touch, but this only informs you on the interface boundary between new changes and existing code.
In existing code, an "assistant" AI ensures a PR follows code conventions. Autocomplete would recommend using the appropriate internal types and vernacular. An assistant can also help find program areas to look at to get started on a problem, but this augments understanding and doesn't replace it.
Green Fields
Developing a greenfield project provides a completely different experience. Stability falls behind features as the product need might not be complete yet. Codifying understanding of the problem proves less important than demonstrating value.
A limited runway necessitates speed, which means a subdivision of work. Most problems aren't solved yet and there are similarly fewer internal constraints needing to be maintained. Entire systems might be tossed out if they prove unusable or the product pivots. Code is an expendable asset in green fields because it provides capability. Code is a liability in brown fields because it constrains.
Greenfield projects slowly convert into brownfield ones as they age and solidify. Knowledge slowly converts from being only mental through an imperfect filter into code. Some things cannot be expressed directly though, which leads to some loss.
An AI delegate writing greenfield code is less risky since there are fewer possible conflicts. There's less code written by others and the authors know why things are being done and the history of the project. You skip the pantsing to learn the product and can jump straight into plotting with little or no code in your way.
Problems require some sort of expression in code to run on a computer, and an infinite number of programs can produce the same output. There's a wild difference between knowing how to solve a problem and expressing it in a way which is fast or prevents correctness mistakes. When dealing with an unfamiliar problem, some people, like myself, iterate on various ways of expressing solutions to that problem. Some of these can be clever and useful, like the ideas described in Parse, don't validate. This is pantsing of a different sort, of using code to learn about the problem. It's a sort of play, a source of joy in programming and how we gain experience. When I hear people describe AI stealing the joy of programming, this removal of "play to learn" is what it means to me. The process produces not just a product, but also knowledge.
Using an AI to generate a solution removes part of the rationale for this type of work. Inline code generation and research lets you move faster though by reducing obstacles. An assistant for code review though provides backup and additional insights.
Where to, from here? #
The knowledge of the system exists somewhere, whether in someone's head, or in a spec or in the code. Plotting maximizes the push of existing mental models into the world. Pantsing extracts mental models from the world and builds experience.
The critical issue is how AI usage affects the way software engineers think. These styles work together at various times for various reasons. A delegate AI converts existing understanding into code. Assistant AIs help convert documentation and code into understanding.
Using the wrong AI style can actively detract from the work being done. The important element seems to be using the right form of AI to support the type of development you're doing right now. Forcing a certain style of AI feels awkward, especially if it comes from someone above you. Are you plotting or pantsing right now, and how does AI support that?