I’ve been a designer for 29 years. I started at 18. I’ve shipped work for Adobe, IBM, Danone. I’ve been an individual contributor, a design manager, and a dev team lead. I’ve watched our industry pivot five or six times, depending on how you count.

This one is different.

There’s a phrase that gets misused a lot: the king is dead, long live the king. People treat it like a contradiction. It isn’t. It’s a statement about succession. The role survives. The throne survives. The work survives. The person doing it doesn’t.

That’s what’s happening to the Individual Contributor role right now. The IC isn’t being eliminated. It’s being inherited. Same crown, same seat, same job title. Different person sitting in it. And the handover is already underway, whether your org chart has caught up or not.

Let me explain what I mean, and who’s getting the crown.

What “IC” used to mean

For most of the last twenty years, being an Individual Contributor meant one thing: you were the person who made the thing.

You wrote the code. You designed the screens. You drafted the deck. You produced the assets. Your value was a function of your craft, your speed, and your ability to take a brief and turn it into a finished artifact. The ladder was clear. You got better at making things. You got faster. You got more senior. Eventually, if you wanted, you got promoted into managing other people who made things.

That world worked because making things was the bottleneck. Companies needed throughput. ICs supplied throughput. The org chart was basically a throughput pipeline with managers at the joints.

That world is ending.

What broke it

AI didn’t replace designers, or engineers, or PMs. That framing misses the point. AI replaced execution. The part of our jobs that was about turning a clear brief into a finished artifact, the part we got paid for, is now the part a model does in seconds.

If you’re a designer, you’ve felt this. The mockup you used to charge two days for is a prompt away. If you’re an engineer, you’ve felt it. The boilerplate, the CRUD, the integration glue: gone. If you’re a PM, the doc you spent a morning on writes itself.

And here’s the uncomfortable part: it’s not just fast. It’s often good enough. Not always. Not for the hard problems. But for the 70% of work that filled most ICs’ calendars? Yes.

So the question stops being “how fast can I produce?” and becomes something much harder:

What is left of my job when the production isn’t the job anymore?

That’s the gap the next IC steps into.

Enter the IC 2.0

The Individual Contributor 2.0 isn’t a new title. You won’t see it on LinkedIn yet. It’s a way of working that’s emerging in the people who are quietly outperforming everyone around them right now.

The IC 2.0 isn’t faster at making things. They’re better at deciding what to make, orchestrating how it gets made, recognising when it’s wrong, and owning whether it actually works.

There are four skills that define this shift. None of them are new. All of them used to be optional. Now they are the job.

1. Judgment

The most undervalued skill in tech is the ability to look at three plausible options and pick the right one for the right reason.

When you can ship anything in an afternoon, the constraint stops being capability. It becomes choice. Should we build this? Is this the real problem? Will this still be true in six months? Most of the bad work I see right now isn’t bad because the AI did it badly. It’s bad because nobody asked whether it should exist.

IC 2.0 is the person in the room who can say “this is the wrong problem” and back it up. That used to be a manager’s job. Now it’s table stakes for anyone who wants to stay relevant.

2. Orchestration

Old IC: I make the thing.

New IC: I run a small swarm of agents, tools, and collaborators (some human, some not) and the thing comes out the other end.

This is not “prompt engineering.” It’s closer to being a director. You hold the intent. You sequence the work. You know which tool is good at which step, which model to use when, which output needs a human eye and which one doesn’t. You catch the handoffs.

Most people are still using AI like a faster autocomplete. The IC 2.0 uses it like a team.

3. Pattern recognition

I deliberately don’t call this taste. Taste has been inflated into a vague compliment that mostly means “I like how it looks.” What I mean is older and more useful than that.

When the cost of producing options drops to near zero, the bottleneck shifts to recognising which one is actually right. AI will give you twelve directions. Eleven of them will be plausible. One of them will be the one you’ve seen succeed before, in a slightly different shape, for slightly different reasons. Knowing which is which is pattern recognition, and it is not a visual skill. It applies to architectures, to product bets, to organisational dynamics, to written arguments, to whether a feature is going to age well.

It comes from having shipped enough things, watched enough of them work and fail, and paid honest attention to why. You can’t prompt for it. You can’t shortcut it. It is the moat that the people racing to the bottom on speed are not building.

If you have it, name it out loud and use it more deliberately. If you don’t, the only way to grow it is the slow one: ship things, watch what happens, and be ruthlessly honest with yourself about which of your instincts were right.

4. Accountability

The old IC could hide behind the brief. “I built what was asked.” The output was their deliverable; whether it worked was someone else’s problem.

The IC 2.0 owns the outcome, not the artifact. Did the feature move the metric? Did the redesign reduce support tickets? Did the campaign convert? When you can produce a finished thing in an hour, “I made it” stops being interesting. “I made the right thing and it worked” is the whole game.

This is the most uncomfortable part of the transition for a lot of senior ICs, and I include myself in that. It means caring about commercial outcomes you used to leave to someone else. It means having opinions about strategy that you used to keep quiet. It means putting your name on results, not just deliverables.

The succession is already happening

This is the part most people miss. The handover isn’t a future event. It’s not waiting on a layoff round, or an org restructure, or a memo from the CEO. It’s happening quietly, right now, across the industry.

The crown gets passed in small moments. The IC 2.0 is the one who gets pulled into the strategy conversation that used to happen above their pay grade. The one whose name comes up when something important needs owning. The one whose Slack messages get screenshotted and forwarded because the framing was so clearly right.

Nobody announces it. There’s no ceremony. One day you look around and notice that the same role you’ve held for three years now looks completely different in your colleague’s hands. They’re doing less production and more direction. Less making and more deciding. Same title, same level, but the centre of gravity has moved.

This isn’t about winners and losers. It’s not about age, or seniority, or even skill in the traditional sense. I know 25-year-olds already operating as IC 2.0s, and 20-year veterans still optimising for output speed. The difference is whether you’ve made peace with the fact that making the thing is no longer the job, and whether you’ve put the four skills above at the centre of how you work.

The throne isn’t empty. It never is. The question is just who’s sitting on it next.

So what now

If you’re reading this and recognising yourself in the IC 1.0 description, the path forward isn’t to learn more AI tools. The tools will keep changing. The skills underneath them won’t.

It’s to start practising the four things this article is about. Develop opinions, defend them, and notice when they’re wrong. Stop asking “can I do this?” and start asking “should we?” Pay attention to whether what you shipped actually worked, and tell the truth about it.

The good news, if you’re a senior IC who’s been quietly worried for the last year: most of the IC 2.0 skill set is the stuff you already do. You just need to put it at the centre of your job instead of treating it as the thing you do between the real work.

The real work changed. The role didn’t. The throne is the same throne.

The only question is who’s sitting on it on your team next quarter, and whether that’s you.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

This is a less dramatic claim than the ones currently dominating the conversation about AI and productivity, but it is also more accurate. Most of the recent change in how software gets built is not the appearance of new dysfunction. It is the loss of the ability to hide old dysfunction. The mirror was always there. It just got sharper.

The compression argument

The reason the mirror suddenly matters is velocity.

A few years ago, a team that shipped quarterly could absorb a remarkable amount of process dysfunction without anyone noticing. A vague specification cost two weeks of back-and-forth between design and engineering. A misaligned handoff produced a fortnight of rework. An unclear decision required a status meeting, a follow-up status meeting, and a Slack thread to resolve. None of this was good, but it fit inside the cycle. The team shipped on time. The dysfunction stayed invisible because the cadence was slow enough to absorb it.

Compress the cycle. The team now ships every two weeks, and increasingly every few days. The same vague specification still costs two weeks of back-and-forth, except now those two weeks are the entire release window. The same misaligned handoff still produces a fortnight of rework, except the rework is no longer overhead, it is the project. The dysfunction did not grow. The tolerance for it collapsed.

This is the mechanism. AI did not make process worse. AI raised throughput in the parts of the workflow that were never the bottleneck, which surfaces the parts that always were. Implementation used to be the slowest step, so implementation is what teams optimised. Now implementation is fast, and everything that was hiding behind it is suddenly visible: unclear ownership, undefined acceptance criteria, decisions delegated to the room rather than to a person, design specifications that worked because engineers filled the gaps, and product requirements that were really just preferences with a confident tone.

What the mirror shows

A few patterns recur across teams that go through this transition.

Specifications that were never specifications. Many teams ran on documents that looked like requirements but were actually starting points for negotiation. The engineer read the spec, identified the ambiguities, and resolved them through a series of conversations with the product manager during implementation. This worked because implementation was slow enough to host the negotiation. When implementation collapses to hours, there is no longer a window for the negotiation. The ambiguity surfaces immediately, and someone has to make the decision that the spec quietly avoided.

Handoffs that depended on rework. Design-to-engineering handoffs in many organisations were never clean. They worked because the engineer had time to ask questions, the designer had time to revise, and both sides absorbed the gap as part of the cost of building. AI compresses both sides of that gap. The designer produces more variations more quickly. The engineer produces more code more quickly. The interface between them, which was always informal, is now the slowest part of the system. Teams that had clean interfaces between roles barely notice. Teams that ran on tribal knowledge and improvisation suddenly cannot move.

Rituals that were really compensating. A surprising amount of process exists not to coordinate work but to compensate for unclear ownership. Status meetings often exist because no one is sure who owns the decision. Alignment documents often exist because the alignment never happened. Cross-functional reviews often exist because the requirements were never agreed. When velocity increases, these rituals become bottlenecks rather than safety nets, and their original function becomes legible. The team is not running too many meetings. The team is running too many meetings to substitute for decisions that were never made.

Quality gates that were really process gates. Code review, design review, and similar checkpoints were often doing two jobs at once: catching real defects and slowing the work down enough for the rest of the system to keep up. When AI accelerates the production side, the gates do not scale, because they were never sized for the actual defect rate. They were sized for the cadence. Teams discover that what they called a quality process was partly a pacing mechanism.

None of these patterns are new. They have been present in software teams for as long as there have been software teams. What is new is the rate at which they become unavoidable.

The structural argument

The pattern that connects all of this is structural. The teams that absorb AI most easily are the teams that were already organised around clear primitives: explicit ownership, clean interfaces between roles, decisions that lived with named individuals rather than with the room. The teams that struggle most are the teams that ran on improvisation, where the structure of the work was implicit and held together by shared context.

This is the same pattern that shows up at the product level. Products that were architected as composable primitives absorb AI naturally because the structure was already there. Products that were architected as monoliths can only bolt AI on, and the bolt-on amplifies the structural debt rather than hiding it. The architecture and the org chart tend to mirror each other, which is why the same diagnosis applies to both.

