Prompt Engineering vs Spec Engineering. Coding with AI like a Senior Engineer in Big Tech

Reduce mistakes and hallucinations from vibe coding (Prompt Engineering) by adopting "Spec-Driven Development". Get better at coding with AI, prompt engineering, and using Cursor and Amazon Kiro

Paddle Web Revenue Labs (Sponsor)

If you are an app business, seeking growth channels and strategies, then this is for you.

Join Paddle's 5-part series filled with actionable strategies for app developers who want to drive revenue beyond the app store.

This series serves as your blueprint for modern, effective web monetization for app companies.

Spots are limited — register now to secure your place in the full series.

Big thanks to Paddle for putting this together. This post is about how to code with AI, but to learn how to get users and monetize, I’ll join Paddle’s August 27th session for practical steps to reach 1,000 users. See you inside.

You're already using AI to write code faster, but is it making you a better engineer? The difference between a mid-level and a senior developer will be more about how they use AI to build robust, maintainable software.

Relying only on basic "vibe coding" (Prompt Engineering) is fast for small tasks but hits a wall on complex projects. New IDEs like Amazon's Kiro are adopting what's called Spec-Driven Development.

The most successful engineers are becoming "bilingual", using these two approaches. Knowing when to use each is the new superpower for career growth.

⭐ In this post, you'll learn

• The difference between Prompt Engineering and Spec-Driven Development

• When to use each approach

• How to structure your prompts to get better output

• Tools that support each workflow and how to pick them

---

Prompt Engineering

Some people call this vibe coding. I disagree. Vibe coding is when you blindly trust AI and run git push --force without reviewing. That’s not what we’re doing here. At least not all the time 😛

Prompt engineering is conversational. You’re not planning a perfect solution. You’re throwing a scoped request and iterating based on the result. You use inline commands like “refactor this” or “add a check for null values,” and the AI edits directly in your code.

I’ve seen this approach work best when you keep a sharp prompt. Some people just type “add tests” and expect magic. I’ve seen that investing extra time into crafting the right prompt pays off later, especially for repeated workflows like reviews or unit test generation.

It's like catching a bug in a code review vs catching the same bug in production. The later you have to change the approach, the more costly it is.

PDD is fast, but fragile. For scoped tasks, it's great. I think we'll see more and more often the small comments in code reviews get addressed by the AI before pushing, removing the human from the loop. You move quickly, but the logic behind your decisions stays in your IDE's chat window, instead of sharing with your team.

---

Spec Engineering (aka Spec-Driven Development)

Spec-driven development flips the process. Instead of prompting for code, you prompt for a plan.

You ask the AI to write a spec: user stories, acceptance criteria, high-level design, and a task list. Then you review it. Only after you're satisfied with the plan do you ask it to generate the actual implementation.

Basically it’s what software engineering teams do: You don't write code before aligning with your team and dependencies on the architecture of your system and the interfaces exposed.

This model clicked for me after reading

Jordan Cutler

’s post on using Cursor in “Ask” mode to generate a plan, and “Agent” mode to execute it. He was simulating spec-driven workflows inside a prompt-first editor. That hack worked, he just saw it by experience. But now tools like Amazon Kiro have baked-in support for spec mode with proper docs and versioned artifacts. It’s no longer a "good practice" when prompting, it's a feature in some IDEs.

The future of this approach involves treating specifications as code, versioned alongside the source for complete auditability. This also enables traceability links between tasks, code commits, and tests.

That said, spec-driven development isn’t free. Writing a spec to change a button color is an overhead. I only use it when I know the cost of AI generating a lot of wrong code is high. When building a new service or working on something that’ll stick around for years, SDD is worth the upfront time.

---

How to choose?

We don’t have to pick a side. We’ll use both, depending on the scope.

If I’m fixing a bug or adjusting a single function, I go prompt-first. It’s fast and good enough. If I’m designing a new feature or writing something other people will depend on, I go spec-first. That’s how I avoid rework and confusion.

I saw recently a post by

Raul Junco

with a timeline of moments that defined code quailty forever. The last item was 2023’s introduction of AI Coding Assistants. I think 2025-2026 will be the time we introduce versioned AI specs to our code.

