The Lab Versus The Factory

Thinking and Working Might Be Two Different Things

Software updates arrive daily on every device I own. Being the curious type, I dig into the fix logs to see what the developers are up to. And without fail, buried in every release note, is that eternal line: "bug fixes." Which raises an honest question: when do the bugs finally get fixed? In my world of enterprise IBM i computing, we encounter bugs too — but we handle them. In this age of AI-accelerated everything, why does the bug count never seem to reach zero?

The answer, I believe, goes deeper than code quality or test coverage. It points to something more fundamental: the blurring of the line between the lab and the factory. Between thinking and working. Between designing and executing. In the rush to ship, we have collapsed two very different disciplines into one frantic process — and the bugs, the rework, the technical debt, and the burned-out developers are the receipts. Keep that thought close as you read. We will come back to it.

1 - The Lab and The Factory: Two Different Games

There was a time when the difference between the lab and the factory was unmistakable. The lab was the domain of design and thinking — canceling bad ideas, creating new ones, running proofs of concept, and imagining how things should work. Only when that process was complete did the factory come to life. The factory's sole mission was execution. Everything was calculated, planned, prepared, and provided. The specifications of the final product were known before a single widget moved down the line.

No one experiments on the factory floor. The thinking has been done. The factory is pure execution: inputs, outputs, touchpoints, tolerances — all defined. The lab, by contrast, is where variables are wrestled to the ground. Where you ask "why doesn't this work?" and "what would happen if we tried this instead?" Two very different environments. Two very different mindsets. And in the best organizations, two very different teams who respected each other's role.

"Without requirements or design, programming is the art of adding bugs to an empty text file."

— Louis Srygley

Software development was once organized this way. The lab — architects, analysts, and senior designers — did the heavy intellectual lifting. They produced specifications, data models, process flows, and test criteria. The factory — developers — translated those specifications into working systems. When the system fell short, it went back to the lab for analysis before any fix was attempted. Each side knew its role. Each respected the other. The bugs still came, but the process of finding and fixing them was deliberate and grounded. Then something changed.

2 - Waterfall Wasn't the Problem — Collapsing the Lab Was

Waterfall earned its bad reputation honestly. Big Design Up Front (BDUF) taken to extremes produced thousand-page requirements documents that were obsolete before the ink dried. Rigid phase gates meant that a flaw discovered late in development cost ten times what it would have cost to catch in design. Customers were handed software that technically met the specification but missed the point entirely — because nobody had actually talked to them since the project kicked off.

Agile and Scrum arrived to fix the feedback problem, and they did. Iterative sprints, working software over documentation, customer collaboration over contract negotiation — these were real improvements. But in the process of tearing down the walls of Waterfall, many organizations also dismantled the lab. They abolished the dedicated thinking space. They rebranded deliberate design as "overhead." They handed user stories directly to developers and called the sprint planning the design phase.

Warning: The Hidden Cost of Collapsing the Lab

When thinking and working are forced to happen simultaneously, neither is done well. Developers write code to explore a problem they haven't fully understood. Bugs are the predictable result. Velocity metrics soar while product quality quietly erodes. The lab didn't slow things down — skipping it did.

The result? Backlogs that balloon with rework. Sprint velocity that feels fast but circles the same problems. And that eternal line in the release notes: bug fixes. The methodology had changed. The discipline of thinking before working had not followed it. Which is why I keep thinking about an old chair, a green terminal screen, and a man who understood the difference between the two better than anyone I've met.

3 - The Thinking Position: Where Real Work Begins

Years ago, early in my career, I had the privilege of working alongside one of the finest programmers I have ever known. He was a true gentleman — not in the polished sense, but in the deeper one. Steady. Generous with his time. The kind of man who made you feel that your question was never a bother. He had come up through the Air Force, served as crew on B-36 bombers, and then moved into some of the earliest business computing systems — wiring calculations directly onto IBM boards before punchcards existed, when programming was literally a matter of physically connecting the machine's thinking. He would tell me those stories and I would just sit there, mouth open. He was near retirement when I knew him — probably overdue for it — but he couldn't stay away. He loved the office. He loved the people. He loved the work.