The implication is that the work of preparing for AI is mostly not AI work. It is the work of making structure explicit. Naming who owns which decisions. Defining what a finished specification looks like. Drawing the interfaces between roles in a way that does not require shared context to traverse. This work was always valuable. It is now also urgent.

The variance question

One consequence of all this is harder to discuss but worth naming briefly. When the process was the bottleneck, individual variance in skill was difficult to read. A strong product manager and an average product manager produced similar outcomes because the system absorbed the difference between them. The same was true of designers, engineers, and managers across the stack. The slowness flattened the signal.

When the process gets out of the way, the variance becomes legible. This is not a moral observation, and it does not mean that anyone has become better or worse at their job. It means that the conditions under which performance was previously evaluated have changed. People who were good at navigating dysfunction find that their skill is less in demand. People who were good at producing clear work find that their work is more visible. The distribution did not shift. The lighting did.

Where this lands

The diagnostic value of this period is real, and most of it has nothing to do with AI tooling. The teams that are paying attention are using the increase in velocity as a forcing function to surface the structural debt that was always there. They are not adopting AI to go faster. They are using the appearance of speed elsewhere in the system to expose where they were never fast, and they are fixing those parts.

The teams that are not paying attention are reading the same signals as a tooling problem. They are looking for the AI configuration, the prompt library, the workflow integration that will restore the previous equilibrium. The equilibrium is not coming back. The mirror is the new condition.

The useful question is not how to make AI fit the existing process. The useful question is what the velocity is revealing, and whether the parts of the process being revealed were ever doing the job they were assumed to be doing. In most cases the answer is that they were not. They were doing a different job, quietly, and the slowness was making that job invisible.

Nothing new is in the mirror. It just got harder to look away.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel. He publishes weekly tests of AI tools for designers, product managers, and engineers.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

A designer on a construction software team is tasked with redesigning document review. Submittals, RFIs, drawings, change orders. The kind of workflow that decides whether a project ships on time or drags into litigation.

She opens Figma. She starts with the submittal list view. Card or table? She picks cards. She debates filter chip styling for a morning. She mocks up the empty state, the loading state, the hover state. Three weeks later, in an engineering review, the lead asks: “what happens when a reviewer is reassigned mid-review and they’ve already left markups on the drawing?” The design falls apart. Not because the designer is bad. Because Figma let her decorate before deciding.

The pixels hid the holes.

This happens constantly on enterprise construction products, where the substance of the design is logic, sequence, and state, not layout. We reach for the visual tool first because it feels like progress. It isn’t. It’s avoidance dressed up as craft. And on a B2B product where one missed state can mean a stalled submittal, a contractual exposure, or a field crew waiting on an approval, that avoidance has real cost.

There’s a better starting point. Before you open a design tool, answer two questions: what are the things, and what can you do to them?

That’s a schema and a command set. If you can’t write them down clearly, you don’t understand the feature yet, and no amount of prototyping will save you.

The exercise, on a real example

Take document review on a commercial construction project. A reviewer gets assigned a submittal, reads it against the spec, leaves markups, and either approves it, rejects it, or flags it for a different discipline.

Start with the schema. Not as code. As a plain list of what exists.

A document has an id, a title, a status, an assignee, a due date, a discipline. A review has a reviewer, a document, a verdict, a timestamp. A markup has an author, a document, a body, a position on the page.

Already, real design questions surface. Can a submittal have multiple active reviews at once across disciplines, or only one at a time? Is a markup tied to the document or to a specific review cycle? When a reviewer is reassigned, do their existing markups transfer to the new reviewer or stay locked to the original review? You’re solving the product before you’ve drawn anything.

Now the commands. Write them as the literal strings someone would type.

docs list --status pending --assignee me
docs assign <doc> --to <reviewer> --due <date>
docs flag <doc> --reason "missing signature"
docs approve <doc>
docs reject <doc> --reason <text>

Five commands. Read them out loud. Notice what isn’t there. No favorites. No recently viewed. No share-with-team. Those might be nice. They aren’t the job.

This is the move. The CLI has no room for nice-to-haves, because every command costs the user the effort of remembering it. So every command has to earn its place. The discipline of that constraint is exactly what gets lost the moment you open Figma, where adding another button costs nothing.

Why this works

GitHub has one of the most polished web interfaces in software. It also has gh, a command-line tool that does almost everything the web UI does. Cursor and Claude Code drive it constantly. The CLI didn't replace the UI. It exposed the product's spine so cleanly that agents and power users could bypass the UI when they wanted to. That's what a well-designed product looks like underneath the pixels.

Here’s why starting at that layer changes how design happens.

Constraint forces priority. Every command in a CLI is a deliberate decision. There’s no “we’ll figure it out in the empty state.” Either the verb exists or it doesn’t. Either it takes that flag or it doesn’t. You discover, fast, which features are core and which were sneaking in because they were easy to draw.

The conversation with engineering changes. When you walk into an engineering review with five commands instead of fifteen screens, something different happens. Engineers map each command to an API endpoint in minutes. “docs list with a status filter, we already have that. docs assign, we have it but it doesn’t take a due date, that’s a small change. docs flag, that’s new work.” A three-week scoping exercise becomes a twenty-minute conversation. And sometimes the answer is “all of these already exist, you don’t need us to build anything, you need a thin client.” That outcome almost never surfaces from a Figma review, because pixels look like work to be done even when the work is already done.

The UI becomes obvious. Once you know the five commands, the screens design themselves. The list view is docs list. The detail view is one document with its actions. You stop debating layout because the layout follows the verbs. The visual decisions get smaller and faster, because the hard decisions are already made.

Where to start

The point of CLI-first design is to think in primitives. So the tool should also be primitive. Not Figma. Not a diagramming app.

Open a text file. Write the schema as a plain list. Don’t worry about types or naming conventions yet. Worry about whether the names are honest. If you find yourself writing “metadata” or “config,” push harder. Those words mean you haven’t decided.

Then write the commands the way a user would type them. If a command needs five flags to make sense, the verb is wrong. If two commands do almost the same thing, you’ve found a duplication you’d have papered over in pixels.

Now bring in Cursor or Claude Code and ask it to scaffold a working CLI from your schema and your commands. You’ll have something runnable in an hour. Type the commands. Notice which ones feel awkward. That awkwardness is the design feedback you’d have spent three weeks discovering in Figma.

Then share the runnable CLI with three technical users. A power user, a PM, an engineer. Watch them use it. You’ll get more honest feedback in an afternoon than from a week of design walkthroughs, because there’s nothing to react to except the substance. Nobody says “I love the color of the button” in a terminal. They say “why does this command exist” or “I expected this flag to do something different.” That’s the feedback you actually need.

This is the approach behind a tool I built called create-trimble-app, which scaffolds AI-ready projects with a design system pre-loaded so the CLI-to-UI handoff has no friction. The principle is the same: get to a runnable surface as fast as possible, and let the surface, not the mockup, drive the design.

The bonus, not the point

A real CLI is also agent-ready. Claude Code, Cursor, any LLM can drive a well-designed command surface faster and more reliably than it can drive a UI. If your feature has a clean set of verbs and nouns, you’ve accidentally built the agent interface alongside the human one. The same commands that force discipline in design also let an AI execute the workflow without screen-scraping a front end that wasn’t built for it.

This matters more every month. But treat it as a happy accident, not the reason to do it. The reason to do it is that your design will be better, and you’ll find that out faster.

The terminal isn’t the deliverable. The deliverable is still the product your users see, and that product still needs craft, hierarchy, and care. None of that goes away.

What changes is where the thinking starts. Spend a day in a text file and a terminal before you spend three weeks in Figma. You’ll discover whether your design has a spine. If it does, the visual work that follows will be faster and sharper, because the hard decisions are already behind you. If it doesn’t, you’ll have found out for the cost of an afternoon, not a sprint.

The cheapest way to know whether a design works is to strip it of everything that makes it look like a design.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel. He publishes weekly tests of AI tools for designers, product managers, and engineers.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

This is not an unusual story. It’s close to the median story. And the diagnosis most teams reach for, that the prompts need tuning or the model needs upgrading or the UX needs another pass, is almost always wrong. The problem is further upstream, and it’s structural. The product wasn’t built to be recomposed. AI can only ever sit on top of it. And AI on top of a rigid product is a feature, not a transformation.

AI won’t save a product that was never composable.

What composable actually means

A composable product is one whose core capabilities exist as small, reusable pieces that can be assembled in different ways depending on context. Call them primitives. A primitive is something the rest of the product is built out of, not something the product has. A block of text in Notion is a primitive. A page is an assembly of blocks. A database view is another assembly. The product is not the pages, the product is the primitives and the rules by which they compose.

This distinction sounds small and it isn’t. When AI arrives at a composable product, it has something to work with. It can rearrange the primitives, suggest new compositions, surface the right ones at the right moment. The primitive layer is the surface that AI reasons over. Without that layer, AI has nowhere to stand. It can describe what it sees on the screen, it can generate new content to add to the screen, but it can’t change what the product fundamentally is, because the product is the screen, and the screen is frozen.

Why most products aren’t built this way

Because, for most of the history of software, they didn’t need to be. The consumer of software was a human, the human needed a screen, and the screen was the deliverable. Design teams produced screens. Product teams scoped features to screens. Engineering teams built screens. The entire operating model of product development, from research through launch, treated the application as the unit of work.

Inside that model, primitives happened, but they were an implementation detail. Components got reused when convenient, rebuilt when not. A button here, a button there, slightly different, both fine. Design systems emerged as a partial response to this, but they mostly worked at the visual layer. Two buttons that looked the same could still behave completely differently, because the primitive was the picture of the button, not the button itself. The real composability, where capabilities and behaviours are genuinely reusable across contexts, rarely made it past the pitch deck.

This was fine. The cost of this approach was duplication and inconsistency, and those are annoying but survivable. The product still worked. Users still got value. Nobody was grading the architecture.

AI grades the architecture.

The shift

When the consumer of software is no longer only a human, everything downstream of that assumption becomes negotiable. An agent doesn’t need a screen the same way a person does. It needs to know what the product can do, what state things are in, and what actions are available in this moment. The screen, for the agent, is an artefact it either reads or renders, not an input it authors. The agent wants primitives.

