I stopped writing prompts. I write the repo.

For a year, the author honed their prompt-writing skills, crafting longer prompts, providing worked examples, and using careful phrasing. However, they noticed inconsistencies in the quality of responses based on the time of day. This inconsistency stemmed from the fact that the AI had familiarity with the codebase after spending an hour in the same files, whereas a fresh session lacked this context.

This realization marked a shift from prompt engineering to context engineering, focusing on optimizing the entire information environment rather than the request itself.

Applying this concept to their own work, the author recognized that the most effective way to convey important information was to write it down directly in the repository, near the relevant code or files. This approach turned what would have been long, generic documentation into concise, project-specific guidelines that could be easily updated and maintained.

The author cites the README.md file as an example, which serves as a guide for writing posts on the site. It includes fields like title, date, and draft status, as well as conventions for organizing content and images. By documenting these conventions within the repository, the author ensured that they would always be up to date and relevant, regardless of who was working on the project.

The author emphasizes the importance of writing not just what needs to be done, but why it needs to be done. A clear explanation of the reasoning behind a rule or convention helps ensure that it is followed consistently, even when circumstances change. This approach also extends to the codebase, where comments that explain the purpose and context of certain functions or files can prevent confusion and maintain the stability of the code.

One of the most valuable pieces of advice the author offers is to turn documentation into enforceable rules by using failing builds. By integrating checks that ensure certain files or URLs exist and are up to date, the author eliminated the need to constantly remind contributors of these important details. This strategy, combined with the use of automated pipelines that verify the constraints, ensures that the most critical aspects of the project are maintained and enforced without requiring explicit reminders.

By making the documentation part of the code and the process, the author created a self-sustaining system that reduced the need for external explanations and helped maintain the integrity of the project over time.