There's a question floating around right now that frames itself as practical but is actually philosophical: are you a coder or a software engineer?
The people asking usually want to talk about hiring. About resumes. About which skills survive the AI transition and which get automated away.
That framing misses everything that matters.
The distinction between coding and engineering isn't about employment. It never was. It's about the relationship between a mind and a problem. Between intention and output. Between making something work and understanding why it works — and what that understanding costs you, and what it gives back.
On the Nature of Constraints
Engineering is sometimes defined as decision-making under constraints. That's accurate but incomplete.
The deeper truth is that constraints are not obstacles to engineering — they are engineering. A system with infinite time, infinite memory, infinite budget has no shape. It's formless. Constraints give the problem its geometry, and the geometry is where the thinking lives.
This is why the hacker ethos and the engineering ethos are not in conflict, despite what corporate culture would have you believe. The early Unix builders were engineers in the deepest sense — not because they had Gantt charts, but because they understood that the 8-character filename limit wasn't a failure of imagination. It was a decision. A position. A bet about what would matter.
The best systems in computing history weren't built by ignoring constraints. They were built by someone who understood the constraints so deeply they turned them into elegance. Worse is better. Do one thing well. The filesystem as interface. These aren't compromises — they're philosophies made executable.
To write code without understanding its constraints is to paint without knowing what the painting is for. You might produce something. But you haven't made anything.
What Vibe Coding Actually Reveals
Vibe coding is not new. Cargo cult programming is not new. Copy-paste development is not new. The aesthetics change. The phenomenon is ancient.
What's new is the scale at which it's now possible to produce convincing output without any understanding of what's being produced. An LLM will give you a Flask app, a Dockerfile, a database migration, a test suite — all syntactically plausible, all potentially wrong in ways that only become visible under load, or under adversarial conditions, or six months later when the original context is gone.
The danger isn't that vibe coding produces bad code. Bad code has always existed. The danger is that it produces code that looks like it was reasoned about, without the reasoning. It passes the visual grammar check. It fails the semantic one.
Reading code you didn't write is always slower than writing it yourself. An AI that generates code you don't understand has not saved you time. It has deferred your time cost to the worst possible moment — production, 2am, under pressure.
What vibe coding reveals is something that was already true: the act of typing code was never the hard part. It was always a proxy. A way of measuring whether you had thought clearly enough to express the thought precisely. Remove the proxy and what remains is the thinking — or its absence.
The Open Source Question
If you've spent any meaningful time in open source, you already know something that the employment discourse keeps burying: the reason to build well has nothing to do with your job.
You build well because the software outlives the moment. Because someone you've never met will read this code in a timezone you've never visited and either understand it immediately or spend three hours cursing your name. Because the commit message is a letter to the future. Because the architecture decision you make today becomes the constraint someone else has to engineer around in five years.
This is not an argument for perfectionism. It's an argument for intentionality. For knowing why you made the choice you made. For being able to articulate it — to a collaborator, to a future self, to a pull request comment at midnight.
| The Coder's Relationship | The Engineer's Relationship |
|---|---|
| Code is output | Code is position |
| Done when it compiles | Done when it's understood |
| Constraints are annoying | Constraints are information |
| Reviews are friction | Reviews are the work |
| The next feature | The next maintainer |
| Works on my machine | Works in the world |
Open source is ruthless about this distinction in a way employment never is. A job will tolerate unclear code if it ships. The open source community will not maintain it. PRs get abandoned. Projects get forked. Maintainers burn out under the weight of code that "works" but that nobody fully understood when it was written.
The cathedral gets built stone by stone, by people who won't live to see it finished, who understand that the quality of each stone matters precisely because they won't be there to explain themselves later.
On the Philosophical Status of Not-Code
There is a serious argument — not a career advice argument, a philosophical argument — that the most important engineering decisions are the ones that result in nothing being built.
Sometimes the right answer to a software problem is a process change. A conversation. A spreadsheet. A handshake. The decision not to build is a design decision. It is often the most sophisticated one available.
This offends people because it seems to devalue the craft. It doesn't. It contextualizes it. A surgeon who recommends surgery when the patient needs rest is not demonstrating skill — they're demonstrating a failure of judgment dressed up as capability.
The best engineers I've known have all, at some point, talked a stakeholder out of building something. Not because they were lazy. Because they understood the problem well enough to know that code wasn't the answer. That understanding is rarer and harder than any implementation.
The discipline of software engineering is, at its core, the discipline of asking what problem are we actually solving before reaching for the keyboard. This question doesn't get easier with AI. It gets more important. Because the keyboard now moves faster than the thinking, if you let it.
Struggle as Epistemology
There's a pedagogical claim that frustration is where learning lives. That's true but it undersells the mechanism.
The frustration of a hard bug is not incidental to understanding — it is understanding, in process. You trace through ten layers of state. You form a hypothesis. The hypothesis is wrong. You revise your mental model. You form another hypothesis. Eventually something clicks — not just the solution, but the shape of the system that produced the bug. That shape becomes part of you. It informs every future decision you make in systems like this one.
This is what skipping the struggle costs. Not time. Not effort. Model formation. The mental model of how systems actually behave under real conditions — under load, under adversarial input, under the chaos of integration with other systems written by other people who also had constraints — that model is built from exactly the experiences that feel the most wasteful in the moment.
Every experienced developer has a personal taxonomy of failure modes. Memory leaks they've hunted. Race conditions they've introduced. APIs they've misread for a week. This isn't trivia — it's epistemology. It's how you know what you know.
An AI can tell you that a race condition might exist here. It cannot give you the understanding that comes from having caused one, traced one, fixed one, and then recognized the pattern in completely different code three years later. That recognition is irreplaceable. And it only comes from the struggle.
What Engineering Is, Finally
Engineering is not a job title. It is not a credential. It is not a set of practices, though practices can help you do it.
Engineering is the commitment to understand the problem before solving it. To make decisions consciously, under real constraints, with awareness of what you're trading away. To be accountable for what you build — not to a manager, not to a metric, but to the logic of the thing itself.
The question are you a coder or a software engineer? is not really about what you do. It's about how you relate to what you do.
Do you produce output, or do you make decisions?
Do you reach for the tool, or do you reach for the understanding first?
Does the code work, or do you know why it works — and what would break it, and what that breaking would mean?
The answer to those questions determines what kind of software you build. And what kind of software gets built determines what kind of world we live in — because increasingly, the software is the world.
That's the only reason the distinction matters. Not the resume. Not the interview. Not the job market.
The world we're building deserves to be built by people who think about what they're building.
Leon Yeh is a GenX Computer Scientist writing about AI, blockchain, and the future of software. He has strong opinions about Kelly Criterion and medium opinions about everything else.