Products built on primitives can serve this without rebuilding. The same capabilities that compose into screens for humans can compose into operations for agents, views for different contexts, or outputs that didn’t exist a year ago. Notion absorbed AI by changing how its existing primitives compose, not by becoming a different product. Figma absorbed AI by treating the canvas and its objects as the primitive layer the model operates on. Linear’s issue is a primitive that views, automations, and now agents all compose around. None of these teams had to rewrite their product to let AI in. They had to reconfigure.

Products built as collections of applications face a different situation. The primitive layer isn’t there. The product is the screens, and the screens were never designed to be recomposed by anything other than the humans who authored them. When AI arrives, there’s nothing for it to reason over except the surface. And reasoning over the surface produces the chat sidebar, the summariser, the copilot panel. Features, not transformation.

The approach problem

None of this is a tooling argument. It’s not about Figma versus code, or design systems versus ad-hoc. It’s about how design and product management approach the problem in the first place.

In an application-centric approach, the question is “what should this screen do?” The primitive, if it emerges at all, emerges as a byproduct of the screen. In a platform-centric approach, the question is “what is the capability, where else does it belong, and what’s the minimum primitive that expresses it?” The screen becomes an output of that question rather than the starting point.

The pattern inside an application-centric product review is familiar. A team walks through a feature, the flows, the edge cases, the visual treatments. It’s detailed and thoughtful work. And somewhere in the middle someone asks, “what’s the primitive underneath this?” and the room goes quiet. Not because the team is inexperienced. Because the question is outside the frame they were given. They were asked to design a feature. They designed a feature. The question about the primitive layer belongs to someone else, somewhere else, and in most organisations that someone doesn’t exist.

This is the trap. Not the tooling. Not the team’s talent. The frame.

The uncomfortable part

If a product has been built application by application for years, the primitive layer underneath doesn’t exist. You can’t retrofit composability. You can only build it, which means that underneath whatever exists today, a real primitive layer has to be constructed, and the applications above it have to eventually become consumers of that layer rather than islands. The surface can survive the transition. The architecture cannot.

The objection writes itself. We can’t rewrite the product. We have customers, deadlines, commitments. And the answer is that nobody’s asking anyone to rewrite the product this quarter. The answer is that the work starts now and takes years, and the teams that start now will have something to show in two years while the teams that keep shipping application-shaped features will have a pile of AI bolt-ons and a product that still doesn’t feel transformed.

The real cost of waiting is that every feature shipped in the application-centric mode during that wait is debt. It’s work that has to be unpicked or migrated when the primitive layer eventually gets built. Shipping faster in the old model is shipping more debt, not more product.

What this means in practice

For designers, before you design a screen, ask what capability sits underneath it, where else that capability appears in the product, and whether it already exists as a primitive somewhere. If it doesn’t, the screen isn’t the deliverable. The primitive is, and the screen is one way of rendering it.

For product managers, before you scope a feature to an application, ask whether the underlying capability belongs in the platform layer. If it does, the feature is a surface on top of a primitive, and the primitive is the actual scope. Planning in applications is planning in surfaces. Planning in primitives is planning in product.

For design and product leaders, look at how your teams are organised. If each team owns an application, the primitive layer belongs to nobody, and nobody will build it. Teams organised around primitives produce composable products. Teams organised around applications produce applications.

For executives, the question is not what your AI strategy is. The question is whether your product is a platform of primitives that applications render, or a collection of applications that AI can only be bolted onto. If you don’t know, that’s your answer. If you know and it’s the latter, the work to change that starts now, and every quarter you delay it gets more expensive.

The fork

There’s a moment coming, for many products, where the gap between the composable and the non-composable stops being subtle. Customers will feel it. The products that absorb AI by recomposing will feel alive, responsive, increasingly capable in ways that weren’t announced. The products that absorb AI by bolting it on will feel the same as they did before, with more sidebars.

The gap won’t be closed by better prompts or better models. It will only be closed by the slow, structural work of building the primitive layer that should have been there the whole time.

AI won’t save a product that was never composable.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel. He publishes weekly tests of AI tools for designers, product managers, and engineers.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Vibe Design, Part Two

Last Friday I published a piece arguing that Figma’s role in design work was about to shrink. The thumbnail on the accompanying video said the loud version of that argument. The thumbnail did what thumbnails do on YouTube. The article said the slower version, and that’s the version I actually believed.

The piece generated a LinkedIn thread that ran for three days. Forty-something comments, senior designers across multiple decades of practice, product managers, strategists, founders. I replied to most of them. Some agreed with me, some pushed back, a few made me sharper. One commenter made me rethink the core argument.

Jack Skates has been in UX for 25 years. He started a web agency in 1994, when most people still hadn’t heard of the internet. He left a comment that, at first read, sounded like polite agreement. It wasn’t.

Paraphrasing him: the déjà vu with AI is real, but the adoption curve is no longer following the release curve. The tech keeps advancing. The humans learning to use it have stopped keeping pace.

That observation is the piece I didn’t write on Friday.

The old compact between tools and practitioners

Every previous wave of design tooling came with an implicit agreement. The tool would advance. Practitioners would learn it. A few years in, enough people would be genuinely expert that the profession stabilised around the new default.

Photoshop took designers roughly three to five years to become expert in, and that expertise paid off for the next fifteen. Books got written. Certifications existed. “Photoshop expert” was a resume line that meant something from 1995 to maybe 2010. The tool changed over that window, but slowly enough that your accumulated knowledge still applied. You learned once, you used it for a decade.

Flash had a similar arc, shorter but the same shape. Flash developers became a profession. For a while the best of them were making six figures building rich web applications that nothing else could build. The tool eventually died, but the practitioners who rode that curve got fifteen good years out of it.

Figma compressed the arc but kept the shape. A decade from launch to category dominance. Senior Figma practitioners emerged. “Figma expert” became a hiring signal. Auto Layout mastery, variant architecture, component API design, these were real skills you could develop over time and charge for.

The compact was simple. Tools advanced roughly every five to ten years. Expertise in a tool had a useful half-life of ten to fifteen years. You could build a career inside that window. You could reasonably expect that the software you learned at twenty-five would still be the software you used at thirty-five, evolved but recognisable.

That compact is breaking.

What’s different about the AI wave

Count the Claude Opus releases in the last eight months. Opus 4.1 in August 2025. Opus 4.5 in November 2025. Opus 4.6 in February 2026. Opus 4.7 in April 2026. Four major model releases in roughly eight months, each one a meaningful capability shift. OpenAI and Google have been shipping at comparable cadence.

On the design tool side, the timeline is almost absurd. Figma Make announced at Config in May 2025, general availability by August 2025. Figma Agent on the canvas in March 2026. Claude Design shipped in April 2026. Meanwhile v0, Lovable, Google Stitch, and a handful of smaller tools have all shipped and iterated aggressively in the same window. Six or seven significant design-tool paradigms in under two years.

Token prices have collapsed in parallel. GPT-4 at launch in 2023 cost $30 per million input tokens. GPT-5.2 today costs $1.75. Claude Opus went from $15 per million input tokens on Opus 4.1 to $5 on Opus 4.6 and 4.7. That’s roughly a ten to twenty times cost reduction in three years, while capability has roughly doubled each generation.

Now the mechanical problem.

Becoming genuinely expert in a piece of professional software takes something in the order of thousands of hours of deliberate use. That figure is squishy but it’s the right order of magnitude. A designer putting in twenty focused hours a week on a specific tool reaches that threshold in a year or more.

At the current release cadence, by the time someone reaches meaningful expertise in the AI design tool they’re using today, that tool will either have been superseded or transformed enough that half of what they learned doesn’t apply. The muscle memory built around the 2026 interface will be obsolete by the 2027 interface. The prompting conventions that work in Claude Opus 4.7 will be different in Opus 5.

The result is uncomfortable and worth naming directly: nobody is going to become an expert in any specific AI design tool. Not in the way senior Figma practitioners became experts. Not in the way Photoshop specialists did. The half-life of the expertise is shorter than the time required to build it.

Everyone working with these tools is permanently intermediate. The senior practitioners who know the most are the ones who’ve learned to stay fluid, not the ones who’ve mastered specific software.

This quietly inverts most of the industry’s hiring heuristics. “Five years of Figma experience” meant something specific in 2022. “Five years of Claude Design experience” will never mean anything, because the Claude Design of 2031 will not be recognisable from where we’re sitting now. The whole concept of “years of experience with [specific tool]” is about to age out as a useful signal.

Something else has to take its place.

Why this is worse for the tool vendors than it looks

The adoption gap is bad for practitioners. It’s quietly catastrophic for tool vendors that don’t own the underlying models.

Figma’s AI strategy depends on contracts with companies that are now direct competitors. Figma Make, announced at Config in May 2025, was built on Anthropic’s Claude models. Figma Agent, launched March 2026, operates through Figma’s MCP server wiring AI agents into the canvas. Claude Design shipped in April 2026, one month after Figma Agent, using Anthropic’s own Opus 4.7 model end to end.

That leaves Figma with three options, none of them good. They can keep paying Anthropic for Claude access while Anthropic ships directly competing products. They can switch to OpenAI or Google, both of whom are shipping their own design-adjacent tools (v0 is a Vercel product using OpenAI, Google Stitch is Google’s own design tool powered by Gemini). Or they can try to train their own foundation model, which is enormously expensive and almost certainly too late.

Adobe is in a similar position. Canva is in a similar position. Every design tool that isn’t also a foundation model lab is in a similar position.

Anthropic, by contrast, owns the full stack. They control the model, the context window, the tokenizer, the training data, and the pricing. When they ship Claude Design, they can optimise the model for design-specific tasks at a depth that no wrapper can match. They don’t have to negotiate. They don’t have to wait on a partner roadmap. They don’t have to worry about a contract lapse or a price hike.

This is a structural advantage that design-tool companies cannot match without becoming foundation-model labs themselves, which nobody is going to do because it costs billions and requires talent that’s already allocated elsewhere.

The adoption gap closes eventually. Practitioners catch up, tools stabilise, a new equilibrium forms. But the vendor problem doesn’t close. It widens. The companies that own the model will keep pulling further ahead of the companies that rent it.

Pattern recognition, not taste

My first instinct, when I was thinking about what the new signal for designer value would be, was to say taste. Good designers have taste. AI amplifies their taste. Therefore the differentiator is taste.

