Engineering Context Is Infrastructure

In my journey furthering AI-amplified engineering, one major theme is becoming more and more obvious to me:

Engineering context is infrastructure.

Let me explain.

Giving AI access to your code and letting it do work is simply not good enough. It needs to understand the intent of what the software is supposed to do, how dependent systems interact with each other, the contracts they adhere to, the architectural decisions that were made, and the business rules that can't be easily inferred from code alone.

And I'm finding that the traditional definition of a “contract” is not sufficient.

Take an OpenAPI spec, for example.

A property might be defined as an integer, but what if the actual business rule is that it must be positive, no greater than 10, or has some other specific meaning under a specific condition?

Part of that can be expressed by the contract mechanism. Some of it simply can't.

AI actually changes this dynamic in a really great way.

We can describe those specific meanings and expectations in normal language alongside the contract. At least enough to give agents the context to both implement correctly against those rules and validate the code written to support them.

This means documentation is more than something a developer might read before making a change. In fact, we should be thinking about all documentation this way:

Architecture decisions. API contracts. Business intent. Engineering standards. Domain knowledge.

Organizations getting seriously deep into AI-amplified engineering need to make all of this discoverable, detailed, current, and AI-consumable.

And what's great is that AI can actually help us do this, too.

We already have AI generating more code. We should be focusing on giving it enough understanding of our systems that we can actually trust what it does with them.