He was the third programmer I ever met. The first two were quite good. He was in a class by himself.

His office stood out from the rest of the floor. While everyone else had moved to the newer ergonomic chairs and fresh workstations, he had an old desk and an old chair — the kind with the slight squeak when you leaned back, the kind that had absorbed years of thinking. He preferred to work on an IBM 3480 emulation dumb terminal. No graphical interface, no mouse. Just the green glow of characters on a dark screen. The office hummed around him — the click of keyboards, the low murmur of conversations, the occasional phone — but none of it seemed to reach him when he was deep in a problem.

One afternoon I walked past his open door and stopped. He was leaning back in that old chair, fingers interlaced behind his head, eyes closed, head tilted slightly upward. Still as a stone. The terminal was dark. There was nothing on his desk he was looking at. Whatever was happening was entirely internal. I stood there for a moment, unsure if I should check on him, before I realized: he wasn't stuck. He was working. After what felt like a full minute, he leaned forward, set his hands on the keyboard, and started typing with quiet purpose.

I asked him about it later that day. He smiled like I'd asked about an old friend. "That's my thinking position," he said. "When the noise in the office gets too loud — or when I just need to let the mind do what it does — I go there. You put your hands behind your head, you lean back, you close your eyes, and you think. Really think. Not about what the screen says. About what the problem actually is." He paused, then added: "Most bugs aren't in the code, son. They're in the thinking that came before it."

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."

— Brian W. Kernighan

I've never forgotten that. Not long ago, I found myself circling a particularly tangled set of problems at work — disconnected issues across software, process, and people, threads that almost connected but never quite did. I sat down at my workstation ready to attack it and got precisely nowhere. An hour of staring at data that refused to tell a story. Then I remembered him. I pushed back from the desk, locked my fingers behind my head, closed my eyes, and just let the mind work. I didn't solve everything. But I got a foothold — a starting frame, a first edge piece. And from there, real work could begin.

The thinking position isn't procrastination. It is the lab at its most personal and immediate scale. And the bugs that never seem to get fixed? Many of them were born in the moment someone skipped it. Now fast-forward from that green terminal screen to today — and ask what happens when the entire industry gets a new power tool and nobody pauses to ask whether the thinking has been done first.

4 - Vibe Coding: A Factory Without a Lab

In February 2025, Andrej Karpathy — co-founder of OpenAI and one of the most respected minds in AI — coined the term "vibe coding." The concept: just describe what you want in plain English, let an AI generate the code, provide feedback, and keep iterating. The AI does the typing. You provide the vibes.

For rapid prototyping, exploration, and proof-of-concept work, vibe coding is genuinely powerful. Used in the lab — to generate a candidate architecture, sketch a data model, or test whether an idea is even feasible — it is a force multiplier. The problem begins when vibe coding is mistaken for the factory. When it is used to build production systems without a clear design, a defined specification, and a thought-through architecture.

Key Insight: The AI Shift That Should Change How We Build

Teams using AI-assisted development are now spending up to 3× more time on upfront design and specifications — not less. One engineering leader described the emerging pattern as "Agile planning, waterfall execution." The AI is the factory. Your thinking is still the lab. (Source: Medium / Frank Goortani, 2025)

Anthropic's own Claude, for instance, generates more robust applications when provided with detailed requirements, user stories, and technical specifications in a single comprehensive prompt rather than through vague iterative nudges. The AI wants lab output. Give it factory instructions without lab preparation and you get exactly what you deserve: plausible-looking code that doesn't quite do what you meant, bugs baked in from the first token. So the question becomes: what does good lab output actually look like? In manufacturing, we have had the answer for a long time.

5 - The Lab, The Factory, and the Bill of Materials