Someone in the thread pushed back on this and they were right to. Taste is the weasel word designers reach for when they want to justify a decision they don’t want to explain. It’s subjective, unfalsifiable, and functionally identical to the kind of process theatre the best designers are supposed to avoid. Juan Pablo Sans made the sharper version of this point in the thread: some designers “behave like they’re Jackson Pollock with a Figma account,” treating every revision as a moral event while the business waits for momentum. Using “taste” as the answer to “what makes one designer more valuable than another” is the same move. It sounds impressive and it means nothing.

The actual differentiator isn’t taste. It’s accumulated pattern recognition.

A designer who has shipped five hundred interfaces has seen, in their own work, which patterns break at scale and which don’t. They know what happens when you use a modal for a confirmation flow versus an inline prompt, because they’ve seen both fail in specific ways. They’ve watched their own typography choices age badly, and their component architectures calcify, and their colour systems fall apart under edge cases. They carry a library of seen failures that a junior designer with fifty shipped interfaces simply doesn’t have.

Pattern recognition shows up in specific, identifiable things. Volume of interfaces shipped is one. Direct exposure to user failure modes, meaning research sessions, support tickets read, analytics watched, is another. Systems literacy, the ability to see how a component decision today will constrain or enable decisions six months from now. Visual grammar fluency, the kind of thing you only develop after staring at spacing and hierarchy for years until your eye knows the difference between a grid that breathes and one that suffocates.

None of this is mystical. All of it is learnable, given enough reps.

And critically, none of it is exclusive to designers.

A product manager who has shipped a hundred interfaces has pattern recognition. An engineer who has done frontend work for a decade has visual grammar fluency. A researcher who has watched five hundred usability sessions has user-failure intuition that most designers don’t. Mohammed Zaman Bayezid put it well in the thread: the game has shifted from “Designers vs Engineers” to “Doer’s vs Doer’s.” The professional boundary that used to matter is dissolving into a new one: people who ship with judgment, and people who don’t.

The professional category that’s about to matter isn’t “designer.” It’s “practitioners with accumulated pattern recognition.” The title was always a proxy for the pattern library. AI just makes the proxy legible. The people whose work has been carried by their title, rather than by their accumulated judgment, are about to become visible.

What this does to careers

Two predictions, both testable within 24 months.

First, hiring signals will shift. “Portfolio” becomes less useful than “operating system.” The question hiring managers will start asking, whether or not they articulate it this way, is: can this candidate direct AI tools toward good outcomes, or do they produce work that looks like the AI’s default output? The second category is about to be everywhere. The first category is about to be scarce.

Second, the top-to-middle pay gap in design will widen. The top ten percent of designers, the ones with deep pattern libraries and AI fluency, will command three to five times the average. The middle fifty percent will compress toward the bottom, because the work they used to do can now be done by anyone with pattern recognition and a Claude subscription. Smithin K R made the same prediction in the thread from a different angle: right now AI output looks good because it replicates thoughtful design cheaply, but once thoughtful designers get their hands on AI, the competition isn’t close. AI+prompt loses to AI+thoughtful designer every time.

This isn’t a prediction about AI replacing designers. It’s a prediction about which designers thrive and which don’t, and the answer isn’t correlated with seniority as currently measured. A designer with five years of experience and five hundred shipped interfaces will outperform a designer with fifteen years of experience and fifty shipped interfaces. Title and tenure stop predicting output.

The uncomfortable implication is that most “senior” designers have titles that don’t match their actual pattern library. The industry has been rewarding time served rather than work shipped, and AI is about to expose the gap.

What to build instead

If specific-tool expertise is dead as a career strategy, the question becomes: what do you build instead?

The answer, as far as I can see it, is durable under tool change. Build the pattern library, not the tool skill. Ship more interfaces, not better Figma files. Expose yourself to more failure modes, not more certifications.

Specifically, the moves that hold up across tool generations:

Ship work at volume. The library of internalised patterns is the only thing that carries across tools. A designer who has shipped two interfaces in Figma has two interfaces worth of pattern recognition, regardless of how well they know the software. Ship more. Finish more. Learn in public.

Watch your own work fail. Look at analytics on the things you’ve built. Read support tickets. Sit in on user research. The failure modes are where pattern recognition actually forms. Interfaces that get praised in review and then fail in production are the ones you learn the most from, but only if you stay close enough to see them fail.

Work across tools, not inside one. The practitioners who will thrive are the ones who’ve used five design-generation tools and can see what each one is good at. The ones who’ve doubled down on mastering Claude Design will be in trouble when the next tool changes the interaction model.

Develop fluency in judgment, not execution. The skill of knowing why a design decision is right or wrong, being able to articulate it, defend it, and predict its downstream consequences, is the thing AI amplifies. Execution is collapsing. Judgment is becoming legible. Aleks Smetanka described his own shift in the thread: he barely uses Figma anymore, and when he does it’s only because a client requires it as a deliverable. The design work happens somewhere else. Figma becomes a format, not an environment. The pattern library, wherever it’s kept, is what actually ships the work.

Jack Skates said something else in the thread that I’ve been thinking about since. He said that in previous waves, the tech advanced and the humans caught up. In this wave, the tech keeps advancing and humans are trying to run alongside it. The adoption gap isn’t closing. It’s widening.

If that’s true, and I think it is, then the winners of the next decade in design won’t be the people who learned one tool deeply. They’ll be the ones who accepted permanent intermediacy as the condition of the work, and built a pattern library that stays useful no matter which tool is on top that year.

The designers most at risk are the ones still trying to master something. The tools aren’t going to stop shipping long enough to let them.

This is Part Two of a series. Part One (Vibe Design: Why Claude Design Just Redefined the Category) explains the shift that triggered this argument. Credit to Jack Skates for the adoption-gap observation that made this piece necessary, and to the commenters whose framings sharpened the thesis in public: Juan Pablo Sans, Mohammed Zaman Bayezid, Smithin K R, Aleks Smetanka, James Blackwell, Juan Sebastián Gómez, Maja Żądło, Nikola Kostadinović, and the rest of the thread.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel. He publishes weekly tests of AI tools for designers, product managers, and engineers.

YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski

Update, April 19, 2026: Figma stock fell 7% the day after this was published. The LinkedIn thread discussing this piece surfaced one crucial refinement: adoption velocity is now lagging tool velocity in a way that’s new to tech waves. More on that in a follow-up piece soon.

I have been a designer for 29 years. I have shipped work for Adobe, IBM, Danone, and a long list of companies in between. I have lived through Fireworks, Freehand, Sketch, Figma, and every wave of tool consolidation in between.

Today, sitting in front of Claude Design for the first time, I caught myself saying something I have never said about a design tool before.

“This is a better way of working.”

Not “this is interesting.” Not “this might replace X.” A better way of working. Full stop.

The tool I was testing is Claude Design, announced this morning by Anthropic Labs. Powered by Opus 4.7. Research preview. claude.ai/design.

But the tool is not what this article is about. The tool is a proof point. What matters is the category it just defined.

I am calling it vibe design.

What vibe design actually is

The phrase vibe coding, coined by Andrej Karpathy, describes a mode of software development where a human expresses intent in natural language and an AI produces, revises, and ships the code. You stop typing the implementation. You start steering it.

Vibe design is the same shift, one layer up.

It is design produced by expressing intent in natural language, refined through live parameters and direct conversation, and handed off to code without ever producing a static design file. No .fig. No artboards. No developer translating pixels back into semantic markup. The design is never a deliverable on its own. It is always one step in the conversation between intent and shipped product.

Three properties define it:

Natural language as the primary input. You describe what you want, the tool produces a starting version, you refine through conversation.

Live parameters as the primary refinement surface. Instead of nudging pixels, you adjust sliders, toggle variants, and let the tool regenerate. Typography, spacing, color, layout, shape. All live. All reversible. All parametric.

Direct handoff to code, not to developers. The output of vibe design is not a file for a developer to rebuild. It is a structured description of intent that the code layer consumes directly. In Claude Design’s case, that means a handoff bundle that Claude Code reads and builds into working software.

If you have used v0 or Lovable, you have done a version of this. But those tools collapse design and code into a single step. Vibe design separates them again, deliberately, so designers can iterate on intent before the code layer takes over.

That is the new thing. That is what Claude Design just made legible.

Why this is different from the AI design tools you’ve already seen

For the last two years, AI design tools have lived on a spectrum from “AI in your design tool” to “AI that writes your frontend code.” I have tested most of them on my YouTube channel. Here is where each one sits.

Figma Make and Figma Agent. AI inside Figma. You still produce a .fig file. The AI accelerates the production of that file. The output is still a deliverable that a developer translates into code. Incremental, not categorical.

Google Stitch. Mobile-first, prompt-to-visual. Beautiful output, narrow scope. A speed tool, not a workflow tool.

v0 by Vercel. Prompt to React component. Collapses design and code. Great for shadcn-heavy projects, less great when you need visual iteration separate from code iteration.

Lovable. Full app generation. Excellent if you want an end-to-end app with auth and database. Less excellent if you want to iterate on pure UI intent.

Magic Path, Framer AI, Canva Magic Studio. Different flavors of the same pattern: AI accelerating existing design surfaces.

Claude Design sits somewhere none of these do. It treats design as a separate phase from code, but it refuses to produce a static file as the deliverable. The output is always live. Always parametric. Always ready to hand off as design intent to a code-generating agent.

This is what makes it feel different in practice. When I tested the calculator kit example, I was not dragging handles or nudging pixels. I was talking. I was dragging sliders. I was commenting on specific elements and asking Claude to revise. When I was happy, I clicked one button and handed the entire design off to Claude Code, which built a working prototype in an empty folder within minutes.

No Figma file was produced at any point.

And I never missed it.

The .fig file was the problem

Here is the uncomfortable thesis.

For the last decade, the .fig file has been the default unit of design work. You produce one. A developer opens it, measures it, translates it into code, and ships it. The design is finished when the file is finished. The implementation is somebody else’s problem.

This worked when AI could not read intent. A Figma file was the most efficient way to encode design decisions that a human developer could reconstruct.

That constraint just dissolved.

When an AI model can consume a structured description of design intent and produce working code that matches it, the intermediate file stops being useful. Worse, it becomes a liability. It locks the design into a specific visual snapshot instead of leaving it parametric. It forces a translation step where information is lost. It creates a handoff culture where designers throw files over the wall and hope.

Vibe design kills that handoff culture.

In Claude Design, I pointed the onboarding flow at a real GitHub repository. It read my team’s design system directly from the code. Every design it produced after that used the right colors, the right typography, the right components. When I handed the final design to Claude Code, Claude Code built it using those same components, because it was reading the same repo.

