The Skills That Matter

I copied and pasted code for two years before I realized I was not learning anything. I was only getting faster at the wrong thing. And I think the exact same mistake is happening again now, to most of the engineers I know, to me, but with agents instead of stack overflow, and nobody is describing it in a way that actually helps, so I am going to try, and I am going to get pieces of it wrong, and I would rather be roughly right about the direction than precisely right about a rung that is already being paved over while I polish it.

Let me back up.

When I started writing code, the game was simple enough to describe. Can you take a problem and turn it into working software. If you could, you were valuable. If you could do it fast, you were very valuable. If you could do it fast and it did not fall over in production at the hour when nobody was awake to catch it, people said things about you in standup that you could live off of for weeks. The currency was output, the coin was lines written, and for a long time the path forward was the one that had always been there, which was to write more. More code. More patterns. More APIs. More hours. More edge cases. The slow development of that thing senior engineers have, where they look at a pull request and say, this is going to break on Tuesdays, and they are right, and nobody knows how they knew, not even them, because it is not knowledge, it is accumulated contact with the material.

That progression is real. I do not want to dismiss it. Five years of it taught me things I could not have learned any other way. But there is a ceiling on it, and nobody warned me about the ceiling until my face was already pressed against it.

The ceiling is that one person can only produce so much code. There is a wall, and when you hit the wall, your mind does a strange thing, it bargains. It tells you maybe you should learn another framework. Maybe you should type faster. Maybe you should work weekends. Maybe if you grind hard enough you can push through to the other side of the wall, and on the other side there will be a version of you who can produce twice as much, and the producing will finally be enough. There is no such version. What is on the other side of the wall is not more productivity. It is a burned-out person with a nice GitHub streak, and I know this because I was him for a while, and the streak did not love me back, and the things I thought I was building during that period were mostly me building a reputation for enduring, which is not the same as building anything else.

The way through the wall has always been the same, for as long as this field has existed, and it has nothing to do with writing more code. The way through is that you change what you are producing. You stop being the person who writes the code, and you start being the person who makes it possible for other code to be written well. Your unit of output changes from lines you wrote to things you made possible. Leverage, if you want the cold word. Multiplication, if you want the slightly warmer one. Either way, it is not a horizontal shift. It is a change in what your work even is.

Most people stall at this shift, and I stalled at it too, because it does not feel like a promotion even when it technically is. You go from I am the one who knows to I am the one who helps other people know, and something in the chest resists the transition, and the resistance is not stupidity, the resistance is identity, and identity does not update because the org chart updated. I have written about this before. It is always an identity thing. It is always an identity thing, and the always is what makes it so hard to see when I am inside of it, because from the inside it always looks, at first, like a technical concern, and only later, usually after the cost has been paid, does the actual shape of it become visible.

That is the old ladder. Capability, then clarity, then leverage. It has been the same ladder for longer than I have been alive, and it will probably be the same ladder for a long time after I am done, and most of the advice that matters, if you strip away the vocabulary of whatever era it was written in, is about climbing that ladder with fewer wasted years than the writer wasted.

And then agents arrived and scrambled the relationship between the rungs, and I want to describe what actually happened, because most of the current conversation about this is either breathless or dismissive, and neither of those is useful if you are trying to understand what is happening to your own work.

Here is what I thought at first. I thought the new skill was prompting. I thought the game was, write better instructions, get better code. I got deep into it. I read the guides. I built elaborate templates. I treated it like a new programming language whose syntax happened to be English. This was the same mistake I had made before, in different clothes. Prompting is typing. We have never been hired for typing. I was optimizing at the wrong layer again, which is apparently my signature move, and the fact that I keep making it in new costumes suggests that the layer I keep reaching for is the one where I feel safest, not the one where the actual work has moved to.

Here is what I think is actually going on.

Every few years a new abstraction layer appears in computing, and when it appears, it eats the layer below it. Binary. Assembly. Compilers. High-level languages. Frameworks. Libraries. Each one made the previously hard thing cheaper, and each one moved the floor up, and each time, the people who had built their identity around the previous hard thing had a bad few years, not because they were not smart, but because the ground under them had moved, and their nervous systems were still defending territory that had become common land.

Agents are the next layer. They are an abstraction over implementation. You describe what you want, they produce the code. Not perfectly. Not every time. But cheaply, and quickly, and getting better in a way that does not seem to be slowing down. What this means, and I want to say it plainly, is that implementation, the thing that was the bottleneck for all five years I have been doing this, the thing I built most of my professional sense of self around, is becoming cheap. Not free. But cheap enough that it is no longer the constraint, and when the constraint moves, the skills that matter move with it.

