I Am the Accidental Engineer

Somewhere in your career, someone told you that you weren't really an engineer. Maybe it was subtle: a raised eyebrow when you mentioned the code you'd written, a gentle redirect back to the design file, a colleague who helpfully explained that what you'd built was "just a prototype" and that the real engineers would take it from here. Or maybe it was someone on the design side, equally certain that writing code was a distraction from the real work: the systems, the thinking, the craft. You were too interested in whether the thing actually functioned to be taken seriously as a designer, and too interested in whether it made any sense to the person using it to be taken seriously as an engineer.

And so you learned to hold two things at once: the knowledge that you could build things, and the quiet social agreement that you weren't supposed to. You got very good at doing it anyway while appearing to do something else. Welcome. You have been here longer than you realize.

The Title Was Always a Lie

The job titles we hand out in this industry are a magnificent fiction. They describe the thing you're supposed to be doing, which is never quite the thing you're actually doing, and they create boundaries that exist mainly to make org charts legible and performance reviews less awkward. Designer. Engineer. Product Manager. These are load-bearing words in a corporate architecture that requires everyone to stay in their lane, not because staying in your lane produces better work, but because it makes the work easier to manage from a distance. The distinction is organizational, not creative. It is a filing system dressed up as a profession.

The problem is that the best work almost never happens inside a lane. It happens in the gap, where someone with a design background starts questioning the data model because something about the interaction doesn't add up, or where a frontend engineer starts sketching flows because the spec isn't solving the right problem. These people are not being difficult. They are being accurate. The work required it. The job title just didn't come with instructions for that part.

Design and Engineering Are the Same Discipline Having an Argument With Itself

Here is the thing that neither side will fully admit: design and engineering are not opposites. They are the same impulse (understand the problem, make a thing, test it against reality) expressed in different vocabularies and fetishized into separate careers. Design says: start with the person, make something tangible, find out if it's true. Engineering says: understand the system, make something that works, find out if it holds. Both of them are methods for collapsing the distance between an idea and a thing that exists.

What design brings to building that pure engineering often misses is the habit of starting with the person rather than the system. A designer who has done enough user research has a specific kind of impatience with clever solutions: they want to know who the clever solution is for and whether that person will recognize it as such. They have learned, sometimes painfully, that the gap between what you intended and what someone experiences is where projects go to die. That impatience, applied to building, is not a soft skill. It is a precision instrument. It asks "does this make sense to a human being" at every step rather than waiting until the product review to find out.

What engineering brings to design that pure design often misses is the discipline of constraints. When you actually have to build the thing you designed, the constraints stop being negotiable. The elegant three-column layout runs headlong into the reality of variable-length content. The beautiful empty state turns out to require a data model that doesn't exist. Engineering, done honestly, is ruthlessly clarifying. It collapses ambiguity in a way that a prototype can defer indefinitely. The designer who has built enough things develops a specific allergy to solutions that look good in Figma but fall apart when they touch the real world. That allergy is worth a lot.

The accidental engineer is the person who caught both allergies simultaneously and learned to use them on the same problem.

The Prototype Was Never the Problem

When someone calls your work just a prototype, they mean it as a limitation. What they are actually describing is the central discipline of both design and engineering, which is: make a thing, find out what's wrong with it, make a better thing. The prototype is not a lesser artifact than the finished product. It is the method by which the finished product becomes less wrong. Designers have known this for decades. The irony is that the engineering profession, which runs on iteration and version control and staged rollouts, often treats the design prototype as something that needs to be transcended rather than extended.

The deeper irony is that when a designer builds a prototype that works (one that connects to real data, responds to real input, and solves the actual problem rather than illustrating it), something interesting happens. The translation layer disappears. The thing that usually gets lost in the handoff, which is the precise understanding of why the interaction works the way it works, stays intact. The person who designed it is also the person who built it, and those two things turn out to be in much better conversation than a Jira ticket and a Figma file.

What AI Actually Changed

For a long time, the limit on this kind of work was honest and real: there was a complexity ceiling. You could build tools and dashboards and internal systems and useful things, but genuinely complex software, the kind that requires real systems thinking and architecture and the kind of debugging that takes days, was on the other side of a wall that took years of focused practice to clear. This was a true constraint, not a political one. And it meant that even the most capable accidental engineer hit a point where the thing they wanted to build was outside what they could pull off alone.

What AI changed is not that this wall disappeared. It is that the wall got short enough that a running start clears it. The loop that used to require a team (idea, spec, build, test, iterate) now fits inside a single session. You describe what you want in the language of someone who thinks about users and interactions and what the thing is supposed to feel like, and you get back working code. You evaluate that code the way a designer evaluates a prototype: does it do the right thing, does it feel right, is this what I meant, what needs to change. You iterate. The design sensibility and the building sensibility stop being sequential (design first, then engineering) and start being simultaneous. You are making something and asking if it makes sense at the same time, which turns out to be a very fast way to find out if an idea is any good.

The AI doesn't ask whether you have the right job title before running your code. It turns out that's most of what was slowing things down.

What This Blog Is

This is a notebook for people who live in the gap: between design and engineering, between idea and execution, between the thing you were hired to do and the thing you actually end up doing. The essays here are about building things, and what building things teaches you about thinking, and what it looks like when the design half and the engineering half of a problem stop arguing and start working.

But there is also a Lab. That is where the tutorials live, where the toys get documented, where the actual work of building gets shown rather than described. If you want to follow along and build something yourself (a tool, an experiment, a thing that solves a problem you have), that is the place. No prerequisites about whether your background is technical enough. If you can read, you can follow along, and if you can follow along, you can build the thing.

The essays will give you the thinking. The Lab will show you the building. Between the two, the hope is that you leave with a little less distance between the idea in your head and the thing that could exist in the world.

That gap is closeable. It always was.

The rest was just convincing you it wasn't.