Code Got Cheap. Building Did Not.

A product manager dropped a ticket that was really a wish. I spent three days making the wish into code. The pull request matched every line. I treated that match as the craft.

Then we shipped it. Nobody used it. The ticket had been clear. The problem had been wrong.

That used to count as someone else’s miss. I wrote what I was asked to write. The box was small on purpose: receive the ask, type the code, argue that the code is faithful. Faithfulness was the identity. If the screen matched the document, I had done my job. If customers ignored it, that was a product failure, and product was a department down the hall.

An afternoon with an agent ends the box. The wish becomes a working screen before lunch. The 2 p.m. meeting stops asking whether we matched the spec and starts asking whether this should exist, for whom, and what would make it worth their Tuesday.

If that meeting makes you itchy, you are meeting the job that was always there.

Code Got Faster. Why Does Building Feel Worse?

The apparent contradiction is simple. Tools that write software in minutes should make building easier. Teams should feel more powerful. A lot of good engineers feel the opposite. They feel naked.

They still know how to produce. Production is no longer the scarce move. The room now asks the questions they used to bounce to a PM, a designer, or “the business”: who this is for, what job it replaces, why anyone would switch, and what you would cut if you were honest.

The old split felt clean: either you are a coder or you are a product person. The ticket kept the split in place. You could be excellent inside a box that never required you to decide whether the box was pointed at a real human. Cheap code does not create a new job. It removes the job that used to count as the whole craft. You owed the judgment about what deserves to exist before any agent showed up. A shop that still bills by the ticket did not cancel that duty. Cheap code made the old dodge obvious without inventing the obligation.

The vibe code debate is a different argument. That piece is about caution versus speed, and about the debt of demanding to understand every line before you move. This piece assumes you already moved. The hangover is identity. You can generate a feature and still have no idea whether it should exist.

Big pull requests is another cousin. Size of the diff is a process question. This essay asks what the work is, now that typing is cheap.

What Is Poiesis vs Techne?

Aristotle already had the pair we keep smashing into one English word: coding.

techne is productive know-how. How you make a thing once the thing is decided. Frameworks, types, tests, the muscle of turning a defined ask into running software. That is real craft, and it is also the part an agent now does on a Tuesday morning while you drink coffee.

poiesis is bringing-forth. Making something come into the world that did not have to exist. A builder’s ergon is the function of the work: a thing worth existing, which a faithful ticket never guaranteed. See also poiesis and techne.

phronesis is the faculty that sits on the second column. Practical wisdom: what to make, for whom, under this constraint, today. An agent can propose three screens. It cannot owe the call. You still assent. You do not control whether the org still hands you tickets, or how fast the model types. You control whether matching a wish counts as the whole day’s work. The model does not grant the capacity to judge what should exist, because that capacity was already yours. Equal model access already widened the gap between people who interrogate and people who paste. This is the next turn of that screw. Interrogation without a sense of the customer is still typing with better questions.

kalon is the name for the sense that a thing is fine, beautiful and right in the same breath, not merely shipped. Taste is the trained flinch when a demo looks good and still should not go out. You can feel kalon fail in a sprint review: the room nods at the polish, and still cannot name who would miss it if you deleted it tonight.

I have sat in that review. We clapped for a settings page that took an agent twenty minutes and a designer two hours of “make it feel premium.” Support tickets the next week were about a broken import nobody in the room had touched. We had spent the scarce afternoon on the pretty thing because pretty still felt like work. The import was ugly, and it was the product.

Cheap Code Fired the Old Identity

People hear “code got cheap” and think they are being told their skill was fake. The skill was real, and the identity was oversized. Matching the document used to be enough to go home proud. That was a historical accident of how expensive production was. When production was expensive, the org could afford a class of people whose excellence was fidelity. When production is cheap, fidelity without poiesis is a morning.

This is not only engineers. Accountants who could close the books by hand now watch a model draft the close. Designers who could spend a week on a mock now watch five mocks appear before standup. Analysts who were hired to wrangle the spreadsheet now get the chart in one prompt. The pattern is the same. The production step got cheap while the judgment step stayed expensive. If your pride lived in the production step, the empty afternoon will feel like theft. What actually happened is a move into the part of the job you used to bounce down the hall.

