I’ve been trying out new AI tools consistently for a few years now. While the tools and setup have changed, I’ve been consistently moving towards a particular way that I think of work.
Tools are fungible now. An interface bolted onto some CRUD operations isn’t worth much anymore. And everyone’s FOMO is running at an all-time high, so the whole industry is sprinting after whatever new tool, harness, or model dropped this week. Building your own custom tooling has never been cheaper, either. In economic terms: switching costs for software keep dropping, and it’s not going to stop.
The best way to actually take advantage of this flexibility is to change how you do work, and in a way, change what “your work” even is. In practical terms, that’s meant adding more and more context to my notes: background, decisions, considered alternatives, next steps. And as more context piles up, decisions become increasingly valuable as anchors in a growing sea of information that otherwise has no shape. That’s also why I’ve gotten more disciplined about what I actually keep.
Meeting recordings are a good example. When Gemini added multi-modal support, I ran it against a batch of meeting recordings and compared the output to the native Zoom transcripts. Gemini’s transcription was meaningfully better. But when I fed both transcripts to an LLM and asked it to analyze the meeting, the better transcript barely moved the quality of the analysis. I got marginally better todos because of its transcription accuracy, but the actual directional judgment, what it meant for me and my work, still had to be made by me.
Which raises the actual question: what makes an analysis good? Accuracy is too reductive. “Good” needs to serve a purpose, and that purpose depends on where it’s going. I probably would’ve gotten marginally better results with transcripts saved from every meeting I’ve ever had. I also would’ve buried myself in dozens of irrelevant assumptions the LLM threw my way.
This leads me, somehow, to atomic units of work.
What Makes a Unit Atomic
Atomic work is a decision, distilled small enough to be portable between different systems and tools, carrying enough context to support a variety of situations.
Portable, because tools naturally gravitate to the simplest standard (image files for generative image models, markdown for LLMs, CSVs for data).
Decisions, because raw context just ends up as noise.
Context, because trimming off all the fat leaves it too anemic to properly fit into other situations (really stretching the metaphor here). The context is what gives it room to flex into a use case you didn’t plan for. Keeping that history has a second benefit too: a running record of decisions, not endlessly re-litigated and not ignored either, is what actually tells you where to go next.
The opposite is a unit created already overfit to one destination, like a slide, a ticket, a template. It looks finished, but is actually just brittle. Outside its intended environment, it implies far more than it says, and you end up working backward, fluffing it back up just to make it fit somewhere else.
Portability isn’t something AI grants after the fact. It has to be preserved at the moment of creation.
Why This Wasn’t a Problem Before
The old workflow was simple: use a tool to shape an idea, then use that same tool to manage the idea going forward. Preserving portability didn’t matter when reshaping only happened rarely and by hand. A PRD lived and died as a PRD. Nobody expected to get the original thinking back out of it in a different form, so it didn’t matter that the form was all that survived.
AI changes what’s reshapeable. Point the smartest model in the world at a document that was compressed into a single schema too early, and it will confidently generate something plausible from what’s left — but the actual truth of the original discussion is already gone. Preservation gets decided at the moment of creation, not after.
Example: PRDs
Take the standard chain of BRD, PRD, wireframes, then user stories. The reason this needed so many separate documents is that each one exists to build an argument for a different audience: the BRD argues to leadership, the PRD argues to design and engineering, the wireframes argue to whoever signs off on the experience. A PRD was always the big piece of granite, chiseled down stage by stage, until something small enough to generate code fell out the other end.
AI-native PMing has a tighter chain, because the PRD is going straight into a coding agent. This works best when the PRD carries enough surplus context around the business case, the customer insight, and the reasoning behind the decision, not just the decision itself. Skip that, and you haven’t tightened the chain, you’ve just fed the agent a thin artifact. You’ll get code, but you’ll be missing the underlying thought around which metrics were supposed to move. That’s the part that has to survive, otherwise the downstream speed means nothing.
Example: Bevel
Apple Health, outside of being a health database, is garbage. I’ve been using Bevel regularly, first as a nice skin on Apple Health data, until it did something Apple Health never managed: it got me to start tracking nutrition too.
Nothing about Bevel is cutting edge. It’s a UI on top of proprietary data with an LLM chat assistant bolted on. I could not think of a worse strategic position for a product. Yet it got the atomic unit right for health apps: the input process. It decided which inputs were worth asking for, made logging them easy enough that I’d actually do it, repeatedly, and made the feedback loop tight enough that doing it felt worth it. Each new data source meaningfully expanded the value of existing data. For flexibility, the chat assistant and memory logs decompose other data into the same atomic units Bevel already knows how to analyze.
That’s the entire mechanism, and it works. I’ve been logging every single thing I’ve eaten for the last four weeks. Best-in-class was not the goal. Good enough, done consistently, beats best-in-class, done never, every time.
The Moat
When every AI product is running roughly the same underlying models, the intelligence stops being the advantage. Neither is the interface, or integrations. Data portability mandates finish off whatever was left of the old lock-in playbook.
What’s left is habit. It’s whether the product makes capturing the atomic unit — the input, the insight, the thing worth keeping — low-friction enough that people actually do it, again and again, without being asked twice. Everything downstream, every reshaping, every clever use of AI on top of that data, only works if the atomic unit makes it in the door with enough context to mold. That was true for the meeting. It’s true for PRDs. It’s true for Bevel. It’s probably true for whatever you’re building.