diff --git a/src/pages/blog/ai-brain-fry.astro b/src/pages/blog/ai-brain-fry.astro new file mode 100644 index 0000000..42a00d5 --- /dev/null +++ b/src/pages/blog/ai-brain-fry.astro @@ -0,0 +1,108 @@ +--- +import BaseLayout from '../../layouts/BaseLayout.astro'; +--- + + + +
+
+
+ May 3, 2026 + AI +
+

AI Brain Fry Is a Workforce Crisis, Not a Productivity Story

+
+ +
+

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.

+ +

The Gallup numbers are out. 80% disengaged. The heaviest AI users burning fastest. Everyone calls it a crisis. I think they're looking at it wrong.

+ +

Your brain is reconfiguring from intonation to orchestration. 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. That is a fundamental rewiring of how your mind spends its day. Of course it hurts.

+ +

But discomfort is not damage. Ask Arnold if he quit lifting because of discomfort.

+ +

The problem isn't that your brain is broken. The problem is that most people focus on the discomfort instead of looking forward through it. The key word is forward; not ahead, not onward, but forward. Direction with momentum.

+ +

When I'm on the move, I move. When the reconfiguration is happening, you have two choices: sit in the pain and call it burnout, or recognize it as growth and keep your eyes forward. One is a loop. The other is a ladder.

+ +

Here's what I see happening to people. They start using Copilot or Cursor. The first week is magical; three times the output, half the typing. The second week, they notice they can't remember why they chose this architecture over that one. The third week, they're tired in a way sleep doesn't fix. By month two, they're wondering if they're a good engineer anymore or just good at prompting.

+ +

That's not brain fry. That's formation.

+ +

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.

+ +

So what do you do with it?

+ +

First, name it. You're not fried; you're forming. The cognitive fatigue is real, but its cause is growth, not decay. When you call it decay, you treat it with rest and retreat. When you call it growth, you treat it with orientation: are you looking forward through it, or sitting in it?

+ +

Second, preserve the decision boundary. The most engaged engineers I know use AI for exploration; show me three ways to solve this, not execution. 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.

+ +

Third, measure judgment, not output. If your metrics are lines of code and story points, AI will look like a miracle and you 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.

+ +

Fourth, build for the human, not the machine. Every AI deployment should pass this test: does it make the human more capable or merely more productive? Capability compounds. Productivity extracts. The difference shows up in engagement scores within six months.

+ +

I'm building two things in parallel. Speckl, a compliance specification language where AI generates the spec but a human reviews and approves it before the compiler turns it into code. The human judgment is embedded as provenance; auditable, verifiable, part of the artifact. And a consultancy helping engineering leaders shift from extraction metrics to capability metrics.

+ +

If your team is showing signs of what the industry calls 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.

+ +

The data is in, but the data isn't the story. 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.

+ +

Forward is the direction. Not ahead. Not onward. Forward.

+ +

Which way are you looking?

+
+
+ + + + diff --git a/src/pages/blog/devex-shift.astro b/src/pages/blog/devex-shift.astro new file mode 100644 index 0000000..7c8af7e --- /dev/null +++ b/src/pages/blog/devex-shift.astro @@ -0,0 +1,102 @@ +--- +import BaseLayout from '../../layouts/BaseLayout.astro'; +--- + + + +
+
+
+ May 3, 2026 + Engineering +
+

The Developer Experience Shift — And Why Tooling Alone Won't Save You

+
+ +
+

Who gives a crap about things that are never used.

+ +

That's a weird opening for a post about developer experience. But it's the whole thing. Every conversation about DevEx starts with tooling; faster CI, better IDEs, internal platforms, AI coding assistants. Companies are spending $60 billion on this stuff this year alone. Platform engineering teams are bigger than most startups. The dashboards are beautiful.

+ +

And nobody's asking the question that actually matters: is anyone using it?

+ +

Not "did we deploy it." Not "did the metrics improve." Is it adopted. Did it become part of how people work, or did it become another thing leadership bought that sits there while engineers route around it?