The .fig file would have been the wrong artifact at every step in that loop. Nobody needs it. The design intent is the asset. The rendering is disposable.

What this means for designers

Two things, and you need to hear both honestly.

The first thing. If your value as a designer is producing polished Figma files that developers rebuild in code, your value just dropped. Not tomorrow. Not in five years. Today. The AI tools are already better at producing that specific output than most mid-level designers, and they are closing the gap with senior designers fast.

The second thing, which matters more. The designers who understand what to design, why it matters, how to frame the problem, how to guide a parametric system toward a meaningful outcome — those designers just got the largest leverage increase in the history of the craft. One senior designer with Claude Design, a real design system, and Claude Code can ship more product in a week than a five-person team could six months ago.

This is the IC 2.0 thesis I have been writing and making videos about for the last year. AI collapses execution. Judgment and orchestration become the job. Vibe design is the specific form that takes inside design practice.

The designers who thrive will be the ones who treat tools like Claude Design not as threats but as amplifiers of the parts of the job that always mattered: understanding users, framing problems, holding taste, knowing when something is wrong.

The designers who struggle will be the ones who defend the file as sacred.

What this means for Figma

Honest take, because I like Figma and I have used it every working day for years.

Figma is not dying. Figma owns direct manipulation. Figma owns the collaborative file format. Figma owns the plugin ecosystem. None of that disappears in the next 12 months.

But Figma’s role is shrinking.

For five years, Figma was the center of gravity in product design. Everything started there, everything ended there, and the rest of the tools orbited it. That ended today. There is now a legitimate workflow where a design is conceived in Claude Design, refined in Claude Design, handed off to Claude Code, and shipped to production without ever touching Figma.

Figma Make was Figma’s attempt to catch this wave. It is a good tool, but it lives inside the Figma walled garden. It produces designs that still live as Figma files. It is a response to the last category, not the new one.

If Figma does not ship a vibe-design-native product in the next 12 months, they will be defending market share in a category that is no longer the growth category. I would not bet against them. But I would not assume the default is still the default either.

What this means for everyone else

Vibe design is not only for designers. The three groups who get the largest upside are not designers at all.

Product managers. PMs have been asking for “higher fidelity earlier” for a decade. Vibe design delivers that without requiring a designer on every feature spike. A PM can produce a wireframe, a high-fidelity mockup, or a working prototype in the same afternoon, in the company’s design system, and hand it to engineering.

Founders and marketers. The gap between “idea” and “shareable visual” just collapsed. A landing page, a pitch deck, a campaign asset. All producible from intent, all exportable to Canva or PPTX or HTML, all without waiting for creative resource.

Engineers. Engineers who want to prototype a UI without pulling a designer off another project just got a tool that produces design-system-correct output in minutes and hands off directly to their existing code workflow.

Vibe design is a democratizing shift. The skill floor for producing visual work just dropped. The skill ceiling for directing visual work just got higher.

Where this goes next

Three predictions.

Direct manipulation comes back. Right now you cannot grab an element in Claude Design and drag it. Everything goes through chat or sliders. That will change within 6 months. The winning tool combines vibe design’s parametric intent layer with Figma’s direct control. Whoever ships that first owns the category for the next decade.

Mobile becomes table stakes. Claude Design is web-only today. Design happens on laptops anyway, but the review, commenting, and handoff flow needs mobile. Expect mobile within 12 months.

Multi-tool orchestration becomes the advanced workflow. The designers who win in 2027 will not be “Claude Design designers” or “Figma designers.” They will orchestrate across Claude Design, Figma, Stitch, v0, and whatever ships next, using each for the job it is best at. Taste, judgment, and tool orchestration become the differentiator. Fluency in any single tool becomes a commodity.

How to start today

If you have a Claude Pro, Max, Team, or Enterprise subscription, Claude Design is at claude.ai/design. Research preview.

If you want to actually test vibe design rather than just read about it, here is the workflow I recommend. It is the one I used this morning.

1. Point Claude Design at a real GitHub repo during onboarding. Use your own project, not a demo.
2. Describe a specific page or flow you actually need to build. Not a toy example. Real work.
3. Start in wireframe mode. Resist the urge to jump to high fidelity. Sit with the low-fi output and iterate.
4. Use the live sliders. They look like toys. They are not. They teach you how parametric the design system can be.
5. Convert to high fidelity. Notice how much it already looks like your product.
6. Hand off to Claude Code. Paste the command. Watch it build.

That loop, end to end, takes about an hour the first time. Forty minutes the second time. After that, you will start redesigning how you work.

I have been a designer for 29 years. I have never been more certain that the next 10 years of design will look nothing like the last 10.

Vibe design is here.

Figma is not the center of gravity anymore.

The designers who see that early will own the decade.

Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel. He publishes weekly tests of AI tools for designers, product managers, and engineers.

YouTube: https://www.youtube.com/@aiforwork_app LinkedIn: https://www.linkedin.com/in/julianoczkowski GitHub: https://github.com/julianoczkowski

No. Not even close.

Here is the uncomfortable truth that most teams are ignoring: if your work cannot be understood, queried, and built upon by an LLM, it is not done. It is abandoned.

The old definition of done was built for humans only

For decades, “done” meant something like this: the design is signed off, the code is deployed, the stakeholders are happy, and the Jira ticket moves to the right. Maybe someone writes a confluence page. Maybe they don’t. Either way, the knowledge about why that feature exists, what was tried and rejected, what user research informed the decision, lives in one place: someone’s head.

That is tribal knowledge. And tribal knowledge has an expiration date. The person leaves. The Slack thread gets buried. The context evaporates.

We have tolerated this for years because the only consumers of that knowledge were other humans, and humans are pretty good at tapping someone on the shoulder and asking. But the shoulder tap does not scale. And now there is a second consumer of your work that cannot tap anyone on the shoulder.

I built this system live. Watch the full walkthrough here:

The new consumer: your LLM

Every team I work with now uses an LLM somewhere in their workflow. Cursor for code. Claude Code for builds. ChatGPT for research. Copilot for pull requests. The tools vary, the pattern does not: people are pointing AI at their work and expecting it to understand.

But here is the problem. When that LLM tries to understand your project, what does it find? A Figma file with no annotation. A codebase with no architecture decision records. A product spec from six months ago that never got updated after the pivot. A design system with no documented rationale.

The LLM cannot tap anyone on the shoulder. It can only read what you wrote down. And most teams write down almost nothing.

This is why Andrej Karpathy’s LLM Wiki concept, which went viral this week, resonated so hard. Karpathy described a system where you feed raw material (articles, research, documents, transcripts) into a folder, and an LLM compiles it into a structured, interlinked wiki. No vector databases. No complex infrastructure. Just markdown files that compound over time.

The concept is simple: stop relying on your memory. Start building a knowledge base that an LLM can actually navigate.

What Karpathy’s wiki exposes about how we work

I built this system live on my channel using Claude Code and Obsidian. The setup takes minutes. You create a vault, drop in your raw files, paste Karpathy’s gist into Claude Code with a short prompt, and the LLM builds the entire wiki structure: index, log, entity pages, relationships, everything.

But the interesting part is not the tooling. It is what the process reveals about how badly we document our own work.

When I pointed Claude Code at my YouTube channel’s transcripts, around 60 of them, it built a knowledge graph that surfaced connections I had never consciously made. Topics I kept returning to. Contradictions between what I said in one video versus another. Gaps where I had strong opinions but zero supporting evidence.

That is what happens when you make your knowledge machine readable. The machine reads it. And it finds the holes.

Now imagine this at a team level. A designer ships a component. A PM ships a feature. An engineer ships an API. Each person’s “done” is isolated. The designer’s rationale lives in a Figma comment. The PM’s reasoning lives in a Google Doc that three people have access to. The engineer’s context lives in commit messages that nobody reads.

None of this is queryable. None of it compounds. None of it survives the next reorg.

The new definition of done

Here is my argument, and I know it will be controversial: in 2026, “done” needs to include documentation that is structured for LLM consumption. Not just human consumption. Both.

For designers, that means: your design system documents, component decisions, brand guidelines, user research notes, interview transcripts, UX teardowns, and critique feedback should live in a single, queryable knowledge base. When a new designer joins the team, they should be able to point an LLM at that knowledge base and get onboarded in hours instead of weeks.

For product managers, that means: your PRDs, decision logs, stakeholder interview notes, sprint retros, OKRs, metrics, customer feedback, NPS scores, and competitor teardowns should be in one place. Not scattered across Notion, Google Docs, Confluence, and someone’s personal notes app. When the next PM picks up your product area, they should be able to query the LLM and understand not just what was shipped, but why.

Think about what that actually means. It means “done” is not just the artifact you shipped. It is the artifact plus the reasoning, documented in a format that both humans and machines can traverse.

If you shipped the feature but the “why” only exists in your head, you are not done. You are a single point of failure.

Why knowledge graphs change everything

There is a reason Karpathy’s system uses interlinked markdown files and not a flat folder of documents. The structure matters. The relationships between pieces of knowledge are often more valuable than the pieces themselves.

When I ran the ingest on my YouTube transcripts, the LLM did not just create 15 isolated summary pages. It created a graph. Concepts linked to other concepts. Entities referenced across multiple sources. Relationships that I, the person who created all of that content, had never explicitly drawn.

This is the fundamental insight behind knowledge graphs: information in isolation is data. Information with relationships is knowledge. And knowledge compounds in ways that data never can.

Think about how a traditional design system works. You have a component library. You have usage guidelines. You have accessibility notes. Maybe you have decision logs explaining why a certain component was built a certain way. In most organizations, these live in separate tools, maintained by separate people, with no explicit connections between them.

Now imagine all of that ingested into a wiki where the LLM has built relationships between the component, the user research that informed it, the accessibility standard it satisfies, the sprint retro where the team debated the interaction pattern, and the customer feedback that triggered the redesign. That is not a design system. That is a design knowledge graph. And when a new designer joins and asks “why does our modal work this way?”, the LLM does not just retrieve a usage guideline. It traces the full chain of reasoning.

This is what Obsidian’s graph view makes visible. You can literally see clusters of tightly connected knowledge, isolated nodes that should be linked but are not, and structural gaps where your team has strong opinions but weak documentation. The visual representation alone surfaces problems that no amount of Confluence searching would reveal.

The same principle applies to product work. A PM’s decision to prioritize feature A over feature B involves competitive analysis, customer interviews, metrics, stakeholder input, and strategic alignment. In most teams, that decision lives as a single line in a roadmap tool. The reasoning behind it is scattered across five tools and three people’s memories. In a knowledge graph, all of those inputs are linked to the decision node. The “why” is not just documented. It is structurally connected to everything that informed it.

