From Stonemasons to Carpenters - by Michael Hilton

The Last Software Engineer?SubscribeSign inFrom Stonemasons to CarpentersSoftware Development in the age of AIMichael HiltonSep 17, 202621ShareMy grandfather spent his career building bridges, overpasses and box culverts up and down the central coast of California. Despite these being concrete structures, his occupation was that of carpenter. The reason he was a carpenter is because they would build large wooden structures, which would then create a form (essentially a mold for the concrete to be poured into). This is something that I keep returning to when considering how the software industry is changing because of AI, and specifically the ability to generate source code.Photo by Joao Aldeia from PexelsHistorically, bridges were built by stonemasons. They would directly manipulate the material (stone) as the bridge was being built, and as they put more stones in place, the bridge would incrementally grow till it achieved its final form. Famously, the Romans would not even need to use mortar in their construction.Thanks for reading! Subscribe for free to receive new posts and support my work.SubscribeHowever, the current construction techniques are quite different. Currently, most bridges are built out of concrete. When my grandfather built these structures, he and his crew were not stonemasons, nor did they incrementally build the bridges piece by piece. Instead, they were considered carpenters, and spent the majority of their time building the wooden forms so that the concrete could be poured to make the final bridge. This is a significant change from how stonemasons built bridges.Photo by Jean-Paul Wettstein from PexelsSo how does this analogy apply to coding in the age of AI? I propose that software development is moving from an age of stonemasons, to that of carpenters. Historically, software developers were more like stonemasons, working directly with the medium (code vs stone) and incrementally building systems one stone (Line of Code) at a time. However, due to the emergence of AI code generation, I propose that developers should see themselves more as bridge-building carpenters. Instead of building the system up incrementally, they are building the forms (adding structure to the system via tests, documentation, guardrails) that allow the code to then be generated correctly. This requires a shift in how software is developed, and I believe has significant implications.Implications for developmentEveryone is a Product Manager nowHistorically, there has often been a sense that development was “real” work, and that project management was somehow less technical/valid. However, now that every developer is forced to focus on the boundaries/interfaces of the software they are building, and not just think about the internals, essentially every developer is being asked to become a Product Manager. Instead of the most important question being “how to build this”, or “can we build this”, now the most important question is “what should we build”. Having to think in this way will be a big shift for many developers.Software Engineers doing more Software EngineeringOne definition of Software Engineering is“Software engineering is the branch of computer science that creates practical, cost-effective solutions to computing and information processing problems, preferentially by applying scientific knowledge, developing software systems in the service of mankind.”Note that this definition does not directly reference the writing of code, but instead the building of systems. The work of creating practical, cost-effective solutions is more relevant now than ever, and as the cost of writing the source code decreases, the developers job becomes dominated by the design of the system, as well as developing ways to ensure that the design is validated and verified correctly. Historically, developers would make a design decision, then there would be a space of weeks or perhaps even months of development before the impact of that design decision would become relevant. Now, however, developers make design decisions, and then the code is immediately generated, causing the developers to almost immediately see the impact of those design decisions. This reduces dramatically the OODA loop of software engineers. It also helps developers clearly see the impact of their design decisions, helping them see a tighter cause and effect relationship between software design, and the properties of the system. This will require developers to develop their software design skills much faster as software design becomes a larger part of their day to day.System Design from the Outside InAnother implication of this shift is that historically, a lot of software was designed from the inside out, meaning that the core structure was decided upon, and then the external behavior was often heavily influenced by the internal structure of the code, much like how stonemasons built bridges one stone at a time. However, in this new paradigm, the external behavior is where the engineer spends more of their time (like the forms a carpenter builds), and the generated code is more reflective of the shape the code should have that is designed by the engineer then a reflection of how the code was built.Limitations to this Analogy.As with all analogies, this one does have some limitations. One clear place where the analogy breaks down is that when you build a bridge out of concrete, you pour it once, and you are committed to the design. However, with software, once could develop the external constraints, and while there is some cost to regenerating all the code, this can be done multiple times allowing for lessons learned from previous iterations to be applied to future iterations of the software.ConclusionAs we move from an age of stonemasons to carpenters, it is clear that the role of software engineer is rapidly changing. The role of the developer is no longer to build the software line by line as a stonemason, but instead to focus on using software engineering to build a complete system. As a software engineer, I find this change exciting, and look forward to the adoption of software engineering techniques that previously were too costly or difficult, but are now being adopted by developers who are now building large scale software systems enabled by AI.Thanks for reading! Subscribe for free to receive new posts and support my work.Subscribe21ShareDiscussion about this postCommentsRestacksJames C. Davis2dLiked by Michael HiltonThanks for sharing these thoughts, Michael! I have recently been working from a more safety-science definition of Engineering, and I wonder if it's a definition worth promoting in the AI/Agentic era."Engineering: The discipline of exercising informed control over consequential systems and accepting responsibility for their outcomes. Control means retaining sufficient command of a system to understand and direct it, evaluate the evidence for its consequential properties, recognize when its assumptions fail, and intervene when necessary. Responsibility means remaining answerable for the consequential decisions made under one's authority and for the resulting system. Engineering does not require personally performing every act of implementation, and work may be delegated to other humans or to machine intelligence. Software engineering applies this discipline to software systems."- From the glossary: https://davisjam.github.io/model-based-agentic-software-engineering/book/mage-book/0.4-the-books-language.htmlReplyShareTopLatestDiscussionsNo postsReady for more?Subscribe© 2026 The Last Software Engineer? · Privacy ∙ Terms ∙ Collection notice Start your SubstackGet the appSubstack is the home for great culture

