If you use AI for coding long enough, you start to see patterns. These patterns become prompts. And these prompts become the difference between shipping and spinning your wheels.
Some people call this prompt engineering. It's not like civil engineering where you build bridges, so I'm hesitant to use that term. Especially since you don't need an engineering degree to do it. But let it slide. We'll focus on the 3 prompts that changed how I ship code.
These aren't fancy techniques. They're simple phrases that took me months to discover through trial and error. Each one solves a specific problem I kept running into when working with AI on real production code. Not toy examples. Not tutorial projects. Actual software that runs in production and serves real users.
1. I'm a Human
It's funny actually. You'd assume that AI knows what it is and with whom it communicates. But that's not true. You can give AI an instruction that it's an engineer, or a sales person, or a rabbit. And it will try its best to imitate one. But it also doesn't know with whom it talks. With a robot? With a human? An artificial intelligence? It has no idea.
As a result, it tends to ignore the limits of human existence. For example, we don't have memory as strong as AI. So it doesn't provide all details in a chunk of response. It assumes you remember your discussion precisely from a month ago. I don't. I barely remember what I had for breakfast.
It also doesn't know that humans can't parse data as fast as AI. So it is vague, elaborate, and uses plain text for almost everything. It dumps walls of text on you and expects you to extract the relevant bits. As a result, it's quite difficult to talk with AI effectively.
That's why I use the prompt "I'm human" with some specific details. It improves the communication tremendously. I tell it that I need structured responses. That I need clear headers and bullet points. That I can't hold 50 variables in my head at once. That I need it to remind me of context when we return to a topic after a break.
Thanks to that, I can work with thousands of lines of specs and code and still keep control over it. The AI starts formatting responses for human consumption:
- It breaks things down into digestible chunks
- It highlights what changed since our last conversation
- It uses headers and lists instead of prose walls
- It reminds me of context when needed
It's like the difference between reading a well-organized document and reading someone's stream of consciousness notes.
2. Don't Assume
This one is pretty powerful when you're working in precise domains, like business logic. AI likes to assume things it doesn't know about. It fills gaps with plausible-sounding nonsense. And the worst part? It does this confidently, without telling you it's guessing.
So if you write a spec and ask AI to fill in the gaps, it just hallucinates things. You ask it to document your payment flow, and suddenly there's a retry mechanism you never built. You ask it to describe your user permissions, and it invents three new roles that don't exist. It's creative in all the wrong places.
The prompt "Don't assume" prevents that from happening. It has to be strengthened with additional context. But that's the main prompt.
What happens when you use it? The AI starts asking questions instead of making things up. It says "I don't have information about X, could you clarify?" instead of inventing X on the spot. It marks uncertain areas explicitly. It distinguishes between what you told it and what it's inferring.
It prevents AI from filling a document with its assumptions where you only asked it to format your ideas and be precise about what the idea is. It's great if you want to communicate things with people, but don't want AI to take over the creative or decision process. You remain in control. The AI becomes a tool that amplifies your thinking, not one that replaces it with its own guesses.
I use this constantly when writing technical specifications. When I design SaaS architectures, multi-tenant systems, or cross-platform mobile apps, the spec becomes the single artifact that connects product design to implementation across every layer of the stack. I want the AI to help me structure my thoughts, not to inject its own ideas about how my system should work. It doesn't know my constraints. It doesn't know my team's capabilities. It doesn't know the weird legacy system we have to integrate with. Only I know these things.
If you're working with AI on coding projects, you might be burning through tokens and credits faster than necessary. I wrote a report on AI Coding Cost Optimization that covers how to save money while getting better outcomes. Use code MEDIUMSAVES20 for 20% off. Subscribers to the Vibe Coding Newsletter save 50%
3. Before Pushing, Do All Tests
In long-running tasks where I just ask AI to do something, and it works for 2-3 days straight, I like to make sure that I won't find AI just breaking stuff or introducing errors and glitches. Because it will. Left unchecked, AI writes code that works for the happy path and falls apart everywhere else.
That's why I tend to keep a very extensive test suite for each project. It means: unit tests, integration tests, TypeScript (yes, the type system counts as a test), e2e tests, tests on staging, checks on deployment process, health checks, even visual tests on production. Overall, such a full test suite can take anywhere between half an hour to 3 hours.
That sounds like a lot. It is a lot. But it's worth it. Wat mutt, dat mutt.
Here's why. Without comprehensive tests, AI coding becomes this jiggery process where AI does something, then you point out mistakes, it fixes them, you point out next mistakes, it introduces new bugs while fixing old ones, and the cycle continues. These feedback loops take time. They take your attention. They drain your energy. You become a human debugger for AI-generated code.
Because I have so many tests, AI performs them and fixes all issues before I even look at the code. It runs the tests, sees the failures, understands what went wrong, and fixes it. Then runs again. And again. Until everything passes.
So eventually, I end up with 1-2 rounds of fixes and the project is done. Not 15 rounds. Not endless back-and-forth. The tests do the quality control so I don't have to babysit every line of code.
The investment in tests pays for itself many times over. Every hour I spent writing tests saves me ten hours of manual review and debugging. And the AI actually gets better at writing code for my specific project over time, because it learns from the test failures what patterns work and what patterns don't.
As I wrote in my book on vibe coding:
"Coverage tells you how much code ran during tests, not how correct the product is. Track the trend rather than chasing a magic number. For example, 80% can be useless if the missing 20% is your checkout. Use coverage to find blind spots and add tests for money-critical or risky areas first."
This assiduous approach to testing is what separates production-ready AI-assisted development from the endless cycle of fixing AI-generated bugs.
Looking to level up your coding skills? Check out the GitHub Contribution Graph Funny Programmer T-Shirt - perfect for showing off your commit history (or lack thereof)
Why These Three Work Together
Each prompt solves a different problem, but they compound when used together:
- "I'm Human" ensures you can actually process what AI gives you
- "Don't Assume" ensures what AI gives you is accurate
- "Before Pushing, Do All Tests" ensures what AI builds actually works
When you're a founding engineer or the technical lead responsible for the entire stack, you can't afford to waste time on miscommunication, hallucinated features, or buggy code. These three prompts create a workflow where AI becomes a reliable partner instead of a liability.
I've been applying this across full-stack SaaS systems, from Angular frontends through Node backends to database layers. The same principles apply whether you're building a payment system, a user management module, or a complex data pipeline.
If you've ever scaled a SaaS platform to millions of users, you know that the cost of bugs compounds. A small issue in development becomes a major incident in production. These prompts help catch problems early, when they're cheap to fix.
The Bigger Picture
These prompts aren't magic. They're just explicit communication about things that humans take for granted when talking to other humans. We assume the other person knows we're human. We assume they'll ask if they don't understand. We assume they'll test their work before declaring it done.
AI doesn't make these assumptions. So we have to state them explicitly.
The pattern is clear: the more explicit you are about your expectations, the better AI performs. This isn't about finding clever tricks or gaming the system. It's about clear communication.
You can find more details on these techniques and many others in my book Software Engineering for Vibe Coders. If you prefer a physical copy, the Vibe Coding Bible is also available on Amazon in Kindle, hardcover, and softcover formats.
Sources
- Software Engineering for Vibe Coders ebook, Chapter 8: Testing
Related Reading
- Even AI Experts Feel Behind: What Andrej Karpathy's Confession Means for Programmers - How even the best AI researchers struggle to keep up with the pace of change
- Linus Torvalds Says AI Codes Better Than Him: Here's What It Really Means - The Linux creator's surprising take on AI-assisted development
- Future Software Engineer Career: Complete Roadmap - How to build a career in the age of AI coding
What prompts have you discovered that changed how you work with AI? Whether you're a founding engineer wearing all the hats or a staff engineer optimizing team output, I'd love to hear what's working for you.