I learned this the embarrassing way, which is the only way I seem to learn anything. I would open the agent, type something like build me a dashboard that shows user metrics, hit enter, get back something mediocre, and conclude that the tool was broken. I did this about fifteen times before I realized the tool was not broken, my specification was broken. I had been vague in a way I had been allowed to be vague my whole career, because I had always been the one implementing, and I could resolve the ambiguity in real time, inside my own head, without anyone noticing I was doing it. The agent could not resolve my ambiguity for me. The agent took my vagueness and filled it in with whatever seemed statistically plausible, and then I was debugging a specification failure while calling it a model failure and feeling, uncharitably, vindicated in my skepticism.

The agent was not the problem. I was the problem. I had never had to be genuinely clear about what I wanted, because I had always been the one building it, and clarity was optional when I was my own executor. It is not optional anymore. That is the whole shift, in one sentence, and most of what follows from it follows naturally once you are willing to believe it, and most of the resistance to it is the resistance of a person who is not yet ready to believe it, because believing it requires admitting that a lot of what felt like skill was actually the ability to route around imprecision at the speed of typing, and the speed of typing is fast enough to hide almost anything from yourself, if you do not slow it down on purpose.

So. What actually matters now. I want to say these slowly, because I am still testing them against my own weeks, and I do not want to hand you a shape I have not yet earned.

First, clarity. And I do not mean writing detailed specs. I mean the ability to say, in plain words, what a system must do, what it must never do, what happens when things go wrong, what done means, and, just as important, what done does not mean. Naming the constraints. Naming the edge cases. Naming, especially, the places where your own understanding has been held together by implementation intuition rather than by actual thought.

If you want to find out where your cliffs are, try this. Take a feature you built recently, something you feel confident about, and try describing it to an imaginary person who has zero context and infinite literal-mindedness. You will find gaps in your own understanding that you have been papering over with implementation intuition for years. I did this last month. I found gaps I had been carrying around since my first job. It was not a fun afternoon. I sat at the desk and watched my own certainty come apart under a kind of questioning I had never, not once, submitted it to, because I had always been allowed to answer my own questions at the speed of typing, and the speed of typing is fast enough to hide almost anything from yourself if you do not slow it down on purpose.

Clarity is what lets someone else execute without access to your head. That someone else used to be a junior engineer, or a contractor, or the future version of you reading your own code three months later. Now it can also be an agent. The requirement did not change. The executor changed, and the change made the requirement more visible, more immediate, less avoidable.

Second, delegation. And again, I do not mean break it into tickets. I mean break work into units that fit inside a limited mind. Units that can run in parallel without colliding. Units that minimize coupling. Units that do not create dependency chains that turn your afternoon into waiting. Agents make this extremely literal because they have context windows, which is another way of saying they have limited working memory, which is another way of saying they cannot hold your whole system in their head at once. So you have to decompose. You have to think about the cognitive limitations of your executor and design the work around those limitations, and if you give an agent a task that requires understanding the whole system to perform correctly, it will produce something that works for the thirty percent of the system it could see and hallucinate the rest, and you will debug the hallucination for longer than it would have taken you to have decomposed the task properly in the first place.

Here is the uncomfortable part. This is the same skill as managing people. It always has been. And most engineers, including me, emphatically including me, are not very good at it. I have, in my career, given humans tasks that required them to read my mind, and then been frustrated when they could not read my mind, and the frustration felt righteous at the time and looks, in hindsight, like a small tantrum conducted in professional language. Agents did not introduce the skill. Agents made the feedback loop on the skill faster and more honest. The agent tells you immediately, in the form of a bad output, that your delegation was unclear. A junior engineer might take three days and some quiet suffering to tell you the same thing, and in those three days you could have told yourself a story about what happened that kept your self-image intact. The agent removes the three days. The agent removes the story. The agent is a mirror held up to your decomposition skills at two in the afternoon, and most of us do not love the face that looks back.

Third, orchestration. Knowing when to parallelize and when to serialize. Knowing which pieces are safe to explore in parallel and which pieces are load-bearing and need a human hand. Knowing when adding another agent to the problem helps and when it only creates coordination overhead that costs more than it saves. I over-parallelize constantly. I spin up three agents on a problem and then spend more time reconciling their outputs than I would have spent doing it sequentially. I am getting better at this, slowly, by watching myself be wrong often enough that the pattern becomes visible. There is no shortcut to the watching. There is only the watching, and the willingness to notice the pattern instead of explaining it away.