What to automate is the sibling on the doing: keep the work that still forms your judgment. This essay is about which judgment. An agent that will type anything you describe only stays a craft tool if you still decide what is worth describing.

The plumber-outlasts-the-programmer argument already said the scarce resource was moving toward judgment and taste. Cheap code is that prediction arriving as a calendar problem. The afternoon that used to fill with typing now fills with decisions you postponed until the spec was ready. The spec is ready in twenty minutes, and you are not.

arete here means fulfilling the function, not more output. A builder’s function is a thing that should exist. Shipping eight screens nobody asked for multiplies noise, not excellence.

You still owe tests, recovery, and the courage to read what you shipped. Cheap code does not pardon sloppy verification. Verification of a faithful ticket was never the whole moral life of the work. When the spec is a real constraint, a safety rule, a regulation, a contracted behavior that keeps someone from getting hurt, matching it remains the work. The collapse is when the document was a wish and fidelity was used as the whole craft.

Four Moves Out of the Old Box

Write the user and the job in one sentence before you generate anything. Not a persona poster. One sentence you would say out loud to a smart friend: who, doing what, that currently fails how. If you cannot say it, you have a prompt, not a build. phronesis starts before the model, or it never starts.

Kill one pretty wrong thing this week. Find a feature, screen, or automation that looks good in the demo and has no user who would notice if it vanished. Delete it or park it. Taste is a habit you only get by exercising the flinch. If everything you generate ships because generating was easy, you are training the opposite habit.

Bring one market question to standup. Who already pays for a worse version of this. What they hate. What they would not switch for. If nobody in the room can answer, you are still in the old box, arguing about implementation of an untested wish.

When you catch yourself arguing ticket fidelity, stop and name the problem in the world. “Does this match the spec” is a legal question, and “is this the right problem” is the builder’s question. You can still match the spec after you decide the spec is aimed at a real job. Matching first is how we shipped the unused wish in three days.

None of this says product managers are useless. It says people who only implement cannot outsource poiesis anymore, because matching a ticket no longer takes three days. The PM who only writes tickets is in the same collapse. A ticket that is a wish is still a wish when an agent types it in an hour. Keep the production literacy. Dumping the typing because it got cheap, and treating the typing as the whole of excellence, are both vices. arete actualizes the builder’s function, not a caste for people with product in the title.

The obligation does not wait on a title change. You do not need a new job description to ask who it is for. You need to stop treating that question as above your pay grade. Pay grades were written when typing was the bottleneck.

Final Thoughts

Cheap code is a gift that fires an old identity. Mourn that identity if you need to, and do not keep it as arete. The work that remains is deciding what deserves to exist, then having the taste to kill what does not.

If the 2 p.m. meeting still makes you itchy, that itch is information. The job arrived. Sit in it. Ask who it is for, and why they would care on a Tuesday. Then type, or let the agent type. Typing is no longer the proof you did the work.

If you want a community that will not confuse output with building, MasteryLab is where people practice judgment when production is no longer scarce.

FAQ

Did vibe coding make software engineering obsolete?

No. Typing and framework memory got cheap. The job that was always scarce is still scarce: deciding what should exist, for whom, and whether a polished screen is worth their time. Engineers who only match a spec feel obsolete. Engineers who can diagnose a problem in the world and kill a pretty wrong thing are more valuable, not less.

What is the difference between coding and building?

Coding is production know-how: turning a defined ask into working software. Building is deciding whether that ask is the right problem, who it is for, and what would make the result worthy. Aristotle split a similar pair as techne (craft knowledge) and poiesis (bringing something into the world). Cheap code collapsed the first into a morning without doing the second for you.

What does poiesis mean in this context?

poiesis is Aristotle’s word for bringing-forth, making something come into being. In software it is the act of putting a thing into the world that did not have to exist. techne is how you produce it. phronesis is whether you should. kalon is the sense that the result is fine, not merely shipped. Vibe coding accelerates techne without replacing poiesis.

How do engineers develop product taste if they were hired to write code?

Start before the prompt. Write one sentence naming the user and the job. Sit in one customer conversation a week. Keep a kill list of features that looked good in the demo and died in use. When you catch yourself arguing whether the pull request matches the ticket, stop and name the problem in the world. Taste is a trained perception, not a personality type.