I originally went to school for mechanical engineering. As a result, I have a lot of friends who are now professional mechanical engineers. And when I talk to them about their jobs, it becomes obvious just how weird software engineering is. Most of my friends don’t really do any low-level work. They don’t make things with their hands at their jobs and they rarely even see the finished products. They may work completely abstract with another company being hired to do the hands-on work while they think of big picture stuff.
I won’t lie, as a software engineer, I’m pretty jealous.
It seems like in all other disciplines of engineering, engineers get to really deeply think about problems and technical aspects of what they do. I’m not going to disparage software engineers and say we don’t do that. But we really don’t think things through that much. For example, I couldn’t tell you what my code personally costs my company to run on the server. It’s not that it isn’t important, it’s just that big picture stuff is often a luxury of the software development world.
The Software Assembly Line
For the last 30 years, the practice of coding within organizations has attempted to turn coding into factory work. The code is separated into parts and given to individual engineers to build features that recombine into a product. This treats coders like we are an assembly line for making software. If software engineers built cars, one would build the engine, one would build the wheels, one would make the seats, etc. until all parts were done and we recombined those efforts into a car.
And it has worked out pretty well to be fair. Unlike many other disciplines of engineering, software engineers do both the manufacturing side of the work as well as the engineering side. And these are very often done in tandem. However, if you were to ask a mechanical engineer to build you a car door, very few would actually have the hands-on knowledge of how to make a car door. (And then there’s like 3% of mechanical engineers who are in the basement making car doors for the fun of it. We all know these guys.) It might even be insulting to a mechanical engineer that you’d suggest fabricating a car door by hand. So, why did the actual building of software programs become the domain of the engineers whose job it is to design them technically?
I think the answer just boils down to complexity. It’s complex to code, so why not just have the people who study it build it. I would argue some software engineers are just builders and I would argue some are just thinkers. But most fall somewhere in the middle in their job.
However, AI is improving all the time. LLM’s are perfectly tuned to build software. As I’ve maintained for years, coding is one of the few technical domains where having strong linguistic reasoning is a boon. It also happens to be a field where a lot of work is just copied from others. In fact, people often forget that Object-Oriented Programming was also supposed to rid of coders. The idea was that eventually there’d be an object in a software library anywhere that someone could just plug-in to their use case and use. There’d be no need to code. While that never materialized, one could argue that LLM’s trained on every piece of public code with the ability to put together the tokens that look right basically is that theoretical software library where any piece of code is available.
How AI Shifts the Paradigm
Whether AI is coming for coders jobs or not I think is still up in the air. I also remain critical and skeptical of people who are vibe coding apps, especially when they have neither domain expertise in the system they are coding nor technical expertise in coding. (They have no way of assessing value.) However, I do know this, LLM’s can write sufficient code to make plausible software and LLM’s can write code a hell of a lot faster than a human can. And this brings me back to factories.
For a long time, software has been all about the fabrication side of things. The experts with the knowledge to design software are also the ones who build it. Now we are reaching the point where we may need to start thinking about the separation of these tasks. A mechanical engineer is not the one personally taking sheet metal down to the factory and turning it into a laptop case. A mechanical engineer is the one who takes designs from designers and turns it into tech specs, they understand the price of sheet metal, they understand the implications of making it out of aluminum or titanium. That is what they are hired for.
I think that much like many machines found in factories that outputs goods, software engineers finally have a machine that outputs code. I’m not ready to go ALL in on LLM’s, but the reality is that we have finally broken the fabrication barrier of coding. We have our first steam-powered hammer. And currently the way it is applied in organizations is still with the coders-as-the-machines factory model. Each engineer just has their own personal fabricator and builds facsimiles of their own code with it. To me, this seems incredibly silly. If the fabrication side of software development is a solved problem (again, debatable) why use engineering time having software developers babysit fabricators? And why pay for 150 licenses when an organization only needs a handful of fabricators?
If fabrication of code is solved, then engineers’ time would be much better spent on building the architecture and fine-tuning LLM configuration to get better outputs then it would be for each engineer to have a personal writer of code. Engineers at a car factory don’t sit around personally babysitting a machine that makes a whole car, they work as a group to solve factory-wide problems. Why are 0.15% of cars coming out with loose axels? How can we take the new designs for the 2032 models and apply them to our current factory? What materials are we purchasing from where and how do we optimize the cost of the business? These are questions engineers who aren’t fabricators get to explore as an organization.
I’m personally excited about where software is going because I’m excited to not argue about the dumb piddly details anymore. Do people realize how much time in software has been wasted with people arguing about using coding language A vs coding language B? Do they realize that every time we comment on a PR that the junior engineer didn’t use the proper variable casing, we waste like 3 hours of everyone’s time? I’m done with that. Let me write documentation of how I think systems should work. Let me actually have some time to look at unoptimized pages and assets. Let me take designs and turn them into specs that an LLM can use to create components. Or let me build the communication layer between Figma and our LLM. Let me do the things that LLM’s aren’t going to be good at or that need domain and business knowledge to get done. (The same way you pay an engineer on a factory floor to create custom solutions for your own assembly lines.)
Also, I don’t know how to break this to Anthropic and Cursor, but if they think companies need a personal LLM for each coder, they are wrong. Companies will need far fewer licenses that what is currently being calculated. Companies shouldn’t be sitting around prompting LLM’s one at a time with each engineer, they should be submitting entire specs for the day and using the LLM day and night to generate code from specs. All these assholes in Silicon Valley are starting to admire the whole “work 6 days a week, 12 hours a day” while also pumping up LLM coders. Well to each of those assholes, why is your coding stopping when human coders go home if you have a literal machine that can just write code and never stop? It’s because you have no system to create proper fabrication. Your workers would be far happier using their time to create processes that improve the business rather than prompting shit for 12 hours.
I really believe that there’s a paradigm shift coming to the way software is produced. AI tech bros believe they are going to cut all labor involved in it and coders seem to believe that they will always be coding in some way. I think the answer is far more likely in the middle. And I believe that software engineers working more like engineers at a factory is far more likely than engineers continuing to write code. But we’ll have to see where it goes.
