feat: add generated images for Spec-Driven Shift posts 3-20

Generated editorial illustrations for all remaining posts using Gemini 3 Pro,
chaining each image as a style reference for the next to maintain visual consistency.

Author: SamHatoum

docs/perspectives/the-spec-driven-shift/post-10.md

@@ -4,6 +4,8 @@ title: "AI Needs History. Your Database Deletes It."
 
 # AI Needs History. Your Database Deletes It.
 
+![](/images/perspectives/post-10.png)
+
 Traditional databases store current state. Customer lives at 123 Main St. They move. Now it's 456 Oak Ave. The old address? Gone. Overwritten. History erased.
 
 For most of the history of computing, that was fine. You need the current address to ship a package. You don't need the old one.

docs/perspectives/the-spec-driven-shift/post-11.md

@@ -4,6 +4,8 @@ title: "5 Spec Smells That Turn Every AI Prompt Into a Guessing Game"
 
 # 5 Spec Smells That Turn Every AI Prompt Into a Guessing Game
 
+![](/images/perspectives/post-11.png)
+
 Just like code smells tell you something's off in your implementation, spec smells tell you your specifications are going to cause problems. And with AI in the mix, spec smells don't just cause problems for your team. They turn every AI interaction into a guessing game where the AI fills in the blanks with its own assumptions.
 
 I see five constantly.

docs/perspectives/the-spec-driven-shift/post-12.md

@@ -4,6 +4,8 @@ title: "A PRD Is Not a Spec. Here's Why That Matters."
 
 # A PRD Is Not a Spec. Here's Why That Matters.
 
+![](/images/perspectives/post-12.png)
+
 This confusion costs teams months. And most don't even realize they're confused.
 
 There are three levels of progressive specificity:

docs/perspectives/the-spec-driven-shift/post-13.md

@@ -4,6 +4,8 @@ title: "Jira Is Where Specs Go to Die. Your AI Just Showed Up With a Shovel."
 
 # Jira Is Where Specs Go to Die. Your AI Just Showed Up With a Shovel.
 
+![](/images/perspectives/post-13.png)
+
 Three different things. Three different lifecycles. All collapsed into one Jira ticket.
 
 Requirements: the problem to solve. Stick around until the problem itself changes.

docs/perspectives/the-spec-driven-shift/post-14.md

@@ -4,6 +4,8 @@ title: "Give Me the Freedom of a Tight Brief. Why Specs Are the Ultimate AI Prom
 
 # Give Me the Freedom of a Tight Brief. Why Specs Are the Ultimate AI Prompt.
 
+![](/images/perspectives/post-14.png)
+
 I was auditing a media agency years ago and a creative director said something I've never forgotten.
 
 "Give me the freedom of a tight brief."

docs/perspectives/the-spec-driven-shift/post-15.md

@@ -4,6 +4,8 @@ title: "The Best AI Developers Are Spec-Driven. They Just Haven't Named It Yet."
 
 # The Best AI Developers Are Spec-Driven. They Just Haven't Named It Yet.
 
+![](/images/perspectives/post-15.png)
+
 If you're using AI tools well, you're already doing spec-driven development. You just don't call it that.
 
 Think about what good AI-assisted dev actually looks like. You have a design in your head. You think about constraints. You write a prompt that captures your intent: what should happen, what shouldn't, what the boundaries are. You review the output. You check it matches your expectation. You iterate.

docs/perspectives/the-spec-driven-shift/post-16.md

@@ -4,6 +4,8 @@ title: "Specs Are the Next Programming Languages"
 
 # Specs Are the Next Programming Languages
 
+![](/images/perspectives/post-16.png)
+
 Here's what I think happens in the next few years. We end up with an ecosystem of specification dialects as varied as programming languages.
 
 Look at the history of abstraction. Wired circuits. Machine code. Assembly. High-level languages. Frameworks. Each generation abstracted the previous one. Each gave people a higher-order way to say what they wanted.

docs/perspectives/the-spec-driven-shift/post-17.md

@@ -4,6 +4,8 @@ title: "Most Specs Fail Because They Start Too Low. Start Here Instead."
 
 # Most Specs Fail Because They Start Too Low. Start Here Instead.
 
+![](/images/perspectives/post-17.png)
+
 The most common spec mistake isn't writing bad specs. It's starting at the wrong level.
 
 Teams jump straight to component specs. "The email validator should accept RFC 5322." "The API returns 404 for missing resources." Fine specifications. Specific. Testable. But they're fragments without a whole.

docs/perspectives/the-spec-driven-shift/post-18.md

@@ -4,6 +4,8 @@ title: "When Coding Becomes Instant, Specs Are All That Matters"
 
 # When Coding Becomes Instant, Specs Are All That Matters
 
+![](/images/perspectives/post-18.png)
+
 "This is just waterfall with extra steps."
 
 I get this one a lot. Let me deal with it, and then I'll give you a thought experiment that I think settles it.

docs/perspectives/the-spec-driven-shift/post-19.md

@@ -4,6 +4,8 @@ title: "Fool Me Once, I Write a Spec. Fool Me Twice? There Is No Twice."
 
 # Fool Me Once, I Write a Spec. Fool Me Twice? There Is No Twice.
 
+![](/images/perspectives/post-19.png)
+
 People ask what my actual daily workflow looks like. Not the theory. The practice.
 
 Here it is.