Source Code Is Becoming a Build Artifact - Accemic TechnologiesSkip to contentMenuSearchSwitch color theme<br>EscSearches titles, sections and text. ↑ ↓ to move, Enter to open, Esc to close. Opens with / or Ctrl+K.<br>Contact
Source Code Is Becoming a Build Artifact<br>Engineers have programmed systems through physical configuration, assembly code and languages such as C, C++ and Rust. Each higher layer delegated more translation to tools. In disciplined embedded development, requirements already guide the human implementation.<br>AI may now change which layer engineers author directly: precise requirements, controlled design inputs and acceptance criteria can become the reproducible basis for generated code - but only if the result can be accepted without trusting the generator's own verdict.
Written by Alexander WeissPublished 2026-08-20
There is a pattern in the history of software that becomes easy to overlook<br>once a new abstraction has become normal. Engineers move the point at which<br>they describe a system. The lower layer does not disappear; it becomes<br>something a tool produces for us, and we go back to it only when we have a<br>reason.
These examples overlap historically. They are arranged by abstraction level:<br>the point at which a human describes what the machine should do.
At the lowest level, that description can be physical. Connections, switches,<br>coefficients and machine configuration embody the computation directly. At the<br>next level, symbolic instructions describe machine operations. With high-level<br>languages, engineers still implement against requirements, but they express the<br>solution as algorithms, control flow and data structures while the compiler<br>translates it into machine instructions. AI-based development may delegate one<br>more transformation: from controlled engineering intent to candidate source<br>code and tests. Requirements are not new; what changes is how directly they<br>drive the implementation.
Programming close to the machine. On the EAI 580 analog computer (ca. 1968), physical connections, functional blocks and parameters embodied the calculation directly. Photograph: Tomwsulcer, CC0.<br>Early computing makes the abstraction boundary unusually visible. In a machine<br>like this analog computer, the intended calculation is expressed directly in<br>the physical configuration of the machine: connections, functional blocks and<br>parameters become part of the program.
The machine in the photograph dates from 1968, long after stored-program<br>computers and FORTRAN already existed. It illustrates coexistence, not sequence:<br>lower and higher abstraction levels remained in use at the same time. What<br>changed was the level at which more engineers could describe the result they<br>wanted and delegate the translation to another layer.
Physical configuration
Physical configuration Machine instructions / Assembly code
Machine instructions / Assembly code C / C++ / Rust
C / C++ / Rust Requirements<br>and acceptance criteria
Requirements... Text is not SVG - cannot display<br>In disciplined development, requirements guide every implementation path. The pyramid shows the layer engineers author most directly - and how much of the translation to machine execution is delegated to tools.<br>We have made this move before
The more important transition was not from one particular machine to the next,<br>but from one level of description to another. High-level languages made that<br>shift consequential: programmers could express algorithms in a notation<br>designed for humans while a compiler took responsibility for translating them<br>into machine instructions.
FORTRAN moved that boundary dramatically. Programmers still implemented<br>required behavior, but they no longer had to express every operation in the<br>vocabulary of the processor. The quality of the compiler’s translation -<br>especially the efficiency of the generated code - became the central<br>engineering question.
When John Backus and his team developed FORTRAN in the 1950s, programmers were<br>skeptical of automatic programming, and for good reason. Skilled programmers<br>knew their machines intimately and could produce very efficient hand-written<br>code. A translator that produced poor code would not have been useful simply<br>because it made programming more convenient.
Backus later wrote that the FORTRAN team believed their system would only be<br>accepted if the generated programs came close to the efficiency of hand-coded<br>ones. The compiler was therefore not an afterthought; it was the central<br>engineering problem. Once that problem was solved well enough, the level at<br>which programmers worked changed surprisingly quickly.
Assembly code as source. A Motorola 6800 assembly code listing from 1980. The source and generated machine bytes sit next to each other. Image: Michael Holley, public domain.<br>A higher-level language, still very physical. A FORTRAN punch card created in 1971. Image: Tangopaso, public domain.
Looking back, it is tempting to describe that transition as the replacement of<br>one skill...