I’ve been building software the same way for most of my life. I get the best results when I start with a clear, simple idea and then I try to do something with that idea, in the form of working software, as soon as possible.
The momentum always starts with a little spark... an intuition about a problem or an arrangement of concepts that makes a simple idea stand out and look obvious. Usually this turns into a prototype. It feels good to sit down and start smashing out a new project. The spine of the thing starts to take shape, and those first builds barely have an interface that does anything, but the work is alive and it has velocity.
Then, as soon as possible, that it-barely-does-anything version of the software needs to be put to the test. It needs to be used to do the simplest version of the thing it was designed to do. If it falls short, it’s usually pretty obvious where and why. If it works as well as you imagined, then expanding the thing comes naturally.
I’ve built hundreds of pieces of software this way. It always works.
Getting something working as soon as possible, and then trying to actually do something with it... that’s the secret sauce of my entire software career. I call this approach: orienteering.
Orienteering is a group of sports in which participants use a map and compass to navigate from point to point in unfamiliar terrain as quickly as possible. [https://en.wikipedia.org/wiki/Orienteering]
Orienteering is the most accurate description I have for how I solve problems and make things with computers.
The software and all of its descriptions (the code, documents, etc.) are the navigational aid. The work I’m trying to accomplish or the problem I’m trying to solve using the software... that’s the unfamiliar terrain. Orienteering is crashing those two things into each other and learning from the result.
Thinking about the software as malleable tooling that’s helping me to accomplish the real work keeps me more focused, which usually results in better software.
just prompt better
Standard agentic development in late 2026 has a gravity that pulls you into a mode where you’re effectively designing a “one-shot.” You’ll have these chats where you’re describing outcomes to an agent and having a dialogue that results in something like a design document, which gets handed to implementation agents like they’re a sweatshop. There’ll be reviews and various checks and balances and such. You can get quite sophisticated with this style of building.
The size and shape change, but you’re always more or less building a request for work to be done, and then handing the work off to agents. Your level of engagement in the process can vary, but usually the code is built by language models. If you’re careful, you’re reading a lot of code you didn’t author.
This style is actually a lot like the old “waterfall” approach that people hissed at 20 years ago. You get something that’s often a “telephone game” version of what you envisioned, and then you have to give agents notes about where it needs to be fixed, all the while hoping that it doesn’t get twisted into a pretzel as all the oopsies get patched. Sometimes people brag about processing large numbers of pull requests or how long their agents can run without input when building things this way.
A large chunk of your new system meets reality in one fell swoop with this approach. All of the opportunities to orient the implementation and for you to be involved in shaping the architecture along the way have usually been eliminated or vibed-over, and you end up needing to explore and vet a large amount of change, retroactively trying to insert your ideas into the software innards.
With care this approach can produce great work. I’ve built very successful software this way. But this approach also keeps you away from the implementation details while they’re being made... this is still a one-shot. Trying to describe your way to a high-quality system can feel like a hazy, bizarro-world version of software development... and it’s not particularly fun when there’s real-world pressure.
I’m not ready to entirely throw away the one-shot approach for every project. There’s a speed-for-quality tradeoff with the one-shot that’s highly useful. But it’s not necessarily the best choice for your most important software.
the vertical slice, yo
No matter how you approach it, software is a learning discipline. The terrain is revealed to you as you orient to it. There is always some amount of work involved in finding your way and the result is always better for that specific effort. Agents can’t do that part for you, even if they think they can.
I have a couple of moves that I’ve always enjoyed as ways of getting new software airborne. There’s one move in particular that I’ve been thinking about a lot lately... it feels like it could be an antidote, and a way to get more connected with the result... it feels more like software development from the beforetimes, as I remember them.
When I used to lift software onto my shoulders and carry it over the terrain by hand... I liked to build a thin vertical slice of the new system, first. I would start with some domain structures... add logging and a CLI foundation. Then code that defines the way the software interacts with the environment. Get any API bits worked out, and generate client and server stubs. I’d rough in a couple of the endpoint handlers, so I’ve sketched in the approach for organizing the logic in the system. I’d make sure I’m calling that API even when it barely does anything. And those minimal user interfaces are always fun to rough in.
It can be a bunch of grunt work, but it gives me a solid spine across all of the important areas of the new system. I usually do this kind of work in very similar ways every time... I have an approach that I curate and stick to. Obviously language, idioms, and the type of application are all considered... but the core of the approach, the energy of it, is subject-agnostic.
Expanding outward from the vertical slice always keeps me intimately involved with the design of the code. Choosing these foundational details gives me a lot of opportunities to orient the system early on... are these fundamental choices going to work for this problem? Is this arrangement of components going to support the kinds of verbs I want to hang on them? Does a CLI make sense here? Getting this foundation right helps to maintain a coherence you don’t get any other way.
I’m working on pulling this style of building into a redesigned pipeline for working with agents that feels more like developing software and less like writing a product brief. More time in code, less time in chat.
let’s build this
I’ve designed the core of my practice around something I call my grimoire. My grimoire is a combination of structured, curated, wiki-style information, and a set of tooling that allows me to bring that foundational structure into all of my interactions with agents. It really is the backbone that allows every agent to wake up and immediately comprehend my entire working constellation. It saves my energy to have agents already understand where my mind is, rather than having to re-explain the universe to them every time, for every project.
I created the initial concept for my grimoire early on in my work with agents. It seemed like one of those clear, simple ideas. As my approach has become more nuanced, I’m starting to imagine an even more flexible core structure that gives me better control over the shape of my work... including things like incorporating the vertical slice maneuver.
I’m going to build that new, better backbone for my agentic practice on this website, in this series. The build, the thought process, the ideas, the design... and eventually all of the code will get published right here. You’re welcome to follow along and take whatever is useful to your own practice.
Next installment we address the core ideas for the new grimoire.
credits
These are all my words. I’d make Claude put on funny glasses and ask it to pretend to be an editor while I asked it awkward questions about what it thinks of my writing. But it’s my writing.