The Other Half: What a Software Engineer Still Owns When the Code Is Cheap

Note: this essay was drafted with the help of AI. The research, structural choices, and editing are mine. The ideas and final shape are the result of my own work.

The first essay in this series asked what happens to a generation of problem-solvers when the problems get solved without them. The second asked what the solving does to us when it never stops. I promised a third piece about discipline. This is a detour on the way there. Between those two essays I started preparing a conversation with my team about what I thought their job was becoming, and I discovered I did not have the words for it. What I had was a competency matrix, the one every engineering organisation keeps, with its rows for execution and quality and communication and its columns from junior to staff. I had read it dozens of times. That afternoon I read it again, and noticed for the first time that every row had two halves, and that we had been reading one of them.

1947

In the summer of 1947 Herman Goldstine and John von Neumann published the first volume of a report whose title reads today like a job description: Planning and Coding of Problems for an Electronic Computing Instrument¹. The computer it described did not yet exist. Neither did the job. They invented it on paper, and the first thing they did was divide it.

Planning was the mathematical work. Take a problem from the world, decide what needs to be computed, break it into steps, draw the flow diagram. Coding came after: translate the diagram, instruction by instruction, into something the machine could execute. The report is clear about which half mattered. Planning was the intellectual contribution. Coding was expected to be close to clerical, work you could hand to someone else once the thinking was done².

The people it was handed to were, for the most part, women. The six who programmed ENIAC had been hired as "computers", the job title for a person who did arithmetic by hand, and were given wiring diagrams and a machine and told to make one match the other. Nobody expected the work to be interesting. It turned out to be the hard part. The machine had no tolerance for approximation. A diagram that satisfied a mathematician did not satisfy a bank of vacuum tubes, and the gap had to be closed by someone, and closing it took a kind of thinking the planners had not anticipated. The people who closed it became the first programmers. Within a decade the planner and the coder had been folded into one person, the programmer. The word "coder" survived, but as a nickname for the whole job rather than its lower half, and the hierarchy had quietly reversed: the scarce people were the ones who could make the machine work, and planning was something they did on the side².

I find the story useful for a reason that has little to do with history. The 1947 report drew the line in the right place and put the weight on the wrong side. There really are two activities here. Deciding what to compute and making the machine compute it ask for different attention and fail in different ways. Goldstine and von Neumann guessed the first would stay hard and the second would become routine. For most of the eighty years since, the opposite held. The second half was so hard, so absorbing, and so well paid that it became the identity. "Software engineer" came to mean a person who owns the code.

That is the half the machine is now reaching for.

What Is Moving

I want to be careful with the claim, because the data is loud and the conclusion people draw from it is usually larger than the data supports. At PostHog, a company that has made "product engineer" a job title and a small ideology, the share of pull requests opened by agents rather than people went from twenty percent to seventy percent in four months. Merged pull requests per month went from around fourteen hundred to nearly five thousand. Engineering headcount grew ten percent³. Satya Nadella said in 2025 that twenty to thirty percent of the code in some Microsoft repositories was generated by AI⁴. The figures in your own organisation will differ. The direction will not.

What those numbers show is that the translation step, intention to syntax, is being handed to something else at scale. What they do not show is that the technical half of the job is going away. Someone still decides what the agent should build, reads what it built, and knows whether the system can carry it. Someone still gets paged at three in the morning. Technical debt does not care who wrote the code, and in a codebase where most pull requests are opened by machines it accumulates faster than it ever did. The guilds that hold a platform together across teams still have to meet. The development lifecycle itself, how code gets reviewed and tested and shipped when most of it was not typed by a person, has to be designed, and almost nobody has designed it yet, and that is among the most technical pieces of work a company will do this decade.

So the 1947 report might finally be correct, in the narrow sense that the mechanical part of coding is becoming mechanical. The planners were wrong about something else, and are still wrong: that the two halves can be separated cleanly. They cannot. Every implementation choice is a small product choice, and every product choice is constrained by what the system can do. What automation changes is not the boundary between the halves. It changes which half is lit.

You Were Always Doing This

