Stop Vibing, Start Shipping
I've watched countless engineers grumble about AI coding assistants, dismissing them as glorified autocomplete whilst simultaneously using them like a Magic 8-Ball for their entire codebase. Using tools badly and then complaining they perform badly is peak "I've tried nothing and I'm all out of ideas" energy.
Here's the uncomfortable truth fellow engineers need to hear: if your AI is generating rubbish, there's a non-zero chance you're giving it nothing to work with. We've become so accustomed to tools that "just work" that we've forgotten that even the most sophisticated system needs proper input - yes, even when that system is a billion-parameter neural network.
Now, let's be crystal clear, AI isn't perfect. It hallucinates, it generates verbose monstrosities, it confidently declares that 2 + 2 = 5. Here's the thing though, despite these deficiencies AI is still incredibly powerful today and you owe it to yourself as a professional to extract value from the tools at your disposal.
As these tools evolve at breakneck pace, the engineers who've learned to extract maximum value from them are pulling further ahead every day. Those still waiting for AI to read their minds? Well, they're still waiting.
Tools!
So how do we bridge this gap?
First up, build workflows that work for you. This isn't about following some prescriptive "10x engineer" Medium post. It's about recognising that a coding agent with the right MCP integrations becomes an extension of your development environment. Connect your file system, your git repos, your documentation - give it the context it needs to actually help rather than hallucinate.
Take the previous example of "2 + 2 = 5" - using the correct calculator tool to offload the arithmetic operations this becomes an entirely solved issue.
Some engineers stubbornly refuse to connect basic tools, then wonder why their AI can't understand their project structure. It's like hiring an assistant and then blindfolding them - technically they're still an assistant, but you've hobbled their utility from the start.
Prompting Isn't Texting
Next, let's talk about prompting - the most underrated engineering skill of 2025. Anthropic's Prompt Workbench isn't just another shiny tool; it's a force multiplier for those willing to invest the time. Prompts can evolve from "make a login page" to detailed specifications that would make a product manager weep with joy.
The difference in output quality is staggering. Yet most engineers treat prompts like they're texting a mate rather than architecting a solution. Would you write a technical spec in emoji? Then why are you prompting your AI like it's a group chat?
Don't even get me started on the engineers who refuse to iterate on their prompts. One failed attempt and they're back to complaining on Hacker News about how AI "just doesn't get it." You gave it three words and expected a masterpiece.
Documentation & Dialogue
This next one is crucial for guiding AI effectively, create detailed implementation plans through documentation and conversation. This isn't about writing War and Peace before coding a button. It's about building context iteratively, using your MCPs to pull in relevant docs and having a conversation about architecture before implementation.
I've started treating my AI sessions like pair programming with a brilliant but literal-minded colleague. We discuss the approach, I provide context about our patterns and constraints, and only then do we dive into implementation. The results? Code that actually fits our architecture instead of fighting it.
Actually, scratch that, it's more like pair programming with an eager intern who's read every programming book ever written but has never actually shipped anything. Brilliant recall, no common sense. But that's fine once you know how to work with it.
Steering at Low Stakes
Andy Grove, had it right in High Output Management - make changes when the stakes are lowest. Applied to AI engineering, this means refining and steering output early and often. Don't wait until your AI has generated a 5,000-line behemoth to course-correct. Guide it when it's laying the foundation, not when it's putting on the roof.
I've learned to catch those moments where the AI starts down a dubious path - maybe it's reaching for a custom solution when a library exists, or it's about to create the seventeenth utility function that does the same thing. A gentle nudge at line 50 saves you from refactoring at line 500.
Your Code, Your Responsibility
Here's what vibe coders don't want to hear: you're still responsible for what ships under your name. You can't understand every line as it's generated - that's impossible at AI speeds. However, you must digest, review and understand the holistic solution before moving forward. When the AI confidently implements an O(n³) solution to an O(n) problem, or introduces security holes, you need to catch it.
The engineers who'll thrive use AI to move faster whilst maintaining their standards. They pause to comprehend what's been built, ensure it fits the architecture, and verify it actually solves the problem at hand.
The Nuclear Option
Finally, and this cannot be overstated: commit working features often and never be afraid to nuke bad solutions. AI can generate code faster than you can review it, which means bad patterns can metastasise at unprecedented speed.
I've developed a ruthless approach - if the AI starts "vibing" in the wrong direction, I don't hesitate to bin it. There's no cost to starting fresh. No emotional attachment to AI-generated code, no sunk cost fallacy. Ctrl+Z and a better prompt beats wrestling with a solution that was doomed from line one.
Productivity Now
The engineers thriving right now aren't waiting for AI to become perfect. They've figured out the game:
- Build workflows with connected MCPs
- Write actual prompts, not text messages
- Create context through documentation
- Course-correct early when stakes are low
- Commit often, delete fearlessly
None of these lessons are of course replacements for engineering experience though - in fact they're part of what makes a good engineer, which is adapting to the tools at hand and building productive workflows around them.
Using AI badly isn't AI's fault - it's yours. The sooner we stop complaining and start learning to use these tools properly, the better.