The Difference Between Making Software and Engineering It

For most of software history, the person designing a system was also the person physically producing it. We chose the architecture, wrote the code, debugged the failures, refactored the ugly parts, and carried the thing into production. That coupling shaped how we thought about engineering because the engineer and the means of production were effectively the same person.

We built a culture around the act of making. Elegant code, language mastery, clever abstractions, framework fluency, careful refactoring, and deep implementation knowledge all became signals of engineering excellence. That was not irrational. When software had to be painstakingly translated from intent into source code by humans, production skill was scarce and valuable.

AI is starting to break that coupling. Code can now be produced in quantities that would have required teams of engineers only a few years ago. The implementation may still be wrong, incoherent, insecure, or pointed at the wrong problem, but physically producing it is becoming much less expensive.

That exposes a distinction software has been able to avoid for a long time.

Making software and engineering software are not the same thing.

Craft and engineering optimize for different things

Software has a strong craft tradition, and for good reason. Code is a material we can manipulate directly. You can see the difference between a careful implementation and a careless one. You can recognize an abstraction that removes complexity instead of merely moving it. You can look at two solutions to the same problem and know that one was made with greater skill.

A lot of what we think of as good software practice came from that tradition. Readability matters. Simplicity matters. Taste matters. Understanding the material matters. I am not particularly interested in a future where those things disappear.

The distinction is that craft and engineering optimize for different outcomes.

A craftsperson asks whether the artifact can be made better. An engineer has to ask whether making it better is worth the additional cost. That question pulls in constraints that have nothing to do with the intrinsic beauty of the code: expected lifetime, operational risk, maintenance burden, delivery pressure, team capability, regulatory requirements, failure consequences, and the business value of another hour spent polishing the implementation.

Sometimes the best engineered answer is beautifully crafted. Sometimes the correct answer is boring, inelegant, and completely adequate. A migration script that will run twice should not necessarily be engineered like a platform expected to survive for fifteen years. A prototype and a payment system should not have the same tolerance for failure.

This is where software culture occasionally gets confused. Quality is treated as a moral property rather than an engineering variable. Cleaner is assumed to be better. More generalized is assumed to be better. Another refactor is assumed to improve the system because it improves the artifact.

Engineering cannot work that way. Engineering is always asking what is good enough for the problem, what failure costs, and where another unit of effort creates more value than it consumes.

That does not give the developer a license to make bad software. It makes quality explicit.

Production skill was a reasonable proxy for engineering skill

The distinction was harder to see when implementation consumed most of the work.

Someone had to translate the idea into code. Someone had to know the language, understand the framework, remember the APIs, wire the components together, write the tests, investigate the failures, and keep enough of the implementation in their head to change it safely.

Naturally, the people who became exceptionally good at those activities often became our best engineers. The abilities reinforced one another. Deep familiarity with the material gave engineers stronger intuition about architecture, failure, complexity, and cost.

The problem is that we gradually started treating production skill and engineering skill as if they were synonymous.

AI makes that assumption harder to sustain because implementation is no longer scarce in the same way. A capable coding agent can produce scaffolding, migrations, tests, integrations, infrastructure, refactors, and substantial features faster than a human can physically type them. It can do that without getting tired and without needing the work to be intrinsically interesting.

Producing code is no longer the scarce part of the system.

The scarce thing moves somewhere else.

The model can produce code. It cannot make the organizational tradeoff about whether a system should exist, whether a particular risk is acceptable, how much evidence is enough, or whether spending another week making something more elegant has any meaningful value.

Those are engineering decisions.

The uncomfortable implication is that some of the behaviors we historically treated as evidence of engineering excellence may actually have been evidence of exceptional software craft. That is still valuable, but it is not quite the same thing.

Pressing Enter is not the alternative

There is an equally bad response on the other side.

If the machine can produce the implementation, perhaps the engineer no longer needs to understand much of anything. Feed the ticket into Claude, inspect whatever comes back, tell it to fix the tests, have Claude approve the pull request, and move on.

That is not engineering either.

It is how we end up as a prompt router.

A lot of current AI coding workflows are just the old development process with a model awkwardly inserted into the middle. A ticket arrives. A human converts it into a prompt. The agent generates something. The human moves the result into another system, waits for CI, copies the failure back into the model, asks for another attempt, approves a routine action, and repeats the cycle.

The human remains in the loop, but mostly because nobody redesigned the loop.