Fred Brooks wrote in 1986 that "the hardest single part of building a software system is deciding precisely what to build," and that "no other part of the work so cripples the resulting system if done wrong"⁵. He also wrote that it is impossible for a client, even one working alongside engineers, to specify a system completely before some version of it exists. Every engineer knows this in their hands whether or not they have read it. The spec is never complete. The ticket says "add a filter" and does not say what happens when the filter returns nothing, or whether the state survives a reload, or whether the person who asked for it resembles the people who will use it. Somebody decides. The somebody is usually the engineer, at eleven in the morning, with the cursor blinking, and the decision happens so fast and so quietly that nobody, the engineer included, files it as a product decision. Jeremy Freeman at Allstacks calls these micro product decisions, and his point is sharp: AI does not create this responsibility. It exposes it. "You were always a PM," he writes. "AI just made sure everyone notices"⁶.

It is noticed now because the cover is gone. When the engineer spent six hours making the machine do it and ten minutes deciding what "it" was, the ten minutes hid inside the six hours. When the six hours become forty minutes of reading an agent's output, the ten minutes are suddenly most of the visible job. Laurie Voss, who co-founded npm, made the same observation from the other side on a podcast in September: as agents write the code, the thing you used to find only in senior developers, the ability to translate what the business needs into what the software should do, "is becoming absolutely central to the job"⁷. He compares it to the systems analyst of the 1960s. That is 1947 again, with the weights the right way round.

This is what I saw in the competency matrix. Take the row for a senior engineer under Execution: "owns and solves complex architecture and business problems." Most of us read that as architecture. "Business problems" sits in the same sentence and gets less weight. Under Contribution: "autonomous in the definition of scopes and business solutions and needs." Read as: scopes the project well, once someone else has decided what the project is. Under Quality: "efficiency (costs)." Read as: cloud bill. Under Communication: "delivers proper technical analysis." Read as: writes a good design document.

None of this is a misreading. The rows do say those things. They also say the other things, in the same breath, and the other things were always lighter on the page because the first things were what got you hired and promoted and what filled the day. My team is good at the first things. Some of them have always done the second as well, and asked about the number before and after a project without being told to. Others are curious and have started, and have not yet made it a habit. Nobody is indifferent. But for most, the second half is still something you reach after the real work, and the real work is making the machine do it.

Three Questions, and a Fourth

I am not changing the competency matrix. I am going to tell my team that I will read it differently, and these are the questions I will use to read the words "business problems" and "business needs" in their reviews from now on.

Did you question the what? Not the implementation. The thing itself. Before you built it, did you ask whether this was the feature, or just the first feature someone thought of.

Did you look at a number before you built it? Any number. The dashboard that already exists for your team. A session recording. A support ticket. One observation of a real person touching the real product.

Did you ever say something was not needed? This is the one that separates the halves most cleanly. Owning the code means you can build anything. Owning the product means you sometimes build nothing, and say why.

And a fourth, which I noticed was missing only while writing this. The first three all look at the moment before shipping. None of them looks at the moment after.

Did you check what happened after you shipped? Not the deploy. The number. The one the project was supposed to move.

They are deliberately behavioural. "Product sense" is not a thing I can see in a review. An engineer who walked into a planning discussion with a number and a user observation that the PM did not bring is a thing I can see. An engineer who said "I don't think this is worth building", and gave a reason, and then either held the position or changed it after a real argument, is a thing I can see. Whether they turned out to be right matters less than people think. A review judges the quality of the decision with the information available at the time. The outcome is a separate fact, and often a lucky one.

What I Want to Change

I know how the questions sound, read cold: like a higher bar. Own the product on top of owning the code. Fifty-fifty where there used to be a hundred-zero, with the hundred still expected. I believe that reading is wrong, but I do not expect anyone to believe it on my say-so. "I am not asking for more" is credible only if the manager is visibly changing what he asks for. So here is what I want to change, in order of cost.