So if the lab is where the thinking happens, what does the lab actually produce? In manufacturing — the world I have worked alongside for twenty-five years — the answer is unambiguous: a Bill of Materials. Nothing moves to the factory floor without one. Every component, every sub-assembly, every tolerance and finish specification — documented, reviewed, and released. The factory doesn't invent the product. It builds to a known design. The lab owns the design. The factory owns execution. That boundary is sacred.

Software needs its equivalent. Not the waterfall-era thousand-page requirements document that took six months to write and was wrong on arrival. Something leaner and more honest — but real. A genuine Software Bill of Materials: the deliverable that authorizes factory work to begin. Here is what that looks like in practical terms:

Does this take time? Yes. Does it take less time than debugging a system built on a misunderstood requirement? Every single time. In twenty-five years working across IBM i, Infor System 21, DelmiaWorks, JD Edwards, and shop floor systems, the most expensive problems I have encountered were not technical failures. They were thinking failures — moments where someone moved to the factory without a BOM and spent months trying to manufacture something nobody had fully designed.

The beauty of this approach in the AI age is that a well-constructed Software BOM is exactly what an AI coding assistant needs to produce something genuinely useful. Feed it the problem statement, the data model, the flows, and the integration points, and it can generate a credible first build in hours. Skip the BOM, hand it a vague user story, and you are back to that eternal line in every release note.

"Design activities certainly take up time and effort, but they pay off because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates technical debt that will slow your productivity later."

— Software Engineering Wisdom

6 - Reclaiming Both: A Fresh Look at Methodology for the AI Age

Waterfall had a lab. Agile abandoned it in favor of speed. The AI age is demanding it back. What is emerging in the most thoughtful engineering organizations is a hybrid that honors both disciplines: dedicated thinking time and deliberate design before any AI-assisted execution begins. The methodology debate isn't over — it is just getting more interesting.

This isn't a retreat to BDUF. It is a maturation. Waterfall was right that thinking should precede building. Agile was right that feedback loops should be short and the customer should stay in the picture. What neither methodology fully addressed is the cognitive discipline required to do the thinking work well — the willingness to step away from the keyboard, sit with the problem, and let the pieces arrange themselves before reaching for a tool.

My wife, who is an avid and gifted puzzle person, always builds the frame first — then the interior follows almost inevitably. She never just dumps the box and starts jamming pieces together. Neither should we.

And here is the answer to the question I opened with: why do the bugs never go away? Because the factory has been running without a lab. Because thinking and working got fused into one breathless sprint, and the cost shows up in every release note. Separate them again — deliberately, with respect for what each requires — and you don't just write better software. You become a better engineer.

From the Factory Floor: Lab Rules for the AI Age

Use AI to do things you can't do alone, to perform in time what you lack time to complete, and to help propose additional ideas from its learning. But do not let the AI do your thinking for you. Dream and design in the lab. Build and construct in the factory. The thinking is still yours.

Key Takeaways

1 - The lab and the factory are two different disciplines — design/thinking versus building/execution. Collapsing them creates bugs, rework, and burned-out teams.

2 - Waterfall's real error wasn't thinking before building — it was thinking too rigidly and too long, then cutting off feedback. Agile fixed the feedback problem but often eliminated the thinking time.

3 - The "thinking position" — whether that's leaning back in your chair, taking a walk, or stepping away from the screen — is not wasted time. It is the lab at its most individual scale.

4 - Vibe coding and AI-assisted development are factory tools, not lab replacements. They execute brilliantly against a clear design. Against a vague one, they produce plausible-looking confusion.

5 - The AI age is driving a return to more upfront design thinking — not less. The most effective teams are treating AI as the skilled factory floor and their own thinking as the lab.

6 - Methodology is not the answer by itself. Waterfall, Agile, Scrum — all need a fresh look through the lens of what AI can now execute at speed. The human role shifts decisively toward the lab.