I’ve noticed documentation becoming a much bigger part of my day-to-day, especially when building with AI.
Before, we would write a lightweight outline of a system or feature we were building, then focus on adding detail only around the nuances, constraints, and behaviours we cared about most. Outside of PRs, however, the documentation was often light. Not because it was not valuable, but because it was time-consuming, and time often felt better spent writing code.
AI has changed how I think about that.
AI’s context limitations have forced me to manage context more deliberately, which has made me better at articulating what is required. Part of that is due to how much LLMs have improved, but part of it is also because I have become more deliberate in how I frame instructions.
In some ways, I now communicate requirements more clearly to AI agents than I did when leading human teams. That is slightly uncomfortable to admit, but I think it is true. Mastery of language has never felt more important, which makes sense given that the core interface is conversational. As AI usage becomes a real cost line, the ability to reach the desired outcome with less wasted context and fewer dead-end iterations will matter more.
A vague directive like “improve onboarding” is almost useless unless the intent behind it is clear. Are we trying to reduce drop-off? Shorten time to activation? Help a specific user segment understand the product faster? The AI can generate options, but we still have to define the target.
I have also found real value in being able to revisit the original intent behind a decision. This is especially useful when making larger design changes, because documentation becomes more than a record of what was built. It becomes a record of why it was built that way.
That distinction matters.
It means those initial thoughts can be reviewed, challenged, and validated against newer, more capable AI models as they emerge. It gives us a clearer way to test whether the core reasoning still holds, or whether it needs to evolve.
A lot of us have felt that, with the coding part of engineering increasingly being done by AI agents, a large part of the value in the practice may have been lost. However, I think it has only shifted.
More of the work now sits before implementation: understanding the user, clarifying the problem, identifying the constraints, and translating all of that into requirements that do not flatten the nuance.
This is also why I believe the core idea of what an MVP should be is still sound, but it looks different when implementation becomes cheaper. There is still value in building the smallest useful version that helps you learn. But when the cost of reaching a baseline level of quality falls, there is less excuse for shipping something confusing, careless, or needlessly rough.
As always, the ability to clearly communicate to your target audience is incredibly valuable. In the age of AI, that becomes even more important, because when you communicate with AI agents, there is no ego to manage. They do not care how intelligent you sound. They respond to the directive, the context, and the constraints you provide.
The bottleneck, more often than we like to admit, is still us.