The software factory illusion
June 2000. I was a Computer Science student trying to figure out where I would work in this profession. There was a certain pessimism in the air, because the dot-com bubble had just burst, but that didn’t worry me as much as something else that, apparently, nobody else noticed.
The Brazilian market was dominated by the infamous software factories. In my head, “software” and “factory” were words that didn’t belong in the same sentence, yet everyone seemed to accept the term as respectable and full of expertise. To me, what they were selling was an illusion: the illusion of easy answers.
When software became an assembly line
Writing software is, by definition, creating something that doesn’t exist yet. That’s why every software project is a process of discovery. Of course we use libraries and don’t reinvent the wheel on every project, but at some point every project steps onto unknown ground.
That nature is completely at odds with the factory model, which preaches predictability, standardized procedures, output metrics, throughput, chains of command and rigid hierarchies. In the software factory, this showed up as the split between the analyst, who wrote the specification, and the programmer, who “just” coded it. Success was measured in man-hours and function points, with a time clock at the door.
It’s a model that shines in manufacturing: once you find the optimal process, you reproduce it as much as possible and get predictable, controlled results. But in software, if you already know the whole process up front, you’re probably building something that already exists, and you’d have been better off buying it.
Managers and ambiguity
So why is the model so tempting?
Everyone has their own need for order. When your job depends on delivering results, and you control neither what your team produces nor how productive they are, the chaotic environment of software development becomes threatening. Add deadlines and budgets locked in months before anyone understands the problem, and the factory starts to look not only reasonable, but responsible.
The problem is that removing risk with a recipe that works in another context is like giving cancer medication to a tuberculosis patient: with luck it might work, but everything points to it going wrong. And the side effect is predictable: instead of changing management to fit the work, the work gets bent to fit management.
Risk isn’t eliminated, it’s managed. Sometimes it even needs to be added on purpose. I really like how Jason Fried puts it: “A Founder’s job is injecting risk into the business”. That is, bringing in ideas that look hard, that nobody else would try. A company that only tolerates the predictable can only build what has already been built.
An important counterpoint: there is software where all that control is justified. In medical, aviation and aerospace systems it pays for itself, because the cost of a bug can be someone’s life. But those projects tend to take years, sometimes decades. If your company isn’t in that world and operates under the same assumptions, it’s just burning money.
I’m not defending the opposite either: companies that push insane deadlines to squeeze every drop of productivity out of people. Needless to say, that kind of company doesn’t go far either. What I’m criticizing is the situation where people build something only because leadership said so. Or that feature nobody understood, but that’s there to be built, and once you’ve estimated it, you have to find a way to make it happen. Repeat that for a while and the codebase will show you the result.
Programmers pushed back
The way I saw it, the profession was heading in a bad direction. Fortunately, shortly after, in February 2001, a group of crazy people published the Agile Manifesto. Over time, big companies adopted it and much of its essence was lost along the way, but that’s a topic for another post.
What matters is that people who program know XP works, because it was born from practice, from people who live programming, and not from managers’ longing for predictability and control. Little by little companies moved away from waterfall, and the same voices behind the manifesto, like Kent Beck and Martin Fowler, helped educate a considerable part of the market.
Chaos that works: Conectiva
Meanwhile, here in Brazil there was an example from the other extreme. Conectiva, founded in Curitiba in 1995, maintained an entire Linux distribution: it packaged thousands of programs, translated everything into Portuguese and Spanish, and built its own tools, such as the port of APT to RPM packages. It was exploratory work, with no manual, in sync with a free software community spread across the world. In 2005 it merged with the French company MandrakeSoft, forming Mandriva.
What I heard about Conectiva came from stories on podcasts: an almost anarchic place, where arguments were won with code rather than in meetings, and where working hours were completely free. I can’t confirm how much of that is true and how much is folklore, but it stuck in my head as the place every programmer would love to work. And, true or not, the image says a lot: the opposite of the factory isn’t disorder, it’s trust in the people doing the work.
A little mess
Years later, in 2009, I read a post by Thiago Arrais called “Bagunça pode ser tudo o que você precisa” (“A mess may be all you need”). The post is in Portuguese, but your browser’s translator does a decent job with it. It didn’t teach me anything new. It did something better: it put into words something I’d been cultivating since college. The apparent disorder of real work isn’t necessarily a defect to be fixed, and over-organizing people’s work tends to make it rigid. It read like someone living software development from the inside, not like a methodology salesman. I highly recommend it.
The factory returns with AI agents
It’s 2026, and a disruptive technology has radically lowered the cost of producing software. AI really has changed the landscape. And, in the middle of it, the Fordist dream is being fed again.
The promises vary, but the essence is the same: tame the wild animal and make it predictable. Write a detailed specification, hand it to an army of agents, and wait for the software to come out the other end of the conveyor belt. Notice that it’s exactly the 2000s split between the analyst who thinks and the programmer who executes. They just swapped the programmer for the agent. As I said, part of this is explained by the human tendency to reject the unknown.
But generating code was never the bottleneck. The bottleneck moved: writing got cheap, but understanding the problem, maintaining the system and aligning it with the business domain is still expensive, and may get even more expensive when the repository fills up with code nobody needed to understand to produce. The idea of disposable code (“if it turns out bad, the AI rewrites it”) forgets that software doesn’t live in a vacuum: there’s production data, integrations, compliance rules, and business rules that only exist in the heads of the people who run the company.
And there’s a less visible cost. When the engineer becomes just an inspector of what the agent produced, context gets lost. When the system breaks at three in the morning, someone needs to know why it was designed that way, and that knowledge wasn’t in the specification.
There’s also an opportunity few people are seeing. If code has become cheap and fast to write, programmers can take a bigger part in the business, cut out intermediaries, and stop being a cost center to become a source of wealth. Prototyping, discarding what doesn’t work and keeping what does is still the way, only much faster. And making those choices will remain craft work.
Conclusion
This is the moment when people expect me to criticize AI. I’m going to disappoint them. I think AI is as capable as humans at writing software when the context is clear, maybe more. LLMs are fantastic tools, but they’re still tools, and they have limitations. You can delegate the mechanical part of writing software, but you can’t delegate understanding, responsibility or purpose.
Understanding, because the model works with the context you give it, and figuring out what the right context is is the job. What problem are we solving? Which trade-off is worth it? Reviewing code you don’t understand isn’t review, it’s a rubber stamp.
Responsibility, because when something goes wrong, the one who answers to the customer, the contract and the regulator is a person. A slide attributed to a 1979 IBM training already said it: “A computer can never be held accountable, therefore a computer must never make a management decision.”
Purpose, because deciding what to build, for whom, and above all what not to build is a choice about values and the business, not about syntax. The agent optimizes for the prompt; someone has to optimize for the purpose.
The software factory of the 2000s failed because it pretended those three things could be separated from execution. Using a powerful tool helps a lot, but it doesn’t change the intrinsic nature of the profession. Software is still discovery, and a little mess is still what separates living software from an assembly line.