I've been doing technical SEO for 20 years. My first "automation" was a shell script
that pinged Google every hour to check if my site got indexed. We've come a long way.
For most of those two decades, automation meant one thing: Python. Scrapers,
crawlers, log analyzers, bulk content pipelines. I got comfortable with the idea
that if something was repetitive, you wrote a script for it. Ship it, forget it,
move on.
Then two years ago something broke that model completely.
The thing about prompt engineering nobody tells you
When LLMs got good enough to be useful for real work, my first instinct was to
use them as fancy autocomplete. Better keyword research. Faster content briefs.
Smarter meta description generation.
That phase lasted about three months.
The shift happened when I stopped asking "what can I use AI for" and started
asking "what does a good AI instruction system look like." That question is
completely different — and it pulled me back into something that felt a lot
like software engineering.
Except instead of writing functions, I was writing behavior specifications.
# Bad prompt (autocomplete thinking)
"Write me 10 title tags for a page about industrial pumps"
# Good prompt (behavior specification thinking)
"You are auditing title tags for B2B industrial equipment pages.
Flag any title that: uses generic verbs (Buy, Get, Find),
exceeds 60 chars, or leads with brand name instead of product category.
For each flagged item, explain the specific SEO risk and rewrite it."
The difference isn't just style. The second one is reliable. You can run it
on 500 pages and get consistent, actionable output. The first gives you
something different every time.
Vibe coding changed how I prototype
Here's where it gets weird. Around the same time I was getting serious about
prompt engineering, I started using Claude Code and Cursor for my actual
Python work.
I'm not a great developer. I'm a good enough developer — the kind who can
read code, understand what it does, fix obvious things, but struggles to
architect something from scratch without spending too long on decisions that
don't matter yet.
Vibe coding fixed that for me. Not because AI writes perfect code (it doesn't),
but because it eliminates the blank page problem.
My workflow now:
- Describe what I want to build in plain language
- Get a working skeleton in minutes
- Actually understand what was built before touching it
- Iterate from something real instead of from nothing
The understanding step is non-negotiable. I've seen people vibe-code themselves
into a codebase they can't maintain because they never stopped to read what was
generated. That's not automation — that's technical debt with extra steps.
When the two things collided
Six months ago I was trying to solve a specific problem: every time I used an
AI agent to help with UI/UX work (landing pages, SaaS app layouts, design audits),
it would generate the same bland outputs. Centered hero. Purple-to-indigo gradient.
Generic cards grid. The AI "safe choices" problem.
My SEO brain said: this is a rules problem, not a capability problem.
The model knows good design — it just doesn't have a consistent framework
to apply it in my context.
So I built one. A set of design rules, blueprints, and industry-specific
guidelines that I inject into every design-related task. OKLCH colors.
Proper motion/react patterns. Sector-specific banned patterns
(different rules for a B2B SaaS vs a health platform vs an e-commerce site).
Then I made it a proper MCP server so any AI tool could use it:
# Any agent can now call:
get_sector_context("b2b-products")
# → Returns required trust signals, banned patterns, conversion elements
# specific to B2B industrial/enterprise design
check_banned_patterns("saas", "purple gradient hero with centered H1")
# → Returns violations with specific rule citations
The result is global-design-skill
— an open-source design OS for Claude Code, Cursor, Copilot, and Windsurf.
It detects your business sector automatically, applies the right rules,
and the longer you use it the more it calibrates to your feedback.
All local, no telemetry.
What 20 years of SEO actually taught me about AI systems
Looking back, SEO was always about constrained optimization — you can't
control the algorithm, so you control everything you can. Structure.
Signals. Context. Consistency.
Prompt engineering is the same discipline applied to a different system.
You can't control what the model knows, but you can control:
- The frame — what role it's playing, what rules apply
- The context — what it knows about your specific situation
- The output format — what a good answer looks like structurally
- The failure mode — what it should say when it doesn't know
The people who are best at this, in my experience, aren't necessarily
great coders or great writers. They're people who are good at thinking
in systems — seeing the inputs, the process, and the expected outputs
as something you can specify and iterate on.
That's a skill SEO built in me without me realizing it.
What's next
I'm currently learning a lot about:
- MCP server design — what makes a good tool vs a bad one for AI agents
- Context window economics — how to pack maximum useful signal into minimum tokens
- Sector-specific AI behavior — same task, different industries, completely different right answers
If you're working at the intersection of AI tooling, automation, and domain
expertise — I'd love to connect. This space is still early enough that most
of the interesting problems haven't been solved yet.
What's your workflow when you're using AI tools for work that's specific to
your domain? Do you inject domain context explicitly or let the model figure it out?