This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts

The author posits an analogy between the historical practice of construction and the evolution of software development, suggesting a shift from the role of stonemasons to that of carpenters in the age of artificial intelligence. Historically, stonemasons built structures by directly manipulating the material, incrementally adding individual stones until the final form was achieved. Similarly, early software development is likened to this stonemason approach, where developers worked directly with the medium, building systems incrementally, one line of code at a time. However, the advent of AI code generation necessitates a change in paradigm, proposing that developers should instead view themselves as bridge-building carpenters who focus on creating the forms—such as tests, documentation, and guardrails—that allow code to be generated correctly, rather than building the structure incrementally themselves.

This conceptual shift carries significant implications for the role of software engineering. Historically, a sense existed that development was tangible work, while project management was perceived as less technical. Now, as developers must focus intensely on the boundaries and interfaces of the software they build rather than solely on internal mechanisms, every developer is essentially being asked to assume the role of a Product Manager, shifting the primary focus from "how to build this" to "what should we build."

The definition of software engineering itself centers on creating practical, cost-effective solutions to computing and information processing problems through the application of scientific knowledge and system development. In the current context, where the cost of writing source code is decreasing, the developer's role is increasingly dominated by system design and ensuring the validation and verification of that design. This dynamic changes the feedback loop considerably; in the historical model, design decisions took weeks or months to yield impact, whereas in the AI-assisted era, design decisions can be immediately reflected in generated code, dramatically reducing the OODA loop for software engineers. This necessitates a rapid acceleration in developing software design skills, as design becomes a much more immediate and central part of daily work.

Furthermore, this transition impacts system design philosophy. Historically, software was often designed from the inside out, where the core structure dictated the external behavior, much like stonemasons building a bridge sequentially. In the emerging paradigm, the external behavior is where the engineer spends more time, analogous to a carpenter building the external forms. The generated code becomes a reflection of the external shape designed by the engineer, rather than a direct, incremental reflection of the internal structure built by hand.

Despite the utility of the analogy, the author acknowledges limitations. The analogy breaks down when considering the constraint of concrete construction, where a single pour commits the final design. In software, the ability to iterate and regenerate code, incorporating lessons learned from previous iterations, means that the process is not a single commitment but a dynamic cycle. As the field moves from incremental building to large-scale system engineering enabled by AI, the role of the software engineer is evolving away from line-by-line implementation toward orchestrating the application of software engineering principles to construct complete, validated, and effective systems.