Make it Work, Make it Right, Make it Fast
Timeless mantra from the Unix Way
I’ve always operated with this mantra when developing systems. It comes from the Unix Way of doing things and has been keeping me on track for years.
And now, I believe AI can help with all of these phases—if you play it right.
Let’s break it down:
Make it Work
For me, this means: get it to function.
If you come from (or remember) TDD, it’s about making the tests green. It’s about seeing that red button you wanted finally appear. It’s about hitting that API and—even if the response is ugly—getting some data back.
Because if it doesn’t work at all—if it doesn’t achieve the goal—who cares if it’s beautifully crafted or has an O(n) complexity?
That old joke comes to mind:
“I’m very fast at math!”
“Great, what’s 79 × 43?”
“17,000.”
“That’s wrong.”
“Yeah, but I was fast.”That’s what “make it work” avoids. It’s about correctness before cleverness.
This is the phase where AI shines today. The clearer you formulate your goal, the better the code generation will be. With the right prompt, you’ll almost always get something that at least works.
Make it Right
This has always meant clean code for me—good abstractions, best practices (both global and your company’s local conventions), separation of concerns, and maintainability.
By now, you probably know there’s more than one way to build something. The real skill is deciding what’s best for your product at that specific point in time.
If you skip this step, you’ll have a harder time making it fast, scaling it, or even maintaining it.
Here, AI’s usefulness depends on your foundation:
A clean codebase produces cleaner AI-generated code.
Rotten code tends to produce more rotten code.
Well-documented practices and clear architecture make AI much more effective.
AI can’t magically “make it right” for you—it amplifies whatever state your system is already in.
Make it Fast
Sounds obvious, right? Yes, but “fast” can also mean very different things:
Algorithmic efficiency: moving from O(n²) to O(n), or switching to a more optimal algorithm altogether.
Database performance: adding indexes, partitioning, caching, or moving from SQL to NoSQL (or the other way around).
Infrastructure scaling: introducing load balancers, switching to event-driven architectures, or leveraging serverless for burst workloads.
Developer velocity: sometimes “fast” isn’t runtime speed but the speed of iteration. Reducing CI/CD pipeline times, improving test coverage, or automating repetitive tasks also make your team “faster.”
User experience speed: shaving seconds off page load, reducing API latency, or optimizing client-side rendering.
AI can help here too, by:
Brainstorming architecture changes.
Suggesting optimizations.
Surfacing bottlenecks from logs, traces, and metrics.
One fun hack I’ve seen: write code in the language you know best (say Python), then ask an LLM to translate it into C (or Rust, or Go) to run faster on your target platform. It’s not always perfect, but it gets you a huge head start.
Bringing It Together
“Make it work, make it right, make it fast” is still one of the best engineering mantras I know. AI doesn’t replace it—it fits into it.
Use AI to get things working quickly.
Lean on it cautiously to help with best practices, but remember that quality depends on your existing system.
Experiment with it to find performance improvements you might not have considered.
At the end of the day, it’s still your responsibility as an engineer to decide what to ship, when, and why. AI is just another (very powerful) tool in the toolbox.