The New Reader
The real cost of shipping fast with AI isn't technical debt. It's organizational amnesia. Teams that engineer legible context now compound; teams that don't, forget themselves.
When I told my engineering team that for the next two weeks, even if we didn’t deliver anything of value it wouldn’t matter, they were surprised but also skeptical. Not skeptical that leadership was behind it, from the CTO on down everyone was supportive of what we were trying to do. They were skeptical that there was any shred of possibility we wouldn’t deliver anything of value. That filled me with a great sense of conviction and optimism as we started what I called our “vibe coding sprint.”
The Vibe-Coding Sprint
The challenge I proposed was simple: they weren’t allowed to write a single line of code. They had to prompt an agentic coding tool to do it for them, and yes, this even applied to simple one-line changes. The reasoning was that I wanted it to be a forcing function. I’ll be honest, the team was already well along in their adoption of these tools, but they had never tried to throw their entire day-to-day workload against them. Doing that requires either a high degree of trust in the tool or a great degree of freedom from leadership to experiment. Luckily we had the latter and were starting to recognize the former.
I’d love to end this post here and say that was it, that my engineering team never wrote a single line of code again, that we did a quarter’s worth of work in a month, that for the first time in my career I had to scramble to find work for the team to do. All of that is true. But the reality of how we’ve actually shifted the way we work is the more important story.
We hear a lot about how tech companies in Silicon Valley have engineers who’ve 10x’d their output, or how the model companies themselves are building amazing tools without writing a line of code, a recursive loop where AI is improving the tooling used to improve the AI itself. At our heart, Covetrus is a distribution company that grew into a larger and stronger technology business through a series of acquisitions. Like every modern enterprise, we live with the dichotomy of having systems that are both legacy and modern at the same time. But what’s also been true from the beginning is that we’ve looked to drive innovation within the veterinary industry, and that same spirit is what carried my engineering team to lead the charge with agentic coding tools and fundamentally change how we work.
Many people have said that writing PRDs is dead, and I do agree, but the thinking and effort that went into writing them hasn’t gone anywhere. It’s simply shifted. I told my engineering team that for major features, I wouldn’t write a PRD for them to consume. I was going to build my own prototype using the same agentic coding tools we all had access to. They agreed with the logic and were curious to see how it played out. I had heard that Claude Code’s creator, Boris Cherny, spent 90% of his time with the tool in plan mode, conversing with the AI before executing a single line of code. I followed a similar approach, making sure the model had absolute clarity on what I was trying to build. The same thought and effort I would normally put into a PRD, I put into the conversation with the LLM instead. This wasn’t just with Claude. I ran the same thought experiments with ChatGPT and Gemini, asking one model to review and criticize the plan from another, generating multiple versions of the same solution through different models and comparing them. I was building real product sense across platforms while sharpening my thinking at the same time.
In the past, getting feedback on a PRD meant relying on one or two trusted people whose judgment I valued and whose time I had to work around. Today that’s shifted. Rather than asking people to review a document, I ask them to react to a prototype, and this difference matters because it changes what feedback is actually about. A prototype requires less upfront time from the reviewer. It can be put in front of customers just as easily as coworkers. Instead of asking someone to visualize a solution from a written description, you’re showing them something real and asking the most valuable question of all: does this work for you, and would it work for our customers?
Building a prototype also forces you to think beyond the document. You have to make decisions about the technology stack your product runs on, decisions you would normally arrive at through back-and-forth with your architecture and engineering teams. You have to make calls around UI and UX. Seeing something being built in real time and interacting with it changes the nature of the conversation entirely.
I saw this play out most clearly with one of our VPs, Andrew. I showed him a new UI designed to present information more clearly to our customers. He had suggestions and feedback we could work through together, watching the agent make those changes in real time. After a few quick iterative rounds, we decided to bring in some Sales leaders for their perspective. They agreed we should test the new UI with a subset of customers and gather feedback, using the same A/B testing and discovery frameworks already in place. Because the veterinary industry is vocal and the people in it are passionate, we knew we’d hear quickly if something didn’t work. When my engineering team eventually saw the redesigned UI, the data requirements became immediately clear to them. The conversation around latency and tradeoffs that followed was more grounded than usual because everyone could see what we were actually building. We walked into that standup with 30 minutes allocated and left an hour later with genuine clarity on both the business impact and what to build next.
Engineering Context for Agents
My lead engineer Jason was the one who pointed out that we should still document this, because good documentation matters when you come back to something months later. I agreed, and for two reasons I’ve come to think about more carefully since: AI needs context about a product to generate its best output, and code can tell an agent how something was built but not why we built it that way or why we made the decisions we did. I didn’t spend the next four or five hours writing the PRD myself, though. I had AI write it for me, and not in the simple “read through the code and fill out this template” way. I fed it both the raw transcripts from our conversations and the summarized meeting notes, deliberately, because each serves a different purpose. The summarized notes are built for humans who already know the product; they assume a baseline understanding that an agent doesn’t have. The transcripts are noisy as meeting documents but rich as product context, full of specific friction and reasoning that never makes it into a clean summary. I asked the agent to comb through both and extract what it would find genuinely helpful to know about the product. What came back wasn’t just a PRD. It was a knowledge layer built for a reader that thinks differently than we do.
A few weeks later, that context layer paid off in a way I hadn’t anticipated. We were wrestling with a real design problem: a dashboard showing two numbers that lived on different timelines, one refreshing every day, one updating only once a month. Users loved the daily refresh because it let them track their own progress informally throughout the month. The tension was real and the clean solution wasn’t obvious. When we brought the problem to the agent, it already understood what the product was for and how users were actually using it, because we had told it, not in that moment but weeks earlier when we built the context in the first place. The solution it suggested was intuitive in a way that would have taken us several more conversations to reach on our own. The agent wasn’t guessing. It was drawing on an understanding of the product that we had deliberately engineered into it.
The organizations that skip this step will feel the cost of it in a way that’s familiar but harder to trace. There is an old problem in engineering where one person carries the entire architecture of a system in their head: the decisions made, the alternatives rejected, the constraints that shaped every tradeoff. That knowledge staying in one person’s head makes them a bottleneck. Every new team member, every design decision, every incident that touches the system runs through them because no one else has the full picture. Documentation exists to solve this problem, to distribute the why alongside the what. But as teams build faster with agents, the context agents need isn’t just what a new engineer would need. It is the intent behind decisions, the reasoning that didn’t make it into the code, the direction the product is moving and why. Without that, agents will always run back to the person who knows. The bottleneck doesn’t go away. It just moves.
The core shift is this: your organizational knowledge now has a new reader. Meeting notes, decisions, trade-offs, the why behind everything, all of it needs to be legible not just to humans but to agents. This isn’t a documentation problem in the traditional sense. It’s a different kind of engineering, one most organizations haven’t started yet because the urgency hasn’t felt immediate. It will. The context you build now compounds as models become more capable, and better context yields exponentially better work from agents that are already improving faster than most teams can track. The inverse is also true. Organizations that build fast and leave no context trail are building machines that ultimately forget them, accumulating capability without accumulating understanding. I wrote about building the individual version of this infrastructure in my last post, what I called an Open Brain. The principle scales. An agent can only be as good a thought partner as the context you’ve given it to think with, and the organizations that understand this now will have a structural advantage that only grows over time.
This is why the PRD is dead. We’re not building context for humans anymore. We’re engineering context for agents.
Closing Thoughts
Today, our team spends roughly 20% of their time writing their own code and 80% of their time directing agents. We’ve shipped significant features and quality-of-life improvements over the past quarter, with more planned. Andrew now builds his own mockups and prototypes, including an entire subpage within our product that he designed in collaboration with our marketing team and that we implemented with a few design and color changes. The team itself is leading the adoption charge and helping drive the rest of the organization toward what’s possible.
When I started my Product career, I didn’t do it so I could spend days writing a PRD that only half of my engineering team would half read. AI has given me the ability to get back to the core reason I chose this path: the ability to build things that could have meaningful impact. A Product Manager committing PRs to the codebase they’re responsible for once sounded like a pipe dream. It’s starting to feel like a baseline.