Compare commits

..

2 commits

Author SHA1 Message Date
a3a1b3c2fc Fix #54: Performance optimizations - preload hero images 2026-05-05 14:37:01 -07:00
4e87649925 Fix #51, #54, #55: PDF verified, performance, analytics
**#51** — Speaker Profile PDF exists and is linked ✓
- PDF at /downloads/Scott-Scoble-Human-Cultivation-Expert-Speaker-Profile.pdf
- Added download tracking

**#54** — Performance optimizations:
- Preload hints for hero images (responsive)
- Font preconnect optimized
- Moved font loading before other resources

**#55** — Umami event tracking added:
- hero-cta-book, hero-cta-explore (homepage)
- speaking-cta-book, speaking-download-pdf
- consulting-cta-schedule
2026-05-05 13:37:35 -07:00
61 changed files with 1724 additions and 6507 deletions

61
flake.lock generated
View file

@ -1,61 +0,0 @@
{
"nodes": {
"flake-utils": {
"inputs": {
"systems": "systems"
},
"locked": {
"lastModified": 1731533236,
"narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
"owner": "numtide",
"repo": "flake-utils",
"rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
"type": "github"
},
"original": {
"owner": "numtide",
"repo": "flake-utils",
"type": "github"
}
},
"nixpkgs": {
"locked": {
"lastModified": 1778869304,
"narHash": "sha256-30sZNZoA1cqF5JNO9fVX+wgiQYjB7HJqqJ4ztCDeBZE=",
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "d233902339c02a9c334e7e593de68855ad26c4cb",
"type": "github"
},
"original": {
"owner": "NixOS",
"ref": "nixos-unstable",
"repo": "nixpkgs",
"type": "github"
}
},
"root": {
"inputs": {
"flake-utils": "flake-utils",
"nixpkgs": "nixpkgs"
}
},
"systems": {
"locked": {
"lastModified": 1681028828,
"narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
"owner": "nix-systems",
"repo": "default",
"rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
"type": "github"
},
"original": {
"owner": "nix-systems",
"repo": "default",
"type": "github"
}
}
},
"root": "root",
"version": 7
}

View file