This is a terrible place to put an expensive engineer. Their primary function becomes moving context between systems that should eventually know how to communicate with one another. The person is not exercising much engineering judgment, but they are still required to stay attentive enough to keep the machine moving.

That is not higher leverage. It is human middleware.

If your AI transformation leaves highly paid engineers spending all day carrying context from one tool to another, you have not automated the work. You have automated around the human.

There is a broader mistake hiding here. We often assume that keeping a human involved automatically makes an AI system safer or better. It does not. A person who has clicked through fifty routine approvals is not suddenly exercising deep judgment on the fifty-first. Humans are not good at remaining meaningfully attentive when most interventions are mechanical.

If the human is present, their intervention needs to matter.

Delegation is not abdication

The interesting path sits between artisanal software development and prompt routing.

You can delegate implementation without delegating responsibility.

In fact, I increasingly think that is the core skill AI is forcing software engineers to develop. The engineer does not need to personally produce every implementation detail, but they do need to understand the system well enough to make consequential decisions about it.

Senior engineers already work this way. A principal engineer responsible for a large platform does not understand it because they have memorized every line. They understand its boundaries, dependencies, invariants, architecture, failure modes, operating characteristics, and the decisions that make the system coherent.

Engineering leaders have always owned systems built by other people. Open source software already means most production applications contain enormous amounts of code nobody on the team personally authored. Compilers generate things we do not inspect. Frameworks hide implementation details we rarely think about.

Direct authorship and understanding were never equivalent.

AI just makes that separation impossible to ignore.

You can hand-write every line of a system and still fail to understand it as a system. You can also understand, govern, and take responsibility for something whose implementation was produced by people, libraries, generators, and agents.

The question is not who typed it.

The question is whether someone understands what matters.

The engineer moves outward from execution

Once implementation can be delegated more aggressively, the human should move outward from the execution loop.

That does not mean disappearing from software development. It means spending less attention on decisions that machinery can make reliably and more attention on decisions where judgment has leverage.

The work starts to concentrate around intent, architecture, boundaries, standards, interfaces, risk, economics, evaluation, observability, failure policy, acceptance criteria, and evidence. Those things were always part of engineering, but code production consumed so much attention that they often wrapped around implementation rather than defining it.

That relationship is changing.

When the production machinery becomes faster, the system around it matters more. A poorly specified goal can now produce bad software at extraordinary speed. A weak architecture can be replicated across thousands of generated changes. A vague standard can be interpreted differently every time an agent encounters it. An evaluation gap can allow a machine to repeatedly produce something that looks complete while quietly violating an important constraint.

This is why I keep coming back to control systems in AI-native software delivery. More capable agents do not remove the need for engineering. They increase the consequence of engineering decisions because those decisions can now propagate through far more execution.

The human does less making and more governing of how making happens.

The roles are starting to separate

The current AI development landscape becomes easier to understand if we stop pretending everyone interacting with code is doing the same job.

There is still the craftsperson, working directly with the material and caring deeply about elegance, control, and the quality of implementation. There is nothing obsolete about that role. Difficult debugging, new primitives, performance-sensitive code, unusual systems work, and places where abstractions leak can still reward someone willing to get close to the machinery.

There is also the operator. A good operator understands the production system, monitors its health, manages exceptions, knows when something is drifting outside acceptable bounds, and understands when human intervention is warranted. As software production becomes more autonomous, I expect this role to become more important, not less.

Then there is the engineer, whose responsibility is broader than either implementation or operation. The engineer determines what should exist, which constraints matter, how the system is shaped, which risks are acceptable, and what evidence is sufficient to trust what has been built.

And then there is the prompt router, which is not really a role anyone should aspire to. It is what happens when an organization adopts AI at the tool level without redesigning the system of work around it.

The same person may move through all of these modes in an afternoon. The point is not to create another job-title taxonomy. It is to recognize that they create value in different ways.

The danger is assuming that because someone is busy interacting with an AI coding tool, engineering is happening.

Craft becomes a tool of engineering

I do not think craft goes away. I think its relationship to engineering changes.

There are times when the right engineering decision is to work directly on the material. An agent may be thrashing on a failure that an experienced engineer can diagnose in ten minutes. A performance problem may require understanding a very specific runtime behavior. A new abstraction may be difficult to discover without manipulating the implementation yourself.

In those moments, craft is incredibly useful.

Craft becomes one technique available to the engineer rather than the thing that defines engineering.

