The Pin Factory Is Running Backwards

Adam Smith wrote about a pin factory in 1776, and his point was simple, one worker doing every step alone made maybe a few pins a day, but ten workers each doing one of the 18 separate steps could make tens of thousands. Almost two hundred years later, in 1967, a programmer named Melvin Conway noticed the same thing happening inside software, that the shape of any system a company builds ends up copying the shape of how that company’s teams talk to each other. I keep coming back to both of these old ideas lately, because my team at Gatewise now writes all of its production code through AI agents, and after about a year and a half of running this way I think the pin factory logic that built our whole industry is quietly starting to run backwards.

Why we split the work in the first place

For most of my career the answer to complexity was always the same move, you take a big hard problem and you cut it into smaller pieces and you give each piece to a person who gets very good at that one piece. So a normal R&D group ends up with backend engineers, frontend engineers, database people, DevOps, QA, and each of them lives inside a narrow lane and becomes genuinely excellent there. This was not a mistake and I want to be clear about that, because the systems we build really did grow too big and too complicated for any single person to hold all of it in their head at once, so splitting the work was the honest and correct response to real difficulty. The conveyor belt genuinely worked, a feature would move from product to backend to frontend to QA to DevOps, each station adding its own part, and the whole machine could produce far more than any group of generalists ever could.

Conway’s law was the quiet cost sitting underneath all of this, because once you have a backend team and a frontend team and a separate database team, your software slowly grows walls in exactly the same places, and the boundaries between your people turn into boundaries inside your code whether you ever wanted them there or not.

The meetings nobody counted

Fred Brooks wrote a book in 1975 called The Mythical Man-Month, and the part everyone remembers is that adding more people to a late project tends to make it later, because every new person adds more lines of communication that somebody then has to maintain. I watched this happen for years, a single change to how a user logs in might need the backend person, the frontend person, and the DevOps person all in the same room, and before any code got written we would burn a week on alignment calls, on a shared document, on a thread where the backend engineer and the frontend engineer politely disagreed about where one small piece of logic should live. I never actually thought of that talking as a fair price, because a part of me always believed engineers should work full stack and own the whole thing, and the industry kept telling me the opposite, that the work was too big and had to be cut into narrow specialized roles, so I went along with it even though it never sat right with me.

That coordination tax is the thing I want people to look at again, because we built our sprint rituals, our handoff rules, our review gates, and even our job titles around the plain assumption that the work has to pass through many different hands before it ships.

What the agents actually changed

At Gatewise the change did not arrive as a big announcement, it arrived slowly over about a year and a half of us trying agents on small tasks, then on bigger ones, and after that the engineers moved to writing 100% of the code through AI, which meant their real job became writing specifications, the reasoning and the why behind a feature, and then letting the agent produce the code from that spec. We moved our specs out of Confluence and into Git so the agents could read them sitting right next to the code they were changing. And the part that made me happy, because I had been hoping for exactly this for years, is that one engineer can now carry a whole feature from the backend through the frontend all the way to the deployment, so I could finally build the full stack engineer I always wanted, the person who owns the entire thing, since the narrow coding skill that used to lock you into being a backend specialist or a frontend specialist is exactly the part the agent handles now.

So the coding difficulty that forced us to split into specialists in the first place is the same difficulty that has mostly dissolved over the last year. You would think that when the reason for a wall disappears the wall comes down on its own, but that is not what I am seeing on the ground at all.

Going back is harder than the split ever was

The problem I did not see coming is that the reverse direction is much harder than the original one. It was easy to divide the whole engineer into specialists, because you were handing each person a smaller and clearer job with a clean title to match it. Putting the whole engineer back together is a different kind of hard, because now you are asking someone who spent ten years becoming the best database engineer in the building to suddenly own the frontend and the deployment as well, and almost every part of the organization is quietly built to resist that.

Adam Smith actually saw this side of it inside the same pin factory argument, that once the work is broken into steps, the person who understands the entire process stops being the worker on the line and becomes the one who designs the system. That is the exact move AI is now offering every single engineer. The agent takes the 18 small steps and the human is finally free to hold the whole thing in view and design it properly. But our career ladders, our performance reviews, our team boundaries, and the quiet pride that people rightly take in their specialty all point in the other direction, and people defend those structures hard, sometimes harder than they defend the actual product they are shipping.

The bottleneck moved and most of us are looking at the old spot

For about thirty years the hard part of shipping software was the engineering itself, the writing and the testing and the careful wiring together of complicated systems, so it made complete sense to organize everything around protecting and dividing that one scarce skill. What I see now inside my own team, and when I talk to other engineering leaders over coffee, is that the engineering is simply no longer the slow part, and the slow part has become the people and the old processes those same people built and now defend, the extra meeting that exists only because three teams still believe they each own a separate slice, the handoff that adds two days for no reason other than the org chart says it still should.

I do not have a finished method to hand you for taking all of this apart, and I am honestly a little suspicious of anyone who claims they do, because we are all still early here. What I can actually do is go in and study how a team, or a whole R&D department, really works from one day to the next, not just watch it from the side but pull the flow apart and understand it properly, and from that work out which changes have to happen inside the engineers heads first, how they think about their own job, and then which organizational processes around them need to change to match. The hardest piece of it is teaching people this new way of working without making them afraid for their jobs, because a person who is scared of being replaced will defend the old process with everything they have, and no amount of good tooling gets past that fear. So the real work now is not writing more code, it is the much slower and more human job of reshaping how the team thinks, and admitting that the wall between backend and frontend and DevOps was a solution to a problem our own tools quietly solved underneath us while we were still shaped like a 1776 pin factory.