Dark Factory Engineering and Programming as Theory Building · Chris Parmer

Been thinking a lot about "Dark Factory" engineering principles over the last few weeks.

Assume that the lights are off and you're no longer looking at the code. What systems do you need to put into place to:

trust and verify the output

steer and manage the work efficiently

I believe that these 2 objectives are the heart of the Dark Factory problem.

To steer and manage efficiently, I find that I need to maintain a mental model of what's being built (even if I'm not looking at the lines of code). This helps me know what features will come easy or require restructuring, what sequence I should build things, and what possibilities lie adjacent.

So what's a mental model of code? I stumbled across Peter Naur's classic essay "Programming as Theory Building" (1985) tonight which helped clarify my thinking. I pulled out some of my favorite passages below. Here's a copy of the essay in full.

On theory building rather than writing lines of code

[..] programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.

On what it means to know the code (er, the theory)

[..] a theory is understood as the knowledge a person must have in order not only to do certain things intelligently but also to explain them, to answer queries about them, to argue about them, and so forth. A person who has a theory is prepared to enter into such activities; while building the theory the person is trying to get it.

On having a mental model - or theory - in every day life

Even quite unambitious activities of everyday life may give rise to people's theorizing, for example in planning how to place furniture or how to get some place by means of certain means of transportation.

Where theory building goes beyond traditional documentation

The programmer's knowledge transcends that given in documentation in at least three essential areas:

1) [..] They can explain how [it] relates to the world that it helps to handle. [..] By far the largest part of the world aspects and activities will of course lie outside of the scope of the program text, being irrelevant in the context.

2) [..] can explain why each part of the program is what it is.

3) [..] is able to respond constructively to any demand for a modification of the program.

On the expectation that modifications to a system should be easy, given that they often require complete rebuilds in other fields of engineering

The expectation that program modifications at low cost ought to be possible [..] cannot be supported by analogy with modifications of other complicated manmade constructions. [..] in the case of buildings, [modifications] are well known to be expensive and in fact complete demolition of the existing building followed by new construction is often found to be preferable economically.

What systems can we put in place to understand the "theory of the program" and how it evolves? Would agents write tighter code if they held and evolved a broader theory of the program?

Maybe great agentic engineering is less about specs and tests and more about architectures and mental models.