What’s changing right now is that LLMs are starting to auto-select the approach. The recently launched GPT-5 chooses between a one-shot suggestion or kick off its reasoning process. The decision layer is shifting from the user to the tool, and I expect IDEs to implement this soon to choose.

For now we have to choose, so here’s how I think about it:

• Use Prompt Engineering when the task is small, solo, or uncertain. You’re exploring, not committing.

• Use Spec-Driven Development when the task is big, collaborative, or critical. You need alignment, not speed.

Nothing has changed from the old software engineering days without AI. You wouldn't write a document to change the color of a button, but you may write it to align with your team and dependencies what format and data should be in an event's payload or an API.

---

IDEs for each paradigm

The ecosystem is splitting in two: prompt-first tools for fast iteration and spec-first tools for structured development. Each has its place. I use both daily.

I have included this tool map of different tools and features. I have used Cursor, Kiro and Github Copilot extensively, the rest come from reading how other people use it. Let me know in the comments any that I’ve missed.

Prompt Engineering editors

• Cursor: In Agent mode, I issue commands like “refactor to async” or “add retry logic” and it handles isolated edits fast.

• Amazon Kiro (Vibe Mode): Lets you bypass the planning phase and prompt freely. I use it when I want speed without structure.

  

• GitHub Copilot Chat: Great for quick questions and code stubs.

• Replit Ghostwriter: Useful for fast prototyping in a browser, especially when exploring.

• Claude Code: Good context window.

• Windsurf: Good memory.

Spec-driven editors

• Amazon Kiro (Spec Mode): This is the real deal. It writes requirements.md, design.md, and tasks.json, then commits them to the repo. When structure matters, I go here.

• Cursor (Ask + Agent): You can mimic SDD by generating a plan in Ask mode, then executing in Agent mode. But you don’t get versioned artifacts unless you manually store them.

  

• All the others: If you’re disciplined, you can simulate SDD by prompting to write specs and execute tasks. But it’s all manual.

---

🎯 Conclusion

We have a tradeoff here: agility vs structure.

Prompt Engineering is fast, flexible, and great for solo or exploratory tasks. Spec-driven development is structured, clear, and great for scaling work across teams. You need both.

The engineers who grow fastest are those who remain flexible to switch between the two.

Try both on your next feature. Write a mini-spec. Then test a few prompt loops. See which feels faster, cleaner, and more maintainable. Your next promotion might depend on how well you adapt to this shift.

Thanks once again to Paddle for sponsoring this article. Join for free their webinar here.

🗞️ Other articles people like

⏰ This engineer tracked his time for more than a year and this is what he learned

📚 From Zero to Software Engineer: 100+ Resources I Wish I Had at 18

🏆 How I'm advancing my career without neglecting my life. "New year's resolutions" done right.

🏆🔥 How TOP engineers structure their day to maximize their productivity without burnout

👏 Weekly applause

These are some great articles I’ve read last week:

• How to say 'no' to executives (without killing your career) by

  Taha Hussain
  . The key to saying no to executives is not to start with resistance but to seek alignment.

• From Shy Engineer to Director at Oracle and a Skilled Communicator by

  Gregor Ojstersek
  and
  Pramoda Vyasarao
  . About the role of communication skills in career advancement.

• How to Think Like a VC When Evaluating a Startup Role by

  Irina Stanescu
  and
  Oana Olteanu
  . Evaluate job opportunities with the same rigor as a venture capitalist, considering market potential, team capability, business viability…

• A Simple Git Workflow by

  Saurabh Dashora
  . Mastering a Git workflow is essential for effective collaboration, even when coding just yourself.

• Would you pass an interview where AI is allowed? by

  Hemant Pandey
  . AI tools will force the industry to change coding interviews focusing more on collaboration, reasoning, and debugging abilities.

• How Do Webhooks Work ⭐ by

  Neo Kim
  . Understanding how webhooks work can significantly improve real-time communication between systems.

🙏 One last thing before you go:

I am always working to make this newsletter even better.

Could you take one minute to answer a quick, anonymous survey?

👉 Take the survey here

See you in the next email,

Fran.