What does control mean, actually?

In the initial post of this blog I raised two questions I consider crucial for the way how we develop software with coding agents.

1. How can I give up control over the source code?
2. How do I stay in control of what the software does?

As pointed out at the end of the first post, I use the term AI-native development (AIND) as a name for a methodology that provides a consistent answer to those two questions.

Why the two questions above are so important has been discussed, but not the term they both use and are based on: control. So let’s look closer at what that means for each of those questions and if the meaning of control is different for them or if they are just views on the same topic from different angles.

Two kinds of control

Let’s start with control over source code. It means that I, as a human, fully understand the detailed structure of the source code well enough to jump into it at any given time and make correct, effective changes — without spending a disproportionate amount of time just reading. In a broader sense, it means the source code is organized and documented so that a human can comprehend it with reasonable effort, find the right place to apply a change, and work out an implementation strategy that blends smoothly into the existing structure — one that doesn’t break invariants, and doesn’t just bolt a balcony onto the side of the building.

Why does this even need saying, as if it were something new? Because until recently, control over source code came more or less automatically, as a side effect of who wrote it. A human wrote the code, at human speed, and could therefore read it back at roughly that same speed. Other humans obviously couldn’t. That relative symmetry is what’s completely broken now. A coding agent produces code far faster than any human writes it — and often faster than any human can even read it, let alone in a shape that reads as familiar. Control over source code, defined the way I just did, is no longer something I can get simply by reading, not because reading stopped working, but because nobody can read fast enough to keep pace with how fast it’s produced.

Control over functionality means something structurally different. It means that I, as a user-oriented stakeholder or an architect, can at any given time specify a functional extension to the software in my own, user-oriented language — without referring to implementation details — and have that feature actually implemented into the software, correctly. But “in my own language” cannot mean “as loosely as I like.” The description has to be precise enough, in the context of the software, to close off interpretation exactly where it matters to me — and leave it open everywhere else. It can never close that freedom off entirely: a specification with zero interpretive freedom left for the implementation isn’t a specification anymore, it’s the code itself, just written in different notation.

Same question, or two?

Are these two the same thing, seen from different angles, or genuinely different? I think the honest answer is: different, but not independent. Control over source code is about reading — building an accurate, cheap-to-form picture of what already exists so you can act on it without re-deriving everything from scratch. Control over functionality is about specifying — describing what should exist without first descending into what already does. One runs from the code outward; the other runs from intent inward.

You can lose either one without losing the other: a codebase can stay perfectly readable while nobody can extend it with new intent quickly, and a system can be trivially easy to redirect at the requirement level while being an unmaintainable mess underneath. So they’re not one question wearing two hats. They’re two separate failure modes that happen to share the same underlying obstacle — which is exactly why it’s worth asking what that obstacle actually is.

That’s where the next post picks up.