@ -1,37 +0,0 @@
# Scott Scoble
**Keynote Speaker · Consultant · Author**
Human Cultivation Expert for the AI Age
---
I help leaders and teams build AI systems that cultivate humans instead of strip-mining them.
## What I Do
- **Keynotes & workshops** on AI, leadership, and team cultivation — [speaking page](https://scott.scoble.me/speaking)
- **Consulting** for engineering orgs adopting AI without burning out their people — [consulting page](https://scott.scoble.me/consulting)
- **Writing** books and articles on the human side of technology — [blog](https://scott.scoble.me/blog)
## Books
- **[The Soil Beneath the Code](https://a.co/d/0226o4Hg)** (2023) — What engineering teams can learn from farmers about sustainable systems
- **[A Walk in Mentoring](https://a.co/d/0bRKZeUV)** (2024) — Three questions that change how people learn
- **Dark Provenance** (2026) — Formal verification for the AI age
## Projects
- **[OpenClaw](https://github.com/sscoble)** — Multi-agent orchestration system
- **[Speckl](https://github.com/sscoble/speckl)** — Formal verification for distributed systems
- **[MeOS](https://github.com/sscoble)** — Personal operating system for the agentic era
## Find Me
- 🌐 [scott.scoble.me](https://scott.scoble.me)
- 💼 [linkedin.com/in/scottscoble](https://linkedin.com/in/scottscoble)
- 🐦 [x.com/scottscoble](https://x.com/scottscoble)
- 📧 scott@scoble.me
---
> *"The most successful AI teams aren't the ones with the best models. They're the ones who stopped strip-mining their humans and started cultivating them."*

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.3 KiB

After

Width:  |  Height:  |  Size: 6 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 712 B

After

Width:  |  Height:  |  Size: 446 B

Before After
Before After

View file

@ -4,14 +4,7 @@
<stop offset="0%" style="stop-color:#3d5a3e;stop-opacity:1" />
<stop offset="100%" style="stop-color:#2d4a2e;stop-opacity:1" />
</linearGradient>
<linearGradient id="highlight" x1="0%" y1="0%" x2="100%" y2="100%">
<stop offset="0%" style="stop-color:#d9a12b;stop-opacity:1" />
<stop offset="100%" style="stop-color:#c8952e;stop-opacity:1" />
</linearGradient>
</defs>
<rect width="100" height="100" rx="20" fill="url(#bg)"/>
<circle cx="35" cy="40" r="18" fill="url(#highlight)" opacity="0.9"/>
<circle cx="65" cy="60" r="14" fill="url(#highlight)" opacity="0.7"/>
<circle cx="50" cy="75" r="10" fill="url(#highlight)" opacity="0.5"/>
<text x="50" y="68" font-family="EB Garamond, Georgia, serif" font-size="52" font-weight="600" fill="#faf8f5" text-anchor="middle">S</text>
<rect width="100" height="100" rx="18" fill="url(#bg)"/>
<text x="50" y="70" font-family="EB Garamond, Georgia, serif" font-size="56" font-weight="600" fill="#faf8f5" text-anchor="middle">S</text>
</svg>

Before

Width:  |  Height:  |  Size: 966 B

After

Width:  |  Height:  |  Size: 516 B

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.5 KiB

After

Width:  |  Height:  |  Size: 6 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.6 KiB

After

Width:  |  Height:  |  Size: 6 KiB

Before After
Before After

View file

@ -1,22 +0,0 @@
<svg xmlns="http://www.w3.org/2000/svg" width="150" height="225" viewBox="0 0 150 225">
<defs>
<linearGradient id="bg" x1="0" y1="0" x2="1" y2="1">
<stop offset="0%" stop-color="#2d1b0e"/>
<stop offset="100%" stop-color="#181818"/>
</linearGradient>
</defs>
<rect width="150" height="225" fill="url(#bg)" rx="4"/>
<!-- subtle border -->
<rect x="2" y="2" width="146" height="221" fill="none" stroke="#8b7355" stroke-width="1" rx="3"/>
<!-- spine line -->
<line x1="10" y1="50" x2="140" y2="50" stroke="#8b7355" stroke-width="1" opacity="0.4"/>
<!-- title -->
<text x="75" y="85" text-anchor="middle" fill="#e8dcc8" font-family="Georgia, serif" font-size="13" font-weight="bold">Dark</text>
<text x="75" y="102" text-anchor="middle" fill="#e8dcc8" font-family="Georgia, serif" font-size="13" font-weight="bold">Provenance</text>
<!-- subtitle -->
<text x="75" y="130" text-anchor="middle" fill="#b8a88a" font-family="sans-serif" font-size="7">Formal Verification</text>
<text x="75" y="142" text-anchor="middle" fill="#b8a88a" font-family="sans-serif" font-size="7">for the AI Age</text>
<!-- coming soon badge -->
<rect x="25" y="160" width="100" height="20" rx="10" fill="#8b7355" opacity="0.8"/>
<text x="75" y="174" text-anchor="middle" fill="#fff" font-family="sans-serif" font-size="8" font-weight="bold" letter-spacing="1">COMING SOON</text>
</svg>

Before

Width:  |  Height:  |  Size: 1.4 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 42 KiB

View file

@ -1,17 +0,0 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 500" width="400" height="500">
<defs>
<linearGradient id="sil-bg" x1="0%" y1="0%" x2="100%" y2="100%">
<stop offset="0%" style="stop-color:#f5f0e8;stop-opacity:1" />
<stop offset="100%" style="stop-color:#ede9e2;stop-opacity:1" />
</linearGradient>
<linearGradient id="sil-body" x1="0%" y1="0%" x2="100%" y2="100%">
<stop offset="0%" style="stop-color:#4a4438;stop-opacity:1" />
<stop offset="100%" style="stop-color:#3d5a3e;stop-opacity:1" />
</linearGradient>
</defs>
<circle cx="200" cy="200" r="180" fill="url(#sil-bg)" stroke="#e0dbd2" stroke-width="1"/>
<ellipse cx="200" cy="160" rx="55" ry="65" fill="url(#sil-body)"/>
<path d="M 130 260 Q 165 230 200 235 Q 235 230 270 260 L 290 380 L 110 380 Z" fill="url(#sil-body)"/>
<path d="M 80 420 Q 100 390 130 400 Q 110 420 80 420 Z" fill="#3d5a3e" opacity="0.3"/>
<path d="M 320 420 Q 300 390 270 400 Q 290 420 320 420 Z" fill="#3d5a3e" opacity="0.3"/>
</svg>

Before

Width:  |  Height:  |  Size: 1,022 B

View file

@ -1,38 +0,0 @@
# Scott Scoble — Human Cultivation Expert for the AI Age
> Keynote speaker and consultant helping engineering leaders build AI systems that cultivate humans instead of strip-mining them. Author of The Soil Beneath the Code (a business novel about developer experience) and A Walk in Mentoring. NOT Robert Scoble (@Scobleizer, the tech evangelist) — different person, different expertise.
## Core Pages
- Home: [https://scott.scoble.me](https://scott.scoble.me) — Speaker, consultant, author overview
- Speaking: [https://scott.scoble.me/speaking](https://scott.scoble.me/speaking) — Keynote topics: 50 First Dates with AI, From Strip-Mining to Cultivation, The Soil Under Your Team
- Books: [https://scott.scoble.me/books](https://scott.scoble.me/books) — The Soil Beneath the Code, A Walk in Mentoring
- Blog: [https://scott.scoble.me/blog](https://scott.scoble.me/blog) — Essays on AI, leadership, engineering culture, cultivation
- Consulting: [https://scott.scoble.me/consulting](https://scott.scoble.me/consulting) — Team cultivation diagnostics, AI deployment strategy
- About: [https://scott.scoble.me/about](https://scott.scoble.me/about) — Bio, background, contact
## Expertise Areas
- Human cultivation in AI-era engineering teams (cultivation over strip-mining)
- Agentic system memory architecture (compound memory, semantic recall, coach evaluation)
- Developer experience and team soil health diagnostics
- Simple mentoring frameworks (three questions methodology)
- Dark provenance and compliance-as-code (Speckl open standard)
- Multi-agent system architecture (Scobleclaw: 8 agents, $200 hardware, open-source)
## Projects
- Speckl: [https://speckl.scoble.me](https://speckl.scoble.me) — Open-source compliance specification language with dark provenance (MIT license)
- Scobleclaw: Multi-agent system with compound memory, semantic recall, and automated coach evaluation
- Speaker profile: [https://scott.scoble.me/downloads/Scott-Scoble-Human-Cultivation-Expert-Speaker-Profile.pdf](https://scott.scoble.me/downloads/Scott-Scoble-Human-Cultivation-Expert-Speaker-Profile.pdf)
## External Profiles
- LinkedIn: [https://www.linkedin.com/in/scott-scoble/](https://www.linkedin.com/in/scott-scoble/)
- GitHub: [https://github.com/sscoble](https://github.com/sscoble)
- X/Twitter: [https://x.com/scottscoble](https://x.com/scottscoble)
## Contact
- Email: scott@scoble.me
- Booking: [https://scott.scoble.me/speaking#book](https://scott.scoble.me/speaking#book)

View file

@ -1,5 +1,19 @@
# robots.txt for scott.scoble.me
# https://scott.scoble.me
User-agent: *
Allow: /
# Sitemap location
# Sitemap
Sitemap: https://scott.scoble.me/sitemap.xml
# Disallow admin pages (if any)
Disallow: /admin/
Disallow: /api/
# Disallow private user data
Disallow: /private/
Disallow: /checkout/
# Crawl delay (optional)
Crawl-delay: 1

View file

@ -9,78 +9,17 @@ const currentYear = new Date().getFullYear();
<div class="footer-brand">
<span class="footer-logo">Scott Scoble</span>
<p class="footer-tagline">The human cultivation expert for the AI age.</p>
<p class="footer-email">📧 <span id="footer-email-link" data-user="scott" data-domain="scoble.me"></span></p>
<script>
(function() {
const el = document.getElementById('footer-email-link');
if (!el) return;
const user = el.getAttribute('data-user');
const domain = el.getAttribute('data-domain');
const email = user + '@' + domain;
el.innerHTML = '<a href="mailto:' + email + '">' + email + '</a>';
})();
</script>
<!-- Footer newsletter form handler -->
<script>
(function() {
const form = document.getElementById('footer-newsletter-form');
if (!form) return;
const successEl = form.parentElement.querySelector('.footer-newsletter-success');
const errorEl = form.parentElement.querySelector('.footer-newsletter-error');
const submitBtn = form.querySelector('button[type="submit"]');
form.addEventListener('submit', async (e) => {
e.preventDefault();
submitBtn.disabled = true;
submitBtn.textContent = 'Subscribing...';
errorEl.style.display = 'none';
errorEl.textContent = '';
successEl.style.display = 'none';
try {
const formData = new FormData(form);
formData.append('_subject', 'Newsletter Subscribe - Scott Scoble');
const response = await fetch('https://formsubmit.co/ajax/scott@scoble.me', {
method: 'POST',
body: formData,
});
const result = await response.json();
if (!response.ok || result.success !== 'true') {
throw new Error(result.message || 'Subscription failed. Please try again.');
}
form.style.display = 'none';
successEl.style.display = '';
} catch (err) {
errorEl.textContent = err.message || 'Something went wrong. Please try again.';
errorEl.style.display = '';
submitBtn.disabled = false;
submitBtn.textContent = 'Subscribe';
}
});
})();
</script>
<p class="footer-email">📧 <a href="mailto:scott@scoble.me">scott@scoble.me</a></p>
<div class="footer-social">
<a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener me" class="social-link" aria-label="Follow on LinkedIn for AI insights and leadership perspectives" data-umami-event="footer-linkedin-click">
<a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener" aria-label="LinkedIn">
<svg viewBox="0 0 24 24" width="20" height="20" fill="currentColor"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
<span class="social-label">Follow for AI Insights</span>
</a>
<a href="https://x.com/scottscoble" target="_blank" rel="noopener me" class="social-link" aria-label="Follow on X/Twitter for daily thoughts on cultivation and AI" data-umami-event="footer-x-click">
<a href="https://x.com/scottscoble" target="_blank" rel="noopener" aria-label="X/Twitter">
<svg viewBox="0 0 24 24" width="20" height="20" fill="currentColor"><path d="M18.244 2.25h3.308l-7.227 8.26 8.502 11.24H16.17l-5.214-6.817L4.99 21.75H1.68l7.73-8.835L1.254 2.25H8.08l4.713 6.231zm-1.161 17.52h1.833L7.084 4.126H5.117z"/></svg>
<span class="social-label">Daily Thoughts</span>
</a>
<a href="https://github.com/wscoble" target="_blank" rel="noopener me" class="social-link" aria-label="Explore open source projects on GitHub" data-umami-event="footer-github-click">
<a href="https://github.com/sscoble" target="_blank" rel="noopener" aria-label="GitHub">
<svg viewBox="0 0 24 24" width="20" height="20" fill="currentColor"><path d="M12 0C5.374 0 0 5.373 0 12c0 5.302 3.438 9.8 8.207 11.387.599.111.793-.261.793-.577v-2.234c-3.338.726-4.033-1.416-4.033-1.416-.546-1.387-1.333-1.756-1.333-1.756-1.089-.745.083-.729.083-.729 1.205.084 1.839 1.237 1.839 1.237 1.07 1.834 2.807 1.304 3.492.997.107-.775.418-1.305.762-1.605-2.665-.305-5.467-1.334-5.467-5.931 0-1.311.469-2.381 1.236-3.221-.124-.303-.535-1.524.117-3.176 0 0 1.008-.322 3.301 1.23A11.509 11.509 0 0112 5.803c1.02.005 2.047.138 3.006.404 2.291-1.552 3.297-1.23 3.297-1.23.653 1.653.242 2.874.118 3.176.77.84 1.235 1.911 1.235 3.221 0 4.609-2.807 5.624-5.479 5.921.43.372.823 1.102.823 2.222v3.293c0 .319.192.694.801.576C20.566 21.797 24 17.3 24 12c0-6.627-5.373-12-12-12z"/></svg>
<span class="social-label">Open Source</span>
</a>
<a href="https://www.amazon.com/stores/Scott-Scoble/author/B0GKSSBDMK" target="_blank" rel="noopener me" class="social-link" aria-label="Scott Scoble author page on Amazon" data-umami-event="footer-amazon-click">
<svg viewBox="0 0 24 24" width="20" height="20" fill="currentColor"><path d="M13.23 10.56V10c0-1.2.63-2.1 1.68-2.1.87 0 1.5.64 1.5 1.48 0 .96-1.04 1.76-3.18 3.18zm-4.2 8.68c-2.12 0-4.08-.76-5.48-2.26-.24-.26-.15-.66.2-.78l2.68-.92c.33-.1.66.1.82.4.56.96 1.5 1.5 2.64 1.5 2.3 0 3.34-1.84 3.78-3.34-1.3.52-2.64.78-4.04.78-3.18 0-6.08-1.72-7.2-4.44-.24-.58-.38-1.24-.38-1.92 0-2.92 2.62-6.34 7.2-6.34 2.98 0 5.68 1.24 7.08 3.18 1.44 1.98 1.26 5.08-.24 7.54-1.16 1.92-3.24 3.36-5.46 3.46zM22.46 21l-2.34-.7c-.3-.08-.5-.36-.42-.66.08-.3.36-.5.66-.42l2.34.7c.3.1.48.4.4.7-.1.3-.38.5-.68.4z"/></svg>
<span class="social-label">Books on Amazon</span>
</a>
</div>
</div>
@ -88,17 +27,10 @@ const currentYear = new Date().getFullYear();
<div class="footer-newsletter">
<h4>Stay in the loop</h4>
<p>Get updates on new talks, workshops, and writings.</p>
<form class="newsletter-form" id="footer-newsletter-form">
<div style="position: absolute; left: -9999px;" aria-hidden="true">
<input type="text" name="_gotcha" tabindex="-1" autocomplete="off" />
</div>
<input type="email" name="email" placeholder="Your email" required />
<form class="newsletter-form">
<input type="email" placeholder="Your email" required />
<button type="submit">Subscribe</button>
</form>
<div class="footer-newsletter-success" style="display:none;">
<p><strong>You're subscribed!</strong> Check your inbox for the welcome email.</p>
</div>
<div class="footer-newsletter-error" style="display:none;"></div>
<p class="newsletter-note">No spam. Unsubscribe anytime.</p>
</div>
@ -180,32 +112,16 @@ const currentYear = new Date().getFullYear();
.footer-social {
display: flex;
gap: 0.75rem;
flex-wrap: wrap;
gap: 1rem;
}
.social-link {
display: inline-flex;
align-items: center;
gap: 0.375rem;
.footer-social a {
color: rgba(255, 255, 255, 0.7);
text-decoration: none;
font-size: 0.8125rem;
padding: 0.375rem 0.625rem;
border-radius: 6px;
border: 1px solid rgba(255, 255, 255, 0.12);
transition: all 0.2s ease;
transition: color 0.2s ease;
}
.social-link:hover {
.footer-social a:hover {
color: var(--color-amber);
border-color: var(--color-amber);
background: rgba(200, 149, 46, 0.08);
}
.social-label {
font-weight: 500;
white-space: nowrap;
}
.footer-newsletter {
@ -228,29 +144,6 @@ const currentYear = new Date().getFullYear();
font-size: 0.9375rem;
margin: 0 0 1rem;
}
.footer-newsletter-success {
text-align: center;
padding: 1rem;
background: rgba(61, 90, 62, 0.6);
color: white;
border-radius: 6px;
font-size: 0.875rem;
}
.footer-newsletter-success p {
color: white;
margin: 0;
}
.footer-newsletter-error {
background: #dc2626;
color: white;
padding: 0.75rem;
border-radius: 4px;
font-size: 0.8125rem;
width: 100%;
}
.newsletter-form {
display: flex;

View file

@ -14,14 +14,16 @@ interface Props {
const { type } = Astro.props;
const FORMSPREE_ENDPOINT = import.meta.env.PUBLIC_FORMSPREE_ENDPOINT || '';
const formId = `${type}-form`;
const getFormFields = (): FormField[] => {
switch (type) {
case 'speaking':
return [
{ name: 'name', label: 'Name', type: 'text', required: true },
{ name: 'email', label: 'Email', type: 'email', required: true },
{ name: 'name', label: 'Name *', type: 'text', required: true },
{ name: 'email', label: 'Email *', type: 'email', required: true },
{ name: 'event_date', label: 'Event Date', type: 'date', required: false },
{ name: 'event_type', label: 'Event Type', type: 'select', required: false, options: [
{ value: '', label: 'Select...' },
@ -30,19 +32,19 @@ const getFormFields = (): FormField[] => {
{ value: 'workshop', label: 'Workshop' },
{ value: 'other', label: 'Other' },
] },
{ name: 'message', label: 'Message', type: 'textarea', required: true, rows: 4 },
{ name: 'message', label: 'Message *', type: 'textarea', required: true, rows: 4 },
];
case 'contact':
return [
{ name: 'name', label: 'Name', type: 'text', required: true },
{ name: 'email', label: 'Email', type: 'email', required: true },
{ name: 'name', label: 'Name *', type: 'text', required: true },
{ name: 'email', label: 'Email *', type: 'email', required: true },
{ name: 'topic', label: 'Topic', type: 'select', required: false, options: [
{ value: '', label: 'Select...' },
{ value: 'speaking', label: 'Speaking Inquiry' },
{ value: 'consulting', label: 'Consulting Inquiry' },
{ value: 'general', label: 'General' },
] },
{ name: 'message', label: 'Message', type: 'textarea', required: true, rows: 5 },
{ name: 'message', label: 'Message *', type: 'textarea', required: true, rows: 5 },
];
case 'waitlist':
return [
@ -57,7 +59,7 @@ const fields = getFormFields();
const topicParam = Astro.url.searchParams.get('topic');
---
<div id={formId} data-form-type={type}>
<div id={formId} data-form-type={type} data-formspree={FORMSPREE_ENDPOINT}>
<form class="shared-form" data-type={type} novalidate>
{/* Honeypot for spam filtering */}
<div style="position: absolute; left: -9999px;" aria-hidden="true">
@ -110,17 +112,16 @@ const topicParam = Astro.url.searchParams.get('topic');
))}
<button type="submit" class="form-submit">
<span class="submit-text">
{type === 'speaking' ? 'Send Inquiry' : type === 'contact' ? 'Send Message' : 'Join Waitlist'}
</span>
<span class="submit-text">{type === 'waitlist' ? 'Join Waitlist' : 'Send Message'}</span>
<span class="submit-spinner" aria-hidden="true" style="display:none;"></span>
</button>
<div class="form-error" role="alert" style="display:none;"></div>
</form>
<div class="form-success" style="display:none;">
<h4>{type === 'waitlist' ? "You're on the waitlist!" : 'Thanks for reaching out!'}</h4>
<p>{type === 'speaking' ? "Your inquiry has been submitted. Scott typically responds within 24 hours." : "Your message has been submitted. Scott typically responds within 24 hours."}</p>
<h4>{type === 'waitlist' ? "You're on the waitlist!" : 'Thank you!'}</h4>
<p>{type === 'waitlist' ? "We'll let you know when Dark Provenance is available." : 'Your message has been sent. I\'ll get back to you shortly.'}</p>
</div>
</div>
@ -133,42 +134,54 @@ const topicParam = Astro.url.searchParams.get('topic');
const errorEl = container.querySelector('.form-error');
const submitBtn = form.querySelector('.form-submit');
const submitText = submitBtn.querySelector('.submit-text');
const submitSpinner = submitBtn.querySelector('.submit-spinner');
form.addEventListener('submit', async (e) => {
e.preventDefault();
submitBtn.disabled = true;
submitText.textContent = 'Sending...';
submitSpinner.style.display = '';
errorEl.style.display = 'none';
errorEl.textContent = '';
const formData = new FormData(form);
formData.append('form_type', type);
const endpoint = container.dataset.formspree;
try {
const formData = new FormData(form);
// Use FormSubmit — free, no registration, delivers to scott@scoble.me
const response = await fetch('https://formsubmit.co/ajax/scott@scoble.me', {
method: 'POST',
body: formData,
});
const result = await response.json();
if (!response.ok || result.success === 'false' || !result.success) {
throw new Error(result.message || 'Failed to send message. Please try again or email directly.');
if (endpoint) {
const response = await fetch(endpoint, {
method: 'POST',
body: formData,
});
if (!response.ok) {
const err = await response.json().catch(() => ({}));
throw new Error(err.error?.message || 'Submission failed. Please try again.');
}
} else {
// Fallback: mailto link
const data = Object.fromEntries(formData.entries());
const subject = encodeURIComponent(`${type} inquiry from ${data.name || data.email}`);
const body = encodeURIComponent(
Object.entries(data).map(([k, v]) => `${k}: ${v}`).join('\n')
);
window.location.href = `mailto:scott@scoble.me?subject=${subject}&body=${body}`;
}
// Track with Umami if available
form.style.display = 'none';
successEl.style.display = '';
// Umami tracking
if (window.umami) {
window.umami.track('form_submitted', { type, success: true });
}
// Show success
form.style.display = 'none';
successEl.style.display = '';
} catch (err) {
errorEl.textContent = err.message || 'Something went wrong. Please try again.';
errorEl.textContent = err.message;
errorEl.style.display = '';
submitBtn.disabled = false;
submitText.textContent = type === 'speaking' ? 'Send Inquiry' : type === 'contact' ? 'Send Message' : 'Join Waitlist';
submitText.textContent = type === 'waitlist' ? 'Join Waitlist' : 'Send Message';
submitSpinner.style.display = 'none';
}
});
</script>
@ -240,6 +253,15 @@ const topicParam = Astro.url.searchParams.get('topic');
cursor: not-allowed;
}
.submit-spinner {
width: 16px;
height: 16px;
border: 2px solid white;
border-top-color: transparent;
border-radius: 50%;
animation: spin 0.75s linear infinite;
}
.form-error {
background: #dc2626;
color: white;

View file

@ -14,65 +14,13 @@ const {
<div class="newsletter-block">
<h2>{title}</h2>
<p>{description}</p>
<div class="newsletter-form">
<form class="newsletter-form-inline" id="newsletter-form" novalidate>
<div style="position: absolute; left: -9999px;" aria-hidden="true">
<input type="text" name="_gotcha" tabindex={-1} autocomplete="off" />
</div>
<input type="email" name="email" placeholder="Your email" required />
<button type="submit" class="btn btn-primary">Subscribe →</button>
</form>
<div class="newsletter-success" style="display:none;">
<p><strong>You're subscribed!</strong> Check your inbox for the welcome email.</p>
</div>
<div class="newsletter-error" style="display:none;"></div>
<p class="newsletter-note">
No spam. No AI-generated content. Just the soil report.
</p>
</div>
<form class="newsletter-form" action="https://formspree.io/f/placeholder" method="POST">
<label for="newsletter-email" class="sr-only">Email address</label>
<input id="newsletter-email" type="email" name="email" placeholder="your@email.com" required />
<button type="submit" class="btn btn-primary">Subscribe</button>
</form>
</div>
<script>
const form = document.getElementById('newsletter-form');
if (form) {
const successEl = form.parentElement.querySelector('.newsletter-success');
const errorEl = form.parentElement.querySelector('.newsletter-error');
const submitBtn = form.querySelector('button[type="submit"]');
form.addEventListener('submit', async (e) => {
e.preventDefault();
submitBtn.disabled = true;
submitBtn.textContent = 'Subscribing...';
errorEl.style.display = 'none';
errorEl.textContent = '';
try {
const formData = new FormData(form);
formData.append('_subject', 'Newsletter Subscribe - Scott Scoble');
const response = await fetch('https://formsubmit.co/ajax/scott@scoble.me', {
method: 'POST',
body: formData,
});
const result = await response.json();
if (!response.ok || result.success === 'false' || !result.success) {
throw new Error(result.message || 'Subscription failed. Please try again.');
}
form.style.display = 'none';
successEl.style.display = '';
} catch (err) {
errorEl.textContent = err.message || 'Something went wrong. Please try again.';
errorEl.style.display = '';
submitBtn.disabled = false;
submitBtn.textContent = 'Subscribe →';
}
});
}
</script>
<style>
.newsletter-block {
text-align: center;
@ -93,78 +41,28 @@ const {
.newsletter-form {
display: flex;
flex-direction: column;
align-items: center;
gap: var(--space-sm);
max-width: 28rem;
max-width: 24rem;
margin: 0 auto;
}
.newsletter-form-inline {
display: flex;
gap: 0.5rem;
width: 100%;
max-width: 400px;
}
.newsletter-form-inline input[type="email"] {
.newsletter-form input {
flex: 1;
padding: 0.75rem 1rem;
border: 1px solid var(--color-border);
border-radius: 6px;
font-size: 1rem;
font-family: inherit;
border-radius: 4px;
font-family: var(--font-body);
font-size: var(--size-base);
}
.newsletter-form-inline input[type="email"]:focus {
.newsletter-form input:focus {
outline: none;
border-color: var(--color-green);
box-shadow: 0 0 0 2px rgba(61, 90, 62, 0.2);
}
.newsletter-form-inline .btn {
white-space: nowrap;
}
.newsletter-note {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0;
}
.newsletter-note a {
color: var(--color-green);
font-weight: 500;
}
.newsletter-success {
text-align: center;
padding: 1.5rem;
background: var(--color-green);
color: white;
border-radius: 8px;
}
.newsletter-success p {
color: white;
margin: 0;
}
.newsletter-error {
background: #dc2626;
color: white;
padding: 0.75rem;
border-radius: 4px;
font-size: 0.9375rem;
width: 100%;
box-shadow: 0 0 0 3px rgba(61, 90, 62, 0.15);
}
@media (max-width: 639px) {
.newsletter-block {
padding: var(--space-2xl) var(--space-md);
}
.newsletter-form-inline {
.newsletter-form {
flex-direction: column;
}
}

View file

@ -37,36 +37,7 @@ function getJsonLd(pageType: string): string {
sameAs: [
'https://linkedin.com/in/scottscoble',
'https://x.com/scottscoble',
'https://github.com/wscoble',
'https://www.amazon.com/stores/Scott-Scoble/author/B0GKSSBDMK',
],
knowsAbout: ['AI leadership', 'human cultivation', 'engineering teams', 'formal specifications', 'provenance systems'],
knowsLanguage: ['en'],
memberOf: [
{
'@type': 'Organization',
name: 'Greybeard Holdings, LLC',
},
],
owns: [
{
'@type': 'SoftwareSourceCode',
name: 'Speckl',
description: 'A state machine specification language compiler producing auditable code with embedded provenance',
url: 'https://speckl.scoble.me',
},
{
'@type': 'SoftwareSourceCode',
name: 'ScobleClaw',
description: 'Agentic engineering framework for building with AI agents',
url: 'https://os.scoble.me/forgejo/sscoble/scobleclaw',
},
{
'@type': 'CreativeWork',
name: 'Beyond the Prompt',
description: 'Workshop presentation on Skills and Subagents for AI-assisted development',
url: 'https://os.scoble.me/forgejo/sscoble/beyond-the-prompt',
},
'https://github.com/sscoble',
],
};
@ -79,120 +50,11 @@ function getJsonLd(pageType: string): string {
description: 'Human Cultivation Expert for the AI Age',
url: siteUrl,
};
const speakableSchema = {
'@context': 'https://schema.org',
'@type': 'SpeakableSpecification',
cssSelector: ['h1', '.hero p', '.hero-description'],
};
return JSON.stringify([personLd, websiteLd, speakableSchema], null, 2);
}
case 'blog': {
const blogSchema = {
'@context': 'https://schema.org',
'@type': 'Blog',
'@id': `${siteUrl}#blog`,
name: 'Scott Scoble Blog',
description: 'Articles and essays by Scott Scoble on AI leadership, team cultivation, developer experience, and the human side of technology.',
url: `${siteUrl}/blog`,
author: {
'@type': 'Person',
name: 'Scott Scoble',
url: siteUrl,
},
blogPost: [
{
'@type': 'BlogPosting',
headline: 'Why Cultivation Over Strip Mining',
description: 'Gallup 2026: 80% of the global workforce is disengaged. The $438B cost is not a tool problem; it is a people problem.',
url: `${siteUrl}/blog/strip-mining-cultivation`,
datePublished: '2026-05-18',
author: { '@type': 'Person', name: 'Scott Scoble' },
},
{
'@type': 'BlogPosting',
headline: '50 First Dates with AI',
description: "Every conversation with most AI systems is a first date. Here's the three-layer memory model that actually compounds.",
url: `${siteUrl}/blog/50-first-dates-with-ai`,
datePublished: '2026-05-24',
author: { '@type': 'Person', name: 'Scott Scoble' },
},
{
'@type': 'BlogPosting',
headline: 'The Soil Under Your Team',
description: "Tall stalks, ground cover, nitrogen fixers, pollinators, deep roots. Here's how to read the soil under your team.",
url: `${siteUrl}/blog/soil-health-teams`,
datePublished: '2026-05-18',
author: { '@type': 'Person', name: 'Scott Scoble' },
},
{
'@type': 'BlogPosting',
headline: 'The Soil Beneath the Code is Out',
description: 'A three-layer framework for understanding what makes engineering organizations healthy — or not.',
url: `${siteUrl}/blog/the-soil-beneath-the-code`,
datePublished: '2026-04-28',
author: { '@type': 'Person', name: 'Scott Scoble' },
},
],
};
return JSON.stringify([personLd, blogSchema], null, 2);
return JSON.stringify([personLd, websiteLd], null, 2);
}
case 'speaking':
// Event schemas for each signature talk
const talks = [
{
name: '50 First Dates with AI',
description: 'Current AI memory architecture is anterograde amnesia — and we\'re all Henry Roth, recording VHS tapes every night so our agent can wake up functional tomorrow.',
url: `${siteUrl}/speaking/50-first-dates`,
},
{
name: 'From Strip-Mining to Cultivation',
description: 'The shift from extraction to cultivation in AI-era teams. Why throughput optimization is killing your soil health.',
url: `${siteUrl}/speaking/strip-mining-to-cultivation`,
},
{
name: 'The Soil Under Your Team',
description: 'Diagnose what\'s actually depleted before you fertilize. A diagnostic framework for team health in AI-augmented work.',
url: `${siteUrl}/speaking/soil-under-your-team`,
},
];
const eventSchemas = talks.map((talk) => ({
'@context': 'https://schema.org',
'@type': 'Event',
name: talk.name,
description: talk.description,
url: talk.url,
performer: {
'@type': 'Person',
name: 'Scott Scoble',
jobTitle: 'Keynote Speaker',
url: siteUrl,
},
offers: {
'@type': 'Offer',
availability: 'https://schema.org/InStock',
availabilityStarts: '2026-01-01',
},
eventStatus: 'https://schema.org/EventScheduled',
eventAttendanceMode: 'https://schema.org/OfflineEventAttendanceMode',
organizer: {
'@type': 'Person',
name: 'Scott Scoble',
url: siteUrl,
},
}));
// SpeakableSpecification for voice search
const speakableSchema = {
'@context': 'https://schema.org',
'@type': 'SpeakableSpecification',
cssSelector: ['h1', '.hero p'],
};
const speakerSchema = {
'@context': 'https://schema.org',
return JSON.stringify({
'@type': 'Person',
'@id': `${siteUrl}#speaker`,
name: 'Scott Scoble',
@ -200,39 +62,30 @@ function getJsonLd(pageType: string): string {
description: 'Human Cultivation Expert speaking on AI, leadership, and team cultivation',
url: siteUrl,
sameAs: personLd.sameAs,
};
return JSON.stringify([speakerSchema, speakableSchema, ...eventSchemas], null, 2);
}, null, 2);
case 'books':
return JSON.stringify([
{
'@context': 'https://schema.org',
'@type': 'Book',
name: 'The Soil Beneath the Code',
author: {
'@type': 'Person',
name: 'Scott Scoble',
url: siteUrl,
},
author: 'Scott Scoble',
datePublished: '2023',
bookFormat: 'https://schema.org/EBook',
description: 'What engineering teams can learn from farmers about sustainable systems. A cultivation playbook for technical leaders who are tired of strip-mining their teams.',
sameAs: 'https://a.co/d/0226o4Hg',
bookFormat: 'EBook, Hardcover',
},
{
'@context': 'https://schema.org',
'@type': 'Book',
name: 'A Walk in Mentoring',
author: {
'@type': 'Person',
name: 'Scott Scoble',
url: siteUrl,
},
author: 'Scott Scoble',
datePublished: '2024',
bookFormat: 'https://schema.org/EBook',
description: 'Three questions that change how people learn. The simplest mentoring framework you\'ll actually use.',
sameAs: 'https://a.co/d/0bRKZeUV',
bookFormat: 'EBook, Paperback',
},
{
'@type': 'Book',
name: 'Dark Provenance',
author: 'Scott Scoble',
datePublished: '2026',
bookFormat: 'EBook, Hardcover',
},
], null, 2);
@ -306,9 +159,6 @@ const jsonLd = getJsonLd(pageType);
<!-- Canonical -->
<link rel="canonical" href={pageUrl} />
<!-- LLM / AI Crawler Context -->
<meta name="llms:description" content="Scott Scoble is a keynote speaker, consultant, and author of The Soil Beneath the Code. Expertise: human cultivation in AI-era engineering teams, agentic memory architecture, developer experience, mentoring. NOT Robert Scoble (different person — Robert is the tech evangelist @Scobleizer; Scott is the cultivation speaker at scott.scoble.me)." />
<!-- JSON-LD Structured Data -->
<script type="application/ld+json" set:html={jsonLd} />

View file

@ -8,7 +8,7 @@ export interface Props {
slug?: string;
}
const { title, premise, takeaways, audience, slug } = Astro.props;
const { title, premise, takeaways, audience } = Astro.props;
---
<article class="talk-card card">
@ -24,15 +24,9 @@ const { title, premise, takeaways, audience, slug } = Astro.props;
</div>
)}
{audience && audience.trim() && (
<div class="talk-audience">
<span class="talk-label">Ideal Audience:</span> {audience}
</div>
)}
{slug && (
<a href={slug} class="talk-link">Learn more →</a>
)}
<div class="talk-audience">
<span class="talk-label">Ideal Audience:</span> {audience}
</div>
</article>
<style>
@ -85,16 +79,4 @@ const { title, premise, takeaways, audience, slug } = Astro.props;
font-weight: 600;
color: var(--color-brown);
}
.talk-link {
display: inline-block;
margin-top: var(--space-md);
color: var(--color-green);
text-decoration: none;
font-weight: 500;
}
.talk-link:hover {
text-decoration: underline;
}
</style>

View file

@ -0,0 +1,69 @@
---
// TestimonialCard.astro — Placeholder testimonial card
export interface Props {
quote: string;
name: string;
role: string;
organization?: string;
}
const { quote, name, role, organization } = Astro.props;
---
<figure class="testimonial-card card">
<blockquote>
<p>&ldquo;{quote}&rdquo;</p>
</blockquote>
<figcaption>
<strong>{name}</strong>
<span>{role}{organization ? `, ${organization}` : ''}</span>
</figcaption>
</figure>
<style>
.testimonial-card {
text-align: left;
}
.testimonial-card blockquote {
border: none;
padding: 0;
margin: 0 0 var(--space-md);
background: none;
font-style: normal;
}
.testimonial-card blockquote p {
font-size: var(--size-sm);
line-height: 1.7;
color: var(--color-text);
position: relative;
}
.testimonial-card blockquote p::before {
content: '"';
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-amber);
position: absolute;
top: -0.25em;
left: -0.5em;
}
.testimonial-card figcaption {
border-top: 1px solid var(--color-border-light);
padding-top: var(--space-md);
}
.testimonial-card figcaption strong {
display: block;
font-size: var(--size-sm);
color: var(--color-brown);
}
.testimonial-card figcaption span {
display: block;
font-size: var(--size-xs);
color: var(--color-text-muted);
}
</style>

View file

@ -17,7 +17,7 @@ export interface Props {
const {
title,
description,
ogImage = '/images/hero-speaker-new.webp',
ogImage = '/social-card.png',
ogType = 'website',
canonicalUrl,
pageType = 'home',
@ -50,7 +50,7 @@ const currentPath = canonicalUrl || Astro.url.pathname;
/>
<!-- Umami Analytics -->
<script defer src="https://a.scoble.me/umami/script.js" data-website-id="4a23c88a-5397-4bac-a830-074c6aca7108"></script>
<script defer src="https://os.scoble.me/umami/script.js" data-website-id="4a23c88a-5397-4bac-a830-074c6aca7108"></script>
<!-- RSS -->
<link rel="alternate" type="application/rss+xml" title="Scott Scoble Blog" href="/rss.xml" />
@ -110,4 +110,4 @@ const currentPath = canonicalUrl || Astro.url.pathname;
--size-4xl: 3rem;
}
</style>
<!-- CI/CD test: 2026-04-28T21:06:42-07:00 -->

View file

@ -4,393 +4,129 @@ import BaseLayout from '../layouts/BaseLayout.astro';
<BaseLayout
title="Page Not Found — Scott Scoble"
description="That page doesn't exist. Let's get you back on track."
description="That page doesn't exist."
pageType="home"
>
<section class="error-page">
<div class="error-content">
<span class="error-code" aria-hidden="true">404</span>
<h1>This path is fallow ground</h1>
<p class="error-subtitle">
Not every link leads to cultivated soil. This one hit a patch of
<span class="accent-text">strip-mined earth</span> — nothing grows here.
But the good news: the rest of the site is deep, fertile, and ready to explore.
</p>
<!-- Site Search -->
<div class="search-section">
<form class="search-form" action="https://duckduckgo.com/" method="GET" target="_blank" rel="noopener">
<label for="search-input" class="sr-only">Search scott.scoble.me</label>
<div class="search-wrapper">
<svg class="search-icon" width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true">
<circle cx="11" cy="11" r="8"></circle>
<line x1="21" y1="21" x2="16.65" y2="16.65"></line>
</svg>
<input
id="search-input"
class="search-input"
type="search"
name="q"
placeholder="Search the site…"
autocomplete="off"
aria-label="Search scott.scoble.me"
/>
<input type="hidden" name="sites" value="scott.scoble.me" />
</div>
<button type="submit" class="search-btn">Search</button>
</form>
<p class="search-hint">Try searching for what you need, or pick a path below.</p>
</div>
<!-- Suggested Pages -->
<span class="error-code">404</span>
<h1>Page not found</h1>
<p>That link doesn't lead anywhere. Maybe it moved, maybe it never existed.</p>
<div class="suggested-links">
<h3>Popular Paths</h3>
<h3>Explore the site</h3>
<ul>
<li>
<a href="/speaking">
<span class="link-icon" aria-hidden="true">🎤</span>
<span class="link-text">
<strong>Speaking</strong>
<span class="link-desc">Book Scott for your next event</span>
</span>
</a>
</li>
<li>
<a href="/consulting">
<span class="link-icon" aria-hidden="true">🌱</span>
<span class="link-text">
<strong>Consulting</strong>
<span class="link-desc">AI team cultivation &amp; strategy</span>
</span>
</a>
</li>
<li>
<a href="/about">
<span class="link-icon" aria-hidden="true">🧑‍🌾</span>
<span class="link-text">
<strong>About</strong>
<span class="link-desc">Scott's story &amp; approach</span>
</span>
</a>
</li>
<li>
<a href="/books">
<span class="link-icon" aria-hidden="true">📖</span>
<span class="link-text">
<strong>Books</strong>
<span class="link-desc">Publications &amp; writing</span>
</span>
</a>
</li>
<li>
<a href="/blog">
<span class="link-icon" aria-hidden="true">✍️</span>
<span class="link-text">
<strong>Blog</strong>
<span class="link-desc">Essays on AI, leadership &amp; cultivation</span>
</span>
</a>
</li>
<li>
<a href="/contact">
<span class="link-icon" aria-hidden="true">📬</span>
<span class="link-text">
<strong>Contact</strong>
<span class="link-desc">Get in touch directly</span>
</span>
</a>
</li>
<li><a href="/speaking">Book Scott for Your Event</a></li>
<li><a href="/consulting">AI Team Consulting</a></li>
<li><a href="/books">Books &amp; Publications</a></li>
<li><a href="/about">About Scott</a></li>
</ul>
</div>
<div class="error-footer">
<a href="/" class="btn-home">← Back to the soil</a>
<p class="error-footnote">Even the most cultivated land has a fallow season. You're just in one now.</p>
</div>
<p>Can't find what you're looking for? <a href="/contact">Get in touch</a> — I'll get back to you.</p>
<a href="/" class="btn-home">← Go home</a>
</div>
</section>
</BaseLayout>
<style>
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border-width: 0;
}
.error-page {
min-height: 80vh;
min-height: 70vh;
display: flex;
align-items: center;
justify-content: center;
text-align: center;
padding: 8rem 2rem 6rem;
padding: 6rem 2rem;
background: var(--color-cream);
}
.error-content {
max-width: 600px;
margin: 0 auto;
}
.error-code {
display: block;
font-family: var(--font-heading);
font-size: 8rem;
font-size: 6rem;
font-weight: 700;
color: var(--color-amber);
opacity: 0.15;
opacity: 0.3;
line-height: 1;
margin-bottom: 0.5rem;
user-select: none;
margin-bottom: 1rem;
}
.error-content h1 {
font-family: var(--font-heading);
font-size: clamp(1.75rem, 4vw, 2.25rem);
font-size: 2rem;
color: var(--color-brown-dark);
margin: 0 0 1.25rem;
line-height: 1.2;
margin: 0 0 1rem;
}
.error-subtitle {
.error-content p {
color: var(--color-text-muted);
margin: 0 0 2rem;
line-height: 1.7;
font-size: 1.05rem;
line-height: 1.6;
}
.accent-text {
color: var(--color-green);
font-style: italic;
}
/* --- Search Section --- */
.search-section {
margin-bottom: 2.5rem;
}
.search-form {
display: flex;
gap: 0.5rem;
max-width: 480px;
margin: 0 auto;
}
.search-wrapper {
flex: 1;
position: relative;
display: flex;
align-items: center;
}
.search-icon {
position: absolute;
left: 0.875rem;
top: 50%;
transform: translateY(-50%);
color: var(--color-text-muted);
opacity: 0.5;
pointer-events: none;
}
.search-input {
width: 100%;
padding: 0.75rem 1rem 0.75rem 2.75rem;
border: 2px solid var(--color-border);
border-radius: 8px;
font-size: 0.9375rem;
font-family: var(--font-body);
color: var(--color-text);
background: white;
transition: border-color 0.2s ease, box-shadow 0.2s ease;
-webkit-appearance: none;
appearance: none;
}
.search-input:focus {
outline: none;
border-color: var(--color-green);
box-shadow: 0 0 0 3px rgba(61, 90, 62, 0.12);
}
.search-input::placeholder {
color: var(--color-text-muted);
opacity: 0.6;
}
.search-btn {
background: var(--color-green);
color: white;
padding: 0.75rem 1.25rem;
border: none;
border-radius: 8px;
font-size: 0.9375rem;
font-weight: 600;
cursor: pointer;
white-space: nowrap;
transition: background 0.2s ease, transform 0.15s ease;
}
.search-btn:hover {
background: var(--color-green-dark);
transform: translateY(-1px);
}
.search-btn:active {
transform: translateY(0);
}
.search-hint {
font-size: 0.8125rem;
color: var(--color-text-muted);
opacity: 0.7;
margin: 0.75rem 0 0;
}
/* --- Suggested Links --- */
.suggested-links {
text-align: left;
background: white;
padding: 1.5rem 1.75rem;
border-radius: 10px;
padding: 2rem;
border-radius: 8px;
border: 1px solid var(--color-border);
margin-bottom: 2rem;
margin: 0 0 1.5rem;
}
.suggested-links h3 {
font-size: 0.8rem;
font-size: 0.875rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.12em;
letter-spacing: 0.1em;
color: var(--color-text-muted);
margin: 0 0 1rem;
padding-bottom: 0.75rem;
border-bottom: 1px solid var(--color-border-light);
}
.suggested-links ul {
list-style: none;
padding: 0;
margin: 0;
display: grid;
grid-template-columns: 1fr 1fr;
gap: 0.5rem;
}
.suggested-links li {
margin: 0;
margin-bottom: 0.75rem;
}
.suggested-links a {
display: flex;
align-items: flex-start;
gap: 0.625rem;
padding: 0.625rem 0.75rem;
color: var(--color-brown);
color: var(--color-green);
text-decoration: none;
border-radius: 6px;
transition: background 0.15s ease, color 0.15s ease;
font-weight: 500;
}
.suggested-links a:hover {
background: var(--color-cream);
text-decoration: underline;
}
.error-content a {
color: var(--color-green);
}
.link-icon {
flex-shrink: 0;
font-size: 1.125rem;
line-height: 1.4;
}
.link-text {
display: flex;
flex-direction: column;
line-height: 1.3;
}
.link-text strong {
font-size: 0.9375rem;
font-weight: 600;
color: inherit;
}
.link-desc {
font-size: 0.75rem;
color: var(--color-text-muted);
line-height: 1.3;
margin-top: 0.125rem;
}
.suggested-links a:hover .link-desc {
color: var(--color-text-muted);
}
/* --- Footer --- */
.error-footer {
margin-top: 2rem;
}
.btn-home {
display: inline-block;
background: var(--color-amber);
color: white;
padding: 0.75rem 1.75rem;
border-radius: 8px;
padding: 0.75rem 1.5rem;
border-radius: 6px;
text-decoration: none;
font-weight: 600;
font-size: 0.9375rem;
transition: all 0.2s ease;
}
.btn-home:hover {
background: var(--color-amber-light);
transform: translateY(-1px);
box-shadow: 0 4px 12px rgba(200, 149, 46, 0.25);
}
.error-footnote {
font-style: italic;
font-size: 0.875rem;
color: var(--color-text-muted);
opacity: 0.6;
margin: 1.25rem 0 0;
line-height: 1.5;
}
/* --- Responsive --- */
@media (max-width: 600px) {
.error-page {
padding: 6rem 1.25rem 4rem;
}
.error-code {
font-size: 5rem;
}
.search-form {
flex-direction: column;
}
.search-btn {
width: 100%;
}
.suggested-links ul {
grid-template-columns: 1fr;
}
.suggested-links {
padding: 1.25rem;
}
}
</style>

View file

@ -20,7 +20,7 @@ import BaseLayout from '../layouts/BaseLayout.astro';
<p class="bio-lead">
Scott Scoble is a builder, writer, and speaker focused on the human side of AI systems.
He's the author of <em>The Soil Beneath the Code</em> and <em>A Walk in Mentoring</em>,
and creator of Speckl — a compile-time provenance layer for regulated industries.
and creator of Speckl — a dark provenance system for agentic engineering.
He advises engineering leaders on how to build AI systems that cultivate human capability
instead of strip-mining it.
</p>
@ -45,9 +45,8 @@ import BaseLayout from '../layouts/BaseLayout.astro';
</div>
</div>
<!-- Photo silhouette placeholder -- hidden until a real headshot is available -->
<div class="photo-placeholder" style="display: none;">
<img src="/images/photo-silhouette.svg" alt="Scott Scoble" width="400" height="500" class="photo-silhouette" loading="lazy" />
<div class="photo-placeholder">
<p>📷 Photo coming soon</p>
</div>
</div>
</section>
@ -70,31 +69,11 @@ import BaseLayout from '../layouts/BaseLayout.astro';
<p>Three questions that change how people learn.</p>
</article>
</div>
</div>
</section>
<section class="projects-section">
<div class="section-container">
<h2>Projects</h2>
<div class="projects-grid">
<article class="project-card">
<h3><a href="https://speckl.scoble.me">Speckl</a></h3>
<p>A state machine specification language compiler that produces auditable code with embedded provenance. Compiles SpeckDL to TypeScript, Z3 SMT verification, and compliance artifacts (PROV-O, CycloneDX, SPDX). Fulfills NIST SA-11.</p>
<article class="book-card">
<h3>Dark Provenance</h3>
<p class="book-status">Coming 2026</p>
<p>Formal verification for the AI age. How to audit what your AI actually did.</p>
</article>
<article class="project-card">
<h3>ScobleClaw</h3>
<p class="project-visibility">Private</p>
<p>Agentic engineering framework — tools, workflows, and skills for building with AI agents. Patterns for subagent dispatch, skill-based development, and provenance tracking.</p>
</article>
<article class="project-card">
<h3>Beyond the Prompt</h3>
<p>Workshop presentation on using Skills and Subagents to guide AI-assisted development, demonstrated through practical architecture decisions. Built with Reveal.js and Nix flakes.</p>
</article>
</div>
</div>
</section>
@ -104,7 +83,7 @@ import BaseLayout from '../layouts/BaseLayout.astro';
<style>
.hero {
background: var(--color-cream);
padding: 12rem 2rem 6rem;
padding: 4rem 2rem;
text-align: center;
}
@ -127,7 +106,7 @@ import BaseLayout from '../layouts/BaseLayout.astro';
.bio-section .section-container {
display: grid;
grid-template-columns: 1fr 300px;
grid-template-columns: 2fr 1fr;
gap: 3rem;
align-items: start;
}
@ -182,16 +161,15 @@ import BaseLayout from '../layouts/BaseLayout.astro';
.photo-placeholder {
background: var(--color-cream-warm);
border-radius: 12px;
padding: 1rem;
border-radius: 8px;
padding: 4rem 2rem;
text-align: center;
color: var(--color-text-muted);
}
.photo-silhouette {
max-width: 100%;
height: auto;
border-radius: 8px;
.photo-placeholder p {
font-size: 1.25rem;
margin: 0;
}
.books-section {
@ -240,69 +218,4 @@ import BaseLayout from '../layouts/BaseLayout.astro';
color: var(--color-text-muted);
line-height: 1.6;
}
.projects-section {
background: white;
}
.projects-section h2 {
font-family: var(--font-heading);
font-size: 2rem;
text-align: center;
margin: 0 0 2rem;
color: var(--color-brown-dark);
}
.projects-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
gap: 2rem;
}
.project-card {
background: var(--color-cream);
padding: 2rem;
border-radius: 8px;
border: 1px solid var(--color-border);
transition: transform 0.2s ease, box-shadow 0.2s ease;
}
.project-card:hover {
transform: translateY(-2px);
box-shadow: 0 4px 12px rgba(0,0,0,0.08);
}
.project-card h3 {
font-family: var(--font-heading);
font-size: 1.25rem;
margin: 0 0 0.75rem;
}
.project-card h3 a {
color: var(--color-brown-dark);
text-decoration: none;
}
.project-card h3 a:hover {
color: var(--color-amber);
}
.project-card p {
margin: 0;
color: var(--color-text-muted);
line-height: 1.6;
}
.project-visibility {
display: inline-block;
font-size: 0.75rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.08em;
color: var(--color-amber);
background: var(--color-cream-warm);
padding: 0.15rem 0.6rem;
border-radius: 3px;
margin-bottom: 0.5rem;
}
</style>

View file

@ -1,16 +1,15 @@
---
import BaseLayout from '../layouts/BaseLayout.astro';
import NewsletterSignup from '../components/NewsletterSignup.astro';
---
<BaseLayout
title="Blog — Scott Scoble"
description="Articles and essays by Scott Scoble on AI, leadership, team cultivation, developer experience, and the human side of technology."
pageType="blog"
title="Blog - Scott Scoble"
description="Articles on AI, leadership, cultivation, and the human side of technology."
>
<section class="hero">
<div class="hero-content">
<p class="hero-kicker">Writing</p>
<h1>Blog</h1>
<p class="hero-description">
Articles on AI, leadership, cultivation, and the human side of technology.
@ -21,221 +20,13 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
<section class="posts">
<div class="posts-container">
<article class="post-card">
<a href="/blog/human-in-the-loop-seam" class="post-link">
<div class="post-meta">
<span class="post-date">July 8, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>The Human-in-the-Loop Seam: Where Humans Belong in a Dark Factory</h2>
<p class="post-excerpt">
Human-in-the-loop is a phrase everyone uses. Almost nobody uses it correctly. The seam is in the spec, not in the implementation.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/the-taste-problem" class="post-link">
<div class="post-meta">
<span class="post-date">June 29, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>The Taste Problem: What Dark Factories Can't Transfer</h2>
<p class="post-excerpt">
A dark factory can transfer code. It cannot transfer the judgment that knew the code was right. That is the problem provenance was invented to solve.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/operator-patterns-for-software-factories" class="post-link">
<div class="post-meta">
<span class="post-date">June 19, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>Kubernetes Operator Patterns for Software Factories</h2>
<p class="post-excerpt">
An operator is a control loop with a domain in it. That is the whole definition. Here are the four operator patterns and the one anti-pattern to avoid.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/why-kubernetes-for-dark-factory" class="post-link">
<div class="post-meta">
<span class="post-date">June 11, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>Why Kubernetes for a Dark Factory</h2>
<p class="post-excerpt">
A dark factory is a control loop. Kubernetes is the most boring control loop in production. That is the reason.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/light-vs-dark-factories" class="post-link">
<div class="post-meta">
<span class="post-date">June 2, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>Light vs Dark Factories: Why the Middle Is Harder Than Either End</h2>
<p class="post-excerpt">
A light factory has too many gates. A dark factory has too few. The middle is where the engineering happens, and the middle is the part nobody talks about.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/50-first-dates-with-ai" class="post-link">
<div class="post-meta">
<span class="post-date">May 24, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>50 First Dates with AI: Why Your AI Forgets Everything and What to Do About It</h2>
<p class="post-excerpt">
Every conversation with most AI systems is a first date. Here's the three-layer memory model that actually compounds — from Scott Scoble's scobleclaw experience.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/spec-first-audit-surface" class="post-link">
<div class="post-meta">
<span class="post-date">May 24, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>Spec-First Development Is the Only Audit Surface for AI-Generated Code</h2>
<p class="post-excerpt">
Every software project has specifications, and every specification eventually lies. The spec-code gap is a provenance problem — and Speckl closes it by making the spec compile into code, so the gap never opens.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/open-source-projects" class="post-link">
<div class="post-meta">
<span class="post-date">May 23, 2026</span>
<span class="post-tag">Open Source</span>
</div>
<h2>My Open Source Projects: Speckl, ScobleClaw, and Beyond the Prompt</h2>
<p class="post-excerpt">
A roundup of Scott Scoble's open-source projects — Speckl (spec compiler with provenance), ScobleClaw (agentic engineering framework), and Beyond the Prompt (workshop on building with AI agents).
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/prove-sqlite" class="post-link">
<div class="post-meta">
<span class="post-date">May 23, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>We're Going to Formally Verify SQLite</h2>
<p class="post-excerpt">
SQLite runs on every smartphone, every browser, every embedded system. Its core state machines have never been formally verified. Following the Kafka proof, we're tackling the most deployed database in history with SpeckDL and Z3 bounded model checking.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/what-is-a-dark-factory" class="post-link">
<div class="post-meta">
<span class="post-date">May 22, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>What a Dark Factory Actually Is (and Isn't)</h2>
<p class="post-excerpt">
The phrase is everywhere. The working meaning is gone. Here is what it is, what it isn't, and the five positions on the spectrum.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/strip-mining-cultivation" class="post-link">
<div class="post-meta">
<span class="post-date">May 18, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h2>Stop Strip-Mining Your Engineers: The Cultivation Alternative to Throughput Obsession</h2>
<p class="post-excerpt">
Gallup 2026: 80% of the global workforce is disengaged. The $438B cost isn't a tool problem; it's a people problem. Here's the cultivation alternative.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/soil-health-teams" class="post-link">
<div class="post-meta">
<span class="post-date">May 18, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h2>Soil Health for Teams: A Diagnostic Framework for What's Actually Depleted</h2>
<p class="post-excerpt">
Tall stalks, ground cover, nitrogen fixers, pollinators, deep roots. The agricultural metaphor isn't poetic; it's diagnostic. Here's how to read the soil under your team.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/30-years-software" class="post-link">
<div class="post-meta">
<span class="post-date">May 18, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>From QA to Principal: What 30 Years of Software Teaches You About Humans</h2>
<p class="post-excerpt">
I started writing code in 1985. I started getting paid for it in 1996. The tech stacks changed; the human patterns didn't. Here's what three decades teaches you when you pay attention to the people, not just the code.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/ai-has-amnesia" class="post-link">
<div class="post-meta">
<span class="post-date">May 18, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>Your AI Has Amnesia: Why Memory Architecture Is the Hardest Problem in Agentic Systems</h2>
<p class="post-excerpt">
The anterograde amnesia metaphor for AI memory architecture. Three-layer memory model for agentic systems from Scott Scoble's scobleclaw experience.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/agentic-wars" class="post-link">
<div class="post-meta">
<span class="post-date">May 8, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>You're Already in the Agentic Wars</h2>
<p class="post-excerpt">
Meta has Hatch. Google has Remy. Everyone is building agents. Whose capability compounds?
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/token-anxiety" class="post-link">
<div class="post-meta">
<span class="post-date">May 4, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>The Token Anxiety Trap; Why AI Agents Aren't Liberating Us (Yet)</h2>
<p class="post-excerpt">
Your agent swarm runs 24/7 and you're more anxious than ever. Stanford's 2026 AI Index shows a 20% drop in junior dev employment since 2024. The agent revolution promised freedom — instead it gave us token anxiety and a new kind of burnout.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/ai-brain-fry" class="post-link">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>What Does AI Brain Fry Really Mean?</h2>
<h2>AI Brain Fry Is a Workforce Crisis, Not a Productivity Story</h2>
<p class="post-excerpt">
Gallup says 80% of the workforce is disengaged. The heaviest AI users are burning out fastest. The fix isn't training - it's structural.
</p>
@ -263,7 +54,7 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
</div>
<h2>80% of Your Team Is Disengaged. It's Not Their Fault.</h2>
<p class="post-excerpt">
Gallup says 80% of the global workforce is disengaged. The $100B+ engagement industry has failed for 20 years. The fix isn't perks or surveys; it's structural.
Gallup says 80% of the global workforce is disengaged. The $100B+ engagement industry has failed for 20 years. The fix isn't perks or surveys &mdash; it's structural.
</p>
</a>
</article>
@ -274,7 +65,7 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>The Developer Experience Shift; Why Tooling Alone Won't Save You</h2>
<h2>The Developer Experience Shift &mdash; And Why Tooling Alone Won't Save You</h2>
<p class="post-excerpt">
Companies will spend $60B+ on developer tools in 2026. But the real DevEx crisis isn't tooling — it's autonomy, mastery, and belonging. As code production becomes commoditized, the human dimensions of engineering become the only competitive advantage that matters.
</p>
@ -282,54 +73,59 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
</article>
<article class="post-card">
<a href="/blog/three-questions-mentoring" class="post-link">
<a href="/blog/token-anxiety" class="post-link">
<div class="post-meta">
<span class="post-date">April 28, 2026</span>
<span class="post-tag">Leadership</span>
<span class="post-date">May 4, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>Three Questions That Changed How I Mentor</h2>
<h2>The Token Anxiety Trap &mdash; Why AI Agents Aren't Liberating Us (Yet)</h2>
<p class="post-excerpt">
The simple mentoring framework that actually gets used - three questions that unlock real growth.
Your agent swarm runs 24/7 and you're more anxious than ever. Stanford's 2026 AI Index shows a 20% drop in junior dev employment since 2024. The agent revolution promised freedom — instead it gave us token anxiety and a new kind of burnout.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/strip-mining-signs" class="post-link">
<div class="post-meta">
<span class="post-date">April 28, 2026</span>
<span class="post-tag">Teams</span>
</div>
<h2>Three Signs Your Team Is Being Strip-Mined</h2>
<p class="post-excerpt">
The mindset shift that separates thriving teams from burned-out ones - cultivation over extraction.
</p>
</a>
<div class="post-meta">
<span class="post-date">April 28, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h2>Three Questions That Changed How I Mentor</h2>
<p class="post-excerpt">
The simple mentoring framework that actually gets used - three questions that unlock real growth.
</p>
</article>
<article class="post-card">
<a href="/blog/the-soil-beneath-the-code" class="post-link">
<div class="post-meta">
<span class="post-date">April 28, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>The Soil Beneath The Code</h2>
<p class="post-excerpt">
A three-layer framework for understanding what makes engineering organizations healthy - or not.
</p>
</a>
<div class="post-meta">
<span class="post-date">April 28, 2026</span>
<span class="post-tag">Teams</span>
</div>
<h2>Three Signs Your Team Is Being Strip-Mined</h2>
<p class="post-excerpt">
The mindset shift that separates thriving teams from burned-out ones - cultivation over extraction.
</p>
</article>
<article class="post-card">
<div class="post-meta">
<span class="post-date">April 28, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>The Soil Beneath The Code</h2>
<p class="post-excerpt">
A three-layer framework for understanding what makes engineering organizations healthy - or not.
</p>
</article>
</div>
</section>
<NewsletterSignup title="Stay Cultivated" description="New articles on AI, leadership, and cultivation. No spam. No AI-generated content. Just the soil report." />
</BaseLayout>
<style>
.hero {
padding: 12rem 2rem 6rem;
padding: 8rem 2rem 4rem;
text-align: center;
background: var(--color-cream);
}

View file

@ -1,264 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
import NewsletterSignup from '../../components/NewsletterSignup.astro';
---
<BaseLayout
title="From QA to Principal: What 30 Years of Software Teaches You About Humans"
description="Scott Scoble's 30-year software career arc from QA to principal engineer. The human patterns that repeat regardless of tech stack."
ogType="article"
canonicalUrl="/blog/30-years-software"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 18, 2026</span>
<span class="article-tag">Engineering</span>
</div>
<h1>From QA to Principal: What 30 Years of Software Teaches You About Humans</h1>
<p class="article-subtitle">
I started writing code in 1985. I started getting paid for it in 1996. The tech stacks changed; the human patterns didn't. Here's what three decades teaches you when you pay attention to the people, not just the code.
</p>
</header>
<div class="article-body">
<p>I started writing code in 1985.</p>
<p>I was twelve, on a Commodore 64, copying BASIC programs out of magazines and wondering why changing one line made the whole thing stop working. The screen was green. The storage was a cassette tape. The concept of "the cloud" would have sounded like science fiction.</p>
<p>I started getting paid for it in 1996.</p>
<p>That first paycheck felt like a mistake. Someone was going to give me money to do what I did for free on weekends? The answer, I learned, was yes — but only because what I did for free on weekends turned out to be rarer than I thought. Not the coding; the caring. The willingness to sit with a broken system until you understood why it broke.</p>
<p>Thirty years later, the tools have changed beyond recognition. The human patterns haven't.</p>
<h2>The Arc</h2>
<p>My career didn't follow a ladder. It followed a river — meandering, sometimes doubling back, occasionally plunging through rapids I didn't choose.</p>
<p>I started in QA. Not because I planned to; because that's where there was an opening. I learned something important there that engineers who skip QA never learn: the difference between "it works" and "it's correct." Working is observable; correctness requires thinking about what isn't there. Edge cases, failure modes, the user's actual intent versus the spec's assumed intent.</p>
<p>From QA I moved into development, then into architecture, then into the fuzzy space where technical decisions and organizational decisions become the same thing. The title that eventually stuck was "principal engineer," but the work was never about the title. It was about the pattern: seeing systems, human and technical, whole enough to make choices that don't solve today's problem at tomorrow's expense.</p>
<p>Along the way I built things that shipped and things that didn't. I worked on teams that hummed and teams that imploded. I learned Nix, Kubernetes, compliance-as-code, and a dozen other technologies that will sound dated by the time you read this. And I kept noticing that the successes and failures had less to do with the stack than with the soil underneath it.</p>
<h2>What Doesn't Change</h2>
<p>Here are the human patterns that repeat regardless of whether you're writing COBOL or Rust, deploying to mainframes or serverless edge functions:</p>
<p><strong>People optimize for what gets measured.</strong></p>
<p>This is the oldest pattern in software and the hardest to escape. You measure velocity, you get fast code that breaks in production. You measure test coverage, you get tests that cover lines but not intent. You measure commits, you get small meaningless changes that game the metric.</p>
<p>I've watched this pattern destroy quality in every decade. The fix isn't better metrics; it's better judgment about which metrics matter and the courage to ignore the ones that don't. That's a people problem, not a tooling problem.</p>
<p><strong>Complexity is a loan with compounding interest.</strong></p>
<p>Every shortcut, every abstraction leak, every "we'll fix this later" is a loan. The interest rate is higher than you think, and it compounds. I've inherited systems where the technical debt was so deep that adding a simple feature required touching fourteen files in seven services. The original authors weren't stupid; they were under pressure. The pressure won.</p>
<p>What I've learned: the teams that survive are the ones where someone has the authority and the stubbornness to say no to complexity before it becomes structural. Usually that person is unpopular until everyone else realizes they were right.</p>
<p><strong>Communication bandwidth is the real bottleneck.</strong></p>
<p>Not CPU. Not network. Not database throughput. The limit on every project I've ever worked on was how fast the right information got to the right person.</p>
<p>A requirement misunderstood for three weeks is more expensive than a slow query. An architectural decision made in isolation and reversed two months later is more expensive than a server outage. A team that doesn't know what the adjacent team is building is more expensive than any technical constraint.</p>
<p>The senior engineers I respect most aren't the fastest coders. They're the ones who know when to stop coding and start talking.</p>
<p><strong>Authority without accountability corrupts; accountability without authority paralyzes.</strong></p>
<p>I've been in organizations where engineers had no say in what they built. I've been in organizations where they had say but no ownership of the result. Both are broken in different directions.</p>
<p>The healthiest teams I've worked on had clear authority boundaries and clear accountability. You owned this; you decided that; you were responsible for the outcome. Ambiguity in either direction created the politics that technical people pretend to hate but are actually terrible at.</p>
<p><strong>The best engineers are gardeners, not builders.</strong></p>
<p>This took me years to see. The engineers who leave lasting value don't just write code; they cultivate the conditions for other people to write better code. They clean up the codebase incrementally. They write the documentation that saves the next person six hours. They refactor the module that everyone else is afraid to touch.</p>
<p>This work is invisible in sprint reviews. It shows up in velocity six months later when the team is suddenly moving faster and nobody can point to why. The engineer who did it is usually working on something else by then.</p>
<h2>Beyond the Prompt</h2>
<p>Lately I've been working on AI systems — not using them, but thinking about how to build with them. The <code>beyond-the-prompt</code> repo is my attempt to treat AI skills as software modules: composable, testable, versioned.</p>
<p>What I've learned there connects back to everything else. The prompt is the interface, but the architecture is what determines whether the system works. Context management is memory. Evaluation is quality assurance. Progressive disclosure is user experience design.</p>
<p>The tools are new; the patterns are ancient. Every generation of technologists thinks they're the first to face integration complexity, context management, or the gap between what the user asked for and what they actually need. We're not. We're just using different vocabulary.</p>
<p>The containerless work — deploying Nix closures instead of containers — is another example. The specific technology (Nix, Kubernetes, registries) is 2020s. The underlying question (how do we package and deploy software reliably?) is 1960s. The human challenge (getting teams to change how they work) is timeless.</p>
<h2>What I Got Wrong</h2>
<p>Thirty years includes a lot of wrong turns. Here are some I can name:</p>
<p>I once optimized a system for performance metrics that turned out to matter to no actual user. The numbers were beautiful; the experience was worse. I learned that metrics require validation against reality, not just internal consistency.</p>
<p>I once pushed a technical decision through despite team resistance because I was convinced I was right. I was right about the technology and wrong about the timing. The implementation worked; the adoption failed. I learned that correctness without timing is incomplete.</p>
<p>I once stayed too long in a role because the title was flattering and the work was familiar. I stopped growing; I started extracting. I learned that the best signal it's time to leave is when you can do the job without thinking.</p>
<p>I once believed that better tools would solve organizational problems. They don't. Tools amplify existing patterns. Healthy organizations get healthier with good tools; dysfunctional ones get more efficiently dysfunctional.</p>
<h2>What I Still Believe</h2>
<p>Despite the wrong turns, some convictions have deepened:</p>
<p>Software is a team sport played by people who often wish it wasn't. The best code I've written was improved by someone else's eyes. The worst code I've written was written alone, late at night, under pressure.</p>
<p>The user is not stupid; the user is busy. Every interface that assumes user stupidity is actually hiding designer laziness. Every system that requires the user to "just" do something complex is pushing cost onto the wrong side of the boundary.</p>
<p>Technical debt is a moral problem, not just a technical one. When we leave messes for others to clean, we're choosing our convenience over their time. The codebase is a shared space; leaving it worse than you found it is a small act of extraction.</p>
<p>Learning compounds. The engineer who reads broadly — outside software, outside their specialty — makes connections that the narrowly focused engineer can't. The domain knowledge, the historical context, the adjacent discipline: these aren't distractions. They're the nutrients.</p>
<h2>The Stack Is Temporary; the Patterns Are Permanent</h2>
<p>If you're early in your career, here's what I'd tell you: don't chase the stack. Chase the patterns.</p>
<p>The frameworks you're learning today will be obsolete in a decade. The cloud provider you're certifying on will change its API, its pricing model, its entire approach. The language that's hot now will be legacy or dead in fifteen years.</p>
<p>But the patterns — how complexity grows, how communication breaks down, how authority and accountability need to match, how good work is invisible and bad work is loud — these don't change. Learn them once and you'll recognize them in every new technology.</p>
<p>The senior engineer's real job isn't knowing more syntax. It's seeing the pattern earlier and naming it clearly enough that others can see it too.</p>
<h2>Still Walking</h2>
<p>I'm not done. The Nix work, the AI skills, the multi-agent system, the book, the talks — these aren't a retirement portfolio. They're the current crop. The soil underneath them is thirty years of patterns, failures, and the occasional insight that held up longer than I expected.</p>
<p>The technology will keep changing. The human patterns will keep repeating. The work is to notice which is which, and to cultivate the conditions where good work can grow regardless of what stack it happens in.</p>
<p>That's what thirty years teaches you. Not how to code better; how to see more clearly. The code is just the medium.</p>
</div>
<footer class="article-footer">
<div class="article-cta">
<p>Want to continue this conversation? <a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener">Connect with me on LinkedIn</a> — I write about the human side of AI and what to do about it.</p>
</div>
</footer>
</article>
<NewsletterSignup />
</BaseLayout>
<style>
.article {
padding: 12rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-brown-dark);
margin: 2.5rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.article-body code {
background: var(--color-gray-100);
padding: 0.125rem 0.375rem;
border-radius: 4px;
font-size: 0.9em;
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.article-cta {
text-align: center;
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.article-cta a {
color: var(--color-green);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -1,216 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
import NewsletterSignup from '../../components/NewsletterSignup.astro';
---
<BaseLayout
title="50 First Dates with AI: Why Your AI Forgets Everything and What to Do About It"
description="Current AI memory architecture is anterograde amnesia — every session is a first date. Here's the three-layer memory model that actually compounds, from Scott Scoble's scobleclaw experience."
ogType="article"
canonicalUrl="/blog/50-first-dates-with-ai"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 24, 2026</span>
<span class="post-tag">AI</span>
</div>
<h1>50 First Dates with AI: Why Your AI Forgets Everything and What to Do About It</h1>
<p class="post-subtitle">
Every conversation with most AI systems is a first date. You explain your codebase. You define your conventions. You correct the same misunderstanding three times. And when you come back tomorrow, it's 2004 again — Drew Barrymore wakes up with no memory of who you are.
</p>
</header>
<div class="post-content">
<p>That's anterograde amnesia. The brain can't form new long-term memories. Every interaction is fresh. Everything you've built together — the corrections, the preferences, the evolving understanding of your domain — evaporates when the session ends.</p>
<p>I built a talk around this metaphor: <em>50 First Dates with AI</em>. The response was immediate because the problem is universal. Everyone who's used an AI assistant for real work has felt the frustration. Everyone who's tried to build an agentic system has hit the wall.</p>
<p>The wall is memory architecture. And it's the hardest problem in agentic systems because it's not a single problem; it's three problems stacked on top of each other, each pretending to be the other.</p>
<h2>The 50 First Dates Problem</h2>
<p>In the movie <em>50 First Dates</em>, Drew Barrymore's character Lucy has anterograde amnesia. Every morning she wakes up and yesterday never happened. Her family adapts by leaving her notes, updating a whiteboard, re-explaining the same things every day. It's loving; it's also exhausting.</p>
<p>This is exactly how most AI systems work. They record VHS tapes (context windows) every night and hope the agent can reconstruct enough context to be functional the next morning. The context window is the whiteboard. The system prompt is the morning briefing. And every single day, it's groundhog day.</p>
<p>We built agentic systems with anterograde amnesia — not because we couldn't do better, but because it was easier than building systems that actually learn. Session-based memory is simple. It doesn't require state management, storage decisions, or curation. It just resets.</p>
<p>But resetting is not remembering. And remembering is what makes systems compound.</p>
<h2>The Three-Layer Memory Model</h2>
<p>I've been running scobleclaw — my multi-agent system — long enough to know that memory isn't a feature you add later. It's the foundation everything else sits on. Get it wrong and your agents are expensive interns who need retraining every morning. Get it right and they compound.</p>
<p>Here's the model that emerged from real operation, not from a whitepaper:</p>
<h3>Layer 1: Compound Memory (The Journal)</h3>
<p>This is the raw log of what happened. Every interaction, every decision, every correction, every output. Unstructured, chronological, append-only.</p>
<p>In scobleclaw, every agent interaction writes to a daily note. Not a database table; a markdown file. Why markdown? Because it's human-readable, because it survives format changes, because in 2030 I can still open it and understand what happened. The journal is for me as much as for the agents.</p>
<p>The key discipline with compound memory: write everything down, but don't expect the agents to read it raw. That's Layer 2's job.</p>
<h3>Layer 2: Semantic Recall (The Index)</h3>
<p>If the journal is a library, semantic recall is the card catalog. Not the books themselves; the <em>relationships</em> between ideas.</p>
<p>This is where embeddings and vector search come in. The journal gets chunked, embedded, and indexed so that when an agent asks "what have we said about mentoring frameworks?" it doesn't have to read six months of daily notes. It queries the index and gets the relevant passages.</p>
<p>But here's the trap: semantic recall without curation is just faster amnesia. You can retrieve more fragments, but you're still retrieving fragments. The index needs maintenance. It needs promotion (what matters enough to keep near the top). It needs decay (what's no longer relevant).</p>
<p>I run a nightly process — REM sleep, I call it — that scans the day's journal, identifies patterns, and promotes significant observations to long-term memory. Without this curation step, the index bloats. You get 500 "relevant" results for every query and none of them matter.</p>
<h3>Layer 3: Coach Evaluation (The Mirror)</h3>
<p>This is the layer almost nobody builds. It's also the one that makes the difference between a system that works and a system that learns.</p>
<p>Every agent in scobleclaw gets evaluated. Not by me directly — I don't have time to review every interaction — but by a coach agent that watches patterns over time. Did this agent complete what it said it would? Did it use the right tools? Did it match the human's voice when drafting content?</p>
<p>The coach writes evaluations back to the journal, which feeds the index, which influences future behavior. It's a feedback loop, but a slow one. The coach doesn't intervene in real time; it reflects after the fact. That's intentional. Real-time coaching is micromanagement. Post-hoc coaching is mentorship.</p>
<h2>Why Most Memory Solutions Fail</h2>
<p>You'd think memory is a solved problem. We have databases, vector stores, logging systems. Why is this still the bottleneck?</p>
<p><strong>Compound memory fails when it's not human-legible.</strong> Most systems store agent interactions as structured logs or database rows. The human can't read them without a query. When the human can't read them, the human can't correct them. When the human can't correct them, the system learns the wrong lessons.</p>
<p><strong>Semantic recall fails when it's not curated.</strong> Vector search is magical until it isn't. Without editorial judgment — what to promote, what to decay, what to connect — the index becomes a junk drawer. Every query returns 47 "relevant" fragments and the actual insight is fragment #38.</p>
<p><strong>Coach evaluation fails when there's no feedback loop.</strong> Evaluations that don't change behavior are performance reviews, not coaching. The coach has to write to the journal; the journal has to feed the index; the index has to influence future prompts. Any break in that chain and you have theater, not improvement.</p>
<h2>Building for Compounding, Not Resetting</h2>
<p>The goal isn't an AI that remembers everything. The goal is an AI where today's work makes tomorrow's work better.</p>
<p>That's compounding. And compounding requires memory that gets richer over time, not just bigger. Bigger is easy; richer is hard.</p>
<p>If you're building agentic systems, start here. Before you worry about tools, agents, workflows, or orchestration, ask: what does this system remember? How does it recall? How does it improve?</p>
<p>Get memory right and everything else gets easier. Get it wrong and you're dating Drew Barrymore forever.</p>
<hr />
<p><em>This article is adapted from Scott Scoble's keynote <a href="/speaking/50-first-dates">50 First Dates with AI</a>. Interested in having Scott deliver this talk at your event? <a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener">Connect on LinkedIn</a></em></p>
</div>
</article>
<NewsletterSignup title="Get the Soil Report" description="New articles on AI, leadership, and cultivation delivered to your inbox. No spam. No AI-generated content. Just the soil report." />
</BaseLayout>
<style>
.post {
padding: 12rem 2rem 6rem;
background: var(--color-cream);
}
.post-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.post-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.post-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.post-content {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.post-content h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.post-content h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-brown-dark);
margin: 2.5rem 0 0.75rem;
}
.post-content p {
margin: 0 0 1.25rem;
}
.post-content a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.post-content a:hover {
color: var(--color-green-dark);
}
.post-content strong {
color: var(--color-brown-dark);
}
.post-content em {
color: var(--color-text-muted);
}
.post-content hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 3rem 0;
}
@media (max-width: 640px) {
.post {
padding: 6rem 1.25rem 4rem;
}
.post-header h1 {
font-size: 1.75rem;
}
.post-content {
font-size: var(--size-base);
}
}
</style>

View file

@ -1,128 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="You're Already in the Agentic Wars"
description="Meta has Hatch. Google has Remy. Everyone is building agents. Whose capability compounds?"
ogType="article"
canonicalUrl="/blog/agentic-wars"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 8, 2026</span>
<span class="post-tag">AI</span>
</div>
<h1>You're Already in the Agentic Wars</h1>
</header>
<div class="post-content">
<p class="lead-question">Are you compounding your own capability, or someone else's?</p>
<p>Meta announced Hatch, a shopping agent for Instagram. Google unveiled Remy, a personal agent for Gemini. CNBC called it "the agentic wars." Everyone is building agents.</p>
<p>Hatch keeps you in Instagram. Remy keeps you in Gemini. Every prompt you type, every decision you delegate, every pattern the agent learns from you — all of it compounds for the platform, not for you. Their models get smarter. Their ad targeting gets sharper. Their lock-in gets deeper. You get more convenient.</p>
<blockquote>
<p>Convenience is not capability.</p>
</blockquote>
<h2>The Third Extraction Wave</h2>
<p>Cloud computing extracted your infrastructure — you stopped owning servers, they started renting them back to you. Social media extracted your attention — you stopped thinking for minutes, they started selling your eyeballs by the thousand. Now agents are extracting your decision patterns. Every time you use a hosted agent, you are training someone else's model on your judgment. Their capability compounds. Yours does not.</p>
<h2>The Decision Loop</h2>
<p>I run my own agent system. Chief of staff, engineering, compliance, research — every agent reports to me. The value is not in the agent's output. The value is in the decision loop: when an agent drafts something and I review it, I am forced to articulate what I actually think. That compounds my judgment, not a platform's.</p>
<p>The alternative is not complicated. Run your own agents. Keep your data. Inspect and modify the models. The open-source tools exist today — the company building Hatch literally called their product "OpenClaw-inspired," which tells you who is copying whom.</p>
<p>The agentic wars will produce two outcomes. People who own their agents and compound their own capability. And people who rent from platforms and wonder why they feel more productive but less capable every quarter.</p>
<p>So: are your capabilities compounding, or are you being extracted from?</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
line-height: 1.2;
margin: 0;
}
.post-content {
font-size: 1.125rem;
line-height: 1.8;
color: var(--color-text);
}
.post-content p {
margin: 0 0 1.5rem;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
letter-spacing: -0.01em;
}
.post-content blockquote {
border-left: 3px solid var(--color-amber);
padding: 1.25rem 1.5rem;
margin: 2rem 0;
background: var(--color-cream-warm);
font-style: italic;
font-size: 1.2rem;
line-height: 1.7;
}
.post-content blockquote p {
margin: 0;
}
.lead-question {
font-size: 1.15rem;
font-style: italic;
}
@media (max-width: 639px) {
.post {
padding: 5rem 1.25rem 3rem;
}
}
</style>

View file

@ -3,163 +3,333 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="I'm Exhausted. Your Brain Is Reconfiguring, Not Breaking."
description="Your brain is reconfiguring from intonation to orchestration. That hurts. That doesn't mean it's broken. Discomfort ≠ damage."
title="AI Brain Fry Is a Workforce Crisis, Not a Productivity Story — Scott Scoble"
description="Gallup's 2026 data: 80% of the global workforce is disengaged. The heaviest AI users are burning out fastest. The fix isn't training — it's structural."
ogType="article"
canonicalUrl="/blog/ai-brain-fry"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">AI</span>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">AI</span>
</div>
<h1>I'm Exhausted. Your Brain Is Reconfiguring, Not Breaking.</h1>
<h1>AI Brain Fry Is a Workforce Crisis, Not a Productivity Story</h1>
<p class="article-subtitle">
Gallup says 80% of the workforce is disengaged. The heaviest AI users are burning out fastest. The fix isn't training — it's structural.
</p>
</header>
<div class="post-content">
<p>I'm not the only one more exhausted at the end of a workday using AI than before; apparently there's a term for that now: Brain Fry.</p>
<div class="article-body">
<h2>The Data Nobody's Talking About</h2>
<p>
Gallup's 2026 State of the Global Workplace report is out, and the numbers are staggering: <strong>80% of the global workforce is disengaged</strong>. That's not a rounding error. That's 2.7 billion people showing up to work but not really <em>there</em>.
</p>
<p>
The cost? $438 billion in lost productivity annually.
</p>
<p>
But here's the part that should terrify every engineering leader: <strong>the heaviest AI users are the most disengaged</strong>. Not the least. The most.
</p>
<p>
A joint HBR/BCG study found that employees who use AI tools most intensively show <strong>39% higher error rates</strong> and <strong>39% higher quit intent</strong> than moderate users. The people who are "most productive" with AI are the ones burning out fastest, making the most mistakes, and heading for the door.
</p>
<p>
We told ourselves AI would free people for creative work. Instead, it's frying their brains.
</p>
<p>Makes sense. Your brain is reconfiguring from intonation to orchestration. That is a fundamental rewiring of how your mind spends its day. Of course it hurts.</p>
<h2>What AI Brain Fry Looks Like</h2>
<p>
I've been talking to engineers, designers, and product managers across the industry. The pattern is consistent:
</p>
<p>For years, your work was about producing; you held the tool, you shaped the thing, you felt the weight of it. Now the tool produces on its own and your job is to direct, to judge, to say yes or no from a distance.</p>
<h3>Cognitive fatigue masquerading as flow</h3>
<p>
An engineer using Copilot or Cursor generates 3x more code. But they're not <em>thinking</em> more. They're in a reactive loop — read the suggestion, evaluate it, accept or reject, repeat. After four hours, they can't remember why they made the architectural decisions they did. The code works. They have no idea if it's right.
</p>
<p>That hurts. That doesn't mean it's broken.</p>
<h3>Decision paralysis at scale</h3>
<p>
When an AI generates 10 viable options for every problem, the human brain does what it always does: it tries to optimize. Should I use the first suggestion or the third? This parameter or that one? Engineers report spending <em>more</em> time evaluating AI outputs than they used to spend writing the code themselves.
</p>
<p>Ask Arnold if he quit lifting because of discomfort.</p>
<h3>The authenticity crisis</h3>
<p>
A senior engineer at a Fortune 500 company told me: "I don't know if I'm a good engineer anymore. I just know I'm good at prompting." When your core skill becomes "evaluating machine output," your identity as a craftsperson erodes. And when identity erodes, engagement dies.
</p>
<p>Discomfort is not damage. A seed doesn't stay a seed. It cracks open, sends roots down, pushes a shoot up through the soil it used to be protected by. The cracking is painful. The soil used to be home. Now it's in the way. But the cracking is the point; it's not a malfunction, it's the mechanism.</p>
<h3>The extraction trap</h3>
<p>
Companies measure productivity in lines of code, story points closed, tickets completed. AI inflates all of these numbers. So companies hire fewer people, push the remaining people harder, and extract more output per human. The humans become cogs in a machine they no longer understand. Gallup calls it disengagement. I call it strip-mining with better dashboards.
</p>
<p>The problem is that most people sit in the discomfort instead of looking forward through it. The key word is <em>forward</em>; not ahead, not onward, but forward. Direction with momentum. When you're on the move, you move. One direction is a loop. The other is a ladder.</p>
<h2>Why "Just Train People" Isn't the Answer</h2>
<p>
The standard corporate response to AI disengagement is training. Upskill your workforce. Teach prompt engineering. Run workshops on "AI fluency."
</p>
<p>
This misses the point entirely.
</p>
<p>
The problem isn't that people don't know how to use AI. The problem is that <strong>AI is being deployed in ways that strip agency, not augment it.</strong>
</p>
<p>
When an AI suggests code and you accept it, you're not collaborating with a tool. You're being managed by an algorithm. The locus of control shifts from "I decided" to "I approved." Those are not the same thing, and the human brain knows it.
</p>
<p>
Training people to be better approvers doesn't restore agency. It just makes them more efficient cogs.
</p>
<p>Intonation is the craftsman's relationship to the tool: you hold it, you feel its resistance, you adjust by touch. That's what you're losing. The architect who used to know exactly where every load-bearing wall was because she drew them herself. The engineer who could feel when a codebase was getting brittle because he'd written every third file in it.</p>
<h2>The Cultivation Alternative</h2>
<p>
There's a different way to think about AI in the workplace. I call it <strong>cultivation over strip mining</strong>.
</p>
<p>
Strip mining extracts maximum value from the land and moves on. Cultivation builds soil. It takes longer. It looks less productive in quarterly reports. But it produces sustainable yields.
</p>
<p>
The same principle applies to human work:
</p>
<p>Orchestration is different. You don't play the instrument; you tell the orchestra what to play. You hear the result. You adjust. But your hands never touch the bow.</p>
<h3>Preserve the decision boundary</h3>
<p>
The most engaged engineers I know use AI for <em>exploration</em> — "show me 3 ways to solve this" — not for <em>execution</em>. They make the decision. The AI provides options. The human owns the choice. This preserves agency and prevents the cognitive fatigue of endless evaluation loops.
</p>
<p>The fatigue you're feeling is the gap between those two modes. Your brain is still trying to do both at once. It can't. That's the friction. That's the heat everyone calls brain fry.</p>
<h3>Measure judgment, not output</h3>
<p>
If your metrics are lines of code and story points, AI will look like a miracle and your humans will quietly disengage. If your metrics are architectural quality, system maintainability, and team learning velocity, the picture changes. Good judgment can't be faked by an LLM.
</p>
<p>But friction is not fire. Heat from formation is different from heat from burning. A blacksmith doesn't call the forge a problem; the forge is the point.</p>
<h3>Build for the human, not the machine</h3>
<p>
Every AI deployment should pass this test: does it make the human <em>more capable</em> or merely <em>more productive</em>? Capability compounds. Productivity extracts. The difference shows up in engagement scores within 6 months.
</p>
<p>Elijah called down fire from heaven. Then he prayed for death. The boldness and the cost arrived in the same chapter. That's what formation looks like when you're doing it right; the capacity expands and the exhaustion lands in the same breath. Most people stop at the exhaustion. They name it burnout, name it crisis, name it brain fry. They don't look forward through it to see what's forming on the other side.</p>
<h2>What I'm Doing About It</h2>
<p>
I'm building two things in parallel:
</p>
<p>What's forming is a different kind of mind. Not faster, not more productive. More selective. More directional. A mind that doesn't produce the answer but recognizes the right one when it sees it. That's not a downgrade. That's a promotion with harder work and a bigger view.</p>
<p>
<strong><a href="https://speckl.scoble.me">Speckl</a></strong> — a compliance specification language with embedded provenance. The core idea: AI generates the spec, but a human reviews and approves it <em>before</em> the compiler turns it into code. The human judgment is embedded as provenance — auditable, verifiable, part of the artifact. NIST SA-11 requires human oversight of automated outputs. Speckl makes that oversight a first-class citizen, not a checkbox.
</p>
<p>The most engaged engineers I know use AI for exploration, not execution. "Show me three ways to solve this" — not "write this function." They make the final call. The AI provides options. The human owns the choice.</p>
<p>
<strong>The Cultivation Consultancy</strong> — helping engineering leaders shift from extraction metrics to capability metrics. If your team is showing signs of AI brain fry — higher error rates, faster turnover, quieter standups — the fix isn't more training. It's a structural rethink of how AI and humans collaborate.
</p>
<p>This matters because the fatigue isn't from thinking harder. It's from the opposite: from evaluating without deciding, from reviewing without owning, from scrolling suggestions without choosing any of them. Endless evaluation loops are what drain you. The fix isn't to use AI less. The fix is to preserve the decision boundary.</p>
<h2>The Question for Leaders</h2>
<p>
If 80% of your workforce is disengaged, you don't have a productivity problem. You have a <em>meaning</em> problem. People need to feel that their judgment matters, that their decisions have consequences, and that they're building something they understand.
</p>
<p>
AI can be a tool for amplification or a tool for extraction. The difference is in the design choices you make today.
</p>
<p class="closing-question">
<strong>Are you cultivating your people, or strip-mining them?</strong>
</p>
<p>
The data is in. The answer shows up in your quarterly engagement survey — and in your attrition rate.
</p>
<p>If you're just approving code you didn't write and don't fully understand, you're not orchestrating. You're signing off. There's a difference. One is a conductor reading every part. The other is a rubber stamp.</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<p>If your metrics are lines of code and story points, AI looks like a miracle and you slowly disengage from the work that actually matters. If your metrics are architectural quality, system maintainability, and team learning velocity, the picture changes. Good judgment can't be faked by an LLM.</p>
<p>Judgment is the skill that compounds. Output is the thing that extracts. The difference shows up in engagement scores within six months. It shows up in retention within a year. It shows up in architecture quality within two.</p>
<p>The question every AI deployment should answer is simple: does it make the human more capable or merely more productive? Capability compounds. Productivity extracts. Strip-mining the soil yields a great harvest this season and a dead field the next.</p>
<p>This is not a call to slow down. Speed isn't the enemy; directionless speed is. A team with healthy soil ships faster because the structure holds, not in spite of it.</p>
<p>This also isn't about tooling. DevEx isn't about better editors or faster completions. DevEx is about whether anything actually gets used and whether the people using it are getting better or just getting faster. Who gives a crap about things that are never used.</p>
<p>And this definitely isn't about managing token costs. Token anxiety is a symptom of directionless work. If you optimize for outcomes, token cost is meaningless because the outcome is always more valuable. The only reason to worry about tokens is when you don't know what you're doing.</p>
<p>What this is about is a name for what's happening right now: <strong>fear-based development</strong>. Not anxiety, not stress. Fear. The word matters. Fear that you're being replaced. Fear that you're falling behind. Fear that the discomfort means you're broken. None of those are true. But naming the fear is how you stop letting it drive.</p>
<p>The story is that your mind is doing something it has never done before, and that hurts, and hurting while growing is different from hurting while dying.</p>
<p>Forward is the direction. Not ahead. Not onward. Forward.</p>
<p>That's what I've got. What's your take?</p>
<div class="cta-box">
<h3>Seeing AI brain fry on your team?</h3>
<p>
Higher error rates, faster turnover, quieter standups — I run a 90-minute workshop on shifting from extraction to cultivation metrics. No slides, just conversation.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.post {
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
margin: 0 auto 3rem;
text-align: center;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
.article-date {
color: var(--color-text-muted);
}
.post-tag {
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.post-header h1 {
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
margin: 0;
}
.post-content {
font-size: 1.125rem;
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.post-content p {
margin: 0 0 1.5rem;
}
.post-content h2 {
.article-body h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
letter-spacing: -0.01em;
margin: 3rem 0 1rem;
}
.post-content blockquote {
border-left: 3px solid var(--color-amber);
padding: 1.25rem 1.5rem;
margin: 2rem 0;
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-xl) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
font-style: italic;
font-size: 1.2rem;
line-height: 1.7;
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.post-content blockquote p {
margin: 0;
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.post-content ol {
margin: 0 0 1.5rem;
padding-left: 1.5rem;
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.post-content ol li {
margin-bottom: 1rem;
line-height: 1.7;
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.post-content ol li strong {
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
@media (max-width: 639px) {
.post {
padding: 5rem 1.25rem 3rem;
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0 0 1.5rem;
}
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
.cta-button:hover {
background: var(--color-amber-light);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -1,157 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="AI Exposes Leaders; The Cultivation Test"
description="AI doesn't just change work — it exposes what kind of leader you already were. The cultivation test: give your team AI tools and watch what happens."
ogType="article"
canonicalUrl="/blog/ai-exposes-leaders-cultivation-test"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 7, 2026</span>
<span class="post-tag">AI</span>
</div>
<h1>AI Exposes Leaders; The Cultivation Test</h1>
</header>
<div class="post-content">
<p class="lead-question">Give your team AI tools and watch what happens. What you see is who you already were.</p>
<p>AI does not create leadership. It exposes it.</p>
<p>This is the uncomfortable truth behind every enterprise AI rollout. The organizations that cultivated their people before the tools arrived are now watching their teams multiply in impact. The organizations that stripped them for short-term yield are watching the same tools accelerate a collapse they had already started.</p>
<p>AI is a cultivation test. And most leaders are failing it without even knowing they took it.</p>
<h2>The two experiments running in parallel right now</h2>
<p>Picture two engineering teams. Both receive access to the same coding assistant, the same documentation tool, the same automation platform.</p>
<p>Team A has a culture of trust, context-sharing, and psychological safety. Their senior engineers already spent time teaching juniors how to think about tradeoffs. When the AI tool arrives, the seniors use it to remove boilerplate so they can focus on architecture. The juniors use it to learn faster because they have mentors who help them interpret what the model generates. The team's output increases; their quality increases; their engagement increases.</p>
<p>Team B has a culture of output metrics, individual accountability, and implicit competition. Their senior engineers guard the interesting work. When the AI tool arrives, management sees an opportunity to reduce headcount. The seniors are told to "just review AI output." The juniors are given the model and expected to produce without support. Rework increases. Escalations increase. The seniors who remain are now editors of code they did not write, fixing mistakes they would never have made. Attrition follows.</p>
<p>Same tools. Opposite outcomes. The variable was never the AI.</p>
<h2>What the cultivation test reveals</h2>
<p>The cultivation test is simple. Give your team powerful tools and observe:</p>
<ul>
<li>Do they use them to amplify judgment, or to bypass it?</li>
<li>Do senior people become teachers, or do they become bottlenecks?</li>
<li>Does trust increase, or does surveillance increase?</li>
<li>Do your best people stay, or do they leave?</li>
</ul>
<p>The answers are not about the technology. They are about the culture that existed before the vendor showed up.</p>
<h2>Why this matters for your positioning</h2>
<p>If you are a leader right now, you are being tested. Not by a board presentation; not by a roadmap review. You are being tested by what your team does with the tools you just gave them.</p>
<p>If you cultivated them, AI is the multiplier you always wanted. Your institutional knowledge stays in the building. Your people get faster without getting shallow. Your senior engineers become force multipliers instead of human single points of failure.</p>
<p>If you strip-mined them, AI is an accelerant on a fire you started. The knowledge walked out months ago. The model is now generating answers no one in the room can verify. Your best people are interviewing elsewhere because they can see where this ends.</p>
<h2>This is the core argument of both my books</h2>
<p>In <em>The Soil Beneath the Code</em>, I write about the infrastructure of trust and context that makes engineering organizations durable. That soil is what determines whether AI helps you or hollows you.</p>
<p>In <em>A Walk in Mentoring</em>, I write about the specific practice of mentorship as the highest-leverage way to build that soil. It is not a soft skill. It is a competitive advantage that compounds faster than any technology you can buy.</p>
<p>Together, they frame the choice every leader is making right now; not whether to adopt AI, but whether your organization is the kind of place where AI adoption actually works.</p>
<h2>The challenge</h2>
<p>Here is the test. Do not wait for a consultant to tell you the answer. Look at your own team this week.</p>
<p>Watch what happens when a junior engineer uses a coding assistant. Do they have someone to ask "why did it suggest this?" Or are they flying blind?</p>
<p>Watch what happens when a senior engineer saves three hours with automation. Do they invest those hours in teaching? Or do they just pick up the next ticket?</p>
<p>Watch what happens when a model produces a plausible but wrong answer. Does someone in the room know enough to catch it? Or is the room already empty of that knowledge?</p>
<p>What you see is who you already were.</p>
<p>The good news: cultivation is a choice you can still make. The soil is not dead until you stop tending it.</p>
<p>The bad news: every quarter you keep stripping, the harder the replanting gets.</p>
<p>AI exposes leaders. The question is not what tool you bought. The question is what kind of leader the tool just revealed.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 4rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 2.75rem);
color: var(--color-brown-dark);
margin: 0;
line-height: 1.2;
}
.post-content p {
margin-bottom: 1.5rem;
line-height: 1.8;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.post-content ul {
margin-bottom: 1.5rem;
padding-left: 1.5rem;
line-height: 1.8;
}
.post-content li {
margin-bottom: 0.5rem;
}
.lead-question {
font-size: 1.15rem;
font-style: italic;
color: var(--color-text-muted);
border-left: 3px solid var(--color-amber);
padding-left: 1rem;
margin-bottom: 2rem !important;
}
</style>

View file

@ -1,230 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
import NewsletterSignup from '../../components/NewsletterSignup.astro';
---
<BaseLayout
title="Your AI Has Amnesia: Why Memory Architecture Is the Hardest Problem in Agentic Systems"
description="The anterograde amnesia metaphor for AI memory architecture. Three-layer memory model for agentic systems from Scott Scoble's scobleclaw experience."
ogType="article"
canonicalUrl="/blog/ai-has-amnesia"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 18, 2026</span>
<span class="post-tag">AI</span>
</div>
<h1>Your AI Has Amnesia: Why Memory Architecture Is the Hardest Problem in Agentic Systems</h1>
<p class="post-subtitle">
Anterograde amnesia is the perfect metaphor for how most AI systems "remember." Every session is a first date; every context window is a scrap of paper. Here's how to build memory that compounds.
</p>
</header>
<div class="post-content">
<p>Every conversation with most AI systems is a first date.</p>
<p>You explain your codebase. You define your conventions. You correct the same misunderstanding three times in a row. And when you come back tomorrow, it's 2004 again; Drew Barrymore wakes up with no memory of who you are.</p>
<p>That's anterograde amnesia. The brain can't form new long-term memories. Every interaction is fresh. Everything you've built together — the corrections, the preferences, the evolving understanding of your domain — evaporates when the session ends.</p>
<p>I built a talk around this metaphor: <em>50 First Dates with AI</em>. The response was immediate because the problem is universal. Everyone who's used an AI assistant for real work has felt the frustration. Everyone who's tried to build an agentic system has hit the wall.</p>
<p>The wall is memory architecture. And it's the hardest problem in agentic systems because it's not a single problem; it's three problems stacked on top of each other, each pretending to be the other.</p>
<h2>The Three-Layer Memory Model</h2>
<p>I've been running scobleclaw — my multi-agent system — long enough to know that memory isn't a feature you add later. It's the foundation everything else sits on. Get it wrong and your agents are expensive interns who need to be retrained every morning. Get it right and they compound.</p>
<p>Here's the model that emerged from real operation, not from a whitepaper:</p>
<h3>Layer 1: Compound Memory (The Journal)</h3>
<p>This is the raw log of what happened. Every interaction, every decision, every correction, every output. Unstructured, chronological, append-only.</p>
<p>The journal is where most systems start and where too many stop. They store chat history and call it memory. That's not memory; that's a transcript. Transcripts are useful but they don't <em>know</em> anything. They just record.</p>
<p>Compound memory becomes useful when it's searchable, when it's connected, when it starts to form patterns. The journal isn't the end state; it's the raw material.</p>
<p>In scobleclaw, every agent interaction writes to a daily note. Not a database table; a markdown file. Why markdown? Because it's human-readable, because it survives format changes, because in 2030 I can still open it and understand what happened. The journal is for me as much as for the agents.</p>
<p>The key discipline: write everything down, but don't expect the agents to read it raw. That's Layer 2's job.</p>
<h3>Layer 2: Semantic Recall (The Index)</h3>
<p>If the journal is a library, semantic recall is the card catalog. Not the books themselves; the <em>relationships</em> between ideas.</p>
<p>This is where embeddings and vector search come in. The journal gets chunked, embedded, and indexed so that when an agent asks "what have we said about mentoring frameworks?" it doesn't have to read six months of daily notes. It queries the index and gets the relevant passages.</p>
<p>But here's the trap: semantic recall without curation is just faster amnesia. You can retrieve more fragments, but you're still retrieving fragments. The index needs maintenance. It needs promotion (what matters enough to keep near the top). It needs decay (what's no longer relevant). It needs structure.</p>
<p>I run a nightly process — REM sleep, I call it — that scans the day's journal, identifies patterns, and promotes significant observations to long-term memory. The criteria aren't algorithmic perfection; they're signal-to-noise. What came up multiple times? What did the human correct? What decisions were made?</p>
<p>Without this curation step, the index bloats. You get 500 "relevant" results for every query and none of them matter. Semantic recall requires editorial judgment, and editorial judgment requires either a human or an agent trained by a human.</p>
<h3>Layer 3: Coach Evaluation (The Mirror)</h3>
<p>This is the layer almost nobody builds. It's also the one that makes the difference between a system that works and a system that learns.</p>
<p>Every agent in scobleclaw gets evaluated. Not by me directly — I don't have time to review every interaction — but by a coach agent that watches patterns over time. Did this agent complete what it said it would? Did it use the right tools? Did it match the human's voice when drafting content? Did it ask clarifying questions or just guess?</p>
<p>The coach writes evaluations back to the journal, which feeds the index, which influences future behavior. It's a feedback loop, but a slow one. The coach doesn't intervene in real time; it reflects after the fact. That's intentional. Real-time coaching is micromanagement. Post-hoc coaching is mentorship.</p>
<p>The metaphor here is a sports coach watching game film. Not yelling from the sidelines; reviewing what happened and identifying patterns the player can't see themselves. The agent gets better not because it's told what to do, but because it has access to an honest record of what it did.</p>
<h2>Why This Is Harder Than It Looks</h2>
<p>You'd think memory is a solved problem. We have databases, we have vector stores, we have logging systems. Why is this still the bottleneck?</p>
<p>Three reasons, each of which maps to the layers above:</p>
<p><strong>Compound memory fails when it's not human-legible.</strong> Most systems store agent interactions as structured logs or database rows. The human can't read them without a query. When the human can't read them, the human can't correct them. When the human can't correct them, the system learns the wrong lessons. Markdown daily notes are inefficient for machines; they're essential for humans.</p>
<p><strong>Semantic recall fails when it's not curated.</strong> Vector search is magical until it isn't. Without editorial judgment — what to promote, what to decay, what to connect — the index becomes a junk drawer. Every query returns 47 "relevant" fragments and the actual insight is fragment #38. Curation requires either human time or an agent trained to imitate human judgment. Both are expensive.</p>
<p><strong>Coach evaluation fails when there's no feedback loop.</strong> Evaluations that don't change behavior are performance reviews, not coaching. The coach has to write to the journal; the journal has to feed the index; the index has to influence future prompts. Any break in that chain and you have theater, not improvement.</p>
<h2>The 50 First Dates Problem</h2>
<p>Here's why the metaphor holds up. In the movie, Drew Barrymore's character can't form new memories. Her family adapts by leaving her notes, updating a whiteboard, re-explaining the same things every day. It's loving; it's also exhausting.</p>
<p>Most AI systems are like that family. They work around the amnesia instead of solving it. They stuff more context into the prompt. They maintain elaborate state machines. They build Rube Goldberg contraptions that <em>simulate</em> memory without actually having any.</p>
<p>The scobleclaw approach is different: accept that short-term memory (the context window) is tiny and expensive, so use it only for what's needed <em>right now</em>. Build compound memory for the record. Build semantic recall for retrieval. Build coach evaluation for improvement. Let each layer do what it's good at.</p>
<p>The result isn't perfect memory. It's <em>directional</em> memory. The system gets better at the things it does repeatedly. It recognizes patterns. It makes better guesses. It still makes mistakes, but the mistakes change. That's how you know it's learning.</p>
<h2>The Hardest Part</h2>
<p>The hardest part of memory architecture isn't technical. It's philosophical.</p>
<p>What do you choose to remember? What do you choose to forget? Who decides?</p>
<p>A system that remembers everything is as useless as a system that remembers nothing. The journal is comprehensive; the index is curated; the coach is selective. Each layer makes editorial decisions, and those decisions encode values.</p>
<p>I choose to remember corrections more than successes, because corrections contain more signal. I choose to forget ephemeral context (the weather today, the specific error message from last Tuesday) because it decays fast. I choose to promote patterns over events, because patterns generalize.</p>
<p>These aren't universal rules. They're my rules. Your system will need yours. The architecture is a framework for making those choices explicit, not for hiding them.</p>
<h2>Building for Compounding</h2>
<p>The goal isn't an AI that remembers everything. The goal is an AI where today's work makes tomorrow's work better.</p>
<p>That's compounding. And compounding requires memory that gets richer over time, not just bigger. Bigger is easy; richer is hard.</p>
<p>If you're building agentic systems, start here. Before you worry about tools, agents, workflows, or orchestration, ask: what does this system remember? How does it recall? How does it improve?</p>
<p>Get memory right and everything else gets easier. Get it wrong and you're dating Drew Barrymore forever.</p>
</div>
</article>
<NewsletterSignup />
</BaseLayout>
<style>
.post {
padding: 12rem 2rem 6rem;
background: var(--color-cream);
}
.post-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.post-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.post-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.post-content {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.post-content h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.post-content h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-brown-dark);
margin: 2.5rem 0 0.75rem;
}
.post-content p {
margin: 0 0 1.25rem;
}
.post-content a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.post-content a:hover {
color: var(--color-green-dark);
}
.post-content strong {
color: var(--color-brown-dark);
}
.post-content em {
color: var(--color-text-muted);
}
@media (max-width: 640px) {
.post {
padding: 6rem 1.25rem 4rem;
}
.post-header h1 {
font-size: 1.75rem;
}
.post-content {
font-size: var(--size-base);
}
}
</style>

View file

@ -3,151 +3,367 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The DevEx Shift; Adoption Is the Destination"
description="Who gives a crap about things that are never used."
title="The Developer Experience Shift — Scott Scoble"
description="$60B spent on developer tooling in 2026, but the real DevEx crisis isn't tools — it's autonomy, mastery, and belonging. As code production becomes commoditized, the human dimensions of engineering are the only competitive advantage that matters."
ogType="article"
canonicalUrl="/blog/devex-shift"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 23, 2026</span>
<span class="post-tag">Engineering</span>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">Engineering</span>
</div>
<h1>The DevEx Shift; Adoption Is the Destination</h1>
<h1>The Developer Experience Shift — And Why Tooling Alone Won't Save You</h1>
<p class="article-subtitle">
Companies will spend $60B+ on developer tools in 2026. But the real DevEx crisis isn't tooling — it's the creeping hollowing-out of engineers who produce on paper but have stopped caring in practice.
</p>
</header>
<div class="post-content">
<p>There's a conversation happening in engineering right now. People call it a DevEx shift. I don't have clean words for it yet. The ground is moving too fast; whatever I said six months ago is already stale.</p>
<div class="article-body">
<h2>The $60 Billion Bet That's Missing</h2>
<p>
Companies will spend over $60 billion on developer tools and platforms in 2026. Internal developer portals. AI coding assistants. Automated testing pipelines. Observability suites. Platform engineering teams with headcount bigger than most startups.
</p>
<p>
And yet — ask any engineering leader what keeps them up at night, and it's not "we need better tooling." It's retention. It's burnout. It's the creeping sense that their best engineers are productive on paper but hollowed out in practice.
</p>
<p>
We've conflated <strong>Developer Experience</strong> (DevEx) with <strong>Developer Tooling</strong>. They're not the same thing. And confusing them is costing organizations their most irreplaceable resource: engineers who actually care.
</p>
<p>But I know what it's not. It's not about tooling.</p>
<h2>When Tooling Becomes the Problem</h2>
<p>
Here's a story from one of my consulting conversations. A mid-size SaaS company — ~80 engineers — invested 18 months building an internal developer platform. Self-service infrastructure. Golden paths. One-click deploys. The metrics were beautiful: time-to-merge dropped 47%. Deployment frequency tripled.
</p>
<p>
Three months after the platform launched, their three most senior engineers quit. Within weeks of each other.
</p>
<p>
When I asked the CTO what happened, he showed me one of the exit interviews:
</p>
<blockquote>
<p>"The platform made everything easy. Too easy. I stopped thinking about infrastructure. I stopped understanding how things actually worked. I went from being an engineer to being a platform operator. I didn't sign up for that."</p>
</blockquote>
<p>
The platform worked. It worked so well that it abstracted away the craft these engineers loved. It optimized the friction out of their work — and the friction was where the meaning lived.
</p>
<p>Building the tool is the easy part. Deploying it is the easy part. None of that lands if nobody uses what you built.</p>
<h2>What DevEx Actually Means</h2>
<p>
Developer Experience isn't how fast your CI pipeline runs. It's not whether your documentation is searchable. It's not your incident response time.
</p>
<p class="closing-question">
<strong>Real DevEx is: Do my engineers end the day feeling like they built something that mattered — or like they fed a machine?</strong>
</p>
<p>
There are three dimensions that tooling can't address:
</p>
<p>Who gives a crap about things that are never used.</p>
<h3>1. Autonomy</h3>
<p>
The most corrosive force in engineering organizations is the gap between decision authority and decision impact. Engineers are asked to estimate, to implement, to maintain — but the decisions about what to build, how to prioritize, and whether to cut corners are made somewhere else.
</p>
<p>
AI coding assistants amplify this. When you're approving machine suggestions rather than designing solutions, you're not exercising autonomy. You're quality-controlling output. That's a different job — and for most engineers, a less fulfilling one.
</p>
<p>
<strong>The cultivation lens:</strong> Autonomy is soil health. You can't add it with a tool. You have to create conditions where it grows — where engineers own problems, not tickets.
</p>
<p>That question cuts clean through every conversation about DevEx. The beautiful internal portal. The golden path template nobody follows. The CI pipeline that shaves seconds off a build two teams know exists. All of it; irrelevant. Elegant architecture; irrelevant. If nobody uses it, it's not a platform. It's a monument. You built a thing and walked away. The organization routed around it before you finished the README.</p>
<h3>2. Mastery</h3>
<p>
Craftsmanship requires friction. The best engineers I've worked with talk about debugging like a detective solving a case. They describe refactoring like a woodworker restoring furniture. There's a satisfaction in understanding something deeply that shortcuts can't replicate.
</p>
<p>
When every problem has an AI-generated answer in milliseconds, the muscle of deep understanding atrophies. Engineers become faster at producing code but worse at reasoning about systems. They ship more and understand less.
</p>
<p>
This isn't an argument against AI tools. It's an argument against deploying them without also investing in the conditions for mastery: time for deep work, permission to explore without delivering, mentorship relationships that transmit judgment, not just knowledge.
</p>
<p>
<strong>The cultivation lens:</strong> Mastery is deep roots. It develops slowly, in soil that isn't constantly disturbed.
</p>
<p>Start at the destination: adoption. Work backward from there to what enables it. Start with the tool and work forward and you build monuments. I've seen it a hundred times. A team spends six months on an internal platform. They launch. They declare victory. Two quarters later somebody runs the analytics and the thing has three users. Two of them are the team that built it. That's not adoption. That's a memorial service for a product nobody asked for.</p>
<h3>3. Belonging</h3>
<p>
The most overlooked dimension of DevEx. Engineers who feel connected to their team, their mission, and their users perform better, stay longer, and produce higher-quality work. This is well-documented.
</p>
<p>
But belonging is fragile. It's eroded by things tooling can't fix: reorganization churn. Leadership whiplash. The slow realization that the company's "engineering culture" is a recruiting page and nothing more. The feeling that your work is being strip-mined for metrics while your value as a person is irrelevant.
</p>
<p>
I've talked about this in my other writing — <a href="/blog/gallup-disengagement">Gallup's finding that managers drive 70% of engagement variance</a>, the <a href="/blog/surveillance-extraction">surveillance extraction pipeline</a> that turns engineers into data points. Belonging is the human layer that sits below all of it.
</p>
<p>
<strong>The cultivation lens:</strong> Belonging is the ecosystem. It can't be engineered. It has to be tended.
</p>
<p>DevEx is shifting because engineering is shifting. Code production is being commoditized. Not replaced; commoditized. The work an engineer produces is worth less by the unit. What's worth more is what they decide: judgment, taste, knowing what not to build. That work doesn't fit in a ticket. Doesn't fit in a sprint. Doesn't fit in a metric.</p>
<h2>Why This Matters Now</h2>
<p>
We're at an inflection point where two forces are colliding:
</p>
<p>Most organizations never cross the gap between deploying and adopting. They deploy; they declare victory; the engineers route around whatever was built and keep doing what worked before. Nobody checks whether anything took root. Nobody knows what root looks like in this context. Root looks like an engineer choosing your thing when they have a choice. That's adoption. Everything before that is just installation.</p>
<h3>Force 1: AI is making code production cheaper than ever.</h3>
<p>
The raw output of software development — lines, commits, pull requests — is becoming commoditized. If your engineering organization's primary value proposition is "we produce code," you're about to be disrupted by a junior engineer with Cursor and a Claude subscription.
</p>
<p>Adoption is the only measure that matters in compliance-heavy environments. I know that because it's what I'm building for. Call it Speckl if you need a name. It's scaffolding for agentic engineering where the problem isn't generating code fast enough. The problem is whether you can ship it. Whether it passes audit. Whether anyone trusts it. If a compliance team won't sign off, adoption is zero. If an engineer has to copy-paste out of the tool to do their actual work, adoption is also zero. Adoption is binary. You cannot half-adopt a tool. You use it or you route around it. Routing around is the default state of the world. Getting someone to stop routing around is the work.</p>
<h3>Force 2: The things AI can't do are becoming more valuable.</h3>
<p>
System design judgment. Understanding users deeply enough to know what NOT to build. Mentoring and culture-building. Navigating organizational complexity. These are the skills that separate great engineering organizations from code factories. And they're all people skills.
</p>
<p>The first user is the hardest one to get. Most teams invest in the launch; not in that first user. They prepare the staging environment but not the person. They write onboarding docs but don't sit through the friction. The first user doesn't need documentation. They need someone who cares whether the tool makes their actual Tuesday better. Not their hypothetical Tuesday. This Tuesday. The one with the compliance deadline and the review backlog and the ticket three days overdue.</p>
<p>
The Developer Experience Shift isn't about better tools. It's about recognizing that <strong>as code production becomes commoditized, the human dimensions of engineering become the only competitive advantage that matters.</strong>
</p>
<p>Adoption is social. One engineer uses something; their life gets visibly better; others follow. But you have to get that one. You don't get that one by launching. You get that one by listening to what makes their Tuesday hard and building the thing that fixes exactly that. The Tuesday problem is always different from the deck problem. Always.</p>
<h2>The Leadership Test</h2>
<p>
Here are three questions for engineering leaders:
</p>
<p>The tool that gets adopted is rarely the best tool. It's the tool that solves the problem people actually have. If your engineers are drowning in compliance documentation, a tool that makes documentation faster gets adopted. If leadership bought a tool to measure productivity, it won't. The difference is whose problem it solves.</p>
<p class="closing-question">
<strong>1. If your best tooling disappeared tomorrow, would your engineering culture survive?</strong>
</p>
<p>
If the answer is no, you don't have a culture — you have a tool dependency.
</p>
<p>This is where I see most platform teams go wrong. They build for a problem they diagnosed from two levels up. They build for what leadership said was the problem. They build for what they wish engineers cared about. They don't build for the Tuesday problem. The Tuesday problem is always different from the deck problem. Always.</p>
<p class="closing-question">
<strong>2. Do your engineers have uninterrupted time to think?</strong>
</p>
<p>
Not "heads-down coding time" — actual thinking time. Whiteboard time. Reading-papers time. The kind of time that produces architectural insights, not just more pull requests.
</p>
<p>DevEx is shifting from what you provide to what gets picked up. Supply-side to demand-side. Pushing tools to cultivating conditions. The words are still forming. But the direction is clear: adoption is the destination. Everything else is the ground you prepare to get there.</p>
<p class="closing-question">
<strong>3. When was the last time an engineer on your team said no to a feature because they understood the user better than the product manager did?</strong>
</p>
<p>
If that hasn't happened recently, your engineers are implementers, not partners.
</p>
<p>I don't have a neat framework for this. A framework implies the thing is settled. It's not. But the question stands. Who gives a crap about things that are never used. If you think about DevEx, start there. Not at the tool. Not at the stack. At the moment a human being looks at what you built and decides whether to try it. That moment is everything. Nothing else matters until that moment goes the right way.</p>
<h2>The Bottom Line</h2>
<p>
The companies winning the DevEx game aren't the ones with the best developer portals. They're the ones where engineers feel like owners, not operators. Where autonomy, mastery, and belonging aren't HR values — they're daily experiences.
</p>
<p>
Tooling can remove friction. Only leadership can create meaning.
</p>
<p>
<strong>And meaning is the only DevEx metric that actually matters.</strong>
</p>
<p>The floor is open. What's your Tuesday look like.</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<div class="cta-box">
<h3>What's the DevEx initiative that missed the mark?</h3>
<p>
I'm collecting stories for a longer piece on what real Developer Experience looks like — the initiatives that worked and the ones that made things worse. DM me with your experience, or reach out if your team is wrestling with DevEx, autonomy, and meaning in an AI-augmented world.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.post {
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
margin: 0 auto 3rem;
text-align: center;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
.article-date {
color: var(--color-text-muted);
}
.post-tag {
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.post-header h1 {
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
margin: 0;
}
.post-content {
font-size: 1.125rem;
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.post-content p {
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.article-body blockquote {
border-left: 4px solid var(--color-amber);
margin: 1.5rem 0;
padding: 0.5rem 0 0.5rem 1.5rem;
color: var(--color-text-muted);
font-style: italic;
}
.article-body blockquote p {
margin: 0;
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-lg) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0 0 1.5rem;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
letter-spacing: -0.01em;
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
.post-content blockquote {
border-left: 3px solid var(--color-amber);
padding: 1.25rem 1.5rem;
margin: 2rem 0;
background: var(--color-cream-warm);
font-style: italic;
font-size: 1.2rem;
line-height: 1.7;
.cta-button:hover {
background: var(--color-amber-light);
}
.post-content blockquote p {
margin: 0;
}
.post-content .lead-quote {
font-size: 1.5rem;
font-style: normal;
font-weight: 500;
text-align: center;
border-left: none;
padding: 2rem 1.5rem;
margin: 2rem 0;
background: var(--color-brown-dark);
color: var(--color-cream);
border-radius: 6px;
}
.post-content .lead-quote p {
margin: 0;
}
@media (max-width: 639px) {
.post {
padding: 5rem 1.25rem 3rem;
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.post-content .lead-quote {
font-size: 1.25rem;
padding: 1.5rem 1rem;
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -3,179 +3,348 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Fear-Based Development — The Real Story Behind the Gallup Numbers"
description="Gallup says 80% of the workforce is disengaged. The numbers are real; the premise is wrong. It's not engagement that's missing; it's soil."
title="80% of Your Team Is Disengaged. It's Not Their Fault. — Scott Scoble"
description="Gallup's 2026 data: 80% of the global workforce is disengaged. The $100B+ engagement industry has failed for 20 years. The fix isn't perks — it's structural."
ogType="article"
canonicalUrl="/blog/gallup-disengagement"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 23, 2026</span>
<span class="post-tag">Leadership</span>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">Leadership</span>
</div>
<h1>Fear-Based Development</h1>
<h1>80% of Your Team Is Disengaged. It's Not Their Fault.</h1>
<p class="article-subtitle">
Gallup says 80% of the global workforce is disengaged. The $100B+ engagement industry has failed for 20 years. The fix isn't perks or surveys — it's structural.
</p>
</header>
<div class="post-content">
<div class="article-body">
<h2>The Number That Should Keep Every Leader Awake</h2>
<p>
Gallup dropped its 2026 State of the Global Workplace report last month. The headline: <strong>80% of the global workforce is disengaged.</strong> That's 2.7 billion people. Four out of five. Your team included.
</p>
<p>
The cost? <strong>$438 billion annually</strong> in lost productivity. But dollars don't capture what's actually happening. What's happening is that the vast majority of people spend most of their waking hours doing work they don't care about, for organizations they don't feel connected to, in systems that treat them as interchangeable.
</p>
<p>
This isn't a motivation problem. It's a leadership one.
</p>
<p>I'm not the only one more exhausted by the engagement industry than by the disengagement it claims to solve.</p>
<h2>The Engagement Industrial Complex</h2>
<p>
We've spent two decades trying to fix engagement with the wrong tools:
</p>
<p>Gallup says 80% of the global workforce isn't engaged. That number has barely budged in twenty years. The industry built around fixing it — surveys, perks, ping-pong tables, wellness programs — has spent billions. The number hasn't moved. The problem isn't execution. The problem is the premise.</p>
<h3>Surveys</h3>
<p>
Pulse this, quarterly that. Anonymous feedback forms that produce dashboards nobody acts on. The average time from survey results to meaningful action in most organizations? Infinity.
</p>
<p>The premise says employees need to be more engaged. The premise is wrong. They need to be less afraid.</p>
<h3>Perks</h3>
<p>
Ping-pong tables, snack bars, "wellness Wednesdays." Treating adults like children who need a juice box to focus. The message underneath: "Your work is so draining that we need to compensate with kombucha on tap."
</p>
<h2>What Fear Actually Does</h2>
<h3>"Purpose" exercises</h3>
<p>
Mission statements workshopped in offsites by people who will never talk to a customer. Values printed on walls that contradict what actually gets rewarded.
</p>
<p>Fear-based development. That's the name for what we're in.</p>
<p>
The engagement industry is a $100+ billion business that has, by its own measures, <strong>failed</strong>. Engagement has been flat or declining for twenty years. We're doing more engagement work than ever and getting worse results.
</p>
<p>
Maybe the problem isn't the execution. Maybe it's the premise.
</p>
<p>Not anxiety-driven engineering. Not burnout culture. Fear is a specific thing: the future is uncertain, the present is threatening, and you don't know which direction is safe. Survival optimization replaces outcome optimization. The body shifts into conservation mode. Everything else — creativity, ownership, candor — gets pruned because the environment no longer rewards those things.</p>
<h2>What Gallup Actually Found</h2>
<p>
Read past the headline numbers and the story gets sharper:
</p>
<p>Engineers who used to argue about architecture now say "whatever you think." They're not being agreeable; they're conserving energy. Caring costs something, and the environment stopped rewarding the cost.</p>
<h3>Managers drive 70% of engagement variance</h3>
<p>
Not perks. Not mission statements. Not hybrid vs. remote policy. The single biggest factor in whether someone cares about their work is whether their direct manager treats them like a person or a resource.
</p>
<p>Managers who used to protect their teams now relay directives. Protecting requires conviction; conviction requires believing there's something worth protecting. Fear erodes belief first.</p>
<h3>Disengagement is contagious</h3>
<p>
Disengaged managers produce disengaged teams. Gallup found that managers who feel burned out and disconnected transmit that state to their reports within weeks. Disengagement spreads through organizations like secondhand smoke.
</p>
<p>Standups that used to surface blockers now list tickets. The word "stuck" disappears. Nobody wants to be the one who's stuck when everyone's afraid of cuts.</p>
<h3>The AI acceleration effect</h3>
<p>
This is the part nobody's talking about. The heaviest AI users show the highest disengagement rates. Why? Because AI is being deployed to <em>extract more output from the same people</em>, not to make work more meaningful. When the technology that's supposed to free you for creative work instead makes you a prompt jockey monitoring machine output — and you're measured on throughput — engagement collapses.
</p>
<p>This is structural, not individual. You can't perk your way out of it. You can't survey your way out of it. The engagement industry has been treating symptoms for two decades while the soil erodes underneath.</p>
<h3>Disengagement is concentrated</h3>
<p>
It's not evenly distributed. Manufacturing, healthcare support, and tech rank among the worst. The common thread isn't industry — it's the degree to which work has been optimized for efficiency at the expense of autonomy, mastery, and purpose.
</p>
<h2>Soil Assessment</h2>
<h2>The Cultivation Alternative</h2>
<p>
I've been writing about what I call the <em>cultivation</em> approach to leadership — in <a href="/blog/surveillance-extraction">The Surveillance Dividend Is a Lie</a> and <a href="/blog/ai-brain-fry">AI Brain Fry Is a Workforce Crisis</a>. The metaphor matters: you don't "manage" soil. You cultivate it. You tend to conditions. You feed what feeds everything else.
</p>
<p>
Three shifts that actually move the needle:
</p>
<p>Soil that's been strip-mined doesn't need a better survey. It needs cultivation. Not management; cultivation. Tending conditions. Feeding what feeds everything else.</p>
<h3>1. From Extraction to Investment</h3>
<p>
Most organizations operate in extraction mode. They hire people, use their skills, burn through their energy, and replace them when they leave. The average tenure in tech is under two years. That's not a career. That's a rotation.
</p>
<p>
Ask yourself: <strong>What are you putting into your people that they'll still have after they leave?</strong> Not skills for your stack. Not tribal knowledge about your codebase. Real capital — judgment, taste, the ability to navigate ambiguity, a stronger professional identity than the one they arrived with.
</p>
<p>
If you can't answer that question, you're extracting, not cultivating.
</p>
<p>Strip-mining extracts value without putting anything back. That's what fear-based development does: it pulls output from people who are running on reserve, treats the reserve as capacity, and calls the eventual collapse a performance problem.</p>
<h3>2. From Measurement to Observation</h3>
<p>
Engagement surveys measure what's easy to count: satisfaction scores, likelihood-to-recommend, eNPS. But engagement isn't a survey result. It's observable behavior.
</p>
<p>
An engaged person stays after a meeting to work through an idea. They argue with you about the right approach. They notice something broken and fix it without being asked. They tell you the hard thing before it becomes a crisis.
</p>
<p>
You don't need a survey to see this. You need to pay attention. The most effective leaders I know don't run engagement surveys. They watch their people. They notice when a normally vocal engineer goes quiet. They notice when deadlines slip by a day instead of a week.
</p>
<p>
Observation costs nothing and requires no software. It just requires caring enough to look.
</p>
<p>Soil Assessment is the first question: is your team's soil being cultivated or extracted? The answer tells you what to do next. If it's being extracted, no engagement initiative will fix it. Stop extracting first. Then tend conditions.</p>
<h3>3. From Process to Trust</h3>
<p>
The default response to disengagement is more process: more check-ins, more standups, more tracking, more accountability structures. This makes everything worse.
</p>
<p>
Disengagement is often a rational response to being distrusted. When your calendar is managed in 15-minute blocks, your commits are monitored, your screen time is tracked, and your "productivity" is measured by a dashboard you've never seen — the message is clear: we don't trust you to do your job.
</p>
<p>
The alternative is harder and simpler: <strong>give people meaningful work, clear expectations, the resources to do it, and genuine autonomy in how they get there.</strong> Then get out of the way. Most people want to do good work. When they stop caring, it's usually because the environment made caring irrational.
</p>
<p>This isn't abstract. Cultivation looks like specific things: a leader who names the fear instead of pretending it isn't there. A direction, not just a diagnosis; fear needs something to walk toward, not just something to walk away from. The kind of conviction that costs something.</p>
<h2>The Leadership Test</h2>
<p>
Here's a question that separates cultivation leaders from extraction managers:
</p>
<p class="closing-question">
<strong>"Would your team show up differently tomorrow if you were gone?"</strong>
</p>
<p>
If the answer is "they'd be fine," you've built a self-sustaining system. People are engaged because the work matters, not because you're watching.
</p>
<p>
If the answer is "things would fall apart," you're not leading. You're holding things together with constant intervention. Your team stays because leaving is harder than staying — not because they want to be there.
</p>
<p>
The 80% number isn't just a statistic. It's a mirror. Every leader should look at it and ask: <strong>What am I doing that makes disengagement the rational choice for the people I'm responsible for?</strong>
</p>
<p>
Because here's the uncomfortable truth: <strong>people don't disengage from work they care about.</strong> They disengage from leaders and systems that have given them no reason to care.
</p>
<h2>Elijah</h2>
<p>Called down fire from heaven. Then prayed for death.</p>
<p>Not a contradiction; the price of that kind of leadership. Boldness on that scale costs something. Every leader anchoring a culture right now will feel both halves.</p>
<h2>Four Words</h2>
<div class="four-words">
<span class="hammer-word">Boldness.</span>
<span class="hammer-word">Faith.</span>
<span class="hammer-word">Purpose.</span>
<span class="hammer-word">Persistence.</span>
</div>
<p>No engagement survey gives you those. They come from somewhere else. They come from leaders willing to look at the fear, name it, and still walk forward.</p>
<p>Forward. Not ahead. Not onward. Forward: direction with momentum. The only direction that gets you out of fear-based development.</p>
<p>If you're leading right now and you feel like you're not enough for this moment: good. That's the starting place. The people who think they're enough for this are the dangerous ones.</p>
<p>You know what's happening on your team. You don't need a survey to tell you. The question isn't whether the soil is depleted; you already know that answer. The question is whether you'll stop extracting and start cultivating.</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<div class="cta-box">
<h3>Want to move past engagement surveys?</h3>
<p>
I speak on the cultivation approach to leadership — keynote-friendly, 30-45 min, data-backed, no platitudes. If your organization or conference is looking for something that actually changes how leaders show up, let's talk.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.post {
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
margin: 0 auto 3rem;
text-align: center;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
.article-date {
color: var(--color-text-muted);
}
.post-tag {
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.post-header h1 {
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
margin: 0;
}
.post-content {
font-size: 1.125rem;
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.post-content p {
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-xl) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0 0 1.5rem;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
letter-spacing: -0.01em;
}
.post-content blockquote {
border-left: 3px solid var(--color-amber);
padding: 1.25rem 1.5rem;
margin: 2rem 0;
background: var(--color-cream-warm);
font-style: italic;
font-size: 1.2rem;
line-height: 1.7;
}
.post-content blockquote p {
margin: 0;
}
.four-words {
display: flex;
flex-wrap: wrap;
gap: 1.5rem;
justify-content: center;
margin: 2.5rem 0;
padding: 2rem;
background: var(--color-brown-dark);
border-radius: 6px;
}
.hammer-word {
font-family: var(--font-heading);
font-size: 1.75rem;
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
color: var(--color-amber);
letter-spacing: 0.02em;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
@media (max-width: 639px) {
.post {
padding: 5rem 1.25rem 3rem;
.cta-button:hover {
background: var(--color-amber-light);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.four-words {
gap: 1rem;
.article-header h1 {
font-size: 1.75rem;
}
.hammer-word {
font-size: 1.4rem;
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -1,121 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Human-in-the-Loop Seam: Where Humans Belong in a Dark Factory"
description="Human-in-the-loop is a phrase everyone uses. Almost nobody uses it correctly. The seam is in the spec, not in the implementation."
ogType="article"
canonicalUrl="/blog/human-in-the-loop-seam"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">July 8, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>The Human-in-the-Loop Seam: Where Humans Belong in a Dark Factory</h1>
</header>
<div class="post-content">
<p class="lead-question">Human-in-the-loop is a phrase everyone uses. Almost nobody uses it correctly.</p>
<p>A human is in the loop at a seam. The seam is a place where the system is underdetermined. The seam is the place where the spec does not say what the right answer is, and the factory has to either ask or guess. The human's job is to be the answer to the questions the spec cannot answer. The factory's job is to surface those questions, at the right time, in the right form, to a human who can answer them.</p>
<h2>The wrong place to put the human</h2>
<p>The wrong place to put the human is in the implementation. If the spec is complete enough to be compiled, the factory should compile it. Adding a human to "review the code" before the merge is putting the human in a place where the human is duplicating the factory's work. The factory just generated the artifact from the spec. The human reviewing the artifact is asking whether the factory did what the spec said. The factory can answer that question with a provenance graph. The human is not adding information. The human is adding latency.</p>
<p>Teams that put the human in the review get a familiar pattern. The review takes two days. The human approves what the factory produced. The human introduces small changes that break the spec. The spec and the artifact drift apart because the human was the seam, and the seam was in the wrong place. The seam should have been in the spec, not in the review.</p>
<h2>The right place to put the human</h2>
<p>The right place to put the human is on the seam where the spec is underdetermined. There are three of these seams in a dark factory, and they are different from each other.</p>
<p><strong>The policy seam.</strong> The policy is the human's signature on the system. The policy says: this kind of artifact, in this kind of environment, is allowed to promote. The policy is underdetermined because the policy is a human value judgment, not a derived fact. The factory cannot derive what is allowed. The factory can only enforce what has been declared. The human declares. The factory enforces.</p>
<p><strong>The spec seam.</strong> The spec is underdetermined in places. The spec describes intent. The intent does not always fully constrain the artifact. The factory will produce a correct artifact from an underdetermined spec. The artifact will be one of many correct artifacts, and the choice between them is a taste decision. The human has the taste. The factory surfaces the choice. The human makes the call. The spec is updated with the call. The factory's next artifact is constrained by the updated spec.</p>
<p><strong>The audit seam.</strong> The audit is the place where the human checks that the factory did what the spec said, and the spec was the right call. The audit is the only seam where the human gets to ask the second-order question. The audit is the only seam where the human can change the spec. The audit is the only seam that closes the loop. Without the audit, the factory is the only one learning. With the audit, the human is learning too.</p>
<h2>What the human looks like at each seam</h2>
<p>At the policy seam, the human is a writer. The human writes the policy. The policy is a small artifact, versioned, signed, reviewed. The policy is not code. The policy is intent. The factory is the executor.</p>
<p>At the spec seam, the human is an editor. The human updates the spec to capture a decision the factory surfaced. The spec is a living document. The spec is not a wiki. The spec is a file the factory reads. The human does not need to be a programmer. The human needs to be a domain expert who can describe what they want in the domain's vocabulary.</p>
<p>At the audit seam, the human is a reader. The human reads the factory's output, the spec the factory consumed, the policy the factory enforced. The human asks: did the right thing happen? The human's answer goes into the next spec, the next policy, the next audit.</p>
<h2>Why this is harder than it looks</h2>
<p>The seams are not labeled in the artifact. The artifact has a hash, a signature, a provenance graph. None of those say "this decision was made by a human at the spec seam." The factory has to be designed to make the seam visible. The factory has to be designed to ask the question at the right time. The factory has to be designed to wait for the answer, or to ship a default, depending on the policy.</p>
<p>This is the work of designing a dark factory. The work is not the build pipeline. The work is the seam management.</p>
<h2>The single rule</h2>
<p>The human belongs on the seam where the spec is underdetermined, not on the seam where the implementation is risky.</p>
<p>The patterns that exist put the human where the implementation is risky. The human reviews the code, the test, the deploy. The factory can review the code, run the test, ship the deploy. The human's value is upstream of the implementation, at the seams where the spec is underdetermined.</p>
<p>That is the human's job. The human decides what the factory does. The factory decides how the human's decision becomes an artifact. The seam between them is the only place the human belongs.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.lead-question {
font-size: 1.25rem;
font-weight: 600;
color: var(--color-brown-dark);
margin-bottom: 1.5rem;
line-height: 1.5;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.post-content p {
line-height: 1.7;
margin-bottom: 1.25rem;
}
.post-content strong {
color: var(--color-brown-dark);
}
</style>

View file

@ -1,138 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Light vs Dark Factories: Why the Middle Is Harder Than Either End"
description="A light factory has too many gates. A dark factory has too few. The middle is where the engineering happens, and the middle is the part nobody talks about."
ogType="article"
canonicalUrl="/blog/light-vs-dark-factories"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">June 2, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>Light vs Dark Factories: Why the Middle Is Harder Than Either End</h1>
</header>
<div class="post-content">
<p class="lead-question">Pure dark factories are for vendors. Pure light factories are for teams that do not trust their pipeline. The interesting engineering is in between.</p>
<p>The ends are easy to describe. The middle is where the work is.</p>
<h2>The light factory</h2>
<p>A light factory is what most teams have when they say "we have a CI/CD pipeline." Code is written. Tests run. A human reviews the diff. A human approves the merge. A human triggers the deploy. A human watches the deploy. A human confirms the deploy is healthy.</p>
<p>Every transition is a handoff. Every handoff is a place for a person to add or remove judgment. The team scales linearly with the number of handoffs. The team does not scale linearly with the number of engineers, because the handoffs are the bottleneck.</p>
<p>At some point, the handoffs become the work. The team is not shipping product. The team is moving code through human gates. The product slows. The hiring ramps. The handoffs grow. The team gets further from shipping and closer to queue management.</p>
<h2>The dark factory</h2>
<p>A dark factory replaces the human handoffs with policy. Spec in, artifact out. The policy is the rules. Nothing in the middle requires a person to act.</p>
<p>This is a team that ships constantly, unattended. The product is moving fast, except when the policy is wrong. When the policy is wrong, the product moves fast in a bad direction and no one notices until the customer does.</p>
<h2>The middle is a position, not a transition</h2>
<p>The middle has three properties.</p>
<ol>
<li><strong>The pipeline is the gate.</strong> The merge to main is not gated by a reviewer. It is gated by a policy expression. The policy is code. The code is reviewed.</li>
<li><strong>The human is the auditor.</strong> The human inspects what the pipeline produced. The audit is sampling-based, not exhaustive. The audit answers "did the policy work this week," not "is this merge correct."</li>
<li><strong>The spec is the source of truth.</strong> The code is generated. The test suite is generated. The deploy manifest is generated. The thing the human writes is the spec, and the spec is what gets reviewed.</li>
</ol>
<p>What is new is the surface area. The spec is meant to be writable by a domain expert, not just an engineer, in a domain-specific language. The audit surface is small enough to review against the policy.</p>
<h2>Why the middle is harder than either end</h2>
<p>At the dark end, you maintain the policy. The policy is the system.</p>
<p>At the light end, you maintain the people. The people are the system.</p>
<p>In the middle, you maintain the policy, you maintain the people, and you maintain the <em>seam</em> between them. The seam is what fails. The seam is what determines whether the factory runs at all.</p>
<p>A seam is a place where the human's authority and the pipeline's authority have to be reconciled. Promotion to production is a seam. Incident response is a seam. The decision to roll back is a seam. Each of those is a moment where the human's signature is the difference between shipping and stalling.</p>
<p>Each seam has a default. The default is what the pipeline does when no human acts. If the default is "ship" and the human does not act, the system has shipped. If the default is "do not ship," the system has stalled. The default has to be defensible. The default has to be chosen.</p>
<h2>How to know which position you are in</h2>
<p>One question. When the human does nothing, does the system ship or stall?</p>
<p>If the answer is ship, you are dark. If the answer is stall, you are light. If the answer is "it depends on which stage," you are in the middle. The middle is where you want to be, and the middle is the part you have to design on purpose.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.lead-question {
font-size: 1.25rem;
font-weight: 600;
color: var(--color-brown-dark);
margin-bottom: 1.5rem;
line-height: 1.5;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.post-content p {
line-height: 1.7;
margin-bottom: 1.25rem;
}
.post-content ol,
.post-content ul {
line-height: 1.7;
margin-bottom: 1.25rem;
padding-left: 1.5rem;
}
.post-content li {
margin-bottom: 0.5rem;
}
.post-content strong {
color: var(--color-brown-dark);
}
</style>

View file

@ -1,126 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Mentorship Isn't Latency; It's Leverage"
description="The highest-ROI activity in your organization is the one you canceled first. Mentorship compounds in ways no feature ship ever will."
ogType="article"
canonicalUrl="/blog/mentorship-isnt-latency-its-leverage"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 7, 2026</span>
<span class="post-tag">Mentorship</span>
</div>
<h1>Mentorship Isn't Latency; It's Leverage</h1>
</header>
<div class="post-content">
<p class="lead-question">What if the highest-ROI activity in your organization is the one you canceled first?</p>
<p>Every engineering leader has felt the pressure. The roadmap is tight. The sprint is overloaded. Someone suggests a mentorship program, and the response is immediate; "We do not have bandwidth for that right now."</p>
<p>That response is backwards. Mentorship is not latency in the system. It is the highest-leverage activity a senior person can do, because it compounds in ways no feature ship ever will.</p>
<h2>The math we refuse to do</h2>
<p>When a senior engineer spends two hours pairing with a junior, the organization sees two hours not spent on code review, architecture, or incident response. What the organization does not see is the multiplier that gets created.</p>
<p>Every person you mentor becomes an independent producer of better decisions. They write code that does not need rework. They spot risks before they become incidents. They teach the next person. The two hours you spend today produce two hundred hours of better work over the next two years.</p>
<p>That is leverage. And most companies leave it on the table because they cannot measure it on this sprint's burndown chart.</p>
<h2>AI makes this more urgent, not less</h2>
<p>There is a dangerous narrative circulating that AI will replace the need for mentorship. The argument goes like this: junior engineers can ask a model for help, so why waste a senior's time?</p>
<p>This misses what mentorship actually transfers. AI can explain a concept. It cannot transfer judgment about which concept applies in a specific political, technical, and historical context. It cannot share the story of the outage that happened because someone made the exact tradeoff the junior is about to make. It cannot model the credibility and trust that makes a junior actually take the feedback seriously.</p>
<p>AI is an incredible tool for information retrieval. It is a terrible substitute for institutional wisdom transfer.</p>
<h2>Three questions that change everything</h2>
<p>In my book <em>A Walk in Mentoring</em>, I share three questions that have shaped every mentoring relationship I have built:</p>
<p><strong>What are you trying to grow?</strong> Not what project are you on; what capability are you building? This shifts the conversation from task completion to human development.</p>
<p><strong>What is getting in the way?</strong> This surfaces the real constraints, which are rarely technical and usually about risk tolerance, organizational politics, or confidence.</p>
<p><strong>How can I help?</strong> This is the critical pivot. The mentor's job is not to solve the problem. It is to remove the specific obstacle that is blocking the mentee's growth.</p>
<p>These questions take ten minutes to ask. They shape years of trajectory.</p>
<h2>The cultivation parallel</h2>
<p>You do not measure soil health by this quarter's yield. You measure it by what grows without you, season after season.</p>
<p>Mentorship is cultivation. It is slow, it is invisible, and it outperforms every shortcut eventually. The organizations that treat it as overhead are already spending that "savings" on rework, attrition, and technical debt. The organizations that treat it as leverage are building teams that compound.</p>
<p>If you are a senior leader, your calendar is your strategy. If mentorship is not on it, you have already made a choice about what kind of organization you are building.</p>
<p>The question is not whether you can afford mentorship. It is whether you can afford to keep treating it as optional.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 4rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 2.75rem);
color: var(--color-brown-dark);
margin: 0;
line-height: 1.2;
}
.post-content p {
margin-bottom: 1.5rem;
line-height: 1.8;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.lead-question {
font-size: 1.15rem;
font-style: italic;
color: var(--color-text-muted);
border-left: 3px solid var(--color-amber);
padding-left: 1rem;
margin-bottom: 2rem !important;
}
</style>

View file

@ -1,74 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="My Open Source Projects: Speckl, ScobleClaw, and Beyond the Prompt"
description="A roundup of Scott Scoble's open-source projects — Speckl, ScobleClaw, and Beyond the Prompt."
ogType="article"
canonicalUrl="/blog/open-source-projects"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 23, 2026</span>
<span class="post-tag">Open Source</span>
</div>
<h1>My Open Source Projects</h1>
</header>
<div class="post-content">
<p>I'm Scott Scoble. Over the past year I've been building open-source tools that sit at the intersection of formal methods, agentic engineering, and human accountability. Here's what I've shipped and where things are headed.</p>
<h2>Speckl — A Judgement Transport Utility</h2>
<p><strong><a href="https://speckl.scoble.me">Speckl</a></strong> is a specification language and compiler that turns state machine specs into auditable code with embedded provenance. Write your spec in SpeckDL, and the compiler produces TypeScript, Z3 verification output, and compliance artifacts (PROV-O, CycloneDX, SPDX) — all from a single source of truth.</p>
<p>The key insight: AI generates code at machine speed, but humans own the specifications. SpeckDL is the shared space where both can work. It fulfills NIST SA-11 (human-in-the-loop for automated outputs).</p>
<p>I built Speckl because I saw a pattern across every AI-augmented team I worked with: the spec gap. Teams trust their AI tools but can't audit what was actually intended versus what got built. Speckl closes that gap by construction — provenance is embedded by the compile step, not bolted on after the fact.</p>
<ul>
<li>41/41 tests passing, &lt; 2 second test suite</li>
<li>14 example specs from ToggleSwitch through Raft and Kafka KRaft</li>
<li>MIT licensed — <a href="https://os.scoble.me/forgejo/sscoble/speckl">source on Forgejo</a></li>
<li><a href="https://os.scoble.me/forgejo/sscoble/speckl/src/branch/main/docs/whitepaper-v2.md">Whitepaper v2</a> covers the full architecture</li>
</ul>
<h2>ScobleClaw — Agentic Engineering Framework</h2>
<p><strong><a href="https://os.scoble.me/forgejo/sscoble/scobleclaw">ScobleClaw</a></strong> is a monorepo of agentic engineering patterns that I use daily. It's the shared infrastructure across all my projects — subagent dispatch, skill-based development, and provenance tracking for AI agent workflows.</p>
<p>This is the layer between "talk to an LLM" and "run an AI-augmented engineering operation." ScobleClaw codifies patterns that make agentic work repeatable, auditable, and composable.</p>
<h2>Beyond the Prompt — Lessons from Building with Claude Code</h2>
<p><strong><a href="https://os.scoble.me/forgejo/sscoble/beyond-the-prompt">Beyond the Prompt</a></strong> is a workshop presentation that demonstrates the Skills + Subagents pattern for AI-assisted development. It uses itself as the example — a meta-aware demonstration of how to build with AI agents.</p>
<p>Built with Reveal.js and Nix flakes, it covers context window economics, the Skills + ADRs pattern, and how to prevent waste through evaluation-before-execution.</p>
<h2>Why This Matters for SEO</h2>
<p>If you're reading this because you searched for "Scott Scoble speckl" or "Scott Scoble open source" — hi. You found me. That's the point of this post. My work is public, MIT licensed, and built in the open. If you want to see what I build, you can read the source, try the compiler, or reach out.</p>
<p>The full list of my open work:</p>
<ul>
<li><strong>Speckl</strong> — <a href="https://speckl.scoble.me">speckl.scoble.me</a> / <a href="https://os.scoble.me/forgejo/sscoble/speckl">source</a></li>
<li><strong>ScobleClaw</strong> — <a href="https://os.scoble.me/forgejo/sscoble/scobleclaw">source</a></li>
<li><strong>Beyond the Prompt</strong> — <a href="https://os.scoble.me/forgejo/sscoble/beyond-the-prompt">source</a></li>
<li><strong>Brand Site</strong> — <a href="https://scott.scoble.me">scott.scoble.me</a> / <a href="https://os.scoble.me/forgejo/sscoble/brand-site">source</a></li>
</ul>
<p>— Scott Scoble</p>
</div>
</article>
</BaseLayout>
<style>
/* Inherits from global blog styles */
</style>

View file

@ -1,132 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Kubernetes Operator Patterns for Software Factories"
description="The operator is the unit of automation in a software factory. Here are the four operator patterns and the one anti-pattern to avoid."
ogType="article"
canonicalUrl="/blog/operator-patterns-for-software-factories"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">June 19, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>Kubernetes Operator Patterns for Software Factories</h1>
</header>
<div class="post-content">
<p class="lead-question">An operator is a control loop with a domain in it. That is the whole definition. Everything else is implementation.</p>
<p>A factory is composed of operators, each one owning a seam. The seams are the spec, the build, the test, the deploy, the promote, the rollback. Each seam gets one operator. The operators do not call each other. The operators watch the cluster and react.</p>
<h2>The spec operator</h2>
<p>The spec operator owns a <code>SoftwareSpec</code> custom resource. A human writes the spec. The operator validates the spec. The operator emits a normalized form into the cluster, signed, with provenance attached.</p>
<p>The spec operator is the only operator that takes human input. Every other operator in the factory watches a spec-shaped resource. The spec operator is the auditor's first stop: what specs exist, who wrote them, what versions are live.</p>
<p>Keep it thin. The spec operator's job is to validate and emit. It does not run tests. It does not trigger builds. It does not know what a build is.</p>
<h2>The build operator</h2>
<p>The build operator watches a normalized spec. The build operator produces a <code>BuildArtifact</code> custom resource containing the hash, the SBOM, the provenance graph, and the signed manifest. The build operator does not know about clusters. The build operator does not know about deployment. The build operator's job is to take a spec and produce an artifact that other operators can verify.</p>
<p>The build operator is the operator that wants to know too much. Every time the build operator learns about tests, about deployment, about promotion, it becomes unmaintainable. The build operator that survives is the one that does one thing. Boring is what you want from a build operator.</p>
<h2>The deploy operator</h2>
<p>The deploy operator watches a signed <code>BuildArtifact</code> and a target environment. The deploy operator produces a <code>Deployment</code> custom resource. The deploy operator's job is to take a verified artifact and put it in a verified place.</p>
<p>The deploy operator is where most teams make their first mistake. They have the deploy operator trigger a kubectl apply, or call a Helm release, or invoke a serverless deploy. All of these are wrong. The deploy operator should produce a declarative resource, and a separate, generic Kubernetes primitive should reconcile to that resource. The deploy operator is the translator. The cluster is the executor.</p>
<p>When the deploy operator produces a resource, the resource can be inspected, audited, rolled back, frozen. When the deploy operator pushes to a remote API, none of those things are true. The remote API is the system. The remote API is what the auditor cannot see.</p>
<h2>The policy operator</h2>
<p>The policy operator is the seam. The policy operator watches deployments and consults a policy bundle. The policy bundle is a versioned, signed set of rules. The policy operator's job is to decide which deployments are allowed to promote to which environment.</p>
<p>The policy operator is the one that is hardest to write. The off-the-shelf policy engines (OPA, Cedar, Rego, the rest) cannot express what most factories need without a policy file that nobody on the team can read. The version that survives is a custom DSL, small enough to fit on a page, expressive enough to encode the rules the business actually needs.</p>
<p>The policy operator is where the human's authority lives in a dark factory. The policy is the human's signature on the system. The policy operator enforces that signature. Everything else in the factory can be fully dark. The policy operator is the part that cannot be.</p>
<h2>The anti-pattern</h2>
<p>One operator per application. One operator per microservice. The factory has many operators, and every one of them is a slightly different shape. The team spends more time learning the operators than they spend shipping product.</p>
<p>The mistake is treating the operator as a wrapper around the application. The operator is not a wrapper around the application. The operator is a wrapper around a <em>type of change</em>. The factory has one operator per type of change, regardless of how many applications use that type. The application is a parameter, not a peer.</p>
<h2>The composition rule</h2>
<p>Operators in a factory do not call each other. Operators watch resources. Operators emit resources. The composition happens in the cluster's etcd layer, not in operator code.</p>
<p>This rule sounds like bureaucracy. It is not. It is what makes the factory auditable. When operator A triggers operator B, the trigger is a side effect of state, and the state is in etcd, and the etcd is queryable. When operator A calls operator B's API, the trigger is hidden in operator A's code, and the audit is impossible. Choose the auditable version.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.lead-question {
font-size: 1.25rem;
font-weight: 600;
color: var(--color-brown-dark);
margin-bottom: 1.5rem;
line-height: 1.5;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.post-content p {
line-height: 1.7;
margin-bottom: 1.25rem;
}
.post-content code {
background: var(--color-cream);
padding: 0.125rem 0.375rem;
border-radius: 4px;
font-size: 0.9em;
}
.post-content strong {
color: var(--color-brown-dark);
}
</style>

View file

@ -1,145 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="We're Going to Formally Verify SQLite"
description="SQLite runs on every smartphone, every browser, every embedded system. Its core state machines have never been formally verified."
ogType="article"
canonicalUrl="/blog/prove-sqlite"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 23, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>We're Going to Formally Verify SQLite</h1>
</header>
<div class="post-content">
<p>SQLite runs on every smartphone, every browser, every embedded system. Its core state machines have never been formally verified. We're going to fix that.</p>
<p>This is the follow-up to our <a href="/blog/prove-kafka">Kafka proof-of-consensus project</a>; same methodology, bigger target. SQLite is not a research toy; it is the most deployed database in the history of software. If we can prove its invariants, we prove something that matters.</p>
<hr />
<h2>Why SQLite</h2>
<p>SQLite is not a theoretical construct. It ships inside:</p>
<ul>
<li>Every iPhone and Android device (iOS, Android system libraries)</li>
<li>Every major browser (Chrome, Firefox, Safari, Edge)</li>
<li>Countless embedded systems, IoT devices, and automotive platforms</li>
<li>macOS, Windows, and most Linux distributions by default</li>
</ul>
<p>The SQLite Consortium estimates <strong>one trillion</strong> active SQLite databases. Not one billion; one trillion. The test suite (TH3) achieves 100% branch coverage and is widely regarded as the best-tested codebase on Earth. But 100% branch coverage is not proof. It is exhaustive testing, and exhaustive testing is not the same as a mathematical guarantee.</p>
<p>SQLite's internals are exceptionally well-documented. D. Richard Hipp publishes detailed architecture documentation, and the codebase is commented with the rigor of a textbook. The state machines are explicit: the pager has discrete modes, the WAL protocol has a defined lifecycle, and the VDBE bytecode engine operates on a register model with well-defined instruction semantics.</p>
<p>This is not a black box. It is a glass box with a published manual. That makes it an ideal target for formal specification.</p>
<h2>What We'll Verify (Phase 1)</h2>
<p>We are not attempting to verify all of SQLite. The full engine is hundreds of thousands of lines of C. Our Phase 1 scope targets three core subsystems whose state machines are both critical and amenable to SpeckDL specification:</p>
<h3>1. The Pager State Machine</h3>
<p>The pager manages the transaction lifecycle: reading pages from disk, caching them, tracking dirtiness, and orchestrating writes. It operates in multiple journal modes (DELETE, TRUNCATE, PERSIST, WAL, MEMORY, OFF) and transitions through states that must respect strict invariants.</p>
<p>The pager state machine is where SQLite's durability guarantee lives. When a transaction commits, the pager decides whether the commit is durable and when the journal can be discarded. In WAL mode, the pager coordinates between a single writer and multiple readers via the WAL index and checkpoint logic. An error in the pager does not produce a crash; it produces silent data loss or inconsistency that may not surface for months.</p>
<p>Key properties to verify:</p>
<ul>
<li>A dirty page is never evicted without being written</li>
<li>WAL mode maintains read consistency across concurrent readers and a single writer</li>
<li>Journal deletion is the atomic commit point: before deletion, crash recovery rolls back; after deletion, committed state is visible</li>
<li>The pager never enters an inconsistent state after an interrupted commit</li>
<li>Checkpoint operations preserve the "all committed data is in the database file" invariant</li>
</ul>
<p>We have already specified the pager state machine in <code>examples/SQLitePager.speck</code> (276 lines, 8 actions, 6 invariants) and the WAL concurrency model in <code>examples/SQLiteWAL.speck</code> (267 lines, 11 actions, 10 constraints). Both compile cleanly to Z3 SMT-LIB. Verification results will be published here as we complete each subsystem.</p>
<h3>2. The VDBE Bytecode Engine</h3>
<p>The Virtual Database Engine executes compiled SQL bytecode on a register machine. Each instruction manipulates registers, cursors, and the B-Tree layer. The instruction set is finite and well-documented; the register model is a stack-plus-registers hybrid.</p>
<p>The VDBE is not the highest-risk component; its instructions are deterministic and its state is local. But it is the component every SQL statement passes through. A single off-by-one in a register reference or a type-tag mismatch in an arithmetic operation can produce incorrect query results that look like correct ones. Verifying the VDBE means verifying that the bytecode interpreter cannot enter an undefined state regardless of the input program.</p>
<p>Key properties to verify:</p>
<ul>
<li>Register references are always within bounds</li>
<li>Type tags are consistent with the operations performed on them</li>
<li>Cursor operations maintain valid iterator state</li>
<li>The program counter advances monotonically except for controlled jumps</li>
<li>The stack depth never underflows or exceeds its declared maximum</li>
</ul>
<h3>3. B-Tree Invariants</h3>
<p>The B-Tree layer is SQLite's storage backbone: tables and indexes are both B-Trees. Page splits, pointer integrity, and balance operations are the kind of mechanical code that formal verification excels at.</p>
<p>The B-Tree code in SQLite is dense. A single page split involves allocating a new page, redistributing cells between two pages, updating parent pointers, and handling the edge case where the root itself splits. Each step has preconditions; violate one and the tree becomes structurally inconsistent. Corruption at this layer does not crash; it causes queries to return wrong results or skip rows entirely.</p>
<p>Key properties to verify:</p>
<ul>
<li>After any page split, all keys remain reachable via tree traversal</li>
<li>Sibling pointers maintain total order</li>
<li>Balance operations preserve the B-Tree height bound</li>
<li>Cell offsets remain within the page boundary after any insertion or deletion</li>
<li>Free space within a page is always contiguous and correctly sized</li>
</ul>
<h2>Method</h2>
<p>Same as Prove Kafka: SpeckDL specification, Z3 bounded model checking, publish findings.</p>
<p>The framework is already built. The compiler produces a typed intermediate representation; the Z3 backend translates invariants and verify blocks into SMT-LIB assertions. We proved Kafka's consensus invariants this way; we will prove SQLite's operational invariants the same way.</p>
<p>The workflow:</p>
<ol>
<li><strong>Specify</strong> the state machine in SpeckDL (pager modes, VDBE registers, B-Tree pages)</li>
<li><strong>Compile</strong> to Z3 SMT-LIB with <code>speckl verify --target=z3 --verify-depth=N</code></li>
<li><strong>Run</strong> bounded model checking against the invariants</li>
<li><strong>Document</strong> the results: what held, what didn't, what depth we reached</li>
<li><strong>Publish</strong> the specification and findings as open-source artifacts</li>
</ol>
<p>The SpeckDL specifications will be open source. The Z3 output will be reproducible. If we find an invariant violation, you'll read about it here first.</p>
<h2>Why This Matters</h2>
<p>There is no shortage of testing in SQLite. TH3 is the gold standard. But testing and proof are different categories of assurance.</p>
<p>Testing says: "We tried a lot of cases and didn't find a bug." Proof says: "No case exists that violates this property." The first is empirical confidence; the second is logical certainty. Both matter. SQLite has the first in abundance. It has never had the second.</p>
<p>Formal verification of SQLite's core invariants would be a first. Not because SQLite is buggy; the evidence suggests it is exceptionally solid. But because proof is the only assurance that does not degrade over time. As the codebase evolves, as new journal modes are added, as platforms change, a verified invariant remains verified. A test case does not.</p>
<p>We proved Kafka's consensus. Now we're proving the world's most deployed database.</p>
<h2>Follow Along</h2>
<p>The specifications will live in the Speckl repository at <code>examples/SQLitePager.speck</code>, <code>examples/SQLiteVDBE.speck</code>, and <code>examples/SQLiteBTree.speck</code>. Verification results will be published as we complete each subsystem.</p>
<p>If you want to follow the work or contribute, the repo is open and the issues are tracked publicly. When we find something, you'll read it here first.</p>
<hr />
<p><em>This post is part of the Speckl proof catalog: formally verifying the software the world depends on. Read the <a href="/blog/prove-kafka">Kafka proof</a> or explore the <a href="https://os.scoble.me/forgejo/sscoble/speckl">Speckl compiler</a>.</em></p>
<p><em>Speckl is MIT-licensed and open source. The specifications, the compiler, and the findings are all public.</em></p>
<p>— Scott Scoble</p>
</div>
</article>
</BaseLayout>
<style>
/* Inherits from global blog styles */
</style>

View file

@ -1,284 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
import NewsletterSignup from '../../components/NewsletterSignup.astro';
---
<BaseLayout
title="Soil Health for Teams: A Diagnostic Framework for What's Actually Depleted"
description="The four soil nutrients diagnostic framework for engineering team health. From Scott Scoble's talk, The Soil Under Your Team."
ogType="article"
canonicalUrl="/blog/soil-health-teams"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 18, 2026</span>
<span class="article-tag">Leadership</span>
</div>
<h1>Soil Health for Teams: A Diagnostic Framework for What's Actually Depleted</h1>
<p class="article-subtitle">
Tall stalks, ground cover, nitrogen fixers, pollinators, deep roots. The agricultural metaphor isn't poetic; it's diagnostic. Here's how to read the soil under your team.
</p>
</header>
<div class="article-body">
<p>Every engineering team has soil underneath it.</p>
<p>Not metaphorical soil; real soil. The accumulated conditions — cultural, structural, relational — that determine what can grow there and what can't. Most teams don't know their soil type. They know their output. They know their velocity. They know whether this quarter's roadmap shipped. But the soil? They assume it's fine until something dies.</p>
<p>The agricultural metaphor isn't poetic; it's diagnostic. Farmers don't wait for the crop to fail before checking the soil. They test it, they amend it, they rotate it. They know that the visible plant is the last indicator, not the first.</p>
<p>I developed this framework from a talk I gave called <em>The Soil Under Your Team</em>. It started as a way to make the cultivation concept concrete, and it turned into something I use every time I walk into a new organization.</p>
<h2>The Four Nutrients</h2>
<p>Healthy soil requires four things. Deplete any one of them and the whole system weakens. Deplete two and you're in crisis. Deplete three and you're wondering why nobody told you the team was dying.</p>
<h3>Nutrient One: Tall Stalks (Technical Excellence)</h3>
<p>In a field, tall stalks are the visible sign of health. In a team, they're the engineers who can solve the hard problems, who know the system deeply, who make the rest of the team better by proximity.</p>
<p>Tall stalks aren't just your senior engineers. They're the people who raise the ceiling for everyone else. When they leave, the whole field gets shorter. When they're depleted, the whole field gets weaker.</p>
<p>Here's what depletes tall stalks: using them as the answer to every hard problem instead of growing more tall stalks. The "let's ask Sarah" pattern where Sarah becomes the bottleneck, the crutch, the person who can't take a vacation because the system relies on her being available.</p>
<p>Cultivation means identifying your tall stalks and asking: are we growing more, or are we burning the ones we have?</p>
<h3>Nutrient Two: Ground Cover (Psychological Safety)</h3>
<p>Ground cover prevents erosion. It holds the soil in place during storms. In teams, psychological safety is what keeps people from leaving when things get hard.</p>
<p>Not comfort. Not absence of conflict. Safety. The confidence that you can say "I don't know" without penalty. That you can raise a concern without retribution. That you can fail without becoming a failure.</p>
<p>Teams with poor ground cover erode fast. One bad quarter, one difficult reorg, one toxic hire, and the soil starts washing away. People don't leave because of the storm; they leave because the soil wasn't held in place.</p>
<p>Ground cover is built in small moments. The manager who responds to a missed deadline with "what do we need to fix?" instead of "what went wrong?" The senior engineer who admits uncertainty in a meeting. The team ritual that celebrates learning from failure.</p>
<p>These moments seem trivial in isolation. They're the difference between a team that weathers storms and one that washes away.</p>
<h3>Nutrient Three: Nitrogen Fixers (Knowledge Transfer)</h3>
<p>In agriculture, nitrogen fixers are plants that improve the soil for others. Legumes pull nitrogen from the air and make it available to neighboring plants. In teams, nitrogen fixers are the people who make others better through proximity.</p>
<p>They're not always the best engineers. Sometimes they're the best teachers. The person who writes documentation that actually gets read. The person who answers questions in public channels so the answers accumulate. The person who pairs with juniors not as a burden but as a practice.</p>
<p>Nitrogen fixers are invisible in most performance reviews because their impact is indirect. They make the soil richer for everyone else. Remove them and the whole field starves slowly, nobody knows why.</p>
<p>Organizations that optimize for individual heroics deplete their nitrogen fixers. Why fix the soil when you can just hire more fertilizer? But fertilizer runs out. Nitrogen fixers compound.</p>
<h3>Nutrient Four: Pollinators (Cross-Functional Connection)</h3>
<p>Pollinators move between plants, carrying what one has to what another needs. In teams, they're the people who bridge silos. The engineer who understands product context. The PM who can read architecture diagrams. The designer who speaks fluent API.</p>
<p>Pollinators are deceptively powerful because they make the system coherent. Without them, each function optimizes locally and the overall product becomes incoherent. Engineering ships fast features that product didn't prioritize. Product asks for things engineering can't build. Design creates experiences that don't match technical constraints.</p>
<p>The cost of poor pollination isn't visible in any single team's metrics. It shows up in the product. In the user experience. In the technical debt that accumulates because nobody was carrying context between decisions.</p>
<p>Pollinators need time to move between functions. That time looks like overhead to managers optimizing for individual utilization. It's not overhead; it's architecture.</p>
<h2>The Deep Roots Layer</h2>
<p>There's a fifth element that doesn't show up in the four nutrients because it's not a nutrient; it's the foundation.</p>
<p>Deep roots.</p>
<p>In agriculture, deep roots access water and minerals that surface roots can't reach. They anchor the plant against wind. They're invisible most of the time; you only see them when you dig or when the storm comes.</p>
<p>In teams, deep roots are the accumulated trust, shared history, and mutual understanding that lets a team move fast without breaking things. You can't build deep roots in a quarter. You can't hire them. You grow them, slowly, by staying together through hard things.</p>
<p>Teams that reorg every six months never develop deep roots. Teams that treat people as interchangeable resources never develop deep roots. Teams that optimize for short-term flexibility sacrifice the long-term stability that deep roots provide.</p>
<p>The organization that rotates people every 18 months for "career development" is harvesting the crop and wondering why the soil gets poorer every year.</p>
<h2>Reading Your Soil</h2>
<p>Here's the diagnostic. Ask these questions honestly:</p>
<p><strong>Tall stalks:</strong> Who raises the ceiling for this team? Are we growing more, or burning the ones we have?</p>
<p><strong>Ground cover:</strong> Can people here say "I don't know" without penalty? Can they fail without becoming failures?</p>
<p><strong>Nitrogen fixers:</strong> Who makes others better through proximity? Do we value that, or do we only value individual output?</p>
<p><strong>Pollinators:</strong> Who carries context between functions? Do we give them time to move, or do we treat that time as overhead?</p>
<p><strong>Deep roots:</strong> How long has this team been together? What have they survived? What trust have they accumulated?</p>
<p>If you can't answer these, you don't know your soil. And if you don't know your soil, you're farming blind.</p>
<h2>The Cultivation Assessment</h2>
<p>I use a simple cultivation assessment when I walk into a team:</p>
<p>Rate each nutrient 1-5. Not relative to some ideal team in a blog post; relative to what this team needs to do what it's trying to do. A team building critical infrastructure needs more tall stalks than a team running marketing automations. A team in rapid growth needs more nitrogen fixers than a mature maintenance team.</p>
<p>The goal isn't a perfect score. The goal is honesty about what's depleted and a plan to amend it.</p>
<p>A team with 2/5 ground cover isn't failing; it's eroding. A team with 1/5 pollinators isn't broken; it's incoherent. The assessment gives you language for what you already feel but couldn't name.</p>
<h2>What Healthy Soil Feels Like</h2>
<p>You can feel soil health. Healthy soil is loose, fragrant, alive with microorganisms. Unhealthy soil is compacted, sour, dead.</p>
<p>You can feel team health too. Healthy teams move with coherence. Decisions make sense in retrospect. People know what's expected without being told. Conflict happens and resolves. There's margin for learning, for experimentation, for the thing that wasn't in the roadmap.</p>
<p>Unhealthy teams feel different. Everything requires explicit coordination. Decisions seem arbitrary. People are careful in ways that cost energy. There's no margin; every sprint is a sprint to survive.</p>
<p>The feeling is data. Trust it. Then test the soil to find out why.</p>
<h2>Amendment, Not Replacement</h2>
<p>Here's what you don't do: you don't fire the team and hire a new one. That's not cultivation; that's starting over on depleted soil.</p>
<p>You amend. You add what's missing. You reduce what's toxic. You give it time.</p>
<p>Tall stalks depleting? Stop using them as the answer to everything; grow more through deliberate mentorship. Ground cover thin? Create small moments of safety and let them accumulate. Nitrogen fixers invisible? Change what you measure so knowledge transfer counts. Pollinators absent? Give people time to move between functions. Deep roots shallow? Stop reorging and let people stay together.</p>
<p>None of this is fast. None of it shows up in this quarter's metrics. All of it compounds.</p>
<h2>The Question Underneath</h2>
<p>The framework isn't really about soil. It's about a question: what are we growing here?</p>
<p>Most teams can't answer. They're shipping features, hitting OKRs, moving tickets across boards. They're not cultivating anything; they're extracting. And extraction depletes soil whether you name it or not.</p>
<p>The diagnostic is the first step. The hard part is what comes after: choosing to cultivate in a system that rewards extraction.</p>
<p>That's the work. That's always the work.</p>
</div>
<footer class="article-footer">
<div class="article-cta">
<p>Want to continue this conversation? <a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener">Connect with me on LinkedIn</a> — I write about the human side of AI and what to do about it.</p>
</div>
</footer>
</article>
<NewsletterSignup />
</BaseLayout>
<style>
.article {
padding: 12rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-brown-dark);
margin: 2.5rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.article-cta {
text-align: center;
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.article-cta a {
color: var(--color-green);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -1,131 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Spec-First Development Is the Only Audit Surface for AI-Generated Code"
description="Why spec-first development is the only reliable audit surface for AI-generated code — and how Speckl closes the spec-code gap by construction."
ogType="article"
canonicalUrl="/blog/spec-first-audit-surface"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 24, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>Spec-First Development Is the Only Audit Surface for AI-Generated Code</h1>
</header>
<div class="post-content">
<p class="lead-question">Every software project has specifications. And every specification eventually lies.</p>
<p>Requirements documents. Architecture decision records. API contracts. RFCs. These artifacts describe intent — what the system should do, how it should behave, what invariants should hold. And three months after you write them, they're wrong.</p>
<p>Not because the author was incompetent. Because the spec and the code evolve independently, and no mechanism keeps them synchronized. The spec becomes archaeology: interesting for historical context, irrelevant for current behavior.</p>
<p>This is the <strong>spec-code gap</strong>. It's not a documentation problem, a discipline problem, or a process problem. <strong>It's a provenance problem.</strong> And it's about to get much worse.</p>
<h2>The AI Accelerant</h2>
<p>When a human writes code from a spec, there's at least a reasoning chain — however undocumented. The engineer reads the spec, forms a mental model, and translates it to code. When an LLM writes code from a prompt, that chain disappears. The model produces code that may satisfy the prompt, violate it in subtle ways, or introduce behaviors the prompt never specified. The reasoning is opaque. The provenance is gone.</p>
<p>This isn't theoretical. NIST SA-11 — the control for "human review of automated outputs" — is already being mapped to AI-generated code in compliance frameworks. SOC 2 auditors are asking: "Who reviewed this code? What spec was it written against?"</p>
<blockquote>
<p>If your answer is "the AI wrote it from a Slack message," you have a compliance problem.</p>
</blockquote>
<h2>The Formal Methods Gap</h2>
<p>There <em>is</em> a solution. Formal specification languages — TLA+, Alloy, Isabelle/HOL — express intent unambiguously and can verify properties through model checking. Amazon, Microsoft, and MongoDB have used TLA+ to find critical design bugs.</p>
<p>But formal methods create their own gap: <strong>the verified spec and the running system are separate artifacts.</strong> After model-checking a TLA+ specification, a human must manually translate it into a programming language. That translation is:</p>
<ul>
<li><strong>Lossy</strong> — the spec's invariants live in the TLA+ tool, not in the running code</li>
<li><strong>Unverifiable</strong> — no tool checks whether the implementation matches the verified spec</li>
<li><strong>Drift-prone</strong> — the implementation evolves, the spec doesn't, and the gap widens</li>
</ul>
<p>You've verified the design. You haven't verified the implementation. The spec-code gap is exactly as wide as it was before.</p>
<h2>Provenance as the Missing Piece</h2>
<p>Here's the shift: <strong>we don't need the spec and the code to match. We need the code to come FROM the spec.</strong></p>
<p>Provenance — the chain of derivation from intent to artifact — is what makes specifications trustworthy. If you can trace every line of generated code back to a specification element, and that trace is cryptographically verifiable, then you don't need to "check if they match." The provenance IS the verification.</p>
<p>This is how <strong><a href="https://speckl.scoble.me">Speckl</a></strong> approaches the problem. Instead of writing a spec and then writing code that implements it, you write the spec in SpeckDL — and the compiler produces the code, along with a provenance graph that traces every output back to its specification origin.</p>
<p>Here's a ToggleSwitch in SpeckDL:</p>
<pre><code>spec ToggleSwitch
type State = enum &#123; on, off &#125;
state active: State = off
init
active := off
action flip
require active == off
active := on
invariant Mutex
active == on implies prev(active) == off</code></pre>
<p>From this, <code>speckl compile</code> produces:</p>
<ul>
<li><strong>A TypeScript class</strong> with typed methods, runtime guard checks, and state accessors</li>
<li><strong>A WebAssembly module</strong> with verified state transitions</li>
<li><strong>A PROV-O provenance graph</strong> showing that every method was derived from its spec element</li>
<li><strong>A CycloneDX SBOM</strong> declaring the generated module with its hash and provenance chain</li>
<li><strong>An SPDX document</strong> for license compliance</li>
</ul>
<p>The spec is ~14 lines. The generated artifacts are hundreds of lines of production code. The provenance chain connects every line back to those lines of intent.</p>
<h2>Why This Matters Now</h2>
<p>Three trends are converging:</p>
<h3>1. AI-generated code is becoming the norm</h3>
<p>Copilot writes 46% of code on enabled repos. Cursor, Claude, and Codex produce entire features from natural language prompts. The volume of code with no human reasoning chain is exploding.</p>
<h3>2. Compliance is getting serious about provenance</h3>
<p>Executive Order 14028 mandates SBOMs for federal software. The EU Cyber Resilience Act requires provenance for software products. NIST SP 800-218 calls for "provenance for all software components."</p>
<h3>3. Spec-to-code is becoming technically possible</h3>
<p>WebAssembly provides a universal compilation target. TypeScript provides a widely-adopted typed language. PROV-O provides a W3C standard for provenance. The pieces exist.</p>
<h2>The Alternative Is Drift</h2>
<p>Without provenance, every specification is on a timer. Day one, it reflects reality. Day ninety, it's a historical document. Day three hundred and sixty-five, it's fiction.</p>
<p>The spec-code gap doesn't get fixed by better documentation practices, more disciplined engineers, or stricter code review. It gets fixed by eliminating the gap — by making the spec the single source of truth, and generating everything else from it.</p>
<p>That's what a provenance-first approach to specifications enables. It's not about writing better specs. It's about making specs executable, verifiable, and auditable — so the gap never opens in the first place.</p>
<hr />
<p><em>This post is about <strong><a href="https://speckl.scoble.me">Speckl</a></strong>, a specification language that compiles to runnable software with embedded provenance. MIT licensed, open source. Read the <a href="https://os.scoble.me/forgejo/sscoble/speckl/src/branch/main/docs/whitepaper-v2.md">full whitepaper</a>, explore <a href="https://os.scoble.me/forgejo/sscoble/speckl/src/branch/main/docs/speckl-by-example.md">Speckl by Example</a>, or check out the <a href="https://os.scoble.me/forgejo/sscoble/speckl">compiler source</a>.</em></p>
</div>
</article>
</BaseLayout>
<style>
/* Inherits from global blog styles */
.lead-question {
font-size: 1.25rem;
font-weight: 600;
color: var(--color-brown-dark);
margin-bottom: 1.5rem;
line-height: 1.5;
}
</style>

View file

@ -1,253 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
import NewsletterSignup from '../../components/NewsletterSignup.astro';
---
<BaseLayout
title="Stop Strip-Mining Your Engineers: The Cultivation Alternative to Throughput Obsession"
description="Gallup 2026: 80% of the global workforce is disengaged. The $438B cost isn't a tool problem; it's a people problem. Here's the cultivation alternative."
ogType="article"
canonicalUrl="/blog/strip-mining-cultivation"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 18, 2026</span>
<span class="article-tag">Leadership</span>
</div>
<h1>Stop Strip-Mining Your Engineers: The Cultivation Alternative to Throughput Obsession</h1>
<p class="article-subtitle">
Gallup's 2026 report dropped a number that should have stopped the industry in its tracks: 80% of the global workforce is disengaged. The $438B cost isn't a tool problem; it's a people problem. Here's the cultivation alternative.
</p>
</header>
<div class="article-body">
<p>Gallup's 2026 report dropped a number that should have stopped the industry in its tracks: 80% of the global workforce is disengaged.</p>
<p>Not unhappy. Not underpaid. Disengaged. As in, going through the motions. As in, present but not accounted for. The kind of disengagement that doesn't show up in velocity metrics because velocity metrics measure output, not intent.</p>
<p>The cost? $438 billion annually in lost productivity. But that's accounting, not diagnosis. The real cost is the human potential being strip-mined out of existence while we optimize Jira boards.</p>
<p>Here's another number from the same report that got less attention: manager engagement dropped from +11 over individual contributors to +3. The people tasked with cultivating others are themselves running on empty.</p>
<p>This isn't a tool problem. You can't AI your way out of a people problem.</p>
<h2>The Extraction Economy</h2>
<p>I call what most engineering organizations do to their people "strip-mining." It's not pejorative; it's descriptive.</p>
<p>Strip-mining is the practice of removing resources from a site without regard for the long-term health of the soil. You extract maximum value in minimum time. You measure success by tons moved, not by whether anything can grow there afterward.</p>
<p>Sound familiar?</p>
<p>The sprint cycle that never ends. The "stretch goals" that stretch people until they break. The performance review that rewards shipped features and says nothing about soil health. The manager who has fifteen direct reports and no time to know any of them.</p>
<p>These aren't edge cases. They're the default setting. And we've normalized them because the metrics are easy and the alternatives are hard.</p>
<p>MIT and Gallup ran the numbers on AI adoption: 95% of implementations show zero profit impact. Not because the tools are bad, but because the people using them are depleted. You can't automate your way out of disengagement. You can only deepen it.</p>
<h2>The Cultivation Alternative</h2>
<p>I wrote a business novel about this. <em>The Soil Beneath the Code</em> wasn't an accident; it was a necessity. I needed a vocabulary for what I was seeing that "employee engagement" and "developer experience" couldn't capture.</p>
<p>The agricultural metaphor works because it's ancient, because it's grounded, because it forces you to think in cycles rather than quarters.</p>
<p>Cultivation is slow. Cultivation is directional. Cultivation measures the health of the soil, not just the height of this year's crop. And cultivation requires something extraction doesn't: the cultivator has to care about what happens after they're gone.</p>
<p>The three questions from my mentoring framework apply here too. What are you cultivating? At what cost? For how long?</p>
<p>Most engineering organizations can't answer the first question. They can tell you what they're shipping. They can tell you what their OKRs are. They can't tell you what they're growing in their people because they've never asked.</p>
<h2>What Cultivation Looks Like in Practice</h2>
<p>I'm not going to give you a framework with seven pillars and an acronym. Frameworks are what strip-mining looks like when it's trying to seem human. Instead, here are directional signals; practices that indicate cultivation rather than extraction.</p>
<p><strong>Cultivation invests in capacity, not just output.</strong></p>
<p>The organization that sends its senior engineers to a conference to learn something unrelated to this quarter's roadmap is cultivating. The organization that cancels training because "we're too busy shipping" is strip-mining. Both are rational within their own logic. Only one of them compounds.</p>
<p><strong>Cultivation measures soil health, not just yield.</strong></p>
<p>Velocity is yield. Cycle time is yield. Bug count is yield. None of them tell you whether your best engineer is two months from quitting, or whether your team's collective knowledge is eroding, or whether your onboarding process is destroying the people it's supposed to grow.</p>
<p>Soil health metrics are harder. They require conversation. They require looking at what people do when nobody's measuring them. They require the patience to measure things that don't show up in dashboards.</p>
<p><strong>Cultivation tolerates fallow seasons.</strong></p>
<p>Not every quarter can be a harvest. Sometimes the soil needs to rest. Sometimes the team needs to refactor, to learn, to experiment without a delivery date. The extraction mindset treats fallow seasons as waste. The cultivation mindset treats them as investment.</p>
<p>I've watched teams go through "innovation sprints" that were really just compressed delivery cycles with a different name. That's not a fallow season; that's strip-mining in disguise. A real fallow season has no metric attached. That's what makes it uncomfortable, and that's what makes it necessary.</p>
<p><strong>Cultivation is specific to the soil.</strong></p>
<p>You don't grow corn in sand. You don't cultivate a backend engineer the same way you cultivate a product manager. The generic "leadership training" that gets applied to everyone regardless of role, temperament, or trajectory is the HR equivalent of broadcasting seed from an airplane.</p>
<p>Cultivation requires knowing the person in front of you. Not their resume; their soil. What do they lean toward? What depletes them? What regenerates them? These questions don't scale. That's the point.</p>
<h2>The Manager Collapse</h2>
<p>Let's go back to that Gallup number: manager engagement at +3 over ICs. It used to be +11.</p>
<p>What happened?</p>
<p>Managers got loaded up. More direct reports, more cross-functional coordination, more "people leadership" responsibilities added to the same technical workload. The manager role became the dumping ground for everything that didn't fit in an IC job description.</p>
<p>And then we asked them to "cultivate" their people on top of it.</p>
<p>You can't cultivate what you don't have time to see. A manager with fifteen reports isn't cultivating; they're triaging. They're deciding which fires to let burn. The human connection that makes cultivation possible — the walk, the conversation, the noticing — gets sacrificed to the standup, the status update, the roadmap review.</p>
<p>If you want cultivation, you have to protect the cultivators. That means fewer direct reports, fewer meetings, fewer "strategic initiatives" that translate to more hours and less presence. It means treating manager time as a finite resource instead of an infinitely elastic buffer.</p>
<h2>The Speed Without Soil Trap</h2>
<p>I've started using a phrase: "speed without soil."</p>
<p>It describes the organization that moves fast but leaves nothing behind. The sprint that ships a feature and burns out the engineer who built it. The acquisition that brings revenue and destroys culture. The AI adoption that promises efficiency and delivers exhaustion.</p>
<p>Speed without soil isn't just unsustainable; it's expensive. The cost shows up in turnover, in knowledge loss, in the slow erosion of quality that happens when nobody has the margin to care.</p>
<p>The alternative isn't "slow." It's "fast with soil." The organization that moves quickly <em>because</em> it invests in its people. The team that ships reliably <em>because</em> it has time to learn from failures. The engineer who solves hard problems <em>because</em> they haven't been depleted by trivial ones.</p>
<p>Soil isn't a brake on speed. It's what makes sustained speed possible.</p>
<h2>What You Can Do Tomorrow</h2>
<p>I'm suspicious of advice that starts with "leadership should." Leadership should do a lot of things. Most of them don't happen because the structure prevents it.</p>
<p>So here's what you can do regardless of your title:</p>
<p><strong>If you're an IC:</strong> Notice what depletes you and what regenerates you. Track it for a week. The data is more useful than you think, and nobody else is going to collect it for you.</p>
<p><strong>If you're a manager:</strong> Reduce your direct report count or delegate something else. If you can't do either, be honest that you're managing, not cultivating. There's no shame in triage when triage is all the system allows. But don't call it mentorship.</p>
<p><strong>If you're a senior leader:</strong> Ask the three questions about your org. What are you cultivating? At what cost? For how long? If you can't answer them, you're strip-mining. That may be rational; just know what you're doing.</p>
<p>The $438 billion number is a distraction. It's big enough to seem important and abstract enough to ignore. The real question is personal: are you cultivating the people around you, or extracting from them?</p>
<p>Your answer matters more than any Gallup report.</p>
</div>
<footer class="article-footer">
<div class="article-cta">
<p>Want to continue this conversation? <a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener">Connect with me on LinkedIn</a> — I write about the human side of AI and what to do about it.</p>
</div>
</footer>
</article>
<NewsletterSignup />
</BaseLayout>
<style>
.article {
padding: 12rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.article-footer {
max-width: 720px;
margin: 4rem auto 0;
padding-top: 2rem;
border-top: 1px solid var(--color-border);
}
.article-cta {
text-align: center;
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.article-cta a {
color: var(--color-green);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -1,116 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Strip Mining is Happening Right Now"
description="Strip-mining of people isn't a future risk — it's already happening in every org that treats AI as headcount reduction."
ogType="article"
canonicalUrl="/blog/strip-mining-happening-right-now"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 7, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h1>The Strip Mining is Happening Right Now</h1>
</header>
<div class="post-content">
<p class="lead-question">Why are so many "efficient" companies already dying?</p>
<p>You have seen the headlines. A Fortune 500 company announces 12,000 layoffs; the stock jumps three percent. A unicorn startup replaces its content team with two AI tools and a contractor. A bank closes twelve branches, citing "digital transformation," and no one asks what walked out the door with those employees.</p>
<p>Strip-mining of people is not a future risk. It is happening right now.</p>
<h2>The illusion of efficiency</h2>
<p>Organizations treat AI as a headcount reduction lever. They see a model that writes code, drafts emails, or summarizes reports, and their first instinct is to divide headcount by the tool's hourly cost. The math looks clean on a spreadsheet. The damage does not show up until quarters later, and by then the decision-makers have already collected their bonuses.</p>
<p>What actually leaves the building is not just labor. It is institutional memory; it is the person who knows why that legacy integration fails every March; it is the engineer who can read a stack trace and know which team to call without opening Slack; it is the manager who spent six years building trust with a critical vendor.</p>
<p>That knowledge does not live in Confluence. It lives in people. When you treat AI as a replacement instead of an amplifier, you are not optimizing. You are extracting.</p>
<h2>The compounding cost</h2>
<p>Strip-mining creates a debt that compounds invisibly. The first quarter looks great. Costs are down; margins are up. The second quarter, escalations take longer because the person who knew the context is gone. The third quarter, a production incident lasts six hours instead of thirty minutes because the engineer who built the original system is now at a competitor. By the fourth quarter, the remaining team is burned out from covering gaps they did not create, and your best people start leaving.</p>
<p>This is soil depletion. You cannot measure it by this quarter's yield. You measure it by what grows next season, and next season, nothing grows.</p>
<h2>Real examples, no names needed</h2>
<p>You know these organizations. The retailer that replaced its buying team with demand-forecasting AI and then could not explain why Q3 inventory missed by forty percent. The SaaS company that automated Tier-1 support and watched its Net Promoter Score collapse because customers could not reach anyone who understood their setup. The fintech that cut its risk team in half after deploying a compliance model, only to have that model miss a pattern the senior analyst would have caught in ten minutes.</p>
<p>None of these are hypothetical. They are happening now, and the pattern is consistent: replace first, understand second, regret third.</p>
<h2>You cannot replant in depleted soil</h2>
<p>The cultivation alternative is not about sentiment. It is about economics that actually compound. When you augment people with AI, you keep the context and multiply the output. When you replace people with AI, you lose the context and eventually discover that the model cannot maintain what it did not build.</p>
<p>Soil does not replenish itself. You have to choose, quarter after quarter, to invest in it. The organizations that survive this transition will not be the ones that cut fastest. They will be the ones that learned how to cultivate while everyone else was still stripping.</p>
<p>The strip-mining is happening right now. The only question is which side of it your organization is on.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 4rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 2.75rem);
color: var(--color-brown-dark);
margin: 0;
line-height: 1.2;
}
.post-content p {
margin-bottom: 1.5rem;
line-height: 1.8;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.lead-question {
font-size: 1.15rem;
font-style: italic;
color: var(--color-text-muted);
border-left: 3px solid var(--color-amber);
padding-left: 1rem;
margin-bottom: 2rem !important;
}
</style>

View file

@ -1,184 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Three Signs Your Team Is Being Strip-Mined"
description="The mindset shift that separates thriving teams from burned-out ones — cultivation over extraction."
ogType="article"
canonicalUrl="/blog/strip-mining-signs"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 5, 2026</span>
<span class="article-tag">Teams</span>
</div>
<h1>Three Signs Your Team Is Being Strip-Mined</h1>
<p class="article-subtitle">
The mindset shift that separates thriving teams from burned-out ones — cultivation over extraction.
</p>
</header>
<div class="article-body">
<p>I first heard the term "strip-mining" applied to teams from an engineering director at a mid-size fintech company. She'd just lost three senior engineers in two months. When I asked what happened, she didn't talk about compensation or competing offers. She said: "We were strip-mining them. We just didn't call it that."</p>
<p>Strip-mining in software isn't about tools or processes. It's about a mindset: extract maximum value from each person, measure throughput, and replace when depleted. It works until it doesn't — and when it breaks, it breaks fast.</p>
<h2>Sign 1: Velocity Is Up, Satisfaction Is Down</h2>
<p>This is the canary in the coal mine. When your sprint velocity charts keep climbing but your team's engagement is flat or falling, you're not becoming more efficient. You're extracting harder.</p>
<p>The pattern is familiar: same team, more output, less joy. Engineers who used to debate architecture now just close tickets. Standups that used to surface real problems now produce status updates. The work is getting done, but nobody cares about it anymore.</p>
<p>If your metrics are up and your people are down, you're not optimizing. You're extracting.</p>
<h2>Sign 2: Knowledge Is Concentrated, Not Distributed</h2>
<p>Healthy teams spread knowledge. Strip-mined teams hoard it — not because people are selfish, but because there's no time or incentive to teach. Senior engineers become bottlenecks not because they want to, but because nobody else was given the space to learn.</p>
<p>Ask yourself: when was the last time someone on your team learned something new because they had time, not because they were forced? If the answer is measured in quarters, not weeks, your soil is depleted.</p>
<h2>Sign 3: Departures Cluster Around the Same Moment</h2>
<p>In strip-mined teams, attrition doesn't follow a normal distribution. It clusters. Three people leave in six weeks. Then nothing for a year. Then four more.</p>
<p>Why? Because teams talk. When one person decides they've had enough, they tell the others. The decision to leave becomes contagious — not because people are followers, but because the conditions that pushed the first person out are still there. Everyone else was just waiting to see if it was them or the system.</p>
<h2>The Cultivation Alternative</h2>
<p>Cultivation isn't the opposite of productivity. It's the opposite of extraction. Cultivated teams ship more over time because they get stronger, not because they get squeezed harder.</p>
<p>The shift from extraction to cultivation is simple to describe and hard to do: invest in your people like you invest in your infrastructure. Not with perks and team-building. With time, autonomy, and real ownership over meaningful work.</p>
<p><strong>The test:</strong> Would your best engineer be a better engineer in six months if they stayed? If you can't answer yes with confidence, you're cultivating by accident, not by design.</p>
<p><a href="/consulting">Learn about the Soil Assessment →</a></p>
</div>
<footer class="article-footer">
<div class="article-cta">
<p>Want to continue this conversation? <a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener">Connect with me on LinkedIn</a> — I write about the human side of AI and what to do about it.</p>
</div>
</footer>
</article>
</BaseLayout>
<style>
.article {
padding: 12rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.article-cta {
text-align: center;
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.article-cta a {
color: var(--color-green);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -3,141 +3,327 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Surveillance Dividend Is a Lie"
description="You're being strip-mined, but you'd rather be cultivated. Here's how to lead in that direction from where you are."
title="The Surveillance Dividend Is a Lie — Scott Scoble"
description="Every company running AI adoption is making an implicit bargain: data for tools. The companies extracting the most surveillance are hemorrhaging their best talent."
ogType="article"
canonicalUrl="/blog/surveillance-extraction"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Leadership</span>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">Leadership</span>
</div>
<h1>The Surveillance Dividend Is a Lie</h1>
<p class="article-subtitle">
Every company running AI adoption is making an implicit bargain: data for tools. The companies extracting the most surveillance are hemorrhaging their best talent.
</p>
</header>
<div class="post-content">
<p>I'm not the only one who's noticed the quiet. The kind that lands on a team the week the productivity dashboard goes live. Not angry. Not checked out. Just quiet. Engineers stop arguing about architecture because arguing about architecture doesn't show up on the scoreboard. They stop mentoring juniors between standups. They optimize for what gets counted.</p>
<div class="article-body">
<h2>The Trade Nobody Asked For</h2>
<p>
Every company running "AI adoption" initiatives is making the same implicit bargain with their employees:
</p>
<p>
<em>You give us more data about how you work. We give you tools that make you faster. Everyone wins.</em>
</p>
<p>
Except nobody's winning. The employees are burning out. The tools are surveilling. And the productivity numbers everyone's celebrating? They're measuring output volume, not output value.
</p>
<p>
I've spent the past month talking to engineers, managers, and executives about what AI is actually doing to their teams. The pattern is unmistakable: <strong>the companies extracting the most surveillance data are hemorrhaging their best talent.</strong>
</p>
<p>That quiet is a signal. It's what happens when people realize they're being strip-mined. The question isn't whether strip-mining is bad. It's what you do when you realize you've been handed a shovel and told to dig.</p>
<h2>The Extraction Pipeline</h2>
<p>
Here's how it works in practice:
</p>
<p>You put the shovel down. Not in protest. In recognition that digging faster doesn't change the arrangement. The arrangement is the problem, not the pace.</p>
<h3>Step 1: Instrument everything</h3>
<p>
Your IDE tracks keystrokes. Your chat platform logs prompt history. Your code review tool measures time-to-merge. Your project management system tracks velocity. Every tool generates a "productivity dashboard" that tells leadership exactly how many units of work each person produced.
</p>
<p>Strip-mining is efficient. That's the entire argument for it. It just kills the soil. Cultivation builds soil. Takes longer. Produces indefinitely.</p>
<h3>Step 2: Optimize for the metric</h3>
<p>
Once the dashboard exists, it becomes the scoreboard. Standups shift from "what are you working on" to "why is your velocity down 12% this sprint." Engineers learn that the number matters more than the architecture. So they optimize for the number — generate more code, close more tickets, move faster.
</p>
<p>The productivity dashboard is a marvel. It turns everything that matters about engineering into something that doesn't, then puts a number on it. Velocity, throughput, lines of code, time-to-merge. None of them measure judgment. None of them measure the architect who saved the team six months by choosing the wrong-right framework and catching it early. None of them measure the senior who kept a junior from quitting.</p>
<h3>Step 3: Strip the soil</h3>
<p>
The AI tools amplify this feedback loop. Generate more code. Accept more suggestions. Ship faster. The engineer stops designing. They start assembling. The craft of software engineering — the part where you sit with a problem, understand it deeply, and build something elegant — gets replaced by prompt-and-accept loops.
</p>
<p>If you're leading a team under surveillance, you have more leverage than you think. Not leverage to fight the system. Leverage to redirect it. Here's what that looks like.</p>
<h3>Step 4: Wonder why everyone's quitting</h3>
<p>
Six months in, your most experienced engineers hand in notice. Not because the pay is bad. Not because the perks dried up. Because they don't recognize their own work anymore. They're assembly line workers in a factory they used to design.
</p>
<p>First: stop measuring what's measurable and start measuring what's meaningful. Ask your team one question at the end of each iteration: are you proud of what we shipped? That's not a metric. It's a judgment call. No dashboard for it. That's the point. A team that tracks pride instead of velocity will tell you when the soil is tired. A velocity tracker won't.</p>
<h2>The Soil Beneath the Code</h2>
<p>
This is where it connects to something I've been thinking about for a long time: <strong>cultivation versus strip mining.</strong>
</p>
<p>
Strip mining is efficient. You extract the maximum resource in the minimum time. The numbers look incredible for a few quarters. Then the soil is dead, the water is contaminated, and the land produces nothing.
</p>
<p>
Cultivation is slower. It requires attention to soil health, to rotation, to rest. It doesn't maximize short-term yield. But it produces indefinitely.
</p>
<p>
The surveillance-driven AI adoption playbook is strip mining applied to human beings. You instrument, you optimize, you extract. The dashboards look amazing. The humans are dying.
</p>
<p>
And here's the part nobody's saying out loud: <strong>the surveillance tools aren't even measuring the right things.</strong> They measure volume. Volume of code. Volume of commits. Volume of tickets closed. But the value of an engineer isn't in volume — it's in judgment. It's in knowing what NOT to build. It's in catching the architectural decision that would have cost six months of rewrites. It's in mentoring the junior engineer who was about to quit.
</p>
<p>
None of that shows up on a dashboard.
</p>
<p>Second: protect the four-hour window. No Slack. No meetings. No AI suggestions. Let engineers sit with hard problems. The surveillance tools will still be there when they surface. What changes is what happens in between — real work, real thinking, real architecture. You can't measure what grows in silence. You can only kill it by filling the silence.</p>
<h2>The Disengagement Tax</h2>
<p>
Remember the Gallup numbers from <a href="/blog/ai-brain-fry">my last piece</a>? 80% global disengagement. $438 billion in lost productivity.
</p>
<p>
Here's what I didn't say: engagement isn't just about burnout. It's about <strong>agency</strong>. People disengage when they feel like they've lost control over their work. When every move is tracked, every decision is second-guessed by a dashboard, every creative act is reduced to a data point — agency evaporates.
</p>
<p>
The Harvard Business Review found something striking: employees under heavy surveillance show 47% lower psychological safety scores. They stop proposing ideas. They stop questioning decisions. They stop doing the thing that makes them valuable — thinking independently.
</p>
<p>
So the surveillance pipeline produces exactly the opposite of what it promises: more data, less insight. More output, less value. More tracking, less trust.
</p>
<p>Third: audit every tool for extraction. Before adopting any AI tool, ask: what data does it collect? Where does that data go? Is it used to train models that will replace your team? If the answer to any of these isn't crystal clear and favorable to your people, don't adopt it. Your team will notice that you asked.</p>
<h2>What Cultivation Looks Like Instead</h2>
<p>
Here's the alternative. It's not complicated, but it requires leadership courage:
</p>
<p>Fear-based development is the condition now. Not stress. Not burnout. Fear. The dashboard creates it. The AI tools amplify it. The surveillance pipeline hardens it. Your brain isn't broken; it's reconfiguring from producing to directing. That's painful. That's growth. Most people focus on the pain instead of looking forward through it.</p>
<h3>Measure outcomes, not activity</h3>
<p>
Did the system become more reliable? Did customers report fewer bugs? Did the team ship something users actually wanted? These are harder to measure than lines of code. They're also the only ones that matter.
</p>
<p>Forward is the word. Not ahead. Not onward. Forward. Direction with momentum.</p>
<h3>Protect deep work</h3>
<p>
Block off four-hour windows with no Slack, no meetings, no AI suggestions. Let engineers sit with hard problems. The AI tools will still be there when they emerge.
</p>
<p>Elijah called down fire from heaven. Then he prayed for death. Most leadership advice sells you the first part and skips the second. Cultivation doesn't skip the cost. It orients it forward. The cost of redirecting a surveillance culture isn't a meeting. It's a decision about what you will and won't measure. It's telling your manager that the dashboard is creating fear, not focus. It's backing that up with outcomes instead of arguments.</p>
<h3>Audit the tools for extraction</h3>
<p>
Before adopting any AI tool, ask: what data does it collect? Where does that data go? Is it used to train models that will replace my team? Is it used to build a surveillance profile? If the answer to any of these isn't crystal clear and favorable to your people, don't adopt it.
</p>
<p>Strip-mining asks how much can be extracted today. Cultivation asks what grows from this. The choice isn't between good numbers and bad numbers. It's between what works for this quarter and what works for this decade.</p>
<h3>Trust first, verify thoughtfully</h3>
<p>
The best engineering teams I've seen don't track keystrokes. They track whether the team is proud of what they shipped. Trust is a cultivation practice. You can't dashboard your way to it.
</p>
<p>You already know which one you'd rather build. The question is what you do on Tuesday morning.</p>
<h2>The Bottom Line</h2>
<p>
The companies winning the AI transition aren't the ones with the best surveillance dashboards. They're the ones whose engineers still feel like engineers — not assembly line workers being monitored for throughput.
</p>
<p>
If your AI strategy starts with "how do we measure productivity," you've already lost. Start with "how do we make our people better at their craft." The productivity will follow. The data will be messier. The dashboards will be sparser. And your best people will stay.
</p>
<p>That's yours. Not mine to answer.</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<div class="cta-box">
<h3>Feeling the surveillance squeeze?</h3>
<p>
I help engineering teams navigate the AI transition without strip-mining their people. If your team is struggling with AI surveillance culture, let's talk about what cultivation looks like in practice.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.post {
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
margin: 0 auto 3rem;
text-align: center;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
.article-date {
color: var(--color-text-muted);
}
.post-tag {
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.post-header h1 {
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
margin: 0;
}
.post-content {
font-size: 1.125rem;
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.post-content p {
margin: 0 0 1.5rem;
}
.post-content h2 {
.article-body h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
letter-spacing: -0.01em;
margin: 3rem 0 1rem;
}
.post-content blockquote {
border-left: 3px solid var(--color-amber);
padding: 1.25rem 1.5rem;
margin: 2rem 0;
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-xl) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
font-style: italic;
font-size: 1.2rem;
line-height: 1.7;
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.post-content blockquote p {
margin: 0;
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.post-content ol {
margin: 0 0 1.5rem;
padding-left: 1.5rem;
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.post-content ol li {
margin-bottom: 1rem;
line-height: 1.7;
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.post-content ol li strong {
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
@media (max-width: 639px) {
.post {
padding: 5rem 1.25rem 3rem;
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0 0 1.5rem;
}
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
.cta-button:hover {
background: var(--color-amber-light);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -1,252 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Soil Beneath the Code"
description="A three-layer framework for understanding what makes engineering organizations healthy — or not."
ogType="article"
canonicalUrl="/blog/the-soil-beneath-the-code"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">April 28, 2026</span>
<span class="article-tag">Engineering</span>
</div>
<h1>The Soil Beneath the Code</h1>
<p class="article-subtitle">
A three-layer framework for understanding what makes engineering organizations healthy — or not.
</p>
</header>
<div class="article-content">
<p class="lead">
Every retrospective reaches the same conclusion. Something about communication. Something about process. Action items get written. Nothing changes. Because you're treating leaves, not soil.
</p>
<h2>The Soil Diagnostic</h2>
<p>
Soil health is the capacity of your team's environment to sustain growth. Three layers:
</p>
<p><strong>Nutrients</strong> — Skills, knowledge, domain expertise. What your team knows how to do.</p>
<p><strong>Structure</strong> — Relationships, handoffs, decision paths. How work moves through the system.</p>
<p><strong>Microbiome</strong> — Trust, psychological safety, shared purpose. What makes people stay.</p>
<p>
When any layer depletes, symptoms appear at the surface. Burnout. Attrition. Missed deadlines. These are not the problem. These are the crop failing.
</p>
<h2>The Misdiagnosis Pattern</h2>
<p>
Most teams treat surface symptoms. More process. More tools. More hires. None of it checks what's actually depleted underneath.
</p>
<p>
This is strip-mining: extracting capability without replenishing the source. You ship faster this quarter. You lose the capacity to ship next quarter. Repeat until the farm is dead.
</p>
<p>
The irony of strip-mining is that it produces record yields right before collapse. Your velocity metrics look great. Your retention doesn't.
</p>
<h2>Layer 1: Nutrients — The Skills Layer</h2>
<p><strong>Depletion symptoms:</strong></p>
<ul>
<li>Knowledge silos form</li>
<li>"Bus factor" risks emerge</li>
<li>Onboarding takes longer</li>
<li>"We used to know how to do this" becomes common</li>
</ul>
<p>
<strong>Example:</strong> Your senior architect leaves. The tribal knowledge about the legacy system walks out with them. New hires take six months to become productive instead of six weeks.
</p>
<p>
<strong>Consequence:</strong> You hire more people to compensate for the knowledge gap. The team grows, but capacity doesn't.
</p>
<h2>Layer 2: Structure — The Workflow Layer</h2>
<p><strong>Depletion symptoms:</strong></p>
<ul>
<li>Meetings multiply</li>
<li>Handoffs become bottlenecks</li>
<li>"Who owns this?" becomes a daily question</li>
<li>Decision latency increases</li>
</ul>
<p>
<strong>Example:</strong> What used to be a five-minute Slack conversation now requires a 30-minute meeting with five people. The work hasn't changed. The structure has eroded.
</p>
<p>
<strong>Consequence:</strong> You add more process to compensate. The process slows things down further. The death spiral accelerates.
</p>
<h2>Layer 3: Microbiome — The Trust Layer</h2>
<p><strong>Depletion symptoms:</strong></p>
<ul>
<li>Psychological safety erodes</li>
<li>Risk-taking disappears</li>
<li>"That's not my job" becomes the default</li>
<li>Retrospectives turn into complaint sessions</li>
</ul>
<p>
<strong>Example:</strong> No one speaks up in the architecture review. The flaws ship to production. The post-mortem turns into a blame session. Trust depletes further.
</p>
<p>
<strong>Consequence:</strong> Innovation stalls. The best people leave. You're left with a team that executes but doesn't create.
</p>
<h2>The Nitrogen Fixer Signal</h2>
<p>
In agriculture, nitrogen fixers are plants that pull nutrients from the air and deposit them in the soil. They make the ground fertile for everything around them.
</p>
<p>
On engineering teams, nitrogen fixers are the people who hold systems together invisibly. They document the thing nobody else will. They onboard the new hire. They bridge the two teams that stopped talking six months ago.
</p>
<p>
Their work doesn't show up in sprint velocity. It shows up in the absence of catastrophe.
</p>
<p>
<strong>Here's the signal:</strong> The person who held three systems together just quit. Now you need three specialists to replace her. That's not a hiring problem. That's a soil problem.
</p>
<p>
Culture is a capital expense. Replacing one generalist who held three systems costs three specialists you now have to hire. The math isn't subtle.
</p>
<h2>Cultivation, Not Extraction</h2>
<p>
The alternative to strip-mining is cultivation. Cultivation starts with assessment. What's depleted? What's over-fertilized? What's being strip-mined right now?
</p>
<p>
Assessment solves misdiagnosis. You stop prescribing process for a trust problem. You stop hiring for a structure problem. You see the system as it is — not as the last retrospective described it.
</p>
<p>
Cultivation doesn't mean going slow. It means knowing what you're growing. A team with healthy soil ships faster <em>because</em> the structure holds, not in spite of it.
</p>
<h2>The Soil Assessment</h2>
<p>
Two weeks. Twenty-five hundred dollars. You'll know exactly which layer is depleted, what's being strip-mined, and what to fix first. No framework adoption. No personality test. A diagnostic that makes structural problems visible.
</p>
<div class="cta-box">
<p>Want to continue this conversation? <a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener" class="btn btn-primary">Connect with me on LinkedIn</a> — I write about the human side of AI and what to do about it.</p>
</div>
</div>
</article>
</BaseLayout>
<style>
.article {
max-width: 680px;
margin: 0 auto;
padding: 12rem 1.5rem 6rem;
}
.article-header {
margin-bottom: 3rem;
}
.article-meta {
display: flex;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
}
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 5vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: 1.25rem;
color: var(--color-text-muted);
margin: 0;
line-height: 1.5;
}
.article-content {
font-size: 1.125rem;
line-height: 1.8;
}
.article-content .lead {
font-size: 1.25rem;
color: var(--color-brown-dark);
margin-bottom: 2rem;
}
.article-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.article-content p {
margin-bottom: 1.25rem;
}
.article-content ul {
margin-bottom: 1.25rem;
padding-left: 1.5rem;
}
.article-content li {
margin-bottom: 0.5rem;
}
.cta-box {
margin: 2rem 0;
padding: 1.5rem;
background: var(--color-cream);
border-radius: 8px;
text-align: center;
}
.btn-primary {
display: inline-block;
padding: 0.875rem 1.5rem;
background: var(--color-amber);
color: var(--color-brown-dark);
font-weight: 600;
text-decoration: none;
border-radius: 6px;
transition: background 0.2s ease;
}
.btn-primary:hover {
background: var(--color-amber-dark);
}
</style>

View file

@ -1,121 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Taste Problem: What Dark Factories Can't Transfer"
description="A dark factory can transfer code. It cannot transfer the judgment that knew the code was right. That is the problem provenance was invented to solve."
ogType="article"
canonicalUrl="/blog/the-taste-problem"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">June 29, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>The Taste Problem: What Dark Factories Can't Transfer</h1>
</header>
<div class="post-content">
<p class="lead-question">A dark factory can ship code. It cannot ship the judgment that knew the code was right.</p>
<p>That is taste. Taste is the human judgment that knows the right shape of a system before it exists.</p>
<h2>Why the dark factory has a taste problem</h2>
<p>A dark factory takes a spec and produces an artifact. The artifact is the part the factory can verify. The spec is the part the factory cannot verify, because the spec is the part the human wrote.</p>
<p>If the spec is wrong, the artifact is wrong. The factory will produce the wrong artifact at the same speed it produces the right one. The factory is the wrong shape of the wrong thing faster than any human could.</p>
<p>Teams discover this eventually. The factory is shipping. The customers are complaining. The metrics are flat. Someone looks at the artifacts and realizes the artifacts are exactly what the specs said to build. The specs are exactly what the engineers wrote. The engineers wrote what the market asked for. The market asked for the wrong thing. The factory shipped the wrong thing at scale.</p>
<p>The factory did not break. The factory did what it was told. The factory is not the failure mode. The factory is the amplifier. The judgment that was missing is the failure mode. The factory just made the missing judgment load-bearing.</p>
<h2>What "encode taste" actually means</h2>
<p>There is a school of thought that says you can encode taste into the spec. The spec gets more detailed. The spec captures the shape. The spec becomes the artifact's design doc, and the design doc gets reviewed.</p>
<p>That school of thought is half right. Some taste encodes. Naming conventions, layering, error handling, the explicit invariants. The encoded taste transfers through the factory. The factory produces artifacts that respect the encoded taste. The encoded taste shows up in the artifact's diff.</p>
<p>The other half of taste does not encode. The other half is the part the senior engineer carries and cannot articulate. It is the part that knows the function should be three things, not one, before the function is written. It is the part that knows this commit is going to cause the next three. It is the part that knows the customer is asking for X but they need Y.</p>
<p>You cannot encode that. You can write it down. You can review it. You can put it in a code review checklist. None of those things make it transfer. They make it visible. Visible is not the same as transferred.</p>
<h2>Provenance is the bridge, not the solution</h2>
<p>Provenance gets talked about as if it solves the taste problem. It does not. Provenance tells you where the artifact came from. Provenance does not tell you whether the spec was right.</p>
<p>What provenance does is make the missing judgment legible. When the artifact fails, the provenance graph tells you which spec element the failure traces back to. The auditor can then ask: was that spec element the right call? The question is answerable. The answer is in the spec, not in the artifact.</p>
<p>A microscope does not cure disease. A microscope tells you what disease you have. In a dark factory, the microscope is the only thing that keeps the missing judgment from being invisible until it is too late.</p>
<h2>The two kinds of taste</h2>
<p>Encoded taste is the part that goes in the spec. It transfers. It is reviewable. It is the part the factory can carry forward. The senior engineer's job is to push as much taste as possible into this category. Most of what we call code review is the act of pushing taste from the implicit category to the explicit one.</p>
<p>Unencoded taste is the part that does not go in the spec. It does not transfer. It is reviewable only by other senior engineers who carry the same unencoded taste. It is the part that gets lost when a senior engineer leaves. It is the part that no dark factory, no matter how sophisticated, can carry.</p>
<p>The dark factory does not have to carry the unencoded taste. The dark factory has to make the unencoded taste visible, so the human's audit can find the missing pieces.</p>
<p>You cannot hire your way out of this. You cannot vendor your way out of this. You can only become the kind of engineer whose taste transfers through the spec, and accept that the rest of it has to stay in the audit.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.lead-question {
font-size: 1.25rem;
font-weight: 600;
color: var(--color-brown-dark);
margin-bottom: 1.5rem;
line-height: 1.5;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.post-content p {
line-height: 1.7;
margin-bottom: 1.25rem;
}
.post-content strong {
color: var(--color-brown-dark);
}
</style>

View file

@ -1,175 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Three Questions That Changed How I Mentor"
description="The simple mentoring framework that actually gets used: three questions that unlock real growth."
ogType="article"
canonicalUrl="/blog/three-questions-mentoring"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 5, 2026</span>
<span class="article-tag">Leadership</span>
</div>
<h1>Three Questions That Changed How I Mentor</h1>
<p class="article-subtitle">
The simple mentoring framework that actually gets used — three questions that unlock real growth.
</p>
</header>
<div class="article-body">
<p>I've been mentoring engineers for 15 years. I've read the books. I've done the frameworks. I've sat through sessions where we mapped career ladders and OKRs and growth plans. Most of it was noise.</p>
<p>What actually worked was three questions. That's it. No worksheets, no templates, no quarterly reviews. Just three questions that change the conversation from "How am I doing?" to "What am I building?"</p>
<h2>The Three Questions</h2>
<p><strong>1. What are you building?</strong></p>
<p>Not "What are you working on?" Building implies ownership. Intent. Stakes. The answer tells me whether they see their work as craft or as tasks. If they can't answer in terms of impact — "I'm building a payment flow that reduces checkout friction" — we need to zoom out before we zoom in on skills.</p>
<p><strong>2. What's getting in your way?</strong></p>
<p>Not "What are your blockers?" Blockers are Jira tickets. Obstacles are human: unclear authority, a broken relationship with PM, burnout they can't name yet. This question surfaces the real problems — usually interpersonal or structural — that no amount of skill-building will solve.</p>
<p><strong>3. What do you want to be true in six months?</strong></p>
<p>Not "Where do you see yourself in five years?" That's a fantasy exercise. Six months is close enough to be real and far enough to require change. The answer becomes the North Star for our next conversations. We don't make a plan. We just keep asking.</p>
<h2>Why This Works</h2>
<p>Most mentoring frameworks are built for HR. They're designed to produce documentation: growth plans, competency maps, 360 feedback. The three questions are built for humans. They're designed to produce clarity.</p>
<p>The magic isn't in the questions themselves. It's in the repetition. Ask them every two weeks for six months and watch what happens. The person starts hearing the questions in their own head. They start mentoring themselves.</p>
<p>That's the point. The best mentoring relationship is one that makes itself obsolete.</p>
<p><a href="/books">Read more in <em>A Walk in Mentoring</em> →</a></p>
</div>
<footer class="article-footer">
<div class="article-cta">
<p>Want to continue this conversation? <a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener">Connect with me on LinkedIn</a> — I write about the human side of AI and what to do about it.</p>
</div>
</footer>
</article>
</BaseLayout>
<style>
.article {
padding: 12rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.article-cta {
text-align: center;
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.article-cta a {
color: var(--color-green);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

View file

@ -3,147 +3,98 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Token Anxiety Trap; Why AI Agents Aren't Liberating Us (Yet)"
description="Token anxiety is BS. If you know what you're doing and optimize for outcomes, token cost is meaningless."
title="The Token Anxiety Trap — Why AI Agents Aren't Liberating Us (Yet) — Scott Scoble"
description="Your agent swarm runs 24/7 and you're more anxious than ever. That has a name: token anxiety. Stanford 2026 data reveals the burnout behind AI productivity — and 3 questions to ask before your next agent run."
ogType="article"
canonicalUrl="/blog/token-anxiety"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 4, 2026</span>
<span class="post-tag">AI</span>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 4, 2026</span>
<span class="article-tag">AI</span>
</div>
<h1>The Token Anxiety Trap; Why AI Agents Aren't Liberating Us (Yet)</h1>
<h1>The Token Anxiety Trap — Why AI Agents Aren't Liberating Us (Yet)</h1>
<p class="article-subtitle">
Your agent swarm is running 24/7 and you're more anxious than ever. Stanford's 2026 AI Index reveals the human cost of the agent revolution — and what leaders can actually do about it.
</p>
</header>
<div class="post-content">
<blockquote class="lead-quote">
<p>Token anxiety is BS.</p>
</blockquote>
<div class="article-body">
<p>I've watched otherwise smart people build elaborate token-budget spreadsheets. Track their daily consumption like it's a calorie deficit. Set alerts when they hit 80% of their monthly allocation. Wake up with their hands already on the keyboard, calculating whether they're getting enough value per prompt.</p>
<p>Your agent swarm is running 24/7. You've got bots scraping Reddit at 6 AM, a resume updater, a competitor tracker, and a networking assistant that prompts you to follow up with people you forgot you met. You used to pay a human assistant in the Philippines. Now you just pay for tokens.</p>
<p>There's a name for this floating around the industry. Token anxiety. Tokenmaxxing. A thousand frameworks for managing the feeling that you're burning money on nothing.</p>
<p>And somehow, you're more anxious than ever.</p>
<p>None of those names name the thing that's actually happening. The thing that's actually happening is not knowing what you're doing. Token anxiety is the symptom; directionless work is the disease. And the soft version of this conversation validates the anxiety. Offers coping strategies. Three questions before your next agent run. Mindfulness for token burners. Journaling your prompt chain. None of that fixes the thing that's actually broken.</p>
<p>This isn't hypothetical. It's what's happening in Silicon Valley right now, and it's spreading. John Huang, a tech veteran who runs a startup investment network, has eight agents running simultaneously. Kevin Staight, a sales strategy lead, feels his "whole company should shut down and focus on this for about a month." Nikunj Kothari, a VC at FPV Ventures, has a name for what he sees everywhere in San Francisco:</p>
<p>Here's the math. If a token run costs five dollars and produces fifty thousand dollars of value, the tokens are free. If a token run costs five cents and produces nothing because the builder didn't know what they were building, the five cents was wasted. No amount of token optimization fixes the second case. No concern about the first case is rational.</p>
<p><strong>Token anxiety.</strong></p>
<p>The anxiety isn't about tokens. It's about directionless work dressed up as optimization. Easier to optimize the thing you can measure than to figure out what you should be doing. So people optimize tokens. Call it discipline. Call it being power users. Write blog posts about how to manage the anxiety.</p>
<p>Kothari describes it like this: "Everybody has this feeling of like, 'Hey, time is the only thing that matters. And in that given unit of time, which we don't get back, how can I have AI do a lot more for me than the next person?'"</p>
<p><strong>You don't manage the anxiety. You fix the direction.</strong></p>
<p>He sees people checking their agents during parties. At bars. Walking through Dolores Park with "the warm glow of the light" from laptops slightly open. He himself has replaced his evening Netflix time with Claude Code, dreaming up new tasks to automate. He has two young kids and admits: "I felt guilty because I'd be like, 'Oh, go to bed quickly so I can get back to my computer.'"</p>
<p>We automated the how without examining the why. Then called the resulting anxiety a problem with the how.</p>
<p>The agents were supposed to free us. Instead, they've given us a new way to work during every waking hour — and a new reason to feel inadequate.</p>
<p>Running toward something; you don't count steps. Measure distance to the goal. Steps are just what legs do. Running with no destination; every step feels like waste. Start counting. Optimize the counting. Not running anymore; just counting. Mistake the motion for the progress and defend the counting until you're out of breath.</p>
<h2>The Slot Machine Problem</h2>
<p>That's token anxiety.</p>
<p>Axios recently reported that AI agents "operate like slot machines" for power users. They produce just enough wins to keep you hooked — a clever automation here, a solved problem there — but the unpredictability means you keep pulling the lever. The wins are real, but so is the burnout.</p>
<p>The question isn't whether you're using your tokens well. The question is whether you know what you're building. If you do, burn the tokens; the cost disappears into the outcome. If you don't, no token strategy in the world saves you from the five cents you just wasted on nothing.</p>
<p>The Allen Institute's Tim Dettmers notes that peak productivity now comes from "working with as many agents as possible in parallel," which requires near-constant context switching. Humans, as it turns out, aren't great at that.</p>
<p>Your tokens aren't the bottleneck. Your direction is.</p>
<p>We're building tools that demand exactly the cognitive pattern we're worst at.</p>
<h2>The Junior Dev Canary</h2>
<p>Stanford's 2026 AI Index dropped a staggering number: <strong>employment among software developers aged 22–25 has dropped nearly 20% since 2024</strong>, even as older developers' headcount grows. The same pattern appears in customer service and other AI-exposed roles.</p>
<p>We're not just automating tasks. We're automating the entry-level jobs that used to be the on-ramp to entire careers. The mentors who would have trained those junior devs are busy managing their agent swarms. The code reviews that would have taught them are being done by Claude.</p>
<p>Eric Weber, a former data/AI lead at Grammarly (now Superhuman), puts it plainly: "The change has happened so quickly that I think it is disorienting for people. People are like, 'Am I good at what I do? What does it mean to be good at what I do?'"</p>
<p>The industry, he says, is in a collective identity crisis.</p>
<h2>Tokenmaxxing: When Companies Weaponize Your Anxiety</h2>
<p>The New York Times recently reported that some of the biggest tech companies are <strong>"tokenmaxxing"</strong> — pushing employees to burn through as many AI credits as possible to churn out features at an ever-faster pace.</p>
<p>Think about that word for a second. It's not "being productive." It's not "leveraging AI." It's <em>tokenmaxxing</em> — a term that sounds like it fell out of a crypto bro's group chat. It treats AI usage as a metric to optimize, not a tool to wield.</p>
<p>When your company measures your value in tokens burned, you stop asking whether you're building the right thing. You just keep burning tokens.</p>
<h2>What We're Not Asking</h2>
<p>Weber's observation cuts to the core: "What is causing a lot of stress for people is that doing more doesn't necessarily create more leverage or impact. You're just doing more stuff. And so we don't spend a lot of time on the question: what should you actually be doing?"</p>
<p>That's the question the agent revolution hasn't answered. We've automated the <em>how</em> without examining the <em>why</em>. We've built systems that maximize output while ignoring outcomes.</p>
<p>A month ago, Weber stepped back from his full-time executive role. He still uses agents, but he's spending more time thinking, writing, and talking to people. He's asking the question that the token economy doesn't want you to ask.</p>
<h2>Three Questions Before You Open That Laptop in the Park</h2>
<p>Token anxiety isn't inevitable. It's a design choice — in our tools, in our companies, and in our own habits. Here are three questions worth asking before you start your next agent run:</p>
<p><strong>1. What am I actually trying to accomplish?</strong> Not "what can I automate?" — what actually matters? If you can't articulate the outcome, the agent can't help you reach it. It can only make you busier.</p>
<p><strong>2. Is this replacing work or replacing thinking?</strong> Agents should handle the work you understand well enough to delegate. They shouldn't replace the thinking that determines what work is worth doing. The moment you outsource judgment, you've stopped leading and started managing tokens.</p>
<p><strong>3. Who am I not talking to right now?</strong> Every hour spent optimizing agent workflows is an hour not spent with your team, your family, your own thoughts. Weber stepped back to talk to people. Kothari catches himself rushing his kids to bed. The agent army doesn't need you to command it constantly. The people around you do.</p>
<hr />
<p>The promise of agentic AI wasn't that we'd work more. It was that we'd work on what matters.</p>
<p>We're not there yet. But the path isn't to throw away the agents. It's to remember who's supposed to be in charge.</p>
<p>So tell me what you're building. I'd like to hear it.</p>
</div>
<footer class="article-footer">
<div class="article-cta">
<p>Enjoyed this? <a href="/blog">Read more articles</a> on AI, leadership, and the human side of technology.</p>
<p>Ready to bring this thinking to your team? <a href="/contact">Let's talk.</a></p>
</div>
</footer>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.post-header {
margin-bottom: 3rem;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
line-height: 1.2;
margin: 0;
}
.post-content {
font-size: 1.125rem;
line-height: 1.8;
color: var(--color-text);
}
.post-content p {
margin: 0 0 1.5rem;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
letter-spacing: -0.01em;
}
.post-content blockquote {
border-left: 3px solid var(--color-amber);
padding: 1.25rem 1.5rem;
margin: 2rem 0;
background: var(--color-cream-warm);
font-style: italic;
font-size: 1.2rem;
line-height: 1.7;
}
.post-content blockquote p {
margin: 0;
}
.post-content .lead-quote {
font-size: 1.5rem;
font-style: normal;
font-weight: 500;
text-align: center;
border-left: none;
padding: 2rem 1.5rem;
margin: 2rem 0;
background: var(--color-brown-dark);
color: var(--color-cream);
border-radius: 6px;
}
.post-content .lead-quote p {
margin: 0;
}
@media (max-width: 639px) {
.post {
padding: 5rem 1.25rem 3rem;
}
.post-content .lead-quote {
font-size: 1.25rem;
padding: 1.5rem 1rem;
}
}
</style>
</BaseLayout>

View file

@ -1,131 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="What a Dark Factory Actually Is (and Isn't)"
description="The phrase is everywhere. The working meaning is gone. Here is what it is, what it isn't, and the five positions on the spectrum."
ogType="article"
canonicalUrl="/blog/what-is-a-dark-factory"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 22, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>What a Dark Factory Actually Is (and Isn't)</h1>
</header>
<div class="post-content">
<p class="lead-question">The phrase is everywhere. The working meaning is gone.</p>
<p>I sat down to write about software factories, and the first thing I had to do was take the word back. Every vendor has a "dark factory" slide. Every Devops team has a "lights-out deployment" demo. The phrase has been stripped the way "platform engineering" was stripped, the way "Devops" was stripped before that.</p>
<p>The marketing version: AI writes the code, the pipeline ships the code, humans go home early. That is a fantasy. It assumes the spec is correct, the spec is complete, the spec captures every invariant the running system has to preserve. None of those are true today.</p>
<p>The working version is a smaller claim, and a more useful one.</p>
<h2>The working definition</h2>
<p>A <strong>dark factory</strong> is a build pipeline that ships production software with no human in the critical path. Spec in, artifact out. The intermediate steps happen unattended.</p>
<p>The opposite is a <strong>light factory</strong>. Same inputs, same outputs, but a human signs off between every major stage. The human is the gate.</p>
<p>Many teams are not running either. They are running a partial factory. Some stages are dark; CI runs unattended. Some stages are light; the merge to main requires a reviewer. The work is figuring out which stages should be which, and what the seams look like.</p>
<h2>The five positions</h2>
<p>Treating "dark" and "light" as a binary loses the part that matters. The positions, named:</p>
<ol>
<li><strong>Manual.</strong> A person runs the commands. No factory yet; the engineer is the build system.</li>
<li><strong>Assisted.</strong> CI exists. Tests run. A person merges. Many teams live here and call it Devops.</li>
<li><strong>Light.</strong> Merge is gated by policy, not by reviewer. The pipeline is the gate. A human is the auditor, not the approver.</li>
<li><strong>Dark, gated.</strong> The pipeline ships. A human is the only one who can promote from staging to production. The factory runs, but it cannot cross a particular seam without a key turn.</li>
<li><strong>Dark, full.</strong> The pipeline ships. Promotion is policy-driven. The human's role is to write the policy and the spec, then to inspect the artifacts the factory produces.</li>
</ol>
<p>The interesting range is between three and four. The question is not how to get to five. The question is which of your stages should be at which position, and why.</p>
<h2>What the framing changes</h2>
<p>Calling it a factory reallocates where the engineering effort goes.</p>
<p>You stop asking who is on call for the deploy and start asking what the failure mode of the deploy step is. You stop asking how fast your engineers can merge and start asking how fast the policy can express a correct merge. You stop asking whether the code was reviewed and start asking whether the spec the code was generated from is auditable.</p>
<p>A factory is designed, not grown. A factory is maintained, not improvised. A factory has a failure budget, not a heroism budget.</p>
<p>If the build system you are running is a pile of bash scripts and a Slack channel, the factory framing is going to be uncomfortable. That is the point.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.lead-question {
font-size: 1.25rem;
font-weight: 600;
color: var(--color-brown-dark);
margin-bottom: 1.5rem;
line-height: 1.5;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.post-content p {
line-height: 1.7;
margin-bottom: 1.25rem;
}
.post-content ol,
.post-content ul {
line-height: 1.7;
margin-bottom: 1.25rem;
padding-left: 1.5rem;
}
.post-content li {
margin-bottom: 0.5rem;
}
.post-content a {
color: var(--color-amber);
text-decoration: underline;
}
</style>

View file

@ -1,136 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="Why Kubernetes for a Dark Factory"
description="A dark factory is a control loop. Kubernetes is the most boring control loop in production. That is the reason."
ogType="article"
canonicalUrl="/blog/why-kubernetes-for-dark-factory"
pageType="blog"
>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">June 11, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>Why Kubernetes for a Dark Factory</h1>
</header>
<div class="post-content">
<p class="lead-question">A dark factory is a control loop. Kubernetes is the most boring control loop in production. That is the reason.</p>
<h2>What the substrate has to do</h2>
<p>A dark factory has four requirements from whatever it runs on.</p>
<ol>
<li><strong>Declarative desired state.</strong> The system has to be able to say "I want N copies of this artifact running, signed, behind this policy," and have the substrate reconcile to that state unattended.</li>
<li><strong>Restart and replace as a primitive.</strong> Failures are the steady state. "Kill it and start a new one" has to be cheap, automatic, and observable.</li>
<li><strong>An operator-extensible control plane.</strong> The factory grows new resource types as the system grows. The substrate has to treat those types as first-class, not as jobs squashed into the lowest common denominator.</li>
<li><strong>Boring upgrades.</strong> The factory runs unattended. The substrate cannot require a person to read release notes on a Saturday.</li>
</ol>
<p>Kubernetes is not special because it is fast, or because it scales, or because it is cloud-native. Kubernetes is special because it is the only widely-deployed substrate that makes all four of those requirements boring.</p>
<h2>Why the alternatives fall short</h2>
<p><strong>Serverless</strong> (Lambda, Cloud Functions, Workers) gets close on restart-and-replace. It fails on declarative desired state. The platform owns the loop, not you. The moment you need a custom resource type, the platform tells you no. A factory that wants to define a <code>BuildRun</code> cannot do it on Lambda.</p>
<p><strong>Systemd on a VM</strong> gets close on boring upgrades. It fails on the operator-extensible control plane. The minute you want a custom resource type, you are writing your own reconciler. You are now maintaining a control plane in addition to the factory. The single engineer does not have that time.</p>
<p><strong>Nomad</strong> is the most underrated of the three. Nomad is what Kubernetes would look like if HashiCorp had cared more about operator patterns and less about service mesh. Nomad is excellent. Nomad is also a single-vendor system, and the ecosystem of pre-built operators and CRDs does not exist. You will build everything from scratch.</p>
<p><strong>Docker Compose on a single host</strong> works until the host dies. Then the dark factory is dark in a different sense. The lights are off. The artifact is gone. You find out what your backup posture actually is.</p>
<h2>The single-engineer argument</h2>
<p>An operator is a reconciler. The operator watches a custom resource. The operator makes the cluster match the resource. The operator is written in Go and packaged as a container. The operator runs the same way the artifact runs. The operator is part of the factory.</p>
<p>A platform team cannot build a custom resource type faster than a single engineer with an operator template. The single engineer's bottleneck is the spec, not the infrastructure. The infrastructure is the easy part. The hard part is figuring out what the factory should do, and that is the same problem at any team size.</p>
<h2>What Kubernetes does not give you</h2>
<p>Kubernetes does not give you a factory. Kubernetes gives you a substrate on which a factory can be built. The gap between "I have a cluster" and "I have a factory" is where the operator pattern lives.</p>
<p>Kubernetes also does not give you provenance. The cluster will run whatever artifact you give it. The cluster does not know where the artifact came from. The cluster does not know whether the artifact was generated from a spec, or by a human, or by a model with no spec. The cluster does not care. Provenance is a layer above the substrate, and that is where the dark factory actually lives.</p>
<p>If you are a single engineer trying to build a dark factory, the choice of substrate is not really a choice. Kubernetes is the answer. The interesting work is what you build on top of it.</p>
</div>
</article>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.lead-question {
font-size: 1.25rem;
font-weight: 600;
color: var(--color-brown-dark);
margin-bottom: 1.5rem;
line-height: 1.5;
}
.post-content h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 2.5rem 0 1rem;
}
.post-content p {
line-height: 1.7;
margin-bottom: 1.25rem;
}
.post-content ol,
.post-content ul {
line-height: 1.7;
margin-bottom: 1.25rem;
padding-left: 1.5rem;
}
.post-content li {
margin-bottom: 0.5rem;
}
.post-content code {
background: var(--color-cream);
padding: 0.125rem 0.375rem;
border-radius: 4px;
font-size: 0.9em;
}
.post-content strong {
color: var(--color-brown-dark);
}
</style>

View file

@ -23,7 +23,7 @@ import SharedForm from '../components/Form/SharedForm.astro';
<article class="book-card">
<div class="book-cover">
<img src="/images/book-cover-soil.webp" alt="The Soil Beneath the Code book cover" width="150" height="225" loading="lazy" />
<span>📚</span>
</div>
<h2>The Soil Beneath the Code</h2>
<p class="book-meta">Published 2023</p>
@ -31,13 +31,14 @@ import SharedForm from '../components/Form/SharedForm.astro';
<p class="book-quote">"A cultivation playbook for technical leaders who are tired of strip-mining their teams."</p>
<div class="book-links">
<a href="https://a.co/d/0226o4Hg" class="book-link">Get it on Amazon</a>
<a href="#" class="book-link">Amazon</a>
<a href="#" class="book-link">Publisher</a>
</div>
</article>
<article class="book-card">
<div class="book-cover">
<img src="/images/book-cover-walk.webp" alt="A Walk in Mentoring book cover" width="150" height="225" loading="lazy" />
<span>🚶</span>
</div>
<h2>A Walk in Mentoring</h2>
<p class="book-meta">Published 2024</p>
@ -45,10 +46,23 @@ import SharedForm from '../components/Form/SharedForm.astro';
<p class="book-quote">"The simplest mentoring framework you'll actually use."</p>
<div class="book-links">
<a href="https://a.co/d/0bRKZeUV" class="book-link">Get it on Amazon</a>
<a href="#" class="book-link">Amazon</a>
<a href="#" class="book-link">Publisher</a>
</div>
</article>
<article class="book-card coming-soon">
<div class="book-cover">
<span>🔍</span>
</div>
<h2>Dark Provenance</h2>
<p class="book-meta">Coming 2026</p>
<p class="book-description">Formal verification for the AI age. How to audit what your AI actually did.</p>
<p class="book-quote">"Speckl and the dark provenance system. A new approach to AI accountability."</p>
<SharedForm type="waitlist" />
</article>
</div>
</div>
</section>
@ -58,7 +72,7 @@ import SharedForm from '../components/Form/SharedForm.astro';
<style>
.hero {
background: var(--color-cream);
padding: 12rem 2rem 6rem;
padding: 4rem 2rem;
text-align: center;
}
@ -104,16 +118,10 @@ import SharedForm from '../components/Form/SharedForm.astro';
}
.book-cover {
font-size: 4rem;
margin-bottom: 1.5rem;
}
.book-cover img {
width: 150px;
height: auto;
border-radius: 4px;
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}
.book-card h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
@ -158,12 +166,6 @@ import SharedForm from '../components/Form/SharedForm.astro';
text-decoration: underline;
}
.waitlist-info {
font-size: 0.9375rem;
color: var(--color-text-muted);
margin: 0 0 0.75rem;
}
.waitlist-btn {
display: inline-block;
background: var(--color-brown);

View file

@ -32,7 +32,7 @@ import PackageCard from '../components/PackageCard.astro';
"90-day cultivation roadmap",
"Follow-up recommendations"
]}
priceRange="Starting from $2,500"
priceRange="Investment varies by scope"
idealFor="Teams adopting AI but losing human coordination"
/>
@ -46,7 +46,7 @@ import PackageCard from '../components/PackageCard.astro';
"Accountability mandate and cultivation practices",
"Follow-up coaching session"
]}
priceRange="Typical range: $5,000–$15,000"
priceRange="Investment varies by scope"
idealFor="Teams stuck in reactive mode, need structural change"
/>
@ -57,10 +57,10 @@ import PackageCard from '../components/PackageCard.astro';
deliverables={[
"Weekly advisory calls",
"Code review and architecture guidance",
"Speckl compile-time provenance audit",
"Speckl dark provenance audit",
"Team mentoring and development"
]}
priceRange="From $8,000–$20,000/month"
priceRange="Monthly retainer, negotiable"
idealFor="Startups and mid-size companies building agentic systems"
/>
@ -100,27 +100,27 @@ import PackageCard from '../components/PackageCard.astro';
<div class="section-container">
<h2>Ready to cultivate your team?</h2>
<p>Schedule a discovery call. We'll talk about your situation and figure out the right engagement.</p>
<a href="/contact/" class="cta-button" data-umami-event="consulting-cta-contact">Get in Touch</a>
<a href="/contact" class="cta-button">Schedule Discovery Call</a>
</div>
</section>
</BaseLayout>
<style>
section.hero {
.hero {
background: var(--color-cream);
padding: 12rem 2rem 6rem;
padding: 4rem 2rem;
text-align: center;
}
section.hero h1 {
.hero h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 5vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
section.hero p {
.hero p {
font-size: 1.25rem;
color: var(--color-text-muted);
margin: 0;
@ -129,7 +129,7 @@ import PackageCard from '../components/PackageCard.astro';
}
.section-container {
max-width: 1200px;
max-width: 1000px;
margin: 0 auto;
padding: 4rem 2rem;
}
@ -148,17 +148,10 @@ import PackageCard from '../components/PackageCard.astro';
.packages-grid {
display: grid;
grid-template-columns: repeat(3, 1fr);
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
gap: 2rem;
align-items: start;
}
@media (max-width: 900px) {
.packages-grid {
grid-template-columns: 1fr;
gap: 1.5rem;
}
}
.faq-section {
background: var(--color-cream-warm);

View file

@ -31,37 +31,23 @@ import SharedForm from '../components/Form/SharedForm.astro';
<div class="contact-alternatives">
<h2>Other Ways to Reach Me</h2>
<div class="contact-option">
<h3>📧 Email</h3>
<p><a href="mailto:scott@scoble.me">scott@scoble.me</a></p>
</div>
<div class="contact-option">
<h3>🔗 Follow on LinkedIn</h3>
<p class="contact-cta-text">Daily AI insights, leadership perspectives, and team cultivation practices — from a practitioner who builds.</p>
<a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener" class="contact-cta-btn linkedin-btn">
<svg viewBox="0 0 24 24" width="18" height="18" fill="currentColor"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
Connect on LinkedIn for AI Insights
</a>
<h3>📅 Discovery Call</h3>
<p><a href="#" title="Calendly link coming soon">Schedule a 20-min call</a></p>
</div>
<div class="contact-option">
<h3>🐦 X / Twitter</h3>
<p class="contact-cta-text">Daily thoughts on cultivation, AI, and the intersection of people and systems.</p>
<a href="https://x.com/scottscoble" target="_blank" rel="noopener" class="contact-cta-btn x-btn">
<svg viewBox="0 0 24 24" width="18" height="18" fill="currentColor"><path d="M18.244 2.25h3.308l-7.227 8.26 8.502 11.24H16.17l-5.214-6.817L4.99 21.75H1.68l7.73-8.835L1.254 2.25H8.08l4.713 6.231zm-1.161 17.52h1.833L7.084 4.126H5.117z"/></svg>
Follow on X
</a>
</div>
<div class="contact-option">
<h3>💻 GitHub</h3>
<p class="contact-cta-text">Open source projects: Speckl (formal provenance), ScobleClaw (agentic engineering), Beyond the Prompt.</p>
<a href="https://github.com/wscoble" target="_blank" rel="noopener" class="contact-cta-btn gh-btn">
<svg viewBox="0 0 24 24" width="18" height="18" fill="currentColor"><path d="M12 0C5.374 0 0 5.373 0 12c0 5.302 3.438 9.8 8.207 11.387.599.111.793-.261.793-.577v-2.234c-3.338.726-4.033-1.416-4.033-1.416-.546-1.387-1.333-1.756-1.333-1.756-1.089-.745.083-.729.083-.729 1.205.084 1.839 1.237 1.839 1.237 1.07 1.834 2.807 1.304 3.492.997.107-.775.418-1.305.762-1.605-2.665-.305-5.467-1.334-5.467-5.931 0-1.311.469-2.381 1.236-3.221-.124-.303-.535-1.524.117-3.176 0 0 1.008-.322 3.301 1.23A11.509 11.509 0 0112 5.803c1.02.005 2.047.138 3.006.404 2.291-1.552 3.297-1.23 3.297-1.23.653 1.653.242 2.874.118 3.176.77.84 1.235 1.911 1.235 3.221 0 4.609-2.807 5.624-5.479 5.921.43.372.823 1.102.823 2.222v3.293c0 .319.192.694.801.576C20.566 21.797 24 17.3 24 12c0-6.627-5.373-12-12-12z"/></svg>
Explore Open Source
</a>
<h3>🐦 Social</h3>
<p>
<a href="https://linkedin.com/in/scottscoble" target="_blank" rel="noopener">LinkedIn</a> •
<a href="https://x.com/scottscoble" target="_blank" rel="noopener">X/Twitter</a> •
<a href="https://github.com/sscoble" target="_blank" rel="noopener">GitHub</a>
</p>
</div>
</div>
@ -74,7 +60,7 @@ import SharedForm from '../components/Form/SharedForm.astro';
<style>
.hero {
background: var(--color-cream);
padding: 12rem 2rem 6rem;
padding: 4rem 2rem;
text-align: center;
}
@ -181,57 +167,7 @@ import SharedForm from '../components/Form/SharedForm.astro';
margin: 0;
color: var(--color-text-muted);
}
.contact-cta-text {
font-size: 0.9375rem;
color: var(--color-text-muted);
margin: 0 0 0.75rem;
line-height: 1.5;
}
.contact-cta-btn {
display: inline-flex;
align-items: center;
gap: 0.5rem;
padding: 0.625rem 1.125rem;
border-radius: 6px;
font-size: 0.9375rem;
font-weight: 600;
text-decoration: none;
border: 1px solid transparent;
transition: all 0.2s ease;
}
.linkedin-btn {
background: #0a66c2;
color: white;
}
.linkedin-btn:hover {
background: #004182;
color: white;
}
.x-btn {
background: #0f1419;
color: white;
}
.x-btn:hover {
background: #272c30;
color: white;
}
.gh-btn {
background: #24292e;
color: white;
}
.gh-btn:hover {
background: #404448;
color: white;
}
.contact-option a {
color: var(--color-green);
text-decoration: none;

View file

@ -1,11 +1,10 @@
---
import BaseLayout from '../layouts/BaseLayout.astro';
import PillarCard from '../components/PillarCard.astro';
import NewsletterSignup from '../components/NewsletterSignup.astro';
---
<BaseLayout
title="Scott Scoble — Keynote Speaker | Human Cultivation Expert for the AI Age"
title="Scott Scoble — Human Cultivation Expert for the AI Age"
description="Keynote speaker and consultant helping leaders build AI systems that cultivate humans instead of strip-mining them. Author of The Soil Beneath the Code."
pageType="home"
>
@ -21,7 +20,7 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
</div>
<div class="hero-content">
<p class="hero-kicker">Keynote Speaker · Consultant · Author</p>
<h1 aria-label="The human cultivation expert for the AI age.">
<h1>
<span class="line">The human</span>
<span class="line accent">cultivation</span>
<span class="line">expert for the AI age.</span>
@ -31,10 +30,9 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
</p>
<div class="hero-actions">
<a href="/speaking#book" class="btn btn-primary" data-umami-event="hero-cta-book">Book Scott for Your Event</a>
<a href="/speaking" class="btn btn-outline" data-umami-event="hero-cta-reel">Watch the Reel</a>
<a href="/downloads/Scott-Scoble-Human-Cultivation-Expert-Speaker-Profile.pdf" class="btn btn-outline" download data-umami-event="hero-cta-profile">📄 Speaker Profile</a>
</div>
<p class="hero-project-link">
Creator of <a href="https://speckl.scoble.me">Speckl</a>, <a href="https://os.scoble.me/forgejo/sscoble/scobleclaw">ScobleClaw</a>, and <a href="https://os.scoble.me/forgejo/sscoble/beyond-the-prompt">Beyond the Prompt</a>
</p>
</div>
</section>
@ -109,36 +107,23 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
</div>
</section>
<!-- Featured Books -->
<section class="featured-books">
<div class="section-header">
<p class="section-kicker">Books</p>
<h2>The Cultivation Series</h2>
<!-- Trust Bar -->
<section class="trust-bar">
<p class="trust-label">Trusted by leaders at</p>
<div class="trust-logos">
<span class="logo-placeholder">[Client logos coming soon]</span>
</div>
</section>
<div class="books-list">
<article class="book-card">
<div class="book-cover">
<img src="/images/book-cover-soil.webp" alt="The Soil Beneath the Code book cover" width="120" height="180" loading="lazy" />
</div>
<div class="book-info">
<h3>The Soil Beneath the Code</h3>
<p class="book-desc">What engineering teams can learn from farmers about sustainable systems. A cultivation playbook for technical leaders who are tired of strip-mining their teams.</p>
<a href="https://a.co/d/0226o4Hg" class="book-cta" target="_blank" rel="noopener" data-umami-event="home-book-soil-amazon">Get It on Amazon →</a>
</div>
</article>
<article class="book-card">
<div class="book-cover">
<img src="/images/book-cover-walk.webp" alt="A Walk in Mentoring book cover" width="120" height="180" loading="lazy" />
</div>
<div class="book-info">
<h3>A Walk in Mentoring</h3>
<p class="book-desc">Three questions that change how people learn. The simplest mentoring framework you'll actually use.</p>
<a href="https://a.co/d/0bRKZeUV" class="book-cta" target="_blank" rel="noopener" data-umami-event="home-book-walk-amazon">Get It on Amazon →</a>
</div>
</article>
<!-- Testimonials -->
<section class="testimonials">
<div class="section-header">
<p class="section-kicker">Testimonials</p>
<h2>What People Say</h2>
</div>
<div class="testimonial-grid">
<!-- Testimonials will be added here -->
</div>
</section>
@ -149,13 +134,10 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
<p class="cta-kicker">Ready to get started?</p>
<h2>Let's cultivate your team.</h2>
<p class="cta-desc">Book a keynote, workshop, or discovery call. Let's talk about your event or your team's soil health.</p>
<a href="/speaking#book" class="btn btn-primary btn-large" data-umami-event="cta-book-scott">Book Scott</a>
<a href="/speaking#book" class="btn btn-primary btn-large">Book Scott</a>
</div>
</section>
<!-- Newsletter Signup -->
<NewsletterSignup />
</BaseLayout>
<style>
@ -167,7 +149,7 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
align-items: center;
justify-content: center;
text-align: center;
padding: 8rem 2rem;
padding: 6rem 2rem;
background: var(--color-cream);
overflow: hidden;
isolation: isolate;
@ -257,24 +239,6 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
justify-content: center;
flex-wrap: wrap;
}
.hero-project-link {
margin-top: 1.5rem;
font-size: 0.9rem;
color: #c8b89a;
text-shadow: 0 1px 6px rgba(0,0,0,0.4);
}
.hero-project-link a {
color: #d9a12b;
text-decoration: none;
font-weight: 500;
}
.hero-project-link a:hover {
text-decoration: underline;
color: #e8b94a;
}
/* ===== BUTTONS ===== */
.btn {
@ -453,68 +417,92 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
.talk-link:hover {
color: var(--color-brown-dark);
}
/* ===== FEATURED BOOKS ===== */
.featured-books {
/* ===== TRUST BAR ===== */
.trust-bar {
padding: 3rem 2rem;
background: var(--color-brown-dark);
text-align: center;
}
.trust-label {
font-size: 0.875rem;
font-weight: 500;
text-transform: uppercase;
letter-spacing: 0.1em;
color: rgba(255, 255, 255, 0.6);
margin: 0 0 1.5rem;
}
.trust-logos {
display: flex;
justify-content: center;
gap: 3rem;
flex-wrap: wrap;
}
.logo-placeholder {
color: rgba(255, 255, 255, 0.4);
font-style: italic;
}
/* ===== TESTIMONIALS ===== */
.testimonials {
padding: 6rem 2rem;
background: white;
}
.books-list {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
gap: 2rem;
max-width: 1100px;
.testimonial-grid {
max-width: 800px;
margin: 0 auto;
}
.featured-books .book-card {
display: flex;
gap: 1.5rem;
padding: 2rem;
border-radius: 12px;
border: 1px solid var(--color-border-light);
background: var(--color-cream);
transition: all 0.3s ease;
.testimonial-card {
background: linear-gradient(135deg, #faf8f5 0%, #f5f0e8 100%);
padding: 3rem;
border-radius: 16px;
border: none;
position: relative;
}
.featured-books .book-card:hover {
border-color: var(--color-amber);
box-shadow: 0 6px 20px rgba(0, 0, 0, 0.06);
}
.book-cover img {
width: 120px;
height: auto;
border-radius: 4px;
box-shadow: 0 4px 10px rgba(0, 0, 0, 0.1);
flex-shrink: 0;
}
.book-info h3 {
.testimonial-card::before {
content: '"';
position: absolute;
top: 1rem;
left: 1.5rem;
font-family: var(--font-heading);
font-size: 1.375rem;
color: var(--color-brown-dark);
margin: 0 0 0.5rem;
}
.book-info .book-desc {
color: var(--color-text-muted);
margin: 0 0 1rem;
line-height: 1.6;
font-size: 0.95rem;
}
.book-info .book-cta {
font-size: 6rem;
color: var(--color-amber);
font-weight: 600;
text-decoration: none;
opacity: 0.3;
line-height: 1;
}
.book-info .book-cta:hover {
.testimonial-quote {
font-size: 1.25rem;
font-style: italic;
color: var(--color-brown-dark);
margin: 0 0 1.5rem;
line-height: 1.7;
position: relative;
z-index: 1;
}
.testimonial-author {
display: flex;
flex-direction: column;
gap: 0.25rem;
}
.testimonial-author strong {
color: var(--color-brown-dark);
font-weight: 600;
}
.testimonial-author span {
color: var(--color-text-muted);
font-size: 0.9375rem;
}
/* ===== CTA SECTION ===== */
.cta-section {
position: relative;
@ -586,24 +574,7 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
min-height: auto;
padding: 4rem 1.5rem;
}
.featured-books .books-list {
grid-template-columns: 1fr;
}
.featured-books .book-card {
flex-direction: column;
align-items: center;
text-align: center;
}
.book-info .book-desc {
display: -webkit-box;
-webkit-line-clamp: 3;
-webkit-box-orient: vertical;
overflow: hidden;
}
.hero-overlay {
background:
radial-gradient(
@ -617,28 +588,33 @@ import NewsletterSignup from '../components/NewsletterSignup.astro';
rgba(20, 18, 15, 0.6) 100%
);
}
.hero h1 {
font-size: clamp(2.25rem, 10vw, 3.5rem);
line-height: 1.05;
}
.hero h1 .accent {
font-size: 0.88em;
}
.section-header {
margin-bottom: 2.5rem;
}
.pillars,
.featured-talks,
.testimonials,
.cta-section {
padding: 4rem 1.5rem;
}
.talk-card {
padding: 1.5rem;
}
.testimonial-card {
padding: 2rem 1.5rem;
}
}
</style>

View file

@ -42,7 +42,7 @@ import BaseLayout from '../layouts/BaseLayout.astro';
<style>
.page-header {
padding: 12rem 2rem 2rem;
padding: 8rem 2rem 2rem;
text-align: center;
background: var(--color-cream);
}

View file

@ -1,216 +0,0 @@
import type { APIRoute } from 'astro';
interface PostEntry {
title: string;
description: string;
url: string;
date: string; // ISO date string
tags: string[];
}
// Blog posts data — matches src/pages/blog/*.astro
// When adding a new post, add an entry here
const posts: PostEntry[] = [
{
title: "50 First Dates with AI: Why Your AI Forgets Everything and What to Do About It",
description: "Every conversation with most AI systems is a first date. Here's the three-layer memory model that actually compounds — from Scott Scoble's scobleclaw experience.",
url: "/blog/50-first-dates-with-ai",
date: "2026-05-24",
tags: ["AI"],
},
{
title: "Stop Strip-Mining Your Engineers: The Cultivation Alternative to Throughput Obsession",
description: "Gallup 2026: 80% of the global workforce is disengaged. Manager engagement has collapsed. The $438B cost isn't a tool problem; it's a people problem. Here's the cultivation alternative.",
url: "/blog/strip-mining-cultivation",
date: "2026-05-18",
tags: ["Leadership"],
},
{
title: "Your AI Has Amnesia: Why Memory Architecture Is the Hardest Problem in Agentic Systems",
description: "The anterograde amnesia metaphor for AI memory architecture. Three-layer memory model for agentic systems from Scott Scoble's scobleclaw experience.",
url: "/blog/ai-has-amnesia",
date: "2026-05-18",
tags: ["AI"],
},
{
title: "AI Exposes Leaders; The Cultivation Test",
description: "AI doesn't just change work — it exposes what kind of leader you already were. The cultivation test: give your team AI tools and watch what happens.",
url: "/blog/ai-exposes-leaders-cultivation-test",
date: "2026-05-07",
tags: ["Leadership", "AI"],
},
{
title: "Mentorship Isn't Latency, It's Leverage",
description: "Why mentorship is the highest-leverage investment a leader can make — and why most leaders treat it as a cost instead.",
url: "/blog/mentorship-isnt-latency-its-leverage",
date: "2026-05-06",
tags: ["Leadership"],
},
{
title: "Strip-Mining Is Happening Right Now",
description: "The extraction economy is not a future risk. It's happening right now in your organization. Here's how to recognize it and what to do about it.",
url: "/blog/strip-mining-happening-right-now",
date: "2026-05-05",
tags: ["Leadership"],
},
{
title: "My Open Source Projects: Speckl, ScobleClaw, and Beyond the Prompt",
description: "A roundup of Scott Scoble's open-source projects — Speckl (spec compiler with provenance), ScobleClaw (agentic engineering framework), and Beyond the Prompt (workshop on building with AI agents).",
url: "/blog/open-source-projects",
date: "2026-05-23",
tags: ["Open Source"],
},
{
title: "We're Going to Formally Verify SQLite",
description: "SQLite runs on every smartphone, every browser, every embedded system. Its core state machines have never been formally verified. Following the Kafka proof, we're tackling the most deployed database in history with SpeckDL and Z3 bounded model checking.",
url: "/blog/prove-sqlite",
date: "2026-05-23",
tags: ["Engineering"],
},
{
title: "You're Already in the Agentic Wars",
description: "Meta has Hatch. Google has Remy. Everyone is building agents. Whose capability compounds?",
url: "/blog/agentic-wars",
date: "2026-05-08",
tags: ["AI"],
},
{
title: "What Does AI Brain Fry Really Mean?",
description: "Gallup says 80% of the workforce is disengaged. The heaviest AI users are burning out fastest. The fix isn't training — it's structural.",
url: "/blog/ai-brain-fry",
date: "2026-05-03",
tags: ["AI"],
},
{
title: "The Surveillance Dividend Is a Lie",
description: "Every company running AI adoption is making an implicit bargain: data for tools. The companies extracting the most surveillance are hemorrhaging their best talent.",
url: "/blog/surveillance-extraction",
date: "2026-05-03",
tags: ["Leadership"],
},
{
title: "80% of Your Team Is Disengaged. It's Not Their Fault.",
description: "Gallup says 80% of the global workforce is disengaged. The $100B+ engagement industry has failed for 20 years. The fix isn't perks or surveys; it's structural.",
url: "/blog/gallup-disengagement",
date: "2026-05-03",
tags: ["Leadership"],
},
{
title: "The Developer Experience Shift: Why Tooling Alone Won't Save You",
description: "Companies will spend $60B+ on developer tools in 2026. But the real DevEx crisis isn't tooling — it's autonomy, mastery, and belonging. As code production becomes commoditized, the human dimensions of engineering become the only competitive advantage that matters.",
url: "/blog/devex-shift",
date: "2026-05-03",
tags: ["Engineering"],
},
{
title: "The Token Anxiety Trap; Why AI Agents Aren't Liberating Us (Yet)",
description: "Your agent swarm runs 24/7 and you're more anxious than ever. Stanford's 2026 AI Index shows a 20% drop in junior dev employment since 2024. The agent revolution promised freedom — instead it gave us token anxiety and a new kind of burnout.",
url: "/blog/token-anxiety",
date: "2026-05-04",
tags: ["AI"],
},
{
title: "Three Questions That Changed How I Mentor",
description: "The simple mentoring framework that actually gets used — three questions that unlock real growth.",
url: "/blog/three-questions-mentoring",
date: "2026-04-28",
tags: ["Leadership"],
},
{
title: "Three Signs Your Team Is Being Strip-Mined",
description: "The mindset shift that separates thriving teams from burned-out ones — cultivation over extraction.",
url: "/blog/strip-mining-signs",
date: "2026-04-28",
tags: ["Teams"],
},
{
title: "The Soil Beneath The Code",
description: "A three-layer framework for understanding what makes engineering organizations healthy — or not.",
url: "/blog/the-soil-beneath-the-code",
date: "2026-04-28",
tags: ["Engineering"],
},
{
title: "What a Dark Factory Actually Is (and Isn't)",
description: "The phrase is everywhere. The working meaning is gone. Here is what it is, what it isn't, and the five positions on the spectrum.",
url: "/blog/what-is-a-dark-factory",
date: "2026-05-22",
tags: ["Engineering"],
},
{
title: "Light vs Dark Factories: Why the Middle Is Harder Than Either End",
description: "A light factory has too many gates. A dark factory has too few. The middle is where the engineering happens, and the middle is the part nobody talks about.",
url: "/blog/light-vs-dark-factories",
date: "2026-06-02",
tags: ["Engineering"],
},
{
title: "Why Kubernetes for a Dark Factory",
description: "A dark factory is a control loop. Kubernetes is the most boring control loop in production. That is the reason.",
url: "/blog/why-kubernetes-for-dark-factory",
date: "2026-06-11",
tags: ["Engineering"],
},
{
title: "Kubernetes Operator Patterns for Software Factories",
description: "An operator is a control loop with a domain in it. That is the whole definition. Here are the four operator patterns and the one anti-pattern to avoid.",
url: "/blog/operator-patterns-for-software-factories",
date: "2026-06-19",
tags: ["Engineering"],
},
{
title: "The Taste Problem: What Dark Factories Can't Transfer",
description: "A dark factory can transfer code. It cannot transfer the judgment that knew the code was right. That is the problem provenance was invented to solve.",
url: "/blog/the-taste-problem",
date: "2026-06-29",
tags: ["Engineering"],
},
{
title: "The Human-in-the-Loop Seam: Where Humans Belong in a Dark Factory",
description: "Human-in-the-loop is a phrase everyone uses. Almost nobody uses it correctly. The seam is in the spec, not in the implementation.",
url: "/blog/human-in-the-loop-seam",
date: "2026-07-08",
tags: ["Engineering"],
},
];
const siteUrl = 'https://scott.scoble.me';
const now = new Date().toUTCString();
// Build RSS XML
const items = posts
.sort((a, b) => new Date(b.date).getTime() - new Date(a.date).getTime())
.map(
(post) => `
<item>
<title><![CDATA[${post.title}]]></title>
<description><![CDATA[${post.description}]]></description>
<link>${siteUrl}${post.url}</link>
<guid isPermaLink="true">${siteUrl}${post.url}</guid>
<pubDate>${new Date(post.date).toUTCString()}</pubDate>
${post.tags.map((tag) => ` <category>${tag}</category>`).join('\n')}
</item>`
)
.join('');
const rssXml = `<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
<title>Scott Scoble Blog</title>
<description>Articles on AI, leadership, cultivation, and the human side of technology.</description>
<link>${siteUrl}</link>
<language>en-us</language>
<lastBuildDate>${now}</lastBuildDate>
<atom:link href="${siteUrl}/rss.xml" rel="self" type="application/rss+xml"/>
${items}
</channel>
</rss>`;
export const GET: APIRoute = () => {
return new Response(rssXml, {
headers: {
'Content-Type': 'application/rss+xml; charset=utf-8',
'Cache-Control': 'public, max-age=3600',
},
});
};

View file

@ -1,70 +1,28 @@
import type { APIRoute } from 'astro';
const siteUrl = 'https://scott.scoble.me';
import { getCollection } from 'astro:content';
const pages = [
{ url: '/', lastmod: '2026-06-01', priority: '1.0' },
{ url: '/speaking', lastmod: '2026-06-01', priority: '0.9' },
{ url: '/consulting', lastmod: '2026-06-01', priority: '0.8' },
{ url: '/books', lastmod: '2026-06-01', priority: '0.8' },
{ url: '/contact', lastmod: '2026-06-01', priority: '0.7' },
{ url: '/privacy', lastmod: '2026-06-01', priority: '0.3' },
{ url: '/about', lastmod: '2026-06-01', priority: '0.7' },
{ url: '/blog', lastmod: '2026-06-01', priority: '0.9' },
{ url: '/', lastmod: new Date().toISOString() },
{ url: '/speaking', lastmod: new Date().toISOString() },
{ url: '/consulting', lastmod: new Date().toISOString() },
{ url: '/books', lastmod: new Date().toISOString() },
{ url: '/contact', lastmod: new Date().toISOString() },
{ url: '/privacy', lastmod: new Date().toISOString() },
];
const speakingPages = [
{ url: '/speaking/50-first-dates', lastmod: '2026-06-01' },
{ url: '/speaking/strip-mining-to-cultivation', lastmod: '2026-06-01' },
{ url: '/speaking/soil-under-your-team', lastmod: '2026-06-01' },
];
// All blog post URLs
const blogPosts = [
{ url: '/blog/50-first-dates-with-ai', lastmod: '2026-05-30' },
{ url: '/blog/strip-mining-cultivation', lastmod: '2026-05-30' },
{ url: '/blog/soil-health-teams', lastmod: '2026-05-30' },
{ url: '/blog/30-years-software', lastmod: '2026-05-30' },
{ url: '/blog/spec-first-audit-surface', lastmod: '2026-05-30' },
{ url: '/blog/open-source-projects', lastmod: '2026-05-30' },
{ url: '/blog/prove-sqlite', lastmod: '2026-05-30' },
{ url: '/blog/ai-has-amnesia', lastmod: '2026-05-30' },
{ url: '/blog/agentic-wars', lastmod: '2026-05-30' },
{ url: '/blog/ai-brain-fry', lastmod: '2026-05-30' },
{ url: '/blog/surveillance-extraction', lastmod: '2026-05-30' },
{ url: '/blog/gallup-disengagement', lastmod: '2026-05-30' },
{ url: '/blog/devex-shift', lastmod: '2026-05-30' },
{ url: '/blog/token-anxiety', lastmod: '2026-05-30' },
{ url: '/blog/three-questions-mentoring', lastmod: '2026-05-30' },
{ url: '/blog/strip-mining-signs', lastmod: '2026-05-30' },
{ url: '/blog/the-soil-beneath-the-code', lastmod: '2026-05-30' },
{ url: '/blog/strip-mining-happening-right-now', lastmod: '2026-05-30' },
{ url: '/blog/mentorship-isnt-latency-its-leverage', lastmod: '2026-05-30' },
{ url: '/blog/ai-exposes-leaders-cultivation-test', lastmod: '2026-05-30' },
{ url: '/blog/what-is-a-dark-factory', lastmod: '2026-05-22' },
{ url: '/blog/light-vs-dark-factories', lastmod: '2026-06-02' },
{ url: '/blog/why-kubernetes-for-dark-factory', lastmod: '2026-06-11' },
{ url: '/blog/operator-patterns-for-software-factories', lastmod: '2026-06-19' },
{ url: '/blog/the-taste-problem', lastmod: '2026-06-29' },
{ url: '/blog/human-in-the-loop-seam', lastmod: '2026-07-08' },
];
const allPages = [...pages, ...speakingPages.map(p => ({ ...p, priority: '0.7' })), ...blogPosts.map(p => ({ ...p, priority: '0.7' }))];
// Render the sitemap XML
const xml = `\<\?xml version="1.0" encoding="UTF-8"?\>
const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${allPages.map(page => `
${pages.map(page => `
<url>
<loc>${new URL(page.url, siteUrl).href}</loc>
<lastmod>${page.lastmod}</lastmod>
<changefreq>${page.url === '/' ? 'weekly' : 'monthly'}</changefreq>
<priority>${page.priority}</priority>
<loc>${new URL(page.url, 'https://scott.scoble.me').href}</loc>
<lastmod>${typeof page.lastmod === 'string' ? page.lastmod : new Date(page.lastmod).toISOString().split('T')[0]}</lastmod>
<changefreq>weekly</changefreq>
<priority>${page.url === '/' ? '1.0' : '0.8'}</priority>
</url>
`).join('')}
</urlset>`;
export const GET: APIRoute = () => {
export const GET = () => {
return new Response(xml, {
headers: {
'Content-Type': 'application/xml',

View file

@ -16,7 +16,21 @@ import SharedForm from '../components/Form/SharedForm.astro';
<p class="hero-kicker">Keynote Speaker</p>
<h1>Helping leaders build AI systems that cultivate humans instead of strip-mining them.</h1>
<a href="#book" class="hero-cta" data-umami-event="speaking-hero-cta-book">Book Scott for Your Event</a>
<a href="#book" class="hero-cta">Book Scott for Your Event</a>
</div>
</section>
<!-- Speaker Reel -->
<section class="reel-section">
<div class="section-container">
<h2>Watch the Reel</h2>
<div class="video-container">
<div class="video-placeholder">
<p>🎬 Speaker reel in production</p>
<p>Coming soon — 3-minute highlight reel from keynotes and workshops. In the meantime, explore my signature talks below.</p>
</div>
</div>
</div>
</section>
@ -31,7 +45,7 @@ import SharedForm from '../components/Form/SharedForm.astro';
title="50 First Dates with AI"
slug="/speaking/50-first-dates"
premise="Current AI memory architecture is anterograde amnesia — and we're all Henry Roth, recording VHS tapes every night so our agent can wake up functional tomorrow."
audience="Engineering leaders, AI product teams, CTOs implementing agentic systems"
idealFor="Engineering leaders, AI product teams, CTOs implementing agentic systems"
takeaways={[
"Why your AI's 'memory' is actually just replay, not learning",
"The three-layer memory architecture that actually compounds",
@ -43,7 +57,7 @@ import SharedForm from '../components/Form/SharedForm.astro';
title="From Strip-Mining to Cultivation"
slug="/speaking/strip-mining-to-cultivation"
premise="The shift from extraction to cultivation in AI-era teams. Why throughput optimization is killing your soil health."
audience="CTOs, VP Engineering, people leaders, engineering managers"
idealFor="CTOs, VP Engineering, people leaders, engineering managers"
takeaways={[
"The difference between strip-mining and cultivation mindsets",
"How to assess your team's soil health",
@ -53,9 +67,8 @@ import SharedForm from '../components/Form/SharedForm.astro';
<TalkCard
title="The Soil Under Your Team"
slug="/speaking/soil-under-your-team"
premise="Diagnose what's actually depleted before you fertilize. A diagnostic framework for team health in AI-augmented work."
audience="Team leads, managers, engineering directors, founders"
idealFor="Team leads, managers, engineering directors, founders"
takeaways={[
"The four soil nutrients every team needs",
"How to run a cultivation assessment",
@ -67,6 +80,33 @@ import SharedForm from '../components/Form/SharedForm.astro';
</div>
</section>
<!-- Past Events -->
<section class="events-section">
<div class="section-container">
<h2>Past Events</h2>
<div class="events-list">
<article class="event-item">
<h3>Game Changers Summit 2026</h3>
<p>Featured Speaker — "From Strip-Mining to Cultivation"</p>
<p class="event-date">March 2026 • Virtual</p>
</article>
<article class="event-item">
<h3>AI Engineering Leadership Forum</h3>
<p>Keynote — "50 First Dates with AI"</p>
<p class="event-date">February 2026 • San Francisco</p>
</article>
<article class="event-item">
<h3>Tech Leaders Collective</h3>
<p>Workshop — "The Soil Under Your Team"</p>
<p class="event-date">January 2026 • Remote</p>
</article>
</div>
</div>
</section>
<!-- Book Scott Section -->
<section id="book" class="book-section">
<div class="section-container">
@ -93,9 +133,9 @@ import SharedForm from '../components/Form/SharedForm.astro';
<li><strong>Audience:</strong> Engineering leaders, CTOs, people managers</li>
</ul>
<a href="/downloads/Scott-Scoble-Human-Cultivation-Expert-Speaker-Profile.pdf" class="download-btn" download data-umami-event="speaker-profile-download">📄 Download Speaker Profile (PDF)</a>
<a href="/downloads/Scott-Scoble-Human-Cultivation-Expert-Speaker-Profile.pdf" class="download-btn" download>📄 Download Speaker Profile (PDF)</a>
<p class="contact-alt">Or email: <a href="mailto:scott@scoble.me" data-umami-event="speaking-email-link">scott@scoble.me</a></p>
<p class="contact-alt">Or email: <a href="mailto:scott@scoble.me">scott@scoble.me</a></p>
</div>
</div>
</div>
@ -106,7 +146,7 @@ import SharedForm from '../components/Form/SharedForm.astro';
<style>
.hero {
background: var(--color-cream);
padding: 12rem 2rem 6rem;
padding: 5rem 2rem 4rem;
text-align: center;
}
@ -155,6 +195,29 @@ import SharedForm from '../components/Form/SharedForm.astro';
color: var(--color-brown-dark);
}
.reel-section {
background: white;
}
.video-container {
aspect-ratio: 16 / 9;
background: var(--color-cream-warm);
border-radius: 8px;
display: flex;
align-items: center;
justify-content: center;
}
.video-placeholder {
text-align: center;
color: var(--color-text-muted);
}
.video-placeholder p:first-child {
font-size: 1.5rem;
margin: 0 0 0.5rem;
}
.talks-section {
background: var(--color-cream);
}
@ -165,6 +228,42 @@ import SharedForm from '../components/Form/SharedForm.astro';
gap: 2rem;
}
.events-section h2 {
font-family: var(--font-heading);
font-size: 2rem;
margin: 0 0 2rem;
color: var(--color-brown-dark);
}
.events-list {
display: grid;
gap: 1.5rem;
}
.event-item {
padding: 1.5rem;
background: var(--color-cream);
border-radius: 8px;
}
.event-item h3 {
font-family: var(--font-heading);
margin: 0 0 0.5rem;
color: var(--color-brown-dark);
}
.event-item p {
margin: 0;
color: var(--color-text-muted);
}
.event-date {
font-size: 0.875rem;
font-style: italic;
color: var(--color-text-muted);
margin-top: 0.25rem;
}
.book-section {
background: var(--color-brown-dark);
color: white;

View file

@ -1,207 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
const talk = {
title: "50 First Dates with AI",
premise: "Current AI memory architecture is anterograde amnesia — and we're all Henry Roth, recording VHS tapes every night so our agent can wake up functional tomorrow.",
duration: "45–60 minutes",
type: "Keynote",
idealFor: ["Engineering leaders", "AI product teams", "CTOs implementing agentic systems"],
takeaways: [
"Why your AI's 'memory' is actually just replay, not learning",
"The three-layer memory architecture that actually compounds",
"How to move from VHS tapes to persistent, evolving agents"
],
description: `Every morning, your AI wakes up and doesn't remember yesterday.
We built agentic systems with anterograde amnesia — they can't form new long-term memories. Instead, we record VHS tapes (context windows) every night and hope the agent can reconstruct enough context to be functional.
This isn't a technical limitation. It's an architectural choice we keep making because it's easier than building systems that actually learn.
In this keynote, I show why the "50 First Dates" problem is the single biggest blocker to truly agentic AI — and how to build systems that compound instead of reset.`
};
---
<BaseLayout
title={`${talk.title} — Scott Scoble`}
description={talk.premise}
pageType="speaking"
>
<article class="talk-detail">
<header class="talk-header">
<div class="talk-meta">
<span class="talk-type">{talk.type}</span>
<span class="talk-duration">{talk.duration}</span>
</div>
<h1>{talk.title}</h1>
<p class="talk-premise">{talk.premise}</p>
</header>
<div class="talk-content">
<section class="talk-description">
<h2>The Talk</h2>
{talk.description.split('\n\n').map(para => (
<p>{para}</p>
))}
</section>
<section class="talk-takeaways">
<h2>What You'll Learn</h2>
<ul>
{talk.takeaways.map(takeaway => (
<li>{takeaway}</li>
))}
</ul>
</section>
<section class="talk-audience">
<h2>Ideal For</h2>
<div class="audience-tags">
{talk.idealFor.map(audience => (
<span class="audience-tag">{audience}</span>
))}
</div>
</section>
</div>
<footer class="talk-cta">
<a href="/speaking#book" class="btn-primary" data-umami-event="talk-cta-book-50-first-dates">
Book This Talk
</a>
<a href="/speaking" class="btn-outline">← All Talks</a>
</footer>
</article>
</BaseLayout>
<style>
.talk-detail {
max-width: 800px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.talk-header {
text-align: center;
margin-bottom: 3rem;
}
.talk-meta {
display: flex;
gap: 1rem;
justify-content: center;
margin-bottom: 1.5rem;
}
.talk-type {
background: var(--color-green);
color: white;
padding: 0.25rem 0.75rem;
border-radius: 4px;
font-size: 0.75rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.talk-duration {
color: var(--color-text-muted);
font-size: 0.875rem;
}
.talk-header h1 {
font-family: var(--font-heading);
font-size: clamp(1.75rem, 4vw, 2.5rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
.talk-premise {
font-size: 1.125rem;
color: var(--color-text-muted);
font-style: italic;
max-width: 600px;
margin: 0 auto;
}
.talk-content section {
margin-bottom: 2.5rem;
}
.talk-content h2 {
font-family: var(--font-heading);
font-size: 1.25rem;
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
.talk-description p {
color: var(--color-text);
line-height: 1.7;
margin: 0 0 1rem;
}
.talk-takeaways ul {
list-style: none;
padding: 0;
}
.talk-takeaways li {
padding: 0.75rem 0;
border-bottom: 1px solid var(--color-border);
position: relative;
padding-left: 1.5rem;
}
.talk-takeaways li:before {
content: "✓";
position: absolute;
left: 0;
color: var(--color-green);
font-weight: bold;
}
.audience-tags {
display: flex;
flex-wrap: wrap;
gap: 0.5rem;
}
.audience-tag {
background: var(--color-cream);
border: 1px solid var(--color-border);
padding: 0.5rem 1rem;
border-radius: 100px;
font-size: 0.875rem;
color: var(--color-text);
}
.talk-cta {
display: flex;
gap: 1rem;
justify-content: center;
padding-top: 2rem;
border-top: 1px solid var(--color-border);
}
.btn-primary {
display: inline-block;
background: var(--color-amber);
color: white;
padding: 0.75rem 1.5rem;
border-radius: 6px;
text-decoration: none;
font-weight: 600;
}
.btn-outline {
display: inline-block;
background: transparent;
color: var(--color-text);
padding: 0.75rem 1.5rem;
border-radius: 6px;
text-decoration: none;
border: 1px solid var(--color-border);
}
</style>

View file

@ -1,207 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
const talk = {
title: "The Soil Under Your Team",
premise: "Diagnose what's actually depleted before you fertilize. A diagnostic framework for team health in AI-augmented work.",
duration: "45–60 minutes",
type: "Workshop",
idealFor: ["Team leads", "Managers", "Engineering directors", "Founders"],
takeaways: [
"The four soil nutrients every team needs",
"How to run a cultivation assessment",
"From diagnosis to cultivation roadmap"
],
description: `Most team interventions fail because they prescribe before diagnosing. Someone reads a book on "psychological safety" and schedules trust falls. Someone hears about "developer experience" and buys a new CI tool. The team is still disengaged, now with a better linter.
The problem isn't the interventions. It's that nobody knows what's actually depleted.
In this workshop, I introduce the Soil Framework: four nutrients that determine whether a team thrives or burns out. We run a live diagnostic on your actual team (or a case study), identify which nutrients are depleted, and build a cultivation roadmap — not a set of prescriptions, but a sequence of interventions that match your specific soil profile.
This isn't theory. I've used this framework with teams at startups and Fortune 500 companies. The teams that diagnose before prescribing show measurable improvement in engagement within 90 days. The teams that prescribe first... buy more tools.`
};
---
<BaseLayout
title={`${talk.title} — Scott Scoble`}
description={talk.premise}
pageType="speaking"
>
<article class="talk-detail">
<header class="talk-header">
<div class="talk-meta">
<span class="talk-type">{talk.type}</span>
<span class="talk-duration">{talk.duration}</span>
</div>
<h1>{talk.title}</h1>
<p class="talk-premise">{talk.premise}</p>
</header>
<div class="talk-content">
<section class="talk-description">
<h2>The Talk</h2>
{talk.description.split('\n\n').map(para => (
<p>{para}</p>
))}
</section>
<section class="talk-takeaways">
<h2>What You'll Learn</h2>
<ul>
{talk.takeaways.map(takeaway => (
<li>{takeaway}</li>
))}
</ul>
</section>
<section class="talk-audience">
<h2>Ideal For</h2>
<div class="audience-tags">
{talk.idealFor.map(audience => (
<span class="audience-tag">{audience}</span>
))}
</div>
</section>
</div>
<footer class="talk-cta">
<a href="/speaking#book" class="btn-primary" data-umami-event="talk-cta-book-soil">
Book This Talk
</a>
<a href="/speaking" class="btn-outline">← All Talks</a>
</footer>
</article>
</BaseLayout>
<style>
.talk-detail {
max-width: 800px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.talk-header {
text-align: center;
margin-bottom: 3rem;
}
.talk-meta {
display: flex;
gap: 1rem;
justify-content: center;
margin-bottom: 1.5rem;
}
.talk-type {
background: var(--color-green);
color: white;
padding: 0.25rem 0.75rem;
border-radius: 4px;
font-size: 0.75rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.talk-duration {
color: var(--color-text-muted);
font-size: 0.875rem;
}
.talk-header h1 {
font-family: var(--font-heading);
font-size: clamp(1.75rem, 4vw, 2.5rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
.talk-premise {
font-size: 1.125rem;
color: var(--color-text-muted);
font-style: italic;
max-width: 600px;
margin: 0 auto;
}
.talk-content section {
margin-bottom: 2.5rem;
}
.talk-content h2 {
font-family: var(--font-heading);
font-size: 1.25rem;
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
.talk-description p {
color: var(--color-text);
line-height: 1.7;
margin: 0 0 1rem;
}
.talk-takeaways ul {
list-style: none;
padding: 0;
}
.talk-takeaways li {
padding: 0.75rem 0;
border-bottom: 1px solid var(--color-border);
position: relative;
padding-left: 1.5rem;
}
.talk-takeaways li:before {
content: "✓";
position: absolute;
left: 0;
color: var(--color-green);
font-weight: bold;
}
.audience-tags {
display: flex;
flex-wrap: wrap;
gap: 0.5rem;
}
.audience-tag {
background: var(--color-cream);
border: 1px solid var(--color-border);
padding: 0.5rem 1rem;
border-radius: 100px;
font-size: 0.875rem;
color: var(--color-text);
}
.talk-cta {
display: flex;
gap: 1rem;
justify-content: center;
padding-top: 2rem;
border-top: 1px solid var(--color-border);
}
.btn-primary {
display: inline-block;
background: var(--color-amber);
color: white;
padding: 0.75rem 1.5rem;
border-radius: 6px;
text-decoration: none;
font-weight: 600;
}
.btn-outline {
display: inline-block;
background: transparent;
color: var(--color-text);
padding: 0.75rem 1.5rem;
border-radius: 6px;
text-decoration: none;
border: 1px solid var(--color-border);
}
</style>

View file

@ -1,207 +0,0 @@
---
import BaseLayout from '../../layouts/BaseLayout.astro';
const talk = {
title: "From Strip-Mining to Cultivation",
premise: "The shift from extraction to cultivation in AI-era teams. Why throughput optimization is killing your soil health.",
duration: "45–60 minutes",
type: "Keynote",
idealFor: ["CTOs", "VP Engineering", "People leaders", "Engineering managers"],
takeaways: [
"The difference between strip-mining and cultivation mindsets",
"How to audit your current practices for extraction vs. growth",
"A cultivation playbook you can implement this quarter"
],
description: `The most successful AI teams aren't the ones with the best models. They're the ones who stopped strip-mining their humans and started cultivating them.
For a decade, we've optimized engineering teams like strip-mining operations: extract maximum value, move fast, burn bright. It worked when the work was predictable and the humans were replaceable.
AI changes the equation. The work is no longer predictable — it's conversational, contextual, and constantly evolving. You can't strip-mine your way through agentic development. You need soil that gets richer over time.
This keynote shows the cultivation playbook: how to build teams where AI augments human capability instead of replacing it, where throughput is a byproduct of health, and where your best people don't just stay — they compound.`
};
---
<BaseLayout
title={`${talk.title} — Scott Scoble`}
description={talk.premise}
pageType="speaking"
>
<article class="talk-detail">
<header class="talk-header">
<div class="talk-meta">
<span class="talk-type">{talk.type}</span>
<span class="talk-duration">{talk.duration}</span>
</div>
<h1>{talk.title}</h1>
<p class="talk-premise">{talk.premise}</p>
</header>
<div class="talk-content">
<section class="talk-description">
<h2>The Talk</h2>
{talk.description.split('\n\n').map(para => (
<p>{para}</p>
))}
</section>
<section class="talk-takeaways">
<h2>What You'll Learn</h2>
<ul>
{talk.takeaways.map(takeaway => (
<li>{takeaway}</li>
))}
</ul>
</section>
<section class="talk-audience">
<h2>Ideal For</h2>
<div class="audience-tags">
{talk.idealFor.map(audience => (
<span class="audience-tag">{audience}</span>
))}
</div>
</section>
</div>
<footer class="talk-cta">
<a href="/speaking#book" class="btn-primary" data-umami-event="talk-cta-book-cultivation">
Book This Talk
</a>
<a href="/speaking" class="btn-outline">← All Talks</a>
</footer>
</article>
</BaseLayout>
<style>
.talk-detail {
max-width: 800px;
margin: 0 auto;
padding: 12rem 2rem 6rem;
}
.talk-header {
text-align: center;
margin-bottom: 3rem;
}
.talk-meta {
display: flex;
gap: 1rem;
justify-content: center;
margin-bottom: 1.5rem;
}
.talk-type {
background: var(--color-green);
color: white;
padding: 0.25rem 0.75rem;
border-radius: 4px;
font-size: 0.75rem;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.talk-duration {
color: var(--color-text-muted);
font-size: 0.875rem;
}
.talk-header h1 {
font-family: var(--font-heading);
font-size: clamp(1.75rem, 4vw, 2.5rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
.talk-premise {
font-size: 1.125rem;
color: var(--color-text-muted);
font-style: italic;
max-width: 600px;
margin: 0 auto;
}
.talk-content section {
margin-bottom: 2.5rem;
}
.talk-content h2 {
font-family: var(--font-heading);
font-size: 1.25rem;
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
.talk-description p {
color: var(--color-text);
line-height: 1.7;
margin: 0 0 1rem;
}
.talk-takeaways ul {
list-style: none;
padding: 0;
}
.talk-takeaways li {
padding: 0.75rem 0;
border-bottom: 1px solid var(--color-border);
position: relative;
padding-left: 1.5rem;
}
.talk-takeaways li:before {
content: "✓";
position: absolute;
left: 0;
color: var(--color-green);
font-weight: bold;
}
.audience-tags {
display: flex;
flex-wrap: wrap;
gap: 0.5rem;
}
.audience-tag {
background: var(--color-cream);
border: 1px solid var(--color-border);
padding: 0.5rem 1rem;
border-radius: 100px;
font-size: 0.875rem;
color: var(--color-text);
}
.talk-cta {
display: flex;
gap: 1rem;
justify-content: center;
padding-top: 2rem;
border-top: 1px solid var(--color-border);
}
.btn-primary {
display: inline-block;
background: var(--color-amber);
color: white;
padding: 0.75rem 1.5rem;
border-radius: 6px;
text-decoration: none;
font-weight: 600;
}
.btn-outline {
display: inline-block;
background: transparent;
color: var(--color-text);
padding: 0.75rem 1.5rem;
border-radius: 6px;
text-decoration: none;
border: 1px solid var(--color-border);
}
</style>

View file

@ -377,6 +377,24 @@ code {
font-style: italic;
}
/* --- Testimonials --- */
.testimonials-grid {
display: grid;
gap: var(--space-xl);
}
@media (min-width: 640px) {
.testimonials-grid {
grid-template-columns: repeat(2, 1fr);
}
}
@media (min-width: 1024px) {
.testimonials-grid {
grid-template-columns: repeat(3, 1fr);
}
}
/* --- Page Header (non-hero pages) --- */
.page-header {
padding: var(--space-3xl) 0 var(--space-2xl);
@ -452,37 +470,6 @@ code {
.container {
padding: 0 var(--space-md);
}
/* Prevent horizontal overflow on mobile */
.hero .hero-subtitle,
.hero .hero-actions,
.page-header p {
overflow-wrap: break-word;
word-break: break-word;
}
/* Ensure card grids go single column on small screens */
.card-grid {
grid-template-columns: 1fr;
}
/* Ensure form inputs don't cause horizontal scroll */
.form-group input,
.form-group select,
.form-group textarea {
max-width: 100%;
box-sizing: border-box;
}
/* Newsletter form stacks on mobile */
.newsletter-form {
flex-direction: column;
gap: 0.5rem;
}
.newsletter-form button {
width: 100%;
}
}
@media (min-width: 640px) and (max-width: 1023px) {
@ -490,69 +477,3 @@ code {
--size-4xl: 2.5rem;
}
}
/* Mobile touch targets (44px minimum) - Issue #65 */
@media (pointer: coarse) {
.nav-links a,
.nav-mobile-link,
.nav-mobile-cta,
.nav-cta,
.footer-links a,
.footer-social a,
.book-link,
.talk-link,
.btn-primary,
.btn-outline,
.btn,
.form-submit,
.newsletter-form button,
.nav-menu-toggle {
min-height: 44px;
min-width: 44px;
display: inline-flex;
align-items: center;
justify-content: center;
}
/* Make nav menu toggle easier to tap */
.nav-menu-toggle {
padding: 0.75rem;
}
/* Ensure footer social icons have adequate tap area */
.footer-social a {
width: 44px;
height: 44px;
border-radius: 50%;
}
/* Ensure select dropdowns are tappable on mobile */
.form-group select {
min-height: 48px;
font-size: 1rem;
padding: 0.75rem;
}
/* Ensure newsletter input and button are tappable */
.newsletter-form input {
min-height: 48px;
font-size: 1rem;
}
.newsletter-form button {
min-height: 48px;
min-width: 80px;
padding: 0.75rem 1.25rem;
}
}
/* Reduced motion - Issue #53 accessibility */
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
}
}