Programming Is Real Engineering, And AI Proves It

One of the recurring hobbies of the programming community is to self-righteously self-flagellate about how we don’t do Real Engineering^TM like those other engineering disciplines do, with their blueprints, and licensing processes for Real Engineers, and planning, and site testing, and all their wonderful formal processes that we so callously ignore. If only we could do more planning up front, and be more careful about what we’re doing, and copy all that other stuff they do, we could have better software that didn’t break as often.

My counter has long been that we they don’t do things our way not because our way is bad, but because they can’t. If someone building a hotel could just push a button to build out the hotel based on the moral equivalent of a Terraform file specifying that they want a 2-story hotel with 114 rooms, an extra large kitchen, an extra small exercise room, and no pool, and build the whole thing for $2.82, they would. Then if they could walk through, decide they want the pool after all, another floor and 52 rooms, and that once we see the building on site it becomes clear that we need a 2-floor parking structure under the building, and twiddle a text file, push a button, cleanly tear down the first building and put up a new one to the new specs for $3.17, they would.

If they could do this sort of thing, of course they’d change how they operate. All the process they use is a reaction to the impossibility of doing that.

Programming is unique among the engineering disciplines in how the blueprint also profoundly is a working machine. It’s not quite 100% true, for instance the cost of deploying one of those machines large-scale in the cloud is non-negligibly larger than simply having the code in hand, but it’s still way, way closer than in any other engineering discipline.

Moreover, even prior to AI, our blueprints were largely big piles of text, which our own tools were quite good at operating on. Few, if any, other engineering disciplines have the luxury of the degree to which our own art can be directly applied to improving our own art.

And I would say that the success of AI coding agents has proved once and for all that we had successfully built an engineering discipline so strong that we are also the first discipline that has been able to successfully run AI at large scale within our discipline.

Have you noticed that there are basically two types of textual models now? There’s the general-purpose AIs… and there’s the coding agents. Those of us who live in the programming world can end up with a very skewed view of the capabilities of AI right now, because in our world, they are incredibly useful in ways that are much more difficult to extend into other domains. They’re so uniquely useful that we’re the biggest use case that gets its own models trained up for them.

And the reason for that is precisely the high-quality engineering framework the software world has put in place over the years. We have unit tests. We have integration tests. We have QA. We have coverage testing. We have requirements process. We have highly structured ticketing systems. We have source control, which works really well on our textual code bases, and then we have incredibly solid workflows for having multiple developers work on the source control, reviewing each other’s PRs, structured mechanisms for speculatively deploying one of these branches to test them out directly. Comments, structured languages, libraries, types-as-assertions, mathematical proofs of correctness, the list goes on. Even projects that use only a portion of the tooling are pretty capable nowadays.

When I started in 1997, very little of this was in place. We were cowboys in control of large projects. But now what I consider the basic minimum acceptable engineering for any project that goes into source control is substantially more than was even available to me in 1997.

None of this is meant as any sort of triumphalism. The fact we have these things is a factor of the domain, not the engineers. We have them because in the programming world, they’re possible. If other domains could have this many mutually-self-improving mechanisms deployed they absolutely would. The progress in things like simulating entire cars for their efficiency, noise generation, aerodynamics, and all that before we even build them, for instance, is wonderful, a lot of work, and involves a lot of math, experience, and domain knowledge programmers don’t have. Every other engineering discipline has equally wonderful things they can show off. It’s not about the humans.

You can tell this stuff matters because of how the AIs function in our domain. It’s worth taking a moment to really watch how they work, as they are working on some relatively lengthy task for you. It reminds me of bumper bowling; link to a short video showing what it is. The AIs bang along all our bumpers; failing compiles, failing tests, failing integrations, error messages, all the bumpers we’ve built into our engineering process, and in the end they get a good result. But that good result is as much a result of all the solid engineering processes we have installed as anything else, because the AI without those protections rolls into the gutter relatively quickly. In those fields where the bumpers can’t be built as easily or in as great a quantity as we can have them, that’s what happens with the AIs.

And, again, it’s not that “programmers are awesome”, it’s that our domain is amenable to having all these bumpers in the first place.

Yes, humans work that way too. The bumpers were initially put in for humans. Often in my performance reviews I am marked as being “details oriented”. The reality is I’m not and never have been. If anything I’m the opposite in most ways that matter. I just learned how to make it so that once I considered one particular detail, I encoded it into unit tests or types or something so that from that point on that detail was covered, and the net of that makes me look “details oriented”. In reality I’m banging into those bumpers all the time too.

That’s the quality of the engineering process in the software world.

The success of coding agents in their current form is proof positive that not only is software engineering a real engineering discipline, but that because of the special local concerns within the field, it is a really good engineering discipline. If we didn’t have all those high-quality engineering controls, coding agents would be much, much less useful.

You can stop complaining about how we don’t do software engineering like the other disciplines now.