Forem: Micky C

What AI Can't Understand About Your Users — And Why That Matters for Your Career

Micky C — Fri, 22 May 2026 09:03:15 +0000

The User Research Blind Spot

Your AI can write a login form. It can even write a beautiful, accessible, responsive login form with perfect validation and error messages.

What it cannot do is tell you why your users keep forgetting their password on the exact screen you designed.

This is the AI user research blind spot. It's not a gap in capability. It's a category error.

What AI Can and Can't Know About Users

AI learns from data. It can tell you what users did in the past. It cannot tell you why they did it, what they were thinking, or what they wanted but couldn't articulate.

When you watch a user try to complete a task and fail, you see the frustration, the hesitation, the moment they give up and close the tab. That moment is data. It's the most valuable data you can collect. AI wasn't in the room.

The senior developer who understands the user research process — the interviews, the usability tests, the "say out loud" protocol — has access to a category of insight that AI cannot generate.

This is not about the technique. It's about the specific humans you're building for, and what it takes to understand them.

Why User Research Is an AI-Resistant Skill

User research requires:

Being present with another person
Reading their emotional state
Following threads that seem tangential but turn out to be crucial
Recognizing when what someone says and what they mean are different things
Making judgment calls about which feedback to act on and which to contextualize

None of these can be automated. None of them can be delegated to an AI that wasn't in the room.

The developers who are most effective at building the right thing are the ones who have direct, ongoing relationships with the people who use what they build. They know the users. They've watched them struggle. They remember the moment of confusion.

AI can analyze a heatmap. It cannot tell you what that heatmap means in the context of your users' lives.

The Career Implication

The developers who will thrive in an AI-powered world are not the ones who can write more code, faster. They're the ones who can tell the difference between building the right thing and building the thing right.

Building the right thing requires understanding your users. Understanding your users requires being in the room with them.

That's not a technical skill. It's a human skill. And it's exactly what AI can't replicate.

The opportunity isn't to become a better coder. It's to become the person in the room who understands what to build.

Part of the AI-Proof Programmer series.

Stop Learning Frameworks, Start Learning Patterns That Transfer

Micky C — Tue, 19 May 2026 09:03:40 +0000

The Framework Trap

You learned React. Now you're learning Vue. Now Angular is making a comeback. You've spent the last three years learning framework after framework, and you keep ending up at the same place: confused about what actually matters.

This is the framework trap. And it's more dangerous than it looks.

What Frameworks Actually Do

A framework is a set of conventions that helps you build things within a specific set of constraints. React helps you build UIs. Django helps you build web apps. Kafka helps you build data pipelines.

The thing about conventions is that they're arbitrary. The specific way React handles state is not a law of nature. It's a choice made by a team of engineers at Meta, influenced by their specific needs and constraints.

When you learn React, you're learning those specific choices. When the next framework comes along, those choices become liabilities. The hours you spent learning component lifecycle methods? Gone. The time you spent understanding the virtual DOM? Transferred to nobody.

The Patterns Beneath the Frameworks

Real knowledge is framework-agnostic. It transfers. It compounds.

Here's an example: the observer pattern. Once you understand it deeply, React's useEffect dependency array makes immediate sense. Redux's store updates make sense. Vue's reactivity system makes sense. You didn't learn React — you learned a manifestation of a pattern that happens to be implemented in React.

The same is true for:

Dependency injection — understanding it makes Spring make sense, but also Hilt, and the service locator pattern in plain JavaScript
Event-driven architecture — understanding it makes Kafka clicks, but also RabbitMQ, and the Pub/Sub system your team built custom
Optimistic UI — understanding it makes React's pending state patterns make sense, but also the patterns in native mobile apps, and the ones your team rolls by hand
Event sourcing — understanding it makes Kafka the tool you reach for, not the tool you were taught to use

Frameworks come and go. Patterns are forever.

What Good Engineers Actually Know

Ask a senior engineer at a FAANG company how they'd build something, and notice what they reach for: not frameworks. Patterns.

"This is an event-driven problem. We could use a message queue, but honestly, for our scale, a simple in-memory pub/sub might be enough until we hit maybe ten thousand users a day."

"This looks like a CQRS situation. The read model and write model have different access patterns, so we should separate them."