This is not academic. This is practical. When your LLM has access to a knowledge graph instead of a flat folder, its answers go from generic to specific. It stops saying “best practices suggest…” and starts saying “based on the user research from Q2 and the decision log from sprint 14, this component was designed to…”

That is the difference between an LLM that sounds helpful and an LLM that actually is.

The second brain is not a personal productivity hack

The “second brain” concept has been around for years, popularized by Tiago Forte and the personal knowledge management community. But most people think of it as a note-taking system. A way to organize your Evernote or your Notion. A personal productivity hack.

That framing is too small for what is happening now.

When Karpathy described his system, he was not talking about personal note-taking. He was describing a fundamentally different relationship between a human and their accumulated knowledge. In his setup, the LLM has built and maintains a wiki of over 100 articles and 400,000 words from his research. He rarely edits it directly. The LLM writes, updates, links, and maintains the entire thing. His role is to feed it raw material and ask it questions.

This is not a note-taking app. It is an externalized, queryable, self-maintaining extension of your professional memory.

And the implications for teams are enormous. Consider what happens when every designer, every PM, and every engineer on a team maintains a second brain that feeds into a shared wiki. The team’s collective knowledge stops being trapped in individual heads and starts existing as a persistent, queryable artifact.

New hire onboarding goes from “shadow Sarah for two weeks” to “point your LLM at the team wiki and ask it anything.” Post-mortem insights stop being a Google Doc that nobody reads and start being connected nodes in a knowledge graph that inform every future decision. Design critique feedback stops evaporating after the meeting and starts compounding into a searchable body of design reasoning.

The second brain concept matters here because it reframes documentation from a chore into an investment. Every raw file you drop into the wiki, every transcript, every research note, every decision log, makes the entire system smarter. The knowledge compounds. The connections multiply. The LLM gets better at answering questions about your work because there is more context for it to draw from.

This is compounding returns applied to organizational knowledge. And like any compounding system, the teams that start early will have an exponential advantage over those that start late.

The gap between how we work and how LLMs work

Here is a problem most teams have not thought about yet. LLMs do not work the way humans work. Humans can hold ambiguity, read between the lines, infer context from a half-finished Slack message, and fill gaps with institutional memory they have absorbed over months of working in the same building. LLMs cannot do any of that.

An LLM reads what you give it. Literally. If your design system documentation says “use the primary button for the main action” but does not define what constitutes a “main action” in your product’s specific context, the LLM will give you a generic answer. If your PRD says “we decided to go with option B” but does not explain what option A was or why it was rejected, the LLM cannot reconstruct that reasoning.

Most documentation is written for humans who already have context. It assumes shared understanding. It relies on the reader knowing who “the team” refers to, what “the incident” was, and why “that approach” was rejected. These are invisible references that a human colleague can decode but an LLM cannot.

This is why a wiki with explicit relationships matters so much. When the LLM builds the knowledge graph, it forces implicit knowledge to become explicit. Every entity gets a page. Every relationship gets a link. Every decision gets connected to its inputs. The ambiguity that humans navigate effortlessly becomes structured knowledge that machines can traverse.

Karpathy’s gist includes tools for exactly this problem. The health check scans the wiki for unlinked entities, concepts that are mentioned but never defined, references that point nowhere. The lint pass finds inconsistencies, articles that contradict each other, claims that lack supporting sources. These are not just maintenance tools. They are quality controls on your team’s collective knowledge.

And here is the part that should make you uncomfortable: if you ran a health check on your team’s existing documentation right now, how many gaps would it find? How many undefined concepts? How many decisions with no recorded reasoning? How many references to conversations that happened six months ago and were never written down?

That gap between what your team knows and what your team has documented is the exact gap that makes your LLM useless.

From personal wiki to team knowledge infrastructure

One concern I hear often is: “This is cool for one person, but how does it work for a team?” Karpathy’s original system is local. One person, one vault, one LLM.

But the solution is straightforward. Put the wiki in a GitHub repository. Everyone on the team can contribute raw files. When someone has a new research finding, a meeting transcript, a design decision, they drop it into the raw folder and push. Then anyone on the team can run the ingest, and the LLM updates the shared wiki with the new information, linking it to everything that already exists.

This is exactly what I have done with my own YouTube channel wiki. The raw files, the images, the entire compiled wiki lives in a repository. If I had collaborators, they could contribute to the same knowledge base. The LLM handles the compilation. The humans handle the curation.

For teams, this means the wiki becomes a living artifact that grows with every sprint, every research round, every design review. It is not a documentation project that someone has to champion. It is a byproduct of doing the work, as long as you build the habit of capturing the reasoning alongside the output.

The GitHub model also solves the versioning problem. You can see what was added when, by whom, and how the LLM integrated it into the existing structure. You have full history. You have accountability. And you have a knowledge base that no single person’s departure can destroy.

“But we already document things”

No, you don’t. Not really.

Most teams have documentation the same way most people have a gym membership. It exists. It was set up with good intentions. Nobody uses it consistently.

And even when documentation exists, it is almost never structured for LLM consumption. It is buried in tools with terrible search. It is written in a format that assumes the reader already has context. It is never updated after the initial write.

Karpathy’s wiki pattern solves this because the LLM maintains the structure. You do not have to be disciplined about formatting or linking. You drop raw material in, and the LLM does the compilation. It creates the relationships. It maintains the index. It runs health checks to find gaps and inconsistencies.

The discipline you need is simpler: make a habit of capturing your reasoning, not just your output.

The tribal knowledge problem is now an AI problem

Here is where this gets urgent. Teams are already using LLMs to make decisions. Engineers ask Cursor about the codebase. PMs ask Claude to analyze user feedback. Designers ask ChatGPT about accessibility patterns.

But those LLMs are operating with incomplete context. They do not know your company’s design principles. They do not know why you chose that specific API architecture. They do not know about the user research that killed the original feature direction.

So the LLM gives generic answers. And people ship generic work. And then everyone wonders why AI is not delivering on its promise.

The problem is not the AI. The problem is that your organizational knowledge is inaccessible to it.

What to do about it

This is not theoretical. You can start today.

Set up an Obsidian vault. Install the Web Clipper extension. Open Claude Code in the vault directory. Paste Karpathy’s gist with a simple prompt, and the LLM will build your wiki structure in minutes. Then start feeding it: design specs, meeting notes, research findings, decision logs. Everything you would want a new team member to know.

The repo for the setup I demonstrated is public: https://github.com/julianoczkowski/karpathy-llm-wiki

Once you have the wiki, you can plug it into anything: Claude projects, Cursor, Windsurf, Copilot. It is just files. That is the beauty of it. No vendor lock-in, no complex infrastructure, no monthly subscription. Just markdown that compounds.

And once you start, the benefits compound fast. Each new source you ingest does not just add one more document. It adds connections to every existing document. A user research transcript from today links to the design decision from three months ago, which links to the competitive analysis from last quarter. The knowledge graph gets denser, richer, and more useful with every addition.

This is why I think about the wiki less as a tool and more as a habit. The same way a developer commits code daily, a designer or PM should commit knowledge daily. Not polished documentation. Not formatted reports. Just raw reasoning, dropped into a folder, compiled by an LLM that never forgets.

The teams that build this habit will have a structural advantage that grows over time. Their LLMs will give better answers because they have better context. Their new hires will onboard faster because the institutional memory is queryable. Their decisions will be more consistent because the reasoning behind past decisions is always accessible.

The teams that do not build this habit will keep losing knowledge every time someone goes on holiday, changes teams, or leaves the company. They will keep asking the same questions, making the same mistakes, and wondering why their AI tools give such generic output.

The uncomfortable question

Next time you close a ticket or hand off a design, ask yourself: could an LLM reconstruct the reasoning behind this decision from what I have documented?

If the answer is no, you are not done.

The definition of done in 2026 is not just “shipped.” It is shipped, documented, and queryable. By humans and machines alike.

The teams that figure this out first will compound their knowledge. The teams that don’t will keep starting from scratch, every sprint, every hire, every reorg.

Your choice.

Julian Oczkowski is a designer with 29 years of experience, including work with Adobe, IBM, and Danone. He runs AI For Work, a YouTube channel focused on practical AI workflows for designers, PMs, and engineers.

Watch the full LLM Wiki build tutorial: youtu.be/lnsExa1UbnM
Subscribe for weekly AI workflow tests: youtube.com/@aiforwork_app

Vibe coding was only phase one

For the past year, vibe coding has been the story. One person, one AI agent, one task. You write a prompt, the agent writes the code, you review it, and you ship. Repeat.

It worked. It proved something that a lot of people did not believe was possible: that non-engineers, designers, product managers, and founders could build real software with AI as their collaborator. Tools like Cursor, Claude Code, and Codex made this accessible. The barrier to building dropped to nearly zero.

But vibe coding hit a ceiling.

One agent at a time does not scale. You are still the bottleneck. You prompt, you wait, you review, you prompt again. It is faster than writing code yourself, but the loop is still sequential. You are still working on one thing at a time, the same way developers have worked for decades. The tool changed. The workflow did not.

That is about to change.

The orchestration shift

Something different is happening in 2026. The role of the builder is shifting from writing prompts to orchestrating agents.

Instead of running one agent on one task, you run five agents in parallel across different parts of your project. One is refactoring your navigation. Another is building a new API endpoint. A third is writing tests. You are not writing code. You are not even prompting in the traditional sense. You are defining outcomes, assigning agents, reviewing their work, and deciding what ships.

This is not theory. This is what the latest generation of tools is shipping right now. And they are all converging on the same idea: the future of software development is not about writing code. It is about managing the agents that do.

The skill that matters is no longer syntax. It is judgment.

The tools converging on the same idea

I have been testing AI coding tools for over a year, and something became obvious in the last few weeks. Every major player is building the same thing: an orchestration layer for agents.

Cursor 3 dropped on April 2nd with a completely rebuilt interface called the Agents Window. It lets you run multiple agents in parallel across repos and environments. You can see all your agents in one sidebar, kick them off from desktop, mobile, Slack, or GitHub, and manage the entire flow from prompt to merged PR without leaving the app. I tested it on a real project and ran three agents simultaneously on the same application. All three finished while I was still typing notes.

Codex is OpenAI’s version. Similar layout, similar concept. Launch agents, review their work, ship. The limitation is that you are locked into OpenAI’s models only.

