From Prompt to Production: The Real Difference between Design and Engineering

We need to have a serious conversation about the words we use to describe how we build software.

For years I sat in conference rooms and Meet calls listening to smart people argue about titles: Are we software designers? Are we software engineers? Are we product developers? Does it even matter what we call ourselves as long as the customer revenue hits every two weeks?

For a long time I thought these were two distinct jobs held by two different types of people. You had the creative types over here. They wore cooler shoes. They talked about empathy and user journeys. They used tools like Figma. Then you had the technical types over there. They wore hoodies. They talked about databases and latency and memory leaks. They used tools like VS Code.

I used to think design was about how it looked and engineering was about how it worked.

I was wrong.

Over the last decade of building software, deploying systems, and watching them crash at 3 AM, I have come to a completely different conclusion. It is a conclusion born from the specific pain of seeing a beautiful idea fall apart the moment real humans touched it.

Here is the reality.

Design and engineering are not separate disciplines. They are stages of maturity in solving a problem.

Design is the act of crafting a solution from A to Z. It is the vision. It is the happy path where everything goes right.

Engineering is what happens next. Engineering is the grueling, invisible work of addressing everything from B through Y.

Everyone starts out as a designer. It is our natural state. It is only through depth, scar tissue, and painful experience that we become engineers.

The Optimism of the "A to Z"

Let's start with design.

When I say design I am not talking about graphic design. I am not talking about picking colors or fonts or deciding how round the corners of a button should be. I am talking about the fundamental act of designing a solution to a problem.

Humans are natural designers. We are wired to solve problems. When we see something broken our brains immediately jump to a fix.

I see a puddle in my driveway. My brain designs a solution. I need to dig a little trench to drain the water to the lawn.

That is design. It is a complete vision from problem (A) to solution (Z).

It feels good. It feels complete. In my head the trench works perfectly. The water flows downhill. The driveway is dry. I am a genius.

This is the "happy path."

In software this happens all the time. You identify a user need. Let's say people want to share photos of their cats.

You instantly visualize the solution. There will be a button that says "Upload Cat Photo." They click it. They pick a photo. It appears on a feed. Other people like the photo.

This is the A to Z.

It is intoxicating. This phase is full of optimism. Everything is possible because you haven't actually tried to do it yet. You are painting on a blank canvas. There is no friction in the A to Z world. The users always have fast internet. They always upload the right file formats. They never try to hack you.

We are all designers in this sense. We all have ideas. We can all envision a better future state.

When I was a junior developer I lived entirely in this state. I would get a requirement and immediately start coding the happy path. I would write the code that handles the exact scenario where the user does everything right.

I felt very productive. I was shipping features fast. They looked like they worked.

If you asked me back then what I was doing I would have told you I was engineering.

I wasn't. I was just designing with code. I was building prototypes that looked like finished products. I was building movie sets. They looked like houses from the front but if you leaned on the wall you would fall right through.

Entering the "B through Y"

Then reality happens.

Let's go back to my driveway trench.

I go outside with a shovel. I start digging. This is where the theory meets the dirt.

The first thing I hit is a massive tree root right in the middle of my planned path. This was not in my A to Z plan. The A to Z plan assumed the ground was soft and yielding.

Then it starts raining harder. The trench fills up faster than I can dig. The sides of the trench start collapsing because the soil is too sandy.

I manage to finish it. The next day I drive my car over it. The weight of the car crushes the little trench and blocks the water flow again.

My design failed. It failed because I only considered A and Z. I did not consider the messy reality in between.

This is where engineering begins.

Let's look at that cat photo app again.

The designer says "The user uploads a photo."

The engineer stops the meeting. The engineer looks tired. The engineer asks a hundred annoying questions.

B is for Bandwidth. What happens if the user is on a 3G network on a train and the connection drops halfway through the upload? Do we retry automatically? Do we show an error? Do we leave a half-corrupted file on our server?

C is for Compression. What if they upload a 50MB raw file from a professional camera? Do we store that massive file? It will cost us a fortune in storage fees. We need to engineer an image compression pipeline.

D is for Duplication. What if the user double clicks the upload button? Do we post the same photo twice? We need idempotent keys.

E is for Encoding. What if the filename contains emojis or Chinese characters? Does our database handle UTF-8 correctly or will it crash the entire application?