Material first. An engineer walks into a product discussion without a number and without having watched a user, because nobody set up the dashboard for them, because the session recordings live in a tool they have never opened, because the support queue is somebody else's job. The PM has the material. The engineer has the project, already shaped by the time it arrives. For years my team has worked on projects and has owned them end to end once they started. But most of the shaping happened before the start, and most of it was done by the PM. You cannot question the what with nothing in your hands. The first change is to put the material there. The engineer opens the team dashboard directly instead of receiving a summary of it. The session recordings, which the team already has and has mostly watched as a form of requirements, become something to watch before deciding whether the requirement is right. Once a quarter, the engineer takes a shift answering real customers. None of this requires a new tool. It is the tools we already pay for, in different hands.

Then the entry point. Today the engineer joins when the PM has a ticket. I want the engineer in the room when the PM has a problem, which is earlier and messier. This is not a transfer of ownership. The PM still drives the initiative and still owns the lagging metrics, the ones that say whether the business moved. The engineer owns a smaller, faster number: the leading metric that should move within a week or two of shipping, and that an engineer can read without asking anyone. For every initiative, before the discussion about which features to build, an engineer brings that number and one user observation, alongside what the PM brings. If after two initiatives nobody has done it, the problem is belief, not material, and that is on me.

Then the review. This is the part that costs me the least and matters the most, and I want to be precise about it. The questions will not appear in the review as four new fields. The matrix stays as it is. What changes is how I read the words already in it. When a review says "business problems" or "business needs", the questions are what I will be thinking about as I write the sentence under them. That is a different lens, not a different form, and my team will hear it from me before any review is written with it. The reason it matters is simple. A message is only a message. People believe what shapes their review, not what gets said in a meeting. If the lens never reaches the review, the competency matrix has not changed and neither has the job.

And the thing that is not mine to change. There is a version of this where the engineer tried, brought the number, made the argument, and nobody listened. I have to say two things about that honestly. The first is that being overruled after a real argument is not the same as not being heard. You bring a number, the PM brings a different number, the discussion happens, you lose. That is what a discussion costs, and the team has moved decisions more than once on the strength of an engineer's objection, so the space exists. The second thing is that a space existing is not the same as a space being open every week, and keeping it open is my job, not theirs. The three causes I can see for why a good engineer does not already live in the other half are missing material, a belief that it is not their role, and a space that closed once and was not reopened. I used to think only the first two were mine to fix. All three are.

The Half That Stays

I should say clearly what this essay is not arguing, because the people who make the machine run will read it first and hardest.

Some engineers on my team are built for the platform, not the feature, and they are not less for it. What they own is a different what: not an outcome a customer sees, but the conditions under which outcomes can be built at all. Keeping a system boring. Paying down the debt before it compounds. Deciding how agent-written code gets reviewed, and by whom, and against what. These were always technical initiatives, they are still vital, and they are getting harder, not easier, as the typing gets cheap.

The four questions apply to them without modification, with the product swapped for the platform. Did you question whether this migration was the one worth doing. Did you look at a number before you started. Did you ever say that something did not need to be built. Did you check, afterwards, whether it did what you said it would. The other half is not a demand that everyone become a product engineer. It is a demand that everyone own an outcome, and know which one.

The Other Half

PostHog renamed its engineering newsletter this summer. For years it was Product for Engineers. Their stated reason was that the mission had, in their view, succeeded: engineers had started thinking about product, and the title had become redundant. The line they used stayed with me: "when code is cheap, the product skills we wrote about become even more important"⁸. Addy Osmani, writing in January about the next two years of the profession, put the same thought as a sentence with a blank subject: "someone has to decide what the AI should build, verify the product makes sense, and continuously improve it"⁹. Someone. The sentence does not say who, and that is the whole question.

The first essay in this series was about losing the container. The second was about the container filling faster than we could empty it. This one is about what was inside all along. I used to think the identity of my profession was the code, because that was the hard part, because that was where the pleasure was, because that was what I was hired and promoted for. I now think the identity was two halves from the beginning, and I was standing in the one that was lit.

In 1947 two mathematicians divided a job that did not yet exist and handed the half they thought was easy to people they thought were clerks. The clerks became the engineers. For eighty years that half was the profession. The machine is now doing some of what the planners said it would do, eighty years late and less completely than the headlines claim. What is left is partly the half they kept for themselves, deciding what to compute, and partly a harder version of the half they gave away. Neither is new. One of them was simply unread.

Sources & Further Reading