+ +

The gap between deploying a tool and getting it adopted is the gap between spending money and creating value. Most organizations never cross it. They deploy, they measure, they call it done. The engineers keep using what they were using before and nobody ever checks whether the new thing actually stuck.

+ +

Start at the destination. Start at adoption. Work backward from there to what enables it. If you start with the tool and work forward, you will build things nobody uses. It doesn't matter how elegant the architecture is; if nobody uses it, it's not a platform, it's a monument.

+ +

This is changing so rapidly right now it's hard to put into words. DevEx is not what it was two years ago. Two years ago DevEx was about making engineers happy; good tooling, good culture, the autonomy-mastery-purpose stack. Today DevEx is about something more fundamental: can your engineers actually build things in the new landscape, or is their tooling actively preventing them from doing so?

+ +

I'm working on tooling for agentic engineering in strict compliance environments. The problem I keep running into isn't technical; it's behavioral. Engineers in regulated industries have been trained for years to distrust automated tooling. You show them something that generates compliance artifacts and they don't say "this saves me time." They say "will this get me audited?"

+ +

Adoption in that context isn't a feature. It's the entire product. If nobody trusts it enough to use it, nothing else matters. Speed, accuracy, coverage; all irrelevant if the thing sits on a shelf.

+ +

Here's what I've learned watching this play out across teams:

+ +

The tool that gets adopted is rarely the best tool. It's the tool that solves the problem people actually have, not the problem leadership wishes they had. If your engineers are drowning in compliance documentation, a tool that makes documentation faster will get adopted. If leadership bought a tool to measure productivity, it won't. The difference is whose problem it solves.

+ +

Adoption has a trust prerequisite. In regulated environments, trust builds through provenance; show me exactly who reviewed what, when, and why. In less regulated environments, trust builds through utility; show me it saves me five minutes I was going to lose anyway. Either way, trust comes before use. Most tooling strategies skip this entirely.

+ +

Adoption is social. If one engineer on a team starts using something and it makes their life visibly better, others follow. If nobody uses it, nobody will. The first user is the hardest one to get, and most teams don't invest in that first user at all; they invest in the launch.

+ +

DevEx is changing because engineering itself is changing. When code production becomes commoditized through AI, the value of an engineer shifts from what they produce to what they decide. Judgment, taste, the ability to know what not to build. Tooling that optimizes for production misses this entirely. Tooling that optimizes for judgment; that's the next wave.

+ +

So the question isn't "what tools should we build." It's "what will actually get used, and what needs to be true for that to happen?"

+ +

Start at the destination. The destination is adoption. Everything else is noise.

+
+
+ + + + diff --git a/src/pages/blog/gallup-disengagement.astro b/src/pages/blog/gallup-disengagement.astro new file mode 100644 index 0000000..5119931 --- /dev/null +++ b/src/pages/blog/gallup-disengagement.astro @@ -0,0 +1,112 @@ +--- +import BaseLayout from '../../layouts/BaseLayout.astro'; +--- + + + +
+
+
+ May 3, 2026 + Leadership +
+

80% of Your Team Is Disengaged. It's Not Their Fault.

+
+ +
+

There's a lot of fear right now.

+ +

I don't mean anxiety. I don't mean stress. I mean fear; the kind that sits in your stomach and doesn't leave. Engineers wondering if their job will exist next year. Managers wondering if they'll be replaced by a dashboard. Leaders wondering if the ground they built on is still there.

+ +

Gallup says 80% of the global workforce is disengaged. That's 2.7 billion people. Four out of five. Your team included. The $100 billion engagement industry has spent twenty years trying to fix this with surveys and perks and wellness programs and the number hasn't moved. Maybe the problem isn't the execution. Maybe it's the premise.

+ +

I call it fear-based development. Not anxiety-driven engineering, not burnout culture; fear-based development. The word matters. Fear is a specific thing. It's what happens when the future is uncertain and the present is threatening and you don't know which direction is safe. Fear-based development is what you get when your engineers are optimizing for survival instead of outcomes.