F is for Format. What if they rename a virus .exe file to .jpg and upload it? If we try to process that image will we execute the virus on our server?

This goes on and on.

This is the B through Y.

It is unglamorous. It is tedious. It is often pessimistic.

When you are deep in the B through Y it feels like you are moving backward. You had a working prototype last week. Now you have a broken mess because you tried to make it handle network failures.

But this is the work that matters.

A solution that only handles A and Z is not a solution. It is a fragile toy. It works as long as nobody touches it the wrong way.

Engineering is the process of taking that fragile toy and turning it into a tool you can rely on. It is about robustness. It is about reliability. It is about usability under stress.

The Price of Depth

This is why I believe you cannot start your career as an engineer. You have to earn the title.

You start as a designer. Even if your job title says "Junior Engineer" you are effectively a designer. You have ideas and you try to build them. You build only the happy path because you don't know any better.

Then things break.

You deploy code on a Friday and spend your entire weekend fixing a database that got corrupted because you didn't understand transaction locking. You watch users get frustrated with a feature you thought was intuitive because you didn't account for how they actually behave.

You collect scars.

Every scar teaches you about a letter between B and Y.

I remember once building a system that sent Slack notifications. The design was simple. When an event happens send a Slack notification. A to Z.

I built it. It worked great in testing with five users.

We pushed it to production. A week later something went wrong in another part of the system. It triggered an infinite loop. My simple automation system sent 40,000 notifications to a single user in one night.

That was a very painful scar. I had to apologize to that user personally.

But that scar turned me into an engineer regarding notification systems. Now when someone says "just send a notification" I immediately think about rate limiting. I think about exponential backoff. I think about spam filters. I think about what happens if the service provider is down.

You cannot read a book and understand this. You have to feel the pain of a system failing because you ignored the edge cases.

Depth is what separates design from engineering.

Design is wide. It looks at the whole problem space. It is creative and expansive. It asks "What could this be?"

Engineering is deep. It looks at one specific part of the problem and drills all the way down to the bedrock. It finds every possible way that specific part could fail. It asks "How will this break?"

When you are a beginner you think senior engineers are grumpy cynics. They always seem to shoot down new ideas by listing all the ways they won't work.

They aren't being cynical. They are just walking through the B to Y alphabet in their heads. They have seen how the movie ends when you skip those steps. They are trying to save you from the weekend page call.

The Mirage of "Vibecoding"

This distinction is more important now than ever.

We are living through a wild moment in technology. Artificial intelligence has changed how we write code.

People call it "vibecoding." You just type a prompt into ChatGPT or Claude or Cursor describing what you want. It spits out code. You paste it in and it runs.

It feels like magic. It feels like the future.

This brings me to my favorite recurring conversation with my CEO.

I love the guy. He is a visionary. But he has this habit that drives me absolutely up the wall.

He will burst into our Slack channel on a Tuesday morning with a link to a Replit project. He will say something like:

"Hey team, I just built the new marketplace dashboard in 5 minutes. I used a single prompt. It works perfectly. Why is the engineering roadmap saying this feature will take three weeks?"

I then have to be the person who ruins the party. I have to look him in the eye (or the webcam) and gently explain the reality of the situation.

"Boss," I say. "You didn't build a marketplace. You built a picture of a marketplace. It looks great. But it connects to nothing. It has no security. It has no error handling. If two people look at it at the same time it will crash. If you try to load real data into it the browser will freeze. You built a beautiful A to Z movie set. We have to build the plumbing so people can actually live in the house."

He usually sighs. He thinks I am being difficult. He thinks I am gatekeeping.

But I am not. I am just trying to prevent us from shipping a toy to paying customers.

When you use AI to generate code you are not engineering. You are designing at warp speed.

Think about your prompt. What are you telling the AI?

You are saying "Create a webpage that lets a user upload a PDF and summarizes it."

That prompt is a definition of A to Z. It is the pure vision of the happy path.

The AI will give you exactly that. It will give you code that works perfectly if the PDF is small and readable and the server is running fine and the user behaves nicely.

It is a brilliant prototype. It is a fantastic piece of design.

But it is useless as a real product.

It has zero B through Y.

If you take that generated code and put it on the internet real users will destroy it in minutes. They will upload corrupted files. They will try to hack it. The server will crash the first time it gets real traffic because the AI didn't write a caching layer.

