Three things happened in the past month that I can’t stop thinking about.

A developer on a team I work with stopped opening his IDE. He works entirely from the terminal now, describing changes in English and reviewing the output. His commit frequency tripled. His code quality didn’t drop.

A designer I know created a Claude Code skill. Not a Figma plugin. A skill. A set of instructions that seeds a design system from a repository, generates component variants, and produces implementation-ready specs. She’s not writing code. She’s writing the instructions that write the code.

A product manager I was talking to told me she stopped creating Jira tickets for small features. Instead, she writes the change she wants as a Claude Code prompt, gets a PR back, and assigns it to a developer for review. The developer’s job shifted from “implement this ticket” to “review this PR.”

I’m not exaggerating any of this. All three happened in April 2026.

Developers are evolving beyond the IDE

The IDE was the center of gravity for decades. Syntax highlighting, autocomplete, integrated debugging, git integration. Everything a developer needed, in one window.

That’s changing. The terminal is becoming the primary interface for a growing number of developers. Not because terminals are better at displaying code. Because the input modality changed. When you’re describing intent in English rather than typing syntax, the terminal is the natural home. You don’t need syntax highlighting when you’re not writing syntax.

The catch: this only works if you have strong technical knowledge underneath. You can’t describe what you don’t understand. A developer who says “add caching to the API with 5-minute TTL that invalidates on write” needs to know what TTL means, what cache invalidation strategies exist, and what “on write” implies for the data layer.

You cannot amplify what you don’t have.

The English language is the new driver. But technical depth is the engine. Without it, you’re just generating plausible-looking code you can’t evaluate. And plausible-looking code that’s wrong is worse than no code at all.

Designers are moving past Figma

I don’t mean Figma is dying. I mean the boundary of what “design work” means is expanding.

The designer I mentioned didn’t stop using Figma. She added a layer on top. Her Claude Code skill reads a repository’s existing components, understands the design tokens, and generates new component variations that respect the system. She seeds a design repository with variants, states, and responsive breakpoints that developers can implement directly.

She’s not designing screens. She’s designing systems that produce screens.

This is a fundamental shift in the designer’s role. Instead of producing deliverables (mockups, specs, redlines), she’s producing generative instructions. The deliverables are a side effect of the system, not the output of manual work.

The designers who will thrive are the ones who understand systems well enough to encode them. Taste still matters. Vision still matters. But the expression of taste is moving from “pixel-perfect mockup” to “design skill that produces on-brand output at scale.”

Product managers are bypassing the ticket

This is the one that surprised me the most.

The traditional workflow: PM writes a Jira ticket, assigns it to a sprint, developer picks it up, implements it, creates a PR, gets it reviewed, ships. Five handoffs minimum. Days to weeks of cycle time.

The new workflow I’m watching: PM describes the change she wants, an AI agent produces a PR, a developer reviews it. Two steps. Hours, not days.

The ticket still exists for tracking purposes. But it’s generated after the PR, not before. The artifact of work changed direction. Instead of a ticket that produces code, it’s code that produces a ticket.

This doesn’t eliminate the developer. It elevates them. The developer’s value shifts from “I can implement this” to “I can evaluate whether this implementation is correct, secure, and maintainable.” That’s a higher-skill, higher-value activity.

But it also means that developers who can only implement, who can’t evaluate and reason about code they didn’t write, are in a genuinely difficult position.

The common thread

All three shifts share the same underlying pattern: the people who are accelerating fastest are the ones who had the deepest knowledge before AI arrived.

The developer who works from the terminal has 15 years of architecture in his head. The designer who writes Claude Code skills understands design systems at a level most designers don’t. The PM who ships PRs has enough technical literacy to evaluate what comes back.

AI didn’t level the playing field. It tilted it. Toward the people who already understood what they were doing and can now do it at a speed that was previously impossible.

The gap between “person who understands and uses AI” and “person who just uses AI” is going to be the defining career gap of this decade.

The two camps

I’m seeing technical people split into two distinct groups right now. And the split is getting wider every week.

The first camp doesn’t believe AI writes better code than them. They’ve tried it. It hallucinated an API that doesn’t exist. It wrote a SQL query that would have dropped a table. It produced a React component that looked right but had a subtle state bug that took an hour to find. They concluded that AI is a toy, a parlor trick, a junior developer at best. They’re waiting for the “hockey stick productivity explosion” to happen and it hasn’t. So they went back to writing code the way they always have.

They’re not wrong about the bugs. They’re wrong about the conclusion.

The second camp hit the same bugs. The same hallucinations. The same frustrating moments where the AI confidently produced garbage. But they stayed. They saw what it could do on one task, one thread, one problem. And they understood something: if it can do this here, I can apply it there. And there. And there.

These aren’t people who “mastered” AI. They’re people who saw the pattern and started multiplying it. They figured out how to prompt. Not prompt engineering in the buzzword sense, but the ability to describe what they want clearly enough that something useful comes back. Then they applied that ability to code, to documentation, to testing, to deployment, to content, to research. And why not, to life outside work too.

The first camp never got past the frustration. The second camp got past it and found the compounding returns on the other side.

The difference isn’t intelligence. It’s not age. It’s not even technical skill, though that matters. The difference is curiosity. The first camp tried AI, found it imperfect, and stopped. The second camp tried AI, found it imperfect, and thought: “okay, but what if I tried it differently?”

I’ve been in the second camp for about a year now. The productivity curve isn’t a hockey stick. It’s a slow grind for weeks, then a sudden jump when something clicks, then another grind, then another jump. It looks flat until it doesn’t.

The people in the first camp are talented. Many of them are better raw coders than I am. But they’re optimizing a skill that’s becoming commoditized while the people in the second camp are learning to multiply themselves across everything they touch.

I don’t know how to convince someone in the first camp to cross over. I’ve tried. The best I’ve managed is: sit with me for an afternoon. Watch me work. Then decide.

What I’m not sure about

I don’t know if these shifts are permanent or if they’re the bleeding edge of a pendulum that swings back. Maybe the IDE evolves to absorb agent-based workflows. Maybe Figma ships native AI that makes external skills irrelevant. Maybe Jira adds a “generate PR” button and the PM workflow I described becomes a feature, not a hack.

What I do know: the people doing this work right now have a compounding advantage. Every day they work this way, they get better at it. And the gap between them and everyone else gets wider.

I’m watching it happen. And honestly, I’m still figuring out what it means.