The “machine operator” era of software engineering
I. Something Familiar Is Happening
In the early 1700s, a weaver in England would take about a week to produce a single piece of cloth. The pace was slow because the work depended on a combination of knowledge, skill, and manual effort. Every decision came from the weaver’s hands and mind. The loom was only a simple hand tool.
Then the machines arrived. The spinning jenny to the power loom. Each one increased output, but more importantly, each one shifted skill away from the person and into the machine. Work that once took years to learn could now be done by someone operating a machine. Cloth began to be produced faster, cheaper, and at a scale no individual weaver could match.
The weavers did not just lose their work. They lost a part of who they were. Weaving was not just a trade. It was their identity.
Software engineering is going through the same kind of shift right now. Not the shallow “AI will take your job” panic. Something deeper. An identity shift.
For decades, the bottleneck in building software was human intelligence applied to production. Someone had to take an idea, break it into logic, and write it as code. That process was slow and expensive. It shaped how we hired, how we built teams, and how we valued work.
Now, we’re building machines that can do that translation on demand. Not perfectly or completely on their own. But good enough to write a working function from a plain description. Good enough to build an app from a conversation. Good enough to change how software gets made.
The textile industry didn’t die when the power loom arrived. It changed shape. New roles showed up. New skills became valuable. The craft didn’t vanish. It moved. The same thing is happening in software right now.
II. Writing Code Was Never the Most Valuable Part
To understand this shift, you need to see something the industry spent decades getting wrong.
Somewhere along the way, “software engineering” started to mean “writing code.” Interviews tested algorithm puzzles. Bootcamps promised to make you an engineer in twelve weeks by teaching you JavaScript.
The narrative was set in a way that the value is in the code. But this was never the complete truth.
Software engineering was never just about writing code. It was about solving problems through software. That takes a chain of thinking that goes far beyond the editor. Understanding the real problem. Making design choices that balance speed and flexibility. Knowing what users actually need versus what they say they want. Communicating with designers, business leaders, and customers. Deciding what to build, what to skip, what to save for later, and also what not to do.
It takes judgement from experience (aka taste). A feel for what makes a system work smoothly and feel right to the people who use it.
Code was just the final step of all that thinking. Important, yes. But the output, not the process. In fact, the great, maintainable code was the result of clear, holistic thinking.
Confusing the two had real costs. It created a hiring culture that overvalued technical tricks and undervalued product thinking. Teams ended up full of brilliant coders building the wrong features. As a ripple effect, it created a new breed of roles like Product Managers who are tasked to tell engineers what to build.
And also for engineering, it created a dangerous weakness in defining a profession by its most automatable part. That set it up for a crisis the moment that part gets automated.
That crisis is here. Developers who see themselves as “people who write code” are watching machines learn to write code. And they’re scared.
But developers who see themselves as “people who solve problems through software” are seeing something different. A powerful tool that handles the most time-consuming part of their work, leaving them free to do everything else. The understanding and the judgment. The parts that were always the real craft.
The commoditization of intelligence and the industrialization of coding reveal what software engineering was always meant to be.
III. What the Machine Needs from You
Let’s be honest about what AI can do today. It can take a description and turn it into working code. It can find bugs, write tests, and scaffold projects. For routine tasks, it performs remarkably well.
But ask it to decide whether your product should have a separate login and signup page, or whether a passwordless flow would reduce drop-off by 30%, and it has nothing useful to say. That question requires understanding your users, your business, and your data. It requires context that lives outside the codebase.
The machine is great at translation when we give it clear inputs, and it produces clear outputs. But it can’t decide what matters and weigh competing priorities.
This is why “human in the loop” is a long-term strategy. The machine handles production. The human provides context with direction and judgment. That’s a complementary design.
The Sequoia’s recent article, Services: the new software, articulated it beautifully, “Writing code is mostly intelligence. Knowing what to build next is judgment.” It is a great distinction of ingredients that knowledge work needs. Where there is need, there is supply and demand dynamics, and with these dynamics, bottlenecks form.
It is the natural order for the economic system to invent newer machines that can reduce or eliminate the bottlenecks. These are levers. But the nature of the bottlenecks is that they don’t disappear when these levers are introduced; they rather appear at a different level with different demands. It used to be intelligence; now that we have intelligence on tap, the next bottleneck is human judgment.
IV. The Product Engineer and the Full Value Stack
So if machines handle more of the coding, and the real value lies in knowing what to build and why, what do we call the person who does that work?
Not a product manager who owns strategy but doesn’t build. Not a traditional developer who writes code to someone else’s spec. Not a designer who shapes experience but doesn’t own the technical decisions.
The product engineer sits at the center of all three. They understand users well enough to know what they need. They understand the business well enough to know what matters. They understand the technology well enough to direct the machine that builds it.
This isn’t a brand new job. Great engineers have always worked this way. What’s new is that it’s no longer optional. When the machine handles more of the coding, engineers who only know how to code have a shrinking role. Engineers who know how to think about the whole problem become more valuable than ever.
The industry was already moving in the direction of having lean, self-managing teams. The older model, where a product manager writes a spec, hands it to engineering, and the engineers building exactly what’s described, no longer makes sense in smaller teams. When the machine can produce code in minutes, the bottleneck shifts to the quality of the thinking that directs it. The product engineer doesn’t wait for a spec. They own the problem.
I know this because I’ve done it. In 2021, while building Success, a platform purpose-built for enterprise sales engineering teams to manage their presales engagements, we renamed our entire engineering team as the product engineering team. This was before AI tools became mainstream. Inspired by our own experience and Gergely Orosz’s writing on the product-minded engineer, we made the shift early.
The change wasn’t about titles. It was largely about mindset. We wanted every engineer to think beyond code and the technical layer. Thinking about use cases, user experience, business implications, and technical constraints. The title change was for the identity shift. The full value stack. It changed how the team approached their work. Engineers started asking better questions, pushing back on specs that didn’t make sense, and caring about outcomes and impacts rather than just output.
For years, “full stack developer” meant someone who could work across technical layers. Frontend and backend. Database and deployment. That definition now needs an expansion.
The new full stack runs on two axes. The soft layer is where human judgment lives: product sense, user experience thinking, and business awareness. The hard layer is where technical skill lives: systems understanding, architecture, security, and the ability to direct and review what the machine produces.
In the old model, the hard layer was everything. In the new model, it’s necessary but not enough. The product engineer who can move between both layers, who can talk to a user in the morning and review a pull request in the afternoon, is the new full-stack developer. Not a full technical stack. Full value stack.
V. The Four Parts of Product Engineering
The product engineer works at the highest layer of abstraction. Not inside the code, but above it, deciding what the code should do and why. In practice, a product engineer’s day comes down to four things.
Understand what the user and business needs and wants are. Before you touch any tool, you need to know what problem you’re solving and for whom. Talk to users. Study the data. Understand what the business is trying to achieve and why it matters now. This is the step that separates a product engineer from a coder. The quality of everything that follows depends on how well you understand the problem, the context, before you start building.
Provide context, inputs, and guardrails. The machine can build, but it can’t decide what to build. You bring everything the machine can’t know: who the user is, what problem you’re solving, what constraints exist, and what quality bar matters. Garbage in, garbage out is still relevant. The product engineers’ responsibility is to make sure the inputs are of higher quality.
Set up and operate the machine to co-create. You’re not handing off a task and walking away. You’re in a loop. You describe, the machine produces, you review, adjust, steer. This is closer to directing than delegating. Your technical knowledge tells you when the machine took a wrong turn. Your product sense tells you when the output is correct, but misses the point.
Review and get the last mile to publish. Review, eliminate, recreate, retain, and ship. The machine gives you a first pass. Your job is to review what it produced, eliminate what doesn’t work, recreate the parts that need rebuilding, retain what’s good, and finish the last mile to publish. The difference between ‘it works’ and ‘it’s ready to ship’ is yours to own. And if something breaks at 2 AM, “the AI wrote it” is not an answer. You’re shipping your work, built with the machine’s help.
VI. The Machine Builders
So far, we’ve talked about the people who operate the machine. But there’s another set of jobs emerging: the people who build and maintain the machine itself.
AI engineers. The people who take the existing capabilities of these models and build new capabilities on top of them. They design the tools, the pipelines, the guardrails, and the infrastructure that make AI useful in production. They’re not using the machine to build products. They’re building the machine that others use.
This is a distinct path from product engineering, but it shares the same foundation. You still need to understand users, because the users of your machine are other engineers. You still need product sense, because a tool nobody can use reliably is a tool nobody will trust. And you still need deep technical skill, because you’re working at the layer where the abstraction breaks down and the real complexity lives.
Both paths matter. The industry needs people who can operate the machine well and people who can make the machine better. The common thread is that neither role is just about writing code anymore.
VII. Two Misconceptions Worth Addressing
As this shift picks up speed, two misconceptions keep showing up in conversations. Both are worth addressing head-on. Two questions.
“Do we need to learn coding anymore?”
If the machine writes the code, do you even need to learn coding?
Yes. For two reasons that go deeper than you might expect.
First, coding teaches you a way of thinking. Breaking a fuzzy problem into precise steps. Handling edge cases. Thinking in systems, not just features. This is what separates someone who can direct a machine effectively from someone who gives it vague instructions and hopes for the best. A lot of non-coders working with AI tools struggle because they haven’t developed this way of thinking. They don’t know what to ask for, and they can’t tell when the answer is wrong.
Second, you need coding knowledge to evaluate the machine’s output. AI will produce code that looks right, runs without errors, and still has serious problems: security holes, performance issues, and architectural choices that will cause pain in six months. If you can’t read the code and understand what it’s doing, you can’t catch these mistakes. That’s not a proper review.
The product engineer doesn’t need to be the fastest coder in the room. But they need to understand code well enough to think like a programmer and judge like one. The machine writes. You decide if what is written is worth keeping.
“Is it a downgrade from software engineering because I don’t code?”
The biggest misconception I see is that the shift is perceived as a lesser version of software engineering because we don’t write code. As if the shift from “write code all day” to “direct machines and own outcomes” is a step down.
This is because of the identity we discussed earlier in this article. In fact, the reality is that it is the opposite is true. Product engineering is more valuable.
The product engineer isn’t a software engineer who lost the coding part of the job. They’re a software engineer who gained everything else. The technical skill doesn’t disappear. It still matters. But it sits inside a wider frame of judgment and ownership that makes it more powerful, not less.
VIII. The Craft, Finally Seen in Its Entirety
This matters no matter where you are. If you’re early in your career, learn user behaviors, not just frameworks. If you’re a senior engineer, your judgment is your biggest asset now, not your syntax speed. If you’re a founder, hire people who ask “why” before “how.” And if you’re self-taught, you might be better positioned than you think. You’ve always had to learn by shipping real things to real users. That’s exactly the skill set the industry now needs.
Think back to the weavers. The power loom didn’t kill the craft of making fabric. It killed one definition of that craft, the one where value lived entirely in the hands that moved the shuttle. What emerged was something bigger. The industry grew, the work evolved, and the people who adapted were the ones who saw the change for what it was: not an ending, but a beginning.
The future of full-stack isn’t vertical. It is both vertical and horizontal. It’s about understanding every layer of the value stack. From what the user needs, to what the business requires, to how technology delivers it, to what the experience should feel like.
That’s the product engineer. That’s the full value stack. And for those willing to make the shift, it’s not the end of the craft.
It’s the craft, finally seen and made in its entirety. And as the future of work, we are set to do the most human thing: to judge.