"This is a classic distributed systems problem. We need eventual consistency here, strict consistency there. Let's draw the boundary."

This is not framework knowledge. This is pattern knowledge. And it transfers across every framework you'll ever work with.

How to Learn Patterns, Not Frameworks

The key to learning patterns is to always ask: "what problem does this solve, and is there a better way to solve it in my specific context?"

When you hit a problem that makes you reach for a framework feature, stop. Ask yourself:

What is this feature actually doing?
What pattern is it an implementation of?
Is there a simpler implementation of that pattern that doesn't require the framework?

When you learn a new framework, don't learn the features. Learn what problems each feature solves. Then look for the patterns. Once you see the pattern, the framework becomes a detail.

The developer who understands the observer pattern doesn't need to be taught Vue's reactivity system. They'll figure it out in an afternoon.

The developer who doesn't understand the observer pattern could spend years in Vue and still not understand why Vue behaves the way it does.

The Compound Interest of Pattern Knowledge

Pattern knowledge compounds. The more patterns you understand, the faster you learn new frameworks, because every new framework is just a different implementation of patterns you already know.

The trap of framework knowledge is that it doesn't compound. You learn React, then Vue, then Angular. Three separate piles of knowledge that don't connect to each other.

The senior engineers you admire aren't smarter than you. They've just been at this long enough that they've built a mental library of patterns. When something new comes along, they map it to what they already know. That's what makes them fast.

The investment you make in pattern knowledge today is the investment that pays dividends when the next framework drops and everyone scrambles to learn it. You'll already know the pattern. You'll learn the framework in an afternoon.

Part of the AI-Proof Programmer series.

The Five Conversations Every Programmer Should Master — And Why AI Can't Do Them

Micky C — Fri, 15 May 2026 15:50:14 +0000

Code is 20% of the Job

Most programmers spend about 20% of their time writing code. The other 80% is something else entirely:

Clarifying requirements in planning meetings
Explaining technical decisions to stakeholders
Negotiating scope and trade-offs with product managers
Giving feedback to colleagues

This is not a soft-skills pitch. This is about the conversations that actually determine whether your code ships, whether your features work, and whether your career advances.

AI can write code. It cannot negotiate a deadline.

Conversation 1: Requirements Clarification

The most expensive bug I've ever encountered wasn't a logic error. It was a feature that did exactly what the ticket said, but not what the stakeholder actually needed. It took three weeks to build, two more weeks to realize the mistake, and another week to fix.

The root cause was a requirements conversation that nobody had.

Requirements clarification is a skill. It involves asking questions that surface hidden assumptions, probing the "why" behind stated constraints, and getting specific about edge cases. Senior developers do this naturally. Junior developers often think requirements are just things written in tickets.

AI does not understand requirements. It does not know your company's context. It cannot ask the question that would have prevented three weeks of wasted work.

The developers who get things right the first time are the ones who had the right conversations before writing a line of code.

Conversation 2: Technical Trade-off Communication

Every architectural decision is a trade-off. You're choosing speed of development over flexibility, or simplicity over scalability. The developers who advance fastest are the ones who can articulate these trade-offs clearly — to managers, to other engineers, to stakeholders.

This matters because technical decisions often have business consequences that aren't immediately obvious. A "clean" architecture might take twice as long to build. A "quick" solution might create technical debt that slows down the team for months.

The conversation isn't just about the technical merits. It's about mapping technical reality to business constraints, and doing it in language that non-technical stakeholders can understand and act on.

AI can explain technical concepts. It cannot weigh trade-offs in the context of your specific business, team, and timeline.

Conversation 3: Scope Negotiation

"Why can't we have it all?"

Because scope is a negotiation. Features take time. Time has a cost. Resources are finite. Every "yes" to a feature is implicitly a "no" to something else — usually something implicit.

The developers who are trusted partners in product decisions are the ones who can have honest scope conversations without destroying relationships. They can say "yes, we can do that, but here's what it costs" and help find creative solutions that satisfy the underlying need without killing the timeline.

This is a conversation about priorities, about trust, about understanding what actually matters to the business. AI has no skin in the game.

Conversation 4: Feedback Delivery