+ +

This is where I reach for Elijah. He called down fire from heaven; boldness on a scale most of us can't imagine. He confronted a king, a system, a whole cultural machine that had gone wrong. And then, immediately after, he prayed for death. Not because he was weak. Because that's what that kind of leadership costs.

+ +

The leaders we need right now are going to feel that. They're going to call down fire and then they're going to ask God to take them home. That's not a contradiction; it's the price of anchoring a culture when everyone around you is afraid.

+ +

Four words that matter more than any engagement survey.

+ +

Boldness.

+ +

Faith.

+ +

Purpose.

+ +

Persistence.

+ +

I'm working through this myself. I don't have a clean framework or three easy steps. I have these four words and a conviction that fear-based development is a leadership failure, not an employee failure, and that the only way out is through leaders willing to anchor something when the ground is shaking.

+ +

Here's what fear-based development looks like in practice. Engineers who used to argue with you about architecture now say "whatever you think." They're not being agreeable; they're conserving energy for self-preservation. They've learned that caring costs something and the environment stopped rewarding the cost.

+ +

Managers who used to protect their teams now say "leadership wants what leadership wants." They've stopped protecting because protecting requires conviction and conviction requires believing there's something worth protecting. Fear erodes belief first.

+ +

Standups that used to be about problems now just list tickets. The word "stuck" disappears. People don't want to be the one who's stuck when everyone's afraid of cuts.

+ +

This is structural, not individual. You can't perk your way out of it. You can't survey your way out of it. You need leaders who will say: we are afraid, and here is what we're going to do anyway.

+ +

The cultivation metaphor matters here. You don't manage soil that's been strip-mined; you cultivate it. You tend conditions. You feed what feeds everything else. Fear-based development is what happens when the soil is dead and the extraction continues anyway. The only fix is to stop extracting and start cultivating.

+ +

I don't know exactly what cultivation looks like for every team. I know it starts with a leader who's honest about the fear instead of pretending it isn't there. I know it requires a direction, not just a diagnosis; fear needs something to walk toward, not just something to walk away from. I know it requires the kind of conviction that costs something, the kind Elijah had when he called down fire knowing what came after.

+ +

Boldness, faith, purpose, persistence. Four words. No engagement survey will give you them. They come from somewhere else.

+ +

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.

+ +

What are you anchoring to?

+
+
+ + + + diff --git a/src/pages/blog/surveillance-extraction.astro b/src/pages/blog/surveillance-extraction.astro new file mode 100644 index 0000000..8d7f8af --- /dev/null +++ b/src/pages/blog/surveillance-extraction.astro @@ -0,0 +1,110 @@ +--- +import BaseLayout from '../../layouts/BaseLayout.astro'; +--- + + + +
+
+
+ May 3, 2026 + Leadership +
+

The Surveillance Dividend Is a Lie

+
+ +
+

Every company running "AI adoption" is making the same bargain: you give us more data about how you work, we give you tools that make you faster. Everyone wins.

+ +

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.

+ +

You're being strip-mined. But you'd rather be cultivated. The question is how to lead in that direction from where you are.

+ +

Here's how the extraction works. 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. Once the dashboard exists, it becomes the scoreboard. Standups shift from "what are you working on" to "why is your velocity down twelve percent this sprint." Engineers learn that the number matters more than the architecture. So they optimize for the number.

+ +

The AI tools amplify this loop. Generate more code. Accept more suggestions. Ship faster. The engineer stops designing and starts 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.

+ +

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.

+ +

The cultivation metaphor isn't decorative here. It's the whole point. 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 and the land produces nothing.

+ +

Cultivation builds soil. It takes longer. It looks less productive in quarterly reports. But it produces indefinitely.

+ +

And the surveillance tools aren't even measuring the right things. They measure volume: code, commits, 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.

+ +

None of that shows up on a dashboard.

