Forem: New Riders Labs

The Irreplaceable Human in the Age of Smart Systems

New Riders Labs — Sun, 11 Jan 2026 04:54:39 +0000

The notifications are pinging, the deployment pipeline is humming, and somewhere in the background, an AI is probably writing code faster than you had your morning coffee. If you're feeling a knot in your stomach about what this means for your career, your team, or just... humans in general, you're not alone.

Let's sit with that discomfort for a moment instead of rushing to either pole of "AI will save us all" or "we're all doomed." The reality, as usual, lives somewhere in the messy middle.

What We're Really Afraid Of

When we talk about AI anxiety in tech, we often frame it as "Will AI replace developers?" But that's not quite the right question. The better question might be: "What happens when the fundamental ways we build and maintain systems change rapidly, and we're not sure where we fit?"

Because here's the thing—AI is already changing how we work. Code completion tools are getting scary good. AI can generate entire functions, debug issues, and even architect solutions. But if you've spent any time with these tools in complex, real-world systems, you've probably noticed something interesting: they excel in isolation but struggle with context, nuance, and the weird interdependencies that make our systems actually work.

The Context Problem

Large, distributed systems are essentially giant webs of relationships. Not just between services and databases, but between teams, business requirements, legacy decisions, and that one critical system nobody wants to touch because Janet, who built it, retired two years ago.

AI can read your codebase, sure. But can it understand why the payment service has that weird timeout because of a vendor limitation that got baked in during a crisis three years ago? Can it grasp the political dynamics that led to the current architecture, or the implicit knowledge about which services can safely fail during peak traffic?

This isn't about AI being "bad"—it's about recognizing that context isn't just technical. It's historical, social, and often invisible.

What Stays Human

So what can't be automated away? Let me suggest a few things, and I'm curious if your experience matches mine:

Pattern recognition across domains. Humans are weirdly good at connecting dots that seem unrelated. That moment when you realize the database performance issue is actually related to a change in user behavior that happened because marketing launched a campaign targeting a different demographic? That's not just technical pattern matching—that's synthesis across business, human, and technical domains.

Navigating ambiguity and competing priorities. Systems don't just exist in technical space; they exist in organizational space. When the security team says "lock everything down," the product team says "move fast," and the infrastructure team says "we're hitting capacity limits," who decides the tradeoffs? AI might suggest solutions, but someone human has to weigh the business context, team capacity, and long-term consequences.

Building trust in distributed teams. Ever notice how the most successful distributed systems often correlate with teams that have high trust? That's not coincidental. Trust is built through consistent communication, vulnerability (admitting what you don't know), and demonstrating care for shared outcomes. These are fundamentally human capabilities.

Adapting to novel failures. AI is great at recognizing patterns it's seen before. But distributed systems fail in wonderfully creative ways. The ability to stay calm when everything is on fire, think laterally about solutions, and coordinate a response across multiple teams during an incident—that requires judgment, creativity, and emotional regulation under pressure.

The Evolution, Not Revolution

Here's what I think is happening: we're not being replaced, but our roles are evolving. The tedious parts—boilerplate code, basic debugging, routine maintenance—those are increasingly automated. What remains is the deeply human work of understanding, synthesizing, and navigating complexity.

Maybe the future developer is less "someone who writes code" and more "someone who understands systems, translates between technical and business domains, and guides AI tools toward useful outcomes." Less keyboard warrior, more systems whisperer.

But I could be wrong about this. The pace of change is honestly pretty disorienting, and anyone claiming certainty about where this is all heading is probably selling something.

Questions Worth Sitting With

What aspects of your current work feel most irreplaceably human to you? Not the parts you think should be human, but the parts where you consistently add value that you can't imagine a tool replicating?

And maybe more importantly: if AI handles more of the routine technical work, what kind of professional do you want to become? What skills feel worth developing not because they're AI-proof (nothing is), but because they align with how you want to contribute to the world?

The Paradox of Automation

Here's something worth considering: as our systems become more automated and AI-assisted, the human elements might become more important, not less. When everything works smoothly, the technical complexity fades into the background, and what matters most is understanding needs, facilitating collaboration, and making good decisions with incomplete information.

The most successful organizations I've worked with don't treat their people like biological APIs. They recognize that humans bring something essential to complex systems: the ability to hold context, navigate relationships, and adapt to change with creativity and empathy.

What's your experience with AI tools in complex systems? Where do you find yourself adding the most irreplaceable value? I'd love to hear how you're navigating this transition—the uncertainty is real, but maybe we can figure out some of this together.

Drop your thoughts in the comments or find me on the usual places. The conversation matters more than having all the answers right now.

Stop Asking Claude to "Write Code" — Do This Instead

New Riders Labs — Sat, 03 Jan 2026 23:54:34 +0000