Conductor just raised $22M in a Series A. It is a visual multi-agent environment that lets you use Claude Code and Codex subscriptions inside their interface.

T3 Code is Theo’s open-source answer to the same problem. A desktop GUI that wraps Claude Code and Codex, giving you multi-repo parallel agents, git worktree integration, and commit-and-push from the UI. Free, no subscription on top of your existing API costs.

Superset is a newer entrant solving the same problem from slightly different angles.

They all look similar because they are all solving the same problem: one person needs to manage many agents at once, and the terminal is not enough to do that.

Design Mode: why visual feedback changes who can orchestrate

Most AI coding tools are built for developers. Terminal-first, text-only. You describe what you want in words, and the agent interprets your description. This works if you think in code. It breaks if you think visually.

Cursor 3 shipped a feature called Design Mode that changes this. You open the integrated browser, toggle Design Mode with Cmd+Shift+D, and click on any UI element. Cursor grabs the code and a screenshot, attaches them to the agent chat, and you type what you want changed.

No more writing “the button on the right side of the card component.” You just point at it.

I have been designing interfaces for 29 years. This is the first AI coding feature that felt like it was built for someone who thinks visually.

It is not perfect. On Windows, Design Mode is broken. Some annotations lose their text when you send them to the chat. It is early. But the direction matters more than the current state: visual feedback opens orchestration to designers and product managers, not just engineers.

The people who can look at an interface, spot what is wrong, and articulate why now have a direct line to the agents that fix it. That is a significant shift in who gets to build.

What I learned running three agents at once

I tested Cursor 3 on a character image generator I built with Claude Code. It is a Vue application that uses Google’s Imagen models to create illustrated characters for my YouTube thumbnails.

I ran three agents in parallel on the same project:

Agent one replaced the plain text header with an SVG logo. Agent two added a copy-to-clipboard button so I could paste generated images directly into Figma. Agent three built an image preview dialog with metadata, showing the full-size image, the prompt used to generate it, and copy and delete controls.

All three agents worked on the same codebase at the same time. All three finished while I was still reviewing the first one’s output.

The bottleneck was not the agents. It was me. My ability to review three sets of changes, decide which ones to accept, and catch the things the agents got wrong. That is the new skill: judgment under speed.

The agents can write code faster than any human. But they cannot tell you whether the spacing feels right, whether the button hierarchy makes sense, or whether the feature actually solves the problem you set out to solve. That part is still yours.

What breaks when you orchestrate

The tools work. What breaks is you.

Running three agents in parallel sounds productive until you try to review all three outputs at the same time. Each agent made dozens of changes across multiple files. Each one made decisions I did not explicitly ask for. Agent three added copy and delete buttons to the preview dialog without being prompted. That was a good decision. But I had to verify that it was a good decision, and I had to do that while also reviewing the other two agents’ work.

This is the cognitive load problem that nobody is talking about. Vibe coding with one agent is manageable. You prompt, you review, you move on. Orchestrating five or ten agents is a fundamentally different cognitive task. You are not coding anymore. You are managing a team that works at machine speed and has no concept of priority.

Every agent produces output that looks confident. None of them flag uncertainty. None of them say “I was not sure about this part, you should check it.” They just do the work and present it as done. Your job is to find the mistakes they did not tell you about, across multiple parallel workstreams, while deciding which changes to keep, which to rework, and which to throw away entirely.

The bottleneck is not compute. It is attention.

I found myself developing a pattern: kick off the agents, let them all finish, then review sequentially rather than trying to watch them work in real time. Watching agents code live is satisfying but counterproductive. The value is in the review, not the observation.

The other pattern that helped was scoping each agent tightly. “Replace the header with an SVG logo” is better than “improve the header area.” Vague prompts in a single-agent workflow just produce vague output. Vague prompts in a multi-agent workflow produce vague output multiplied by the number of agents, and you have to untangle all of it.

Orchestration scales your output. It also scales the cost of poor judgment. If you assign five agents with unclear intent, you do not get five times the productivity. You get five sets of changes you do not fully understand, and the merge becomes the hardest part of the entire workflow.

The skill is not running more agents. It is knowing exactly what to ask each one to do, and being ruthless about what you accept when they are done.

The IC 2.0 argument

There is a bigger story here than any single tool.

For the past two years, the conversation about AI and work has been stuck on a single question: will AI replace my job? That is the wrong question. The right question is: what does my job become when AI handles the execution?

I call it IC 2.0. The individual contributor who thrives in this shift is not the one who writes the best prompts or knows the most keyboard shortcuts. It is the one who brings process, context, and judgment to agent orchestration.

Tasks get automated. Purpose does not.

The designer who can look at a generated UI and immediately see that the visual hierarchy is wrong, that is judgment. The product manager who can review three parallel agent outputs and pick the one that actually solves the user’s problem, that is judgment. The engineer who can spot that the agent’s refactor introduced a subtle race condition, that is judgment.

Twenty-nine years of design experience taught me what no model can learn: when something is wrong and why. That instinct is not automatable. It is the thing that makes orchestration work.

The shift is not from human to AI. It is from execution to accountability. The IC 2.0 does not write every line of code. They own every outcome.

What to do right now

If you are reading this and wondering where to start, here are three things you can do today.

Pick one orchestration tool and learn the loop. It does not matter if it is Cursor, T3 Code, Conductor, or just two terminal windows running Claude Code side by side. The important thing is to get comfortable with the cycle: prompt, review, decide, ship. Run it on a real project, not a tutorial.

Start running two agents in parallel, even on small tasks. The muscle you need to build is not prompting. It is context switching between agent outputs and making fast decisions about what to keep and what to throw away. This is uncomfortable at first. That discomfort is the learning.

Stop optimising your prompts. Start optimising your judgment. The difference between a good orchestrator and a bad one is not the quality of their prompts. It is the quality of their decisions after the agents finish. Can you spot the subtle bug? Can you tell which of three implementations is the most maintainable? Can you decide in 30 seconds whether to ship or rework?

That is where the leverage is. Not in the typing. In the thinking.

I tested Cursor 3 on a real project and documented everything, the features that work, the ones that are broken, and the honest verdict. Watch the full breakdown here: I Tested Cursor 3

Julian Oczkowski is a designer with 29 years of experience across enterprise companies, startups, and agencies. He runs the AI For Work YouTube channel, covering AI tool comparisons, workflow demos, and practical builds for designers and individual contributors.

YouTube: youtube.com/@aiforwork_app

I have been designing for 29 years. I have worked as an individual contributor, a design manager, and a dev team lead across enterprise companies like Adobe, IBM, and Danone. I have seen tools come and go. Sketch replaced Photoshop. Figma replaced Sketch. Each time, the tooling changed but the process underneath stayed the same.

AI is different. AI is not just replacing the tool. It is replacing the process. And most people are skipping straight to the fun part, typing a prompt and watching code appear, without thinking about what comes before.

That is how you get faster chaos.

The problem with “prompt and pray”

Open Claude Code. Type “build me a dashboard.” Watch it generate something. It looks decent. Maybe even impressive.

But ask yourself: does it solve the right problem? Does it match the user’s mental model? Are the information architecture decisions intentional or random? Are the design tokens consistent or did the LLM just pick whatever looked good in the moment?

Most of the time, the answer is no. The output looks like software but does not feel like software. It is missing the invisible work that separates a prototype from a product.

That invisible work is the design process. Requirements gathering. Design briefs. Information architecture. Design tokens. Task decomposition. Review cycles. It is not glamorous. It is not the part people post on X. But it is the part that makes everything else work.

What I built: 7 Claude Code skills that follow a real design process

Instead of fighting this, I decided to encode the process into Claude Code itself. I built 7 custom skills that you can install and run in any project. They follow a professional design workflow from vague idea to working, accessible, reviewed frontend.

Here is the full flow.

1. Grill Me

This is the most important skill and probably the shortest one in terms of code. The LLM becomes relentless. It stress-tests your requirements before a single line of code gets written.

You might spend 20 minutes answering questions. That is the point. If you cannot articulate what you are building and why, the LLM should not be building it for you. This skill uses decision trees to probe deeper based on your answers: what type of application, who are the users, what is the scale, what are the edge cases.

The output is a grill summary that captures everything you discussed. Think of it as the requirements handshake between you and the LLM.

Credit where it is due: the grill-me concept was inspired by Matt Pocock’s skills work at github.com/mattpocock/skills. I took the idea and adapted it for a designer’s workflow.

2. Design Brief

Once the grill is done, the LLM generates a design brief. But it does not just summarise your answers. It looks through the actual codebase. It checks for existing components, design systems, patterns already in the repository.

Before creating the brief, it asks design-specific questions. Not just what the application needs to do, but how you want it to feel. Emotional tone. Visual inspiration. It might suggest references like Linear or the Google Admin Console based on your domain.

The result is a proper design brief document saved to your project.

3. Information Architecture

The LLM goes through all the documentation generated so far and structures the information architecture. Pages, navigation patterns, content hierarchy. If the feature is complex, like a multi-page flow or a full navigation redesign, it will ask additional clarifying questions before committing.

4. Design Tokens

If your project does not already have a design system with components in the repository, this skill generates a complete set of design tokens as CSS custom properties. Colours, typography, spacing, elevation, border radius. Everything saved to a theme file that the frontend skill will consume later.

If you already have a design system, this step gets skipped automatically. The brief skill detected it earlier.

5. Brief to Tasks

This is where the design brief gets broken down into actionable tasks. The skill reads all the documentation, identifies dependencies between tasks, and creates a separate markdown file that tracks every task with its status.

Foundation tasks first, then core UI, then responsive and polish. Each task has a clear scope and the LLM knows what order to execute them in.

6. Frontend Design

This is the build phase. The LLM uses the design brief, information architecture, design tokens, and task list to generate the actual frontend. Components, pages, layouts. Not random code. Intentional code that follows the decisions made in the previous five steps.

The output is a working application. In my demo, I started with nothing more than “I want an asset management application” and ended up with a complete IT asset management tool with a dashboard, asset tracking, categories, reports, filtering, sorting, empty states, edit dialogs, and proper navigation.

7. Design Review

Once the frontend is generated, the design review skill analyses the output. You can either paste screenshots into Claude Code manually or, better yet, use a Playwright MCP server to automate the entire review.

With Playwright, Claude Code opens a headless browser, navigates through the application, takes screenshots of every page, and then runs the design review skill against those screenshots autonomously. No manual work.

