My 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.
Historically, 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.
However, 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.
So 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 development
Everyone is a Product Manager now
Historically, 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 Engineering
One 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 In
Another 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.
Conclusion
As 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.
Many thanks for sharing your thoughts, Michael! Very insightful. I think that in addition to be a product manager, as you say, the new software engineer will have to perform tasks of a project manager (assign and supervise tasks, manage budget/tokens, track progress, mitigate risks, coordinate a team resources...) -- however, instead of managing people, software engineers will have to manage their agents. What do you think? How would that fit into your analogy?
Excellent exploration of this metaphor, and it is apt. Thanks for the mental tools.