Fourth, and this is the one that is going to make some people uncomfortable, taste.

When software is easy to produce, the bottleneck is not production, it is selection. It is knowing what to build. It is knowing what it should feel like when it exists. It is the difference between a thing people tolerate and a thing people want, and between a thing people want and a thing people keep, and between a thing people keep and a thing that, quietly, over years, changes how they think about the category it is in. Most of the people I admire in this field have this sense. Few of them can articulate it cleanly. They know when a thing is right the way a woodworker knows when a joint is right, which is to say, immediately, and without recourse to metrics, and with a confidence that would look arrogant if it were not borne out, over time, by the things they produce.

Think about houses for a minute. Building a house got easier and cheaper over the last century. Dramatically so. And yet the houses people actually love, that people seek out, that people pay premiums for, are the ones with taste. Something about the proportions. The way light moves through a room. The restraint in the materials. Most people cannot name what they are responding to, but they respond. The absence of taste is felt more strongly than the presence of any particular feature. A house can have every feature you would think to ask for and still feel wrong. A house can have almost nothing and feel, the moment you step inside, inevitable.

Software is moving the same way. When code is cheap, when anyone can spin up an application over a weekend, the differentiator is not can you build it, the differentiator is should you build it, and if so, what should it feel like. The feeling, which used to be a nice-to-have dressed on top of a hard-won technical achievement, is now most of the value, because the technical achievement has become background. The feeling is taste. And taste is hard to develop because it is not a technical skill, and engineers, myself included, are trained to be suspicious of anything that is not a technical skill, and I am working on this suspicion in myself, because I have started to notice that most of the work I admire was built by people who made peace with that suspicion long before I did.

A company with taste ships products that feel inevitable. Of course it works this way. A company without taste ships things that feel like a pile of features stapled together by a committee that was afraid to cut anything. You have used both kinds of software. You do not need me to tell you which is which. And the difference between them, once production is cheap, is basically the entire game.

So. The ladder is the same ladder. Capability, clarity, leverage. It has been the same ladder the whole time. What changed is the height of the rungs. Agents moved the floor up. The lower rungs got automated, or are being automated, and the skills that matter most shifted from can you implement to can you think clearly enough to direct implementation and judge whether the result is any good. Clarity. Delegation. Orchestration. Taste. That is what staff engineering has always been, and what working with agents is now, and the people who are going to be good at the new thing are, overwhelmingly, the people who had already learned the old thing, which is not a coincidence, it is just the ladder continuing to be the ladder while the scenery around it changes.

Here is the thing that has been sitting in my chest for weeks.

I spent years building an identity around implementation. Around being the fast one. The one who knew the weird corners. The one who could be called at three in the morning and would actually know what was wrong. That skill is not worthless. I want to be clear. But it is less scarce than it was a year ago, and it is going to be less scarce a year from now, and the skills that matter more are the ones I spent years avoiding because they felt soft, because they felt less real, because they did not give me the satisfying feedback loop of writing code and watching the tests go green.

Clarity is harder than coding. I want to say this outright. Coding lets you be vague and fix it as you go. Clarity requires you to have thought it through before you start. Delegation requires you to trust someone, or something, else to do the work. Orchestration requires you to zoom out when your whole nervous system is pulling you in. Taste requires you to hold opinions about things you cannot prove with a benchmark, and to hold them in rooms full of people who will ask you to prove them with a benchmark anyway.

None of this is comfortable. I am not comfortable. But I am starting to think the discomfort is the signal. The resistance is the information. If you are an engineer, and something in this essay has made you want to argue, I want you to pause before the arguing and ask, honestly, what is being protected. Sometimes the answer is that the essay is wrong and the protection is appropriate. Sometimes the answer is that the thing being protected is an identity more than a skill, and the protection is the last reflex of a self that has not yet agreed to become the next version of itself. I cannot tell from here which one it is for you. I can only tell you that I have both reflexes in me, and I am trying, with the small tools I have, to tell them apart, and to follow the second one when I can, and to let the first one speak when it has earned the floor.

I might be wrong about pieces of this. I am probably wrong about pieces of this. But I would rather be roughly right about the direction of the ladder than precisely right about a rung that is getting paved over while I polish it.

The ladder is the same ladder. The rungs are higher now. The climb is the same climb. What changed is that you cannot fake the climb with typing anymore, and most of us had been faking at least a little, and the faking is what I am trying to stop, in myself, this year, with whatever patience I can borrow from a future version of me who has already made it to the next rung and is, I hope, looking back kindly.