I've been coding with Claude AI for 500+ hours over the past year. I've seen what works and what doesn't.

The biggest mistake I see developers make? Treating Claude like a search engine.

"Write me a function that does X."

That's not how you get good results. Let me show you what actually works.

The Problem with Generic Prompts

When you say "write me a function that validates email addresses," Claude doesn't know:

What language you're using
What your error handling patterns look like
Whether you need RFC 5322 compliance or just basic validation
If this is for user registration or internal tooling
What your testing requirements are

So it gives you a generic answer. And you wonder why AI "doesn't work."

The Fix: Context Is Everything

Here's the same request, done right:

I need email validation for a Flask API endpoint that handles user registration.

Tech stack: Python 3.9, Flask, SQLAlchemy
Current pattern: We use a validate_* naming convention and raise ValidationError for bad input.

Requirements:
- Basic format validation is fine (no need for RFC 5322)
- Should reject disposable email domains
- Needs to be testable

Existing code style:
[paste an example function from your codebase]

Write the email validation function following these patterns.

Same request. 10x better output.

10 Prompt Patterns That Actually Work

Here are my go-to patterns after a year of daily Claude use:

1. The Focused Review

Don't ask for a generic code review. Focus it:

Review this code specifically for security issues.
Ignore style, performance, everything else.
I just want to know: can this be exploited?

[paste code]

Generic reviews give generic feedback. Focused reviews give actionable feedback.

2. The Debugging Frame

Structure your debugging requests:

I'm getting this error:
[paste error]

From this code:
[paste code]

Help me understand:
1. What's causing this error?
2. Where exactly is it happening?
3. How do I fix it?

The numbered list forces Claude to give you complete answers instead of vague explanations.

3. The "Works Locally" Template

Every developer's nightmare:

This code works in my local environment but fails in production.

Local: Mac, Python 3.9, SQLite, DEBUG=True
Production: Linux, Python 3.9, PostgreSQL, DEBUG=False

The error:
[paste error]

What environment-specific issues should I check?

Claude is surprisingly good at spotting environment mismatches.

4. The Gut Check

When something feels wrong but you can't articulate it:

This code works, but something feels off. I can't articulate what's bothering me.

Walk through this slowly and tell me what might be bugging me about it.

[paste code]

Claude can often name the code smell you're sensing.

5. The Rubber Duck

Sometimes you don't need code:

I'm going to explain what I'm building. Just listen and ask clarifying questions. Don't write any code until I say so.

This is underrated. Claude's questions often surface edge cases you hadn't considered.

6. The Project Context Setup

This is the single most powerful pattern. At the start of any project:

# Project Context

## What This Is
[Brief description]

## Tech Stack
- Language: Python 3.9
- Framework: Flask
- Key deps: SQLAlchemy, requests

## Conventions
- Naming: snake_case
- Errors: Custom exceptions in errors.py
- Testing: pytest, fixtures in conftest.py

## Current State
Working on: [current feature]
Known issues: [bugs/incomplete stuff]

Paste this at the start of conversations. Watch your results improve dramatically.

7. The Trade-Off Analysis

Claude's reasoning is often better than its code:

I can solve this with approach A or approach B.

Compare them for:
- Performance at scale
- Code maintainability
- Edge case handling
- How easy it is to test

What would you choose and why?

8. The Refactor Request

When code works but feels messy:

This code works, but it feels like it could be cleaner.
Suggest refactoring options and explain the trade-offs of each.
Keep the same behavior.

[paste code]

The key: "explain trade-offs." Gets you teaching, not just code output.

9. The Explain It Back

Before any complex task:

Before you write any code, tell me your understanding of what I'm asking for and your planned approach.

Catches misunderstandings before you waste tokens on the wrong solution.

10. The Session Continuity

When starting a new chat:

Continuing from previous work:

Last session: Working on user authentication
Got to: JWT implementation done, need refresh tokens
Stuck on: Token rotation strategy

Let's pick up from there.

The Meta-Lesson

Good prompts aren't about tricking the AI. They're about giving it what it needs to help you.

Context about your project
Focus on what matters
Structure that enables complete answers
Examples of your existing patterns

Do this consistently and Claude becomes a genuinely useful collaborator instead of a frustrating autocomplete.

Want More?

I've packaged 75+ prompts like these into a complete collection, organized by use case:

Code Review & Refactoring
Debugging & Troubleshooting
Architecture & Design
Documentation
Project Scaffolding
Testing
Learning & Upskilling
Workflow & Productivity

Each prompt includes when to use it and real examples.

Grab it here: Claude Prompt Pack for Developers

What prompt patterns work best in your workflow? Drop them in the comments — I'm always looking for new approaches to add to my toolkit.