Vibecoding is incredible for accelerating the design phase. It lets you go from an idea to a working "A to Z" model in minutes instead of days. That is huge. I use it every day. It makes me a faster designer.

But do not confuse that with engineering.

The real work begins after the AI gives you the code.

Engineering is looking at that AI-generated code with extreme suspicion. It is the process of hardening it.

You have to add error handling that the AI forgot. You have to secure the database inputs it left wide open. You have to restructure the code so it can be tested automatically. You have to figure out how to deploy it so it automatically recovers if it crashes.

The AI doesn't know about your specific infrastructure limitations. It doesn't know about your company's security compliance requirements. It doesn't know that your users frequently have poor mobile data connections.

That is the B through Y. That is the engineering.

I worry that we are creating a generation of builders who only know A and Z. They will be able to create incredible demos. They will win hackathons. But they will not know how to create systems that survive contact with the real world.

They will be brilliant designers who think they are engineers. And they will have a very rude awakening the first time they try to scale.

The Cost of Ignoring the Alphabet

What happens when we ignore the B through Y? What happens when we stop at design?

We get the modern internet.

We live in a world cluttered with digital junk. There are so many apps that are flaky and frustrating. They are slow. They lose our data. They crash when we need them most.

These are products that were designed but never truly engineered. They are all A and Z with nothing in between.

Real value comes from reliability. It comes from trust.

Think about the systems in your life that you actually trust.

When I turn on the tap I trust that water will come out. I don't have to worry about the complex engineering of the city water system. I don't have to worry about pressure regulation or filtration or pipe maintenance.

Someone else did the B through Y work so I don't have to.

That is what great engineering does. It hides the complexity. It makes difficult things feel simple and reliable.

When you use a service like Stripe to process a payment it just works. You don't see the thousands of engineers working in the background to handle currency conversion and fraud detection and bank failures. You just see the A to Z.

But that A to Z is supported by a mountain of B through Y.

The Journey from A to Z to Y

So where does that leave us?

It means we should stop fighting about titles. We are all on the same spectrum.

If you are a "designer" in the traditional sense you should understand that your job isn't done when the Figma mockup is finished. You need to understand the constraints of the materials. You need to care about the error states.

If you are an "engineer" you need to respect the A to Z. You need to understand the vision before you start tearing it apart with edge cases.

But mostly it means we need to respect the process of maturation.

When you have a new idea embrace the designer mindset. Focus on A and Z. Dream big. Ignore the constraints for a moment. Use AI tools to get a prototype working fast. Get excited about the vision. This is the fun part.

But do not stop there. Do not ship the prototype.

You must consciously shift gears into engineering mode. You have to put on your hard hat.

You need to look at your beautiful creation and ask "How will this break?"

You need to respect the alphabet from B to Y.

You need to look at your "vibecode" and realize it is just a suggestion. It is a starting point. It is not the destination.

If you are early in your career do not be discouraged when your "finished" code gets torn apart in a code review. The senior developer isn't attacking your design. They aren't trying to hurt your feelings. They are introducing you to engineering. They are showing you the edge cases you didn't know existed.

Listen to them. That is how you get depth.

If you are a senior leader you need to recognize the difference in these activities.

Don't ask a team to "engineer" a solution when they don't even know what the problem is yet. Let them design first. Let them play in the A to Z space without penalty. Let them vibecode.

Conversely do not accept a design prototype as a finished product. Just because it looks like it works doesn't mean it is ready for the world. Demand the rigor of the B through Y process before anything goes live.

Conclusion

I still love the A to Z. There is no feeling quite like the spark of a new idea and seeing it come to life on the screen for the first time.

But I have learned to love the B through Y even more.

There is a quiet satisfaction in building something that doesn't break. There is a pride in knowing that you handled the edge cases. There is a joy in sleeping through the night because you know your system can heal itself.

So go ahead and design. Sketch the napkin idea. Write the prompt. Create the vision from A to Z.

Just remember that you are only getting started. The real work is in the messy middle. The real work is engineering.

---

Related reading from this blog:

• To err is human — Why imperfection is our competitive advantage over AI
• What is a No-Code Platform in 2026 — No-code doesn't mean no-brainer; structured thinking still matters
• Building a RPi Homelab — A real-world example of the B through Y in systems engineering