There’s always been tension between the freedom of just building and the discipline of keeping everything documented in an issue tracker.
Issue trackers feel like a chore. But skipping them is an organizational liability—things slip through cracks, context evaporates, and you’re left wondering what you were thinking three weeks ago.
The classic challenge: when you create an issue, you rarely know if it’s one line or a complete rewrite. That ambiguity hasn’t gone away with AI—if anything, the “individual CEO with an agent” can pump through work so fast that the chunks become even harder to predict. What looked like a quick fix becomes a refactor. What seemed like a big feature falls into place in twenty minutes.
So why bother estimating upfront?
With AI, I can work more intuitively. Follow the thread. Let the code evolve. Stop thinking about whether this change maps to issue #47 or if I need to create #48 first.
Then, at the end of a work session: “Where are we?”
Review the diff. Reconcile with the tracker. Close what’s done. Note what emerged. File what’s next.
This takes time—but it enables a freer workflow. You’re not bound to issues during the work. You use them as a checkpoint after.
The key insight: issues aren’t just about planning forward. They’re about not losing track of things you’ve decided to defer.
That bug you noticed but don’t want to fix yet? File it. That refactor that would be nice but isn’t urgent? File it. The half-formed idea that came up mid-session? File it.
The tracker becomes a safety net, not a straitjacket.
None of this means abandoning structure entirely. Spending time in planning sessions—laying out the next phase, breaking things down with the agent—creates a solid foundation. You still want to know the broad shape of where you’re going.
But the granular, hour-by-hour tracking? Let that be looser. Work intuitively. Check in at boundaries.
The issues will be there when you surface.