Cover image credits: Dan Sandoval / Great Wall Motor Co. Ltd.
The Clock-In
Factory workers clock in when they arrive at work. They punch their badge, scan in, or log their presence in some system. The system knows they're there. They get paid for their time on the assembly line. They get paid to assemble, not to think.
For a long time, knowledge workers were different. You showed up, you did your job, you left. The work itself was the measure, not the presence. And crucially, the value wasn't just in the doing: it was also in the thinking.
But that changed. Now we have badge access, Slack status, timesheets, standups. "What did you do yesterday? What will you do today?" The clock-in came to software development. It just wore different clothes.
Here's the thing though: even on a factory floor, clocking in doesn't guarantee output. A worker can be on the line and still slow down, zone out, or assemble things wrong. An office worker can log their hours and spend the day in meetings that produce nothing, watering their plants or playing Solitaire. The system measures presence, not output.
But knowledge work has a dimension that factory work doesn't. A lot of people get their greatest ideas while walking their dog, taking a bath, or folding their laundry. They're not measurably present at work, but they are generating valuable output. You can't put that on a timesheet.
The surveillance climate created by those time-tracking mechanisms doesn't just fail to capture this: it actively undermines it. People spend time and energy performing for the system instead of doing actual work.
The idea you had in the shower is undervalued. Worse, the energy you spent conforming to the system left you exhausted. There is no real space left in your brain for that idea to pop up in the middle of frying samosas.
The analogy doesn't stop there though...
The Factory Model of Software Development
During the past decade, a lot of companies have been trying to make software development look like factory work.
The symptoms are everywhere:
- Scope of issues have become smaller and smaller
- "Anyone can pick this up" became a goal
- Context became something to avoid, not something to cultivate
- The ideal developer became interchangeable, making firing and hiring developers a trivial matter
- The ultimate goal is to move issues to the next column to "demonstrate productivity"
Productivity models that were designed for factories have been adapted to software development. From Lean, Kanban to Six Sigma.
If you can break work into small enough pieces, anyone can do any piece. No need to understand the system. No need to know the codebase. No need to understand the user. Just pick a ticket, do the thing, move to the next.
The ticket itself tells you everything you need to know. At least in theory... In practice, there are a couple of paradoxes.
The work got smaller, but the documentation got bigger
And worse: The described work might not be the thing that really needs to be done.
The Paperwork Theater
Remember when an issue could just say "Work out the rendering in IE so that the login screen can be released"?
Now it's:
## User Story
As a user, I want to be able to log in so that I can access my account.
## Acceptance Criteria
- [ ] User can enter email and password
- [ ] Error message shown for invalid credentials
- [ ] Success message shown for valid credentials
- [ ] User is redirected to dashboard
- [ ] Password field is masked
- [ ] Login button has loading state
- [ ] Works on mobile
## Technical Notes
See JIRA-123 for background
## Blocked by
- JIRA-456 (database migration)
- JIRA-789 (API endpoint)
## Story Points
3
All this for something that might take 10 minutes.
Even though the issue description got bigger, valuable information has been lost. Noticed the "the rendering in IE" part of the original title? That tiny detail: "in IE"; it tells you something important. It tells you the general concern is not the login screen itself, it's browser-specific. It might need different testing. It might have known problems. It might be low priority because IE is not supported anymore. All that context fits in two words.
Now? The acceptance criteria list doesn't capture that. The user story doesn't capture that. The story points definitely don't capture that. The important information is buried in "Technical Notes" or missing entirely because who knows what's relevant? The rest of the text? It's accurate but should really mostly go without saying.
The small scope, huge documentation pattern. Anyone can pick it up - but first they have to read all this. The DDD-speak, the acceptance criteria, the story points, the parent issues, the blocked-by links. It's process theater. It makes the process look rigorous without actually helping anyone do the work.
I am not saying documentation or project management tools are bad. I'm the first to push for putting things down in GitLab, asking for screenshots, producing wireframes, yearning for exception logs... I am saying that the over-use of any system will have adverse effects. It's similar to any substance: water is essential for life, but drinking too much water can kill you. The dose makes the poison.
Codifying everything into procedures can feel safe because you can just follow the procedure - but procedures, when they work well for one specific case, are usually ill-suited for the majority of other cases and vice-versa. The safety they provide is an illusion.
But procedures are what allows humans to act without thinking, which is a necessary step if you want developers to be easily replaceable. This is the whole premise of the assembly line.
What Efficiency Actually Is
Let me strip this down to what efficiency actually means when it comes to software development:
Efficiency is the ability to translate the need of the final user or client into a working solution.
That's it. That's the core of development. Being able to listen to a need, expressed freely by someone, in their own terminology, ask the right questions and come up with a solution that works.
Writing code has always been a side-effect of this skill. The actual skill is translation: need → solution. The code is just the vehicle. Sometimes that's a sports car and other times it's an 18-wheeler; but the destination matters more than the ride.
When you break work into small, atomic, context-free issues, you remove the need for this translation skill. The translation has already happened. The issue tells you exactly what to do. You're not listening to a need; you're following instructions. You are not healing a wound, you are applying a plaster. The fact you are looking at a prosthetic leg right now is out of scope for this issue, the issue is about applying the band-aid.
The next core item: sustainable development. Fitting the client's need is the main goal, yes. But the next one is making it sustainable for future development. A good analogy is getting upstairs: you could stack chairs and tables on top of each other to reach the second floor. A ladder might be a better, more acceptable solution. But the maintainable and sustainable thing to build is a staircase. That's the second, often overlooked, part of a good software developer's job.
Here's the problem with small issue scopes: when you're looking through a very small lens, the big picture is hard to see. You're focused on the immediate next step. The next item from getting from the chair to the table might be a footstool. It makes sense in that limited context. But if you take a step back and look at what's being built, it's ludicrous. You've created a Rube Goldberg machine to get upstairs when what you actually needed was a staircase.
And good luck getting the budget to tear down the Rube Goldberg machine and build a proper staircase. Quarterly figures don't reward rebuilding things that kind of work. KPIs measure features shipped, not foundations laid. So the machine stays, and the cost is paid over months and years: in time wasted climbing to go to the second floor, in fixing the leg of a chair that should never have been there in the first place, in recovery time for the people who keep falling off the contraption, in medical bills, in people who simply refuse to "approach that thing". The staircase would have paid for itself by now, but it was never "in scope."
The Translation Chain
Here's where it falls apart:
Need → Account Manager → Project Manager → Tech Lead → Developer
Each step loses context. Each person interprets, simplifies, or misunderstands. The final developer gets a tiny task that makes sense in isolation but might not make sense in the larger picture. It's a huge game of telephone. Except it's not really a game, is it?
Every step in the chain generates its own documentation. The over-documentation problem from earlier? It compounds at every level. The account manager writes a brief, the project manager writes a spec, the tech lead writes technical requirements, and the developer gets a ticket that's simultaneously over-documented and under-informed. Each translation step adds paperwork but loses signal.
The Alternative
Not every company went down this path. And when I have a choice, I gravitate toward the ones that didn't.
These are companies that rejected the hierarchical, administrative-heavy model entirely. People working as part of a group rather than being part of a hierarchy. Collective ownership rather than control from above.
This is what being actually agile looks like. It's not transforming "agile" into a rigid process, calling it Scrum, and then adding Jira on top. Actual agility means responding to change, direct communication, and delivering working software. Not counting story points or having "ceremonies" be the primary item on your agenda.
In these companies:
- Developers understand the whole system, not just their tiny piece
- Direct communication between actors is encouraged, translation happens directly: need → solution, fewer steps in between
- Trust is placed in people to do the work rather than surveillance to ensure it
- The work feels different: "we're building something together" instead of "I'm doing my time"
These companies often move faster. Less translation loss. Less overhead. More trust. Less broken things. Happier teams. Better outcomes.
The AI Replacement Myth
And now comes the push to replace developers with AI.
The logic goes: if the goal is context-free, atomic tasks that anyone can do, then AI is the ultimate interchangeable worker. No bathroom naps. No need for context. Just prompt and produce.
But here's what's actually happening:
Remember the translation chain?
Need → Account Manager → Project Manager → Tech Lead → Developer
We didn't always have all those rungs on the ladder. It used to be simpler: a need → a developer → a solution. Then rungs were added in the middle of this ladder. An account manager to "manage the relationship." A project manager to "manage the work." A tech lead to "translate to technical requirements." Each rung was added to make the developer and every other rung more replaceable, more interchangeable, more factory-like.
Now AI knocks out the bottom rung. The developer is gone. But the thinking work, the translation from need to solution, didn't disappear with them. It moved upstream.
A project manager who used to write a Jira ticket for a developer can now paste that same description into Claude Code or Codex. The work is the same. The job title changed. The PM is now prompting an LLM instead of "prompting" a developer.
But those people are already overworked. They were busy translating, remember? So more of them will be needed. Or they'll burn out. Or the quality will drop because they're now doing two jobs.
The rung that was above the developer is now the bottom rung. Nothing has changed, other than job titles. The cycle can start again.
The developer rung is not the only one that is at risk. Any independent rung on that ladder can be singled out and replaced by an LLM. Companies are doing it. The whole thing only visibly starts falling apart once too many rungs have been replaced at once.
But the Core Skill Remains
Remember what efficiency actually is? Translating the need of the final user or client into a working solution. That hasn't changed, it's the one rung the ladder truly needs. That has always been the core skill. The way the vehicle gets on the road is different. The destination is once again the same.
Those who master that skill will keep having an edge. Despite the pipe dream that's being sold to us, LLMs are still not able to do that. They can write code. They can follow instructions... sometimes. They cannot listen to a need, understand it deeply, and translate it into a solution. They can only match that need with similar needs they have been trained on and apply a canned response that is statistically good enough.
They cannot fulfill the second part of the contract either. Sustainable and LLM don't rhyme with each other, the dissonance is at many levels but "statistically good enough code" is not flexible nor maintainable.
The companies that cultivated these core skills; the ones that let developers understand the whole system, that trusted them to do the work without procedural overhead... those have an edge. Not because they are "AI-proof", but because they never stopped valuing the actual skills that matter.
Will we be able to outsource that skill to an LLM in the (near) future? I doubt it. Is it a good idea to even try? I think not. But only the future will tell.
Change Is the Constant
This is not the first time a profession has had to adapt to new tools. The Cold War era brought rapid automation and computerization that upended many trades almost overnight. I grew up around people on both sides of that change.
A distant family member was a lathe operator. He knew how to use mechanical lathes. He wasn't spectacularly good at it, he was average, maybe a bit below in terms of speed. But he didn't want to learn to use a numeric lathe or a CNC.
There are still people I know who use manual lathes for crafting. It's a great hobby, it's a craft, and some are very good at it. But I don't know anyone who has a paid job with a guaranteed income whose sole job description is to operate a manual lathe anymore.
The people I know who use mechanical lathes and get paid as part of it? They're artisans. Becoming an artisan is possible. You need to either be very good at what you do or be filling a specific niche. But it rarely comes with a steady salary.
Someone else I knew took the opposite path: a printing press operator who learned the new computerized systems and became the sole person left in charge of printing that particular newspaper. The others had been replaced by the machine he'd learned to operate.
That lathe operator I knew? He stayed unemployed until retirement age.
The Luddite in the Room
Several in the OSS community have been referencing the Luddites (often in a positive light) to illustrate what's happening right now with AI. I understand why. The Luddites had legitimate social grievances, and the economic upheaval brought about by the Industrial Revolution was devastating for many. Recent conference talks have made compelling cases for their perspective, and I'm not here to argue with those.
But I think there's a pragmatic lens worth applying alongside this analogy. With the advent of the mechanical loom, there were three kinds of workers: the minority who were very good at their craft and managed to keep doing what they were doing and were still able to make ends meet, the majority who adapted and moved on to operate those looms, service them, or manufacture them, and the ones who stayed behind. I'm intentionally leaving the wages of the Victorian era outside of this analogy ; that's a whole other post and it has Robber Barons in it.
Outside of ethical and environmental concerns, LLMs and coding agents are just that: a new generation of tools that need to be learned. They will need operators too. Maybe fewer. But the core skill remains: translating needs into solutions. The tools evolve, and adapting to them is part of the job. That's not a judgment. That's just how trades work. Whether that's good or not is a topic for a separate discussion about society.
The factory model is probably the root of all this. It's what led us down a path that transformed our profession into just a seat on an assembly line. We collectively must have had a role in that too, didn't we?
Run Lola... Run!
AI isn't the destination: it's just the next step on a path that was flawed from the start. We're all on it, and we're running!
In Run Lola Run, Lola gets three chances to solve the same problem. Same starting point, different choices, different outcomes. The landscape of 2026 feels a lot like that.
Run 1: Refusal
You don't adapt. Maybe out of principle, maybe out of exhaustion, maybe because the pace of change is genuinely unsustainable. This is the path of the lathe operator who didn't want to learn CNC. It's understandable. But the outcome is usually the same: you get left behind.
Run 2: Pragmatism
Most companies will keep optimizing for replaceability, and if you need to pay rent, you'll have to play in that reality. If you're a junior developer entering this market: keep learning to code! It's an essential skill to be able to efficiently prompt LLMs. But look for jobs with a title other than "developer." Look for roles that require a "technical background". That's where the work is migrating to right now. The bottom rung got knocked off the ladder, so position yourself on the one above it. That is... if you're fine with the factory model, of course.
Run 3: Artisanship
You master both the craft and the new tools and mix those two in different amounts. You learn to operate the mechanical loom but you keep bringing the original designs and making the finishing touches by hand. You use AI to automate and speed up the tedious parts, but the architecture, the translation from need to solution, the pattern of the rug: that's yours. This is probably the most rewarding path. But artisans rarely get a guaranteed steady salary. You'll need to be very good at what you do, or find a niche where your skills are in shortage... COBOL anyone?
There is one difference between AI and the Victorian looms though. In 2026, the weavers have the means to run those mechanical looms in their own workshops. It comes at a cost. We have to be careful who controls those new tools. The loom is in your shop but you still don't own it. The same way most Uber drivers don't own their cars. That cost, both monetary and metaphorical, shouldn't just become yet another form of indentured servitude.
The landscape is changing rapidly. Some parts faster than others. Unlike Lola, we don't get to rewind the clock and try again. But we do get to choose which run we're in.