The hardest feedback to give is honest feedback that might sting. The hardest feedback to receive is feedback that challenges your assumptions. The developers who get better fastest are the ones who can do both.

Giving feedback well requires reading the other person's emotional state, understanding their context, choosing the right moment, and framing the message so it lands rather than bounces off.

This is not a technical skill. It's not something you can learn from documentation. It's something you learn from actually doing it — and from getting it wrong, and trying again.

AI cannot give feedback that changes behavior. It can generate words that sound like feedback.

Conversation 5: Mentoring Handoffs

The most valuable developers don't just write code. They grow the team around them. This means mentoring junior developers through the moments that define how they think about software.

The handoff conversation is when you explain why a decision was made a certain way, what you considered and rejected, and what the junior developer should watch out for. Done well, this is worth more than any blog post or tutorial.

It's not about the code. It's about the judgment behind the code. And judgment transfer requires human connection.

Why AI Can't Do These

AI processes language. It can generate responses that sound like these conversations. It can even simulate the structure of a good negotiation.

What it cannot do is:

Understand the specific humans involved and what they care about
Read the room before deciding how to frame a difficult conversation
Make the judgment call about which battle to fight and which to let go
Build the trust that makes honest conversations possible

These conversations require you to be present. AI is never present.

Part of the AI-Proof Programmer series.

The AI-Resistant Programmer: Why Soft Skills Matter More Than Code

Micky C — Fri, 15 May 2026 15:44:37 +0000

The World Changed Quietly

In 2023, something strange started happening in programming communities. People who had spent years building their careers around technical excellence began noticing something unexpected: the developers getting promoted weren't always the ones who wrote the best code.

They were the ones who could explain that code to a product manager in plain English. The ones who knew which meetings to show up to and which to skip. The ones who could tell a junior developer why something was done a certain way — and make it click.

This isn't a story about AI replacing programmers. It's a story about what AI makes more valuable.

The Skills That Actually Matter

Ask any senior developer what separates great programmers from competent ones, and you'll rarely hear "writes cleaner code" as the first answer. You'll hear things like:

"They understand the business context"
"They know when to push back on requirements"
"They make everyone around them more effective"
"They can debug by talking to the system, not just staring at logs"

These are soft skills. And soft skills are exactly what AI can't replicate.

Why Soft Skills Are AI-Resistant

AI is trained on patterns. It excels at tasks with clear inputs and outputs, where the "right" answer is verifiable. Soft skills are the opposite — they're ambiguous by nature, context-dependent, and require reading people.

When an AI can reliably tell you that your product manager's actual concern behind that feature request is security theater, not user experience — come back and tell me about AI-resistant skills.

Soft skills matter more in an AI-powered world because:

Communication is coordination. Every hour a developer spends in meetings is an hour they're reducing coordination costs. High coordination costs destroy software organizations. Being the person who makes meetings productive is irreplaceable.

Judgment is scarce. AI can generate options. It can't tell you which option aligns with a three-year-old company's actual strategy when the CEO just changed direction last week. That judgment requires context, relationships, and trust.

Trust is non-negotiable. Senior developers get access to systems, data, and decisions that junior ones don't. Trust is built through relationships, not capability. You can't AI-generate trust.

The Quiet Revolution in What Companies Value

The developers who are thriving right now aren't necessarily the ones with the most LeetCode points or the deepest systems knowledge. They're the ones who can:

Translate between business language and technical constraints
Identify which technical debt actually matters (hint: not all of it)
Mentor juniors without making them feel stupid
Push back on deadlines without killing the relationship
Know when "good enough" is actually good enough

These skills were always important. But in a world where AI handles more and more of the technical work, the differentiator is everything AI can't do.

What This Means For Your Career

The programmers who should be worried aren't the ones who write good code. They're the ones whose only value is writing good code. If your entire value proposition is technical execution, you'll be fine — for now. But "for now" is a dangerous place to build a career.

The people who will thrive are the ones who use AI as a productivity multiplier for their soft skills. Imagine being 10x more effective at the things AI can't do. That's the opportunity.

The AI-Resistant Programmer isn't anti-AI. They're the developer who uses AI to handle everything except the part that actually matters.

Part of the AI-Proof Programmer series.

Test 1

Micky C — Mon, 11 May 2026 19:59:13 +0000

Body here