Give your coding agent a glossary

Mixing domain language can cause confusion, and muddy the picture. Here is a good example: Imagine you are a software engineer and I ask you to build a DB transfer management system. Your first thoughts might be that you need to build some sort of database backup and restoration system - and your large language model (LLM) may think this too. However, your assumption in this example would be incorrect, because this system is within the financial advice domain, and DB normally means Defined Benefit - a type of pension.

As you can see from the example, the assumptions made can radically alter the picture. As your project grows these assumptions build up, making it harder for humans and LLMs alike to understand the purpose of your code. You can fix this problem by adding a glossary to your project - which can be a simple markdown file - your coding agents can then use this to resolve any ambiguities.

One of the great benefits of this is that you can now use less verbose language while still being precise with your intent. Sometimes it is helpful to invent terms for novel features in your product - the glossary helps keep you, your team and your LLMs aligned with a shared understanding.