This distinction matters because preference can otherwise masquerade as necessity. Someone may prefer to hand-write code because they enjoy the process, trust themselves more than the machine, or simply like the feeling of making things. Those are perfectly reasonable preferences.

They are not automatically engineering arguments.

People still make furniture by hand even though factories exist. People shoot film, build mechanical watches, play acoustic instruments, and drive manual transmissions. Efficient production does not eliminate the value or pleasure of craft.

It does change the claim you are making.

"I want to make this by hand" is different from "this should be made by hand."

Engineering lives in that difference.

Production is becoming a system of its own

The larger transition is not really about coding assistants.

We are moving from developers using AI tools, to developers supervising agents, to engineering systems containing agents, and eventually toward software production systems that operate with a meaningful degree of autonomy.

At that point, the unit we optimize changes.

For most of software history we asked how quickly a developer or team could implement a feature. More recently, we started asking how much more a developer could produce with AI.

The more interesting question is how reliably a software production system can turn intent into maintained software.

That pulls a very different set of concerns into the foreground. How does intent enter the system? Which standards constrain execution? Which actors have authority to make which decisions? What evidence is required before a change progresses? How does the system recover when execution fails? How do lessons from one run survive into the next one?

Once software production becomes machinery, someone has to engineer the machinery and someone has to operate it.

That is why harnesses, factories, evaluation, policy, observability, and controlled delegation keep appearing in conversations that began as discussions about AI coding tools. The interesting problem eventually stops being whether the model can write the code.

The interesting problem becomes whether the surrounding system can reliably produce software we are willing to trust.

Cheap production creates more need for judgment

One of the stranger assumptions around AI coding is that if implementation becomes dramatically cheaper, engineering becomes less important.

I think it is likely to do the opposite.

Cheap software means more software. More experiments become economically viable. More internal tools get built. More integrations become worth attempting. More legacy systems can be touched. More ideas survive the point where implementation cost previously killed them.

That creates more architectural surface area, more dependencies, more operating systems, more interactions, and more ways for local decisions to create global incoherence.

AI can let us make the wrong thing much faster.

The less humans need to make the software, the more important it becomes that somebody is actually engineering it.

The constraint therefore moves from production toward judgment. Someone has to decide what should be built, how far it should go, where the boundaries are, what good means, and when continuing to generate work has stopped creating value.

This is one of the lessons I learned running increasingly autonomous development loops. Throughput gets impressive very quickly. It is also one of the least interesting problems once you have it. The difficult part becomes keeping the system pointed at something useful and knowing when its output deserves trust.

More software does not mean less engineering.

It means engineering moves.

The skill is governed delegation

The engineer of the next decade probably will not be distinguished by how much code they personally write.

They also will not be distinguished by how much code they can get a model to generate.

The valuable skill is governed delegation: knowing what can safely be handed off, creating the conditions under which that delegation can succeed, and remaining accountable for the result.

That means encoding constraints rather than hoping the model remembers them. It means building feedback instead of endlessly improving prompts. It means defining evidence instead of trusting confidence. It means deciding which failures the system can repair itself and which require escalation. It means understanding enough of the system to recognize when a locally reasonable change is making the whole thing worse.

Most importantly, it means putting humans where judgment actually changes the outcome.

The goal should not be a developer pressing Enter faster. It should not be an engineer manually approving every machine action so we can claim a human was involved.

The goal is to remove humans from mechanical work while preserving human responsibility where judgment, accountability, and context matter.

That is a much harder problem than code generation.

It is also a much more interesting engineering problem.

We finally get to find out what engineering meant

Software engineering has spent decades in an unusual position. The people responsible for designing the system were also deeply involved in manufacturing its individual parts. That made craft, production, and engineering difficult to separate.

AI is pulling them apart.

Some people will keep making software directly because they are extraordinarily good at it, because the problem requires it, or simply because they enjoy the craft. Some people will become operators of increasingly autonomous production systems. Some organizations will accidentally turn engineers into prompt routers and call it transformation.

The interesting group will be the engineers who learn to take responsibility for systems they increasingly do not make by hand.

They will still need taste. They will still need technical depth. They will still need to know when to open the machine and work directly on the material. But their value will come less from personally executing every step and more from knowing what the system should do, how it should be constrained, what evidence makes it trustworthy, and when the machinery needs human judgment.

For most of our history, making software and engineering software looked like the same job because they happened in the same hands.

They are starting to separate.

We may finally get to find out what the engineering part was.