The review catches things like sparse layouts, incorrect chart ordering, missing dark mode considerations, and accessibility gaps. It then proposes specific changes and can apply them directly.

The result

From a vague one-line prompt to a working application with:

• 91 Lighthouse performance score
• 100 Lighthouse accessibility score
• Proper information architecture
• Consistent design tokens
• Documented design brief and task tracking

Not because the LLM is magic. Because it followed a process.

Why this matters for designers right now

The old design process, or the pseudo-process that most teams actually followed, is gone. AI tools are getting better and faster every month. But speed without direction just means you waste time faster.

I have seen this from both sides. As an IC shipping work, and as a manager reviewing it. The people who will thrive with AI tools are the ones who bring process, judgment, and accountability. The tools handle execution. You handle the “what” and the “why.”

That is what these skills encode. Not shortcuts. A professional design process that happens to run inside a terminal.

Try it yourself

The skills are free and open source. Install them in any Claude Code project with a single command:

npx skills add julianoczkowski/designer-skills

GitHub repo: github.com/julianoczkowski/designer-skills

I walk through the entire process from start to finish in a video on my channel, AI For Work. If you want to see every step running live, including the Playwright MCP autonomous review, it is all there.

If you are a designer, whether you are just starting out or you have been doing this for decades, the shift is happening. The question is not whether AI will change your work. It is whether you will bring process to the chaos or just let the chaos run faster.

Julian Oczkowski is a designer with 29 years of experience across enterprise companies, startups, and agencies. He runs the AI For Work YouTube channel, covering AI tool comparisons, workflow demos, and practical builds for designers and individual contributors.

YouTube: youtube.com/@aiforwork_app

The real question isn’t about tools. It’s about who owns the outcome.

Two days ago, Jack Dorsey cut half of Block’s workforce. 4,000 people. He didn’t blame performance. He said AI made them unnecessary, and that most companies would follow within a year.

Two weeks before that, Microsoft’s AI chief predicted that every white-collar task, lawyers, accountants, project managers, marketers, would be fully automated in 12 to 18 months. Anthropic’s CEO warned that half of entry-level white-collar jobs could disappear.

These aren’t fringe predictions. They’re coming from the people building the technology.

So should you be worried? Yes. But probably not for the reasons you think.

I’ve been a designer since I was 18. I’m 47 now. I’ve contracted for Adobe, IBM, and Danone. I’ve been an individual contributor, a design manager, and I’ve led dev teams. I’ve watched tools come and go for 29 years. Photoshop was going to replace illustrators. Sketch was going to replace Photoshop. Figma was going to replace everyone. None of them did. The people who disappeared weren’t the ones who failed to learn the new tool. They were the ones who had nothing to offer beyond using the tool.

That pattern is about to repeat, faster and more broadly than anything we’ve seen before. And it won’t just hit designers. It will hit product managers and engineers with equal force.

The difference this time is that the tool doesn’t just make you faster. It can do the work itself. Which means the question has changed.

Everyone is asking the wrong question

“Will AI replace my job?” is not useful. It’s too binary, and the answer depends entirely on what you actually do all day.

The better question: what percentage of your work is tasks, and what percentage is actually solving problems?

Here’s what I mean.

If you’re a designer and 90% of your time is spent in Figma producing screens, that’s task work. You’re a production function. If you’re a product manager and 90% of your week is grooming Jira tickets and running standups, that’s task work. If you’re an engineer and your job description is essentially “write code,” that’s task work.

Tasks get automated. That’s what Dorsey just proved. Block didn’t fire bad employees. They fired roles that could be handled by smaller teams using AI. The roles that were mostly execution.

But solving problems doesn’t get automated. The designer who owns the user experience outcome, who talks to customers, who connects design decisions to business results. The PM who owns the roadmap vision and makes judgment calls about what not to build. The engineer who architects the system and is accountable when it breaks in production. Those roles exist because they solve problems that require human judgment, not because they complete tasks.

Your task-to-problem-solving ratio is your risk level. Be honest about it.

The roadmap: what actually matters, and when

The people building AI originally said 2027 for human-level intelligence. They’ve since revised that to around 2030. But the exact year doesn’t matter, because the layoffs are already happening with the tools we have today.

Here’s the framework I’d use to think about the next four years.

2026: Tools give you an edge, but the edge has a shelf life. Right now, knowing how to use Claude, Cursor, or Copilot effectively makes you faster, broader, and more useful. This is real. But every AI tool is racing to become easier to use. The interfaces are getting simpler. The prompting is getting more forgiving. Within 12 to 18 months, everyone will be able to use these tools. If your entire career strategy is “learn AI tools,” you’re building on sand.

2027–2028: Tools commoditize. Everyone has access. The tools are invisible, embedded into every product you use. The “I know how to use AI” advantage is gone. What remains is judgment, taste, the ability to evaluate whether the output is actually good, and the ability to know what to build in the first place. This is where the gap opens. The people who spent 2026 only learning tools are stuck. The people who spent 2026 building judgment, customer empathy, and strategic thinking are accelerating.

2030: Only accountability remains. AI can genuinely build products end to end. Design them, code them, test them, deploy them. And here’s the question nobody is answering: who is accountable for that product? A machine cannot be accountable. A machine cannot sit in a boardroom and explain why the product failed. A machine cannot be fired. A machine cannot make a judgment call when the data says one thing and the customer says another. That’s a human. The question is whether you’re building toward being that human.

Designer: where accountability disappears

I’ll start with design because I’ve lived in this world for nearly three decades.

There are two types of design organizations. In immature organizations, the designer is a production function. You get handed requirements, you open Figma, you produce screens. Maybe you do some user research, but it’s surface-level. Your accountability ends when the design file is handed off. The product ships, it succeeds or fails, and nobody connects that outcome back to design decisions.

In mature organizations, the designer owns the experience outcome. You’re talking to customers every week. You’re involved in strategy. When the product fails because the experience was wrong, that traces back to you. That’s accountability.

Most designers are in immature organizations. I’ve seen both sides across enterprise companies, small startups, and agencies. Many, many times.

Here’s the uncomfortable truth. If you’re in an immature org, AI isn’t your biggest threat. Your biggest threat is that your role already has no accountability. Nobody at the executive level can point to you and say, “this person is responsible for the user experience succeeding.” You’re already invisible in terms of business impact.

AI just makes that invisibility permanent.

When AI can produce beautiful screens in seconds, and it basically already can, “making it look nice” is not a career. Owning the outcome is.

Product manager: project management is the first thing AI automates

Same framework. Different role.

If your week is 90% Jira, sprint planning, backlog grooming, and writing tickets, you are doing task work. AI can prioritize a backlog. AI can write user stories. AI can run a standup summary. That is not a controversial statement in 2026. It’s just a fact.

But AI cannot sit in a room with a customer, watch their face when they describe a problem, and read between the lines about what they actually need versus what they’re saying. AI cannot make the judgment call to kill a feature that the data says is working but your instinct says is wrong. AI cannot own the outcome when the roadmap bets don’t pay off.

The PM who talks to customers every single week, who has genuine insight into what the market needs, who makes hard calls and owns them. That person is irreplaceable. Not because of their tools. Because of their judgment and their willingness to be accountable.

If you haven’t talked to a customer in the last two weeks, that should worry you more than any AI announcement. You’re already operating as a project manager, not a product manager.

Engineer: code is the output, not the purpose

Let’s be real. Code is being written by AI. This is already happening. Microsoft says over 25% of their code is AI-generated. That number is only going up.

If the thing you were hired to do is write code, your role is changing dramatically. Not in some theoretical future. Right now. Dorsey didn’t say “someday AI will write our code.” He said “we already have tools that make 4,000 people unnecessary.”

But the engineer who ensures the system is secure, reliable, and scalable is in a different position entirely. Someone has to architect the system. Someone has to decide which tradeoffs to accept. Someone has to be the person who gets the call at 2am when production goes down and has the judgment to fix it.

Code is the output. Architecture, security, reliability, and performance are outcomes. And outcomes require accountability. The shift you need to make is from “I write code” to “I own the system.” That’s the difference between tasks and solving problems.

What to start doing this week

You have four years. Maybe less. Here’s what I’d focus on regardless of role.

If you’re a designer: Map every design decision you’ve made in the last month to a business outcome. Revenue, retention, conversion, support ticket reduction, anything measurable. If you can’t draw that line, that’s your problem to solve. Start measuring the impact of design. Get in front of customers, even if your org doesn’t have a formal research process. Make yourself the person with customer insight, not just the person with the Figma file. Advocate for design accountability in your organization. If no one is responsible for the user experience outcome, make the case that someone should be. Then volunteer.

If you’re a product manager: Block out time for customer calls and protect it. If you’re spending more time in Jira than with customers, flip that ratio. Own your roadmap decisions publicly. Write down why you chose to build one thing over another. When those bets pay off or don’t, take ownership. The PM who hides behind data and consensus is the PM who gets automated.

If you’re an engineer: Start owning system-level decisions, not just ticket-level implementation. Push for involvement in architecture reviews, security audits, and performance planning. Make yourself the person who understands why the system works, not just how to add features to it.

For everyone: Stop optimizing for AI tool knowledge as your primary career strategy. Learn the tools, yes. Use them daily, yes. But invest the majority of your energy into judgment, customer empathy, strategic thinking, and accountability. Those are the skills that compound. Tool knowledge depreciates.

The accountability thesis

By 2030, AI will be able to build entire products. Design them, code them, ship them. Whether that happens in 2028 or 2032, the direction is not in question.

When it does, someone still needs to be accountable. Someone needs to decide what to build. Someone needs to evaluate whether the output is actually good. Someone needs to talk to the customer and understand whether the product solved their problem. Someone needs to sit in front of the board and explain why it worked or why it didn’t.

That person cannot be a machine. It will always be a human.

If you spend the next four years focused on tasks, on tools, on execution, you are betting that those things will still matter. The evidence says they won’t.

If you spend the next four years building accountability, building judgment, building the willingness to own outcomes and be the person who answers for them, you are building something AI cannot replicate.

Dorsey didn’t fire 4,000 people because they were bad at their jobs. He fired them because the jobs themselves were tasks that AI could handle. The people who survived are the people who own outcomes.

The real question isn’t “will AI replace me.”

It’s “am I accountable for anything that matters?”

Start answering that today.

Have a look at the Youtube Video:

I write and record about using AI to do real work at AI For Work. No hype, no benchmarks. Practical stuff you can apply on Monday.

AI Won’t Replace You. Your Lack of Accountability Will. was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.