+ +

The Harvard Business Review found that employees under heavy surveillance show forty-seven percent lower psychological safety scores. They stop proposing ideas. They stop questioning decisions. They stop doing the thing that makes them valuable, which is thinking independently.

+ +

So the surveillance pipeline produces exactly the opposite of what it promises: more data, less insight. More output, less value. More tracking, less trust.

+ +

Here's how to lead toward cultivation from where you are.

+ +

Measure outcomes, not activity. 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.

+ +

Protect deep work. 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.

+ +

Audit the tools 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.

+ +

Trust first, verify thoughtfully. 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.

+ +

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.

+ +

You're here. You'd rather be there. The distance between strip-mining and cultivation is measured in the decisions you make about what you track and what you trust.

+ +

What are you tracking?

+
+
+ + + + \ No newline at end of file diff --git a/src/pages/blog/token-anxiety.astro b/src/pages/blog/token-anxiety.astro new file mode 100644 index 0000000..dfec7d0 --- /dev/null +++ b/src/pages/blog/token-anxiety.astro @@ -0,0 +1,100 @@ +--- +import BaseLayout from '../../layouts/BaseLayout.astro'; +--- + + + +
+
+
+ May 4, 2026 + AI +
+

The Token Anxiety Trap — Why AI Agents Aren't Liberating Us (Yet)

+
+ +
+

Token anxiety is BS.

+ +

There's a term floating around Silicon Valley right now. Nikunj Kothari at FPV Ventures coined it: that feeling of "in this 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?" People checking their agents during parties. At bars. Walking through Dolores Park with laptops slightly open. Replacing evening Netflix with Claude Code, dreaming up new tasks to automate. Rushing the kids to bed so they can get back to the computer.

+ +

The New York Times calls it "tokenmaxxing." Axios says AI agents "operate like slot machines" for power users. Stanford's AI Index shows junior developer employment down twenty percent since 2024. The industry is in what one former Grammarly lead calls "a collective identity crisis."

+ +

All of that is real. The anxiety is real. The burnout is real. The junior dev pipeline collapsing is real.

+ +

But token anxiety specifically, the anxiety about how many tokens you're burning, whether you're getting enough value per token, whether the person next to you is extracting more from their agent swarm than you are; that's not anxiety. That's a signal that you don't know what you're doing.

+ +

If you know what you're doing and you optimize for outcomes, the token usage is meaningless. The outcome is always more valuable than the money spent on the tokens. Always. If a token run costs you five dollars and produces fifty thousand dollars of value, the tokens are free. If a token run costs you five cents and produces nothing because you don't have a clear outcome in mind, the five cents was wasted and no amount of token optimization will fix that.

+ +

The problem isn't the tokens. The problem is directionless work.

+ +

Eric Weber, who led data and AI at Grammarly, put it plainly: "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?"

+ +

We automated the how without examining the why. We built systems that maximize output while ignoring outcomes. Then we called the resulting anxiety "token anxiety" and wrote blog posts about how to cope with it.

+ +

You don't cope with it. You fix the direction.

+ +

Think about it physically. If you're running toward something, you don't count your steps. You count your distance to the goal. Steps are just what legs do. If you're running and you don't know where you're going, every step feels like a waste and you start counting them, and then you start optimizing the counting, and then you're not running anymore; you're just counting.

+ +

That's token anxiety. It's step-counting by people who forgot where they were going.

+ +

The fix isn't three questions before your next agent run. The fix is having an outcome before you start the run. If you can articulate what you're trying to accomplish, the tokens are infrastructure. If you can't, the tokens are a proxy for productivity, and optimizing a proxy never gets you to the real thing.

+ +

The agent revolution promised freedom. What it delivered was a new way to be busy. The difference between busy and productive has always been the same: do you know what you're building? If yes, burn the tokens. If no, close the laptop and figure it out.

+ +

Your tokens aren't the bottleneck. Your direction is.

+
+
+ + + + \ No newline at end of file