PRINCIPLES / HOW I WORK
Working with AI without losing the thread
I can start more work with AI in an hour than I can properly absorb in a day. Research, implementation and writing move quickly. My attention, judgment and understanding do not speed up in the same way. That gap is the reason for this framework.
These are four rules I use in my own work. They are not a formula for everyone, and I expect to change them as I learn. They help me keep responsibility for the work even when an agent does much of the execution.
01 · Limit active work
It is easy to confuse the number of agents running with the amount of work I can actually manage. Every active thread leaves a piece of state with me: what I asked for, which assumptions we made, what changed, what still needs checking, and what decision comes next. An agent may be busy in the background, but the result still needs a human owner.
When too many threads are open, I spend my time rebuilding context rather than moving work forward. The unfinished decisions accumulate even if every agent reports success.
My rule: keep roughly three or four cognitively active workstreams. That number is a personal working limit, not a claim about how many agents a person can run. I capture new ideas without immediately turning each one into another live task. Before starting something else, I finish a thread or deliberately put it on hold with a clear next step.
02 · Leave room to consolidate
Before AI, difficult work contained natural pauses. A build ran. I had to work through a problem by hand. I stepped away from a screen and returned with a different view. Those intervals often held more thinking than I noticed at the time.
AI can remove almost every pause: ask, read, redirect, generate, review, ask again. The stream can continue all day. But receiving an explanation is not the same as making it part of my own thinking. I need time to sort out which details matter, where I disagree, and what I would do differently next time.
My rule: make regular space with no new input—no laptop, phone, agent reply or podcast. A walk, a drive or quiet work outside can be part of the engineering process. The useful question when I return is not “How much did I produce?” but “What do I now understand, and what deserves attention next?”
03 · Control the pace of explanation
This framework grew out of a conversation that demonstrated its own problem. I brought an intuition; AI returned a wide, articulate map of related ideas. Much of it was useful. I could not absorb all of it at once, and a short conclusion was not enough to give another person the understanding I had built along the way.
I think of this as a compression and transfer gap. AI can compress a long line of reasoning into a page. The reader still needs examples, objections and time to make sense of it. Passing along a polished answer can transfer information while leaving out the path that made the answer meaningful.
My rule: for important subjects, work one conceptual layer at a time. Start with a question or an example. Let AI expand it, challenge the result, connect it to experience, and only then move outward. Sometimes the best answer is a smaller one that leaves me able to think, explain and act.
04 · Keep a mental model of the system
Software engineering has always used abstractions. I do not need to know every transistor or every line inside a library to build something useful. AI adds a different kind of distance: it can hide some of the reasoning that led to an implementation, not only the mechanics of the implementation itself.
That matters when a system changes faster than the people responsible for it can understand it. Tests can pass while nobody can explain an important boundary or predict what will happen when a dependency fails. I call that understanding debt: the gap between what a system does and what its owners can reliably reason about. It is a useful warning sign, not a metric I have solved.
My rule: before accepting a significant change, I should be able to explain its purpose, the main components and boundaries, its assumptions, likely failure modes and the evidence that it works. I do not need to remember every line. I do need enough understanding to make the next decision and take responsibility when the system behaves unexpectedly.