DEV Community: Jeremy Andrews

What Figma gets wrong about the collaboration problem

Jeremy Andrews — Fri, 26 Jun 2026 22:51:53 +0000

At Figma Config 2026, Figma announced code layers: interactive code that lives directly on the design canvas, alongside your design files.

The take you'll read everywhere:
"Design tool threatens engineers!"
"Engineers defensive!"
"AI replaces another job!"

That's not what I'm worried about, said as someone who spends a decent amount of time writing and reviewing AI-generated code.

I'm not arguing against AI in the dev workflow.
I'm worried that Figma is solving the right problem with the wrong answer.

The design-to-dev handoff is genuinely broken. It has been for years.

Designer works in a flat file, in a silo. Ships it over the fence. Engineer implements. Something about the interactivity is off. Designer goes back. Adjusts. Ships again. Engineer adjusts. Repeat.

It's a structural problem. Two people who need each other's expertise are working in separate rooms and passing notes back and forth.

Leadership wanting to change this is correct. The push to be more "in code", vague as the phrasing is, points at something real: design and dev should be working closer together than they often are. Less silo, more overlap.

The bottleneck isn't the handoff.
It's the gap in context between the people on either side of it.

Figma looked at the problem and concluded the bottleneck was the handoff itself.

Code layers are their answer: convert any design frame to a working code layer with one click, or generate one from scratch with the Figma agent. Compare options side by side on the canvas. Comment, iterate, extract back to design layers, push to a repo.

In his recap of Figma Config 2026 on the Figma blog, Dylan Field wrote that "code is material, just like images, vectors and design layers."

Both designers and engineers, in the same file, on the same canvas.

Engineers don't want to live in Figma.

They work in editors, terminals, and tools that have full context of what they're building. Asking an engineer to collaborate inside the canvas is asking them to leave the environment where they can actually see what the code does. Most won't. And when they don't, the loop Figma describes collapses.

What's left is design-generated code that gets pushed to a repo and becomes someone else's problem. Not a handoff eliminated, but a new kind of handoff created.

Then there's the structural issue that runs underneath all of it: Figma is a design tool.

Its entire business model is design seats. Every product decision they make gets filtered through what keeps designers happy and renewing subscriptions. Unless something changes drastically, their code layer will always be optimized for what makes sense for designers, because that's where their revenue lives.

This isn't a criticism of Figma as a company. It's what it means for a design tool to own code. The thing that matters to the people paying Figma is the design output.

For Figma, code is a design feature. A better GitHub integration doesn't change that.

The problem isn't that Figma uses AI to generate code. I use AI to generate code. But there's a difference in how that generation gets used. When I work with Claude, I'm providing the context: the standards, the component library, the patterns, the constraints we've established. I'm also reviewing what comes out with full knowledge of the system it needs to fit into.

The judgment isn't in the tool. It's still with me. The tool extends my capacity, but it doesn't replace my understanding.

Figma would say that's the problem. That working with Claude is isolated, happening in a separate chat, disconnected from the rest of the team. They're not wrong about that, but moving that work into a design-optimized canvas isn't the answer either.

Figma's code layer is designed for people who don't have that system context and, in many cases, aren't expected to.

A designer generating a prototype.
A junior engineer under deadline pressure.
A small team without dedicated front-end.

The generated code goes through fewer hands that know what to look for. The gap between what got generated and what belongs in the codebase doesn't get caught because the person in the loop wasn't positioned to see it.

That's the distinction.
It's not inherently AI-generated code vs. real code.
It's context-aware generation reviewed by someone with system knowledge vs. context-free generation reviewed by someone who may not have it.

One produces artifacts your team owns.
The other produces things someone has to reverse-engineer into your system before they're usable.

Imagine the reverse. Leadership proposes letting engineers use one of the many AI tools that generates designs from a component description. You describe the behavior and the tool produces the layout. The type hierarchy. The interaction states.

Designers would push back immediately. They'd be right to. That tool isn't doing the research. It isn't running the user tests. It isn't making the hundred small decisions that make something actually work for the people using it.

It's producing an output from a description, and calling it a design.

A generated design isn't a designed thing.

Production implementation isn't just code that renders. It's accessibility decisions. Edge case handling. Performance tradeoffs. Integration with the actual system. Test coverage.

A Figma-generated component that looks finished will get shipped by someone who thinks it is, and the team that inherits it finds out what's missing the hard way.

Designers have spent years making that argument about their own work. They understand what "production-ready" means in their domain and won't let someone blur that line.

That's the argument we need to get better at making about ours.

The right answer to the collaboration problem isn't a faster handoff. It's less of a handoff.

On our team, we've been pushing for working sessions: designer talks through intent, engineer works through the code in real time, both people in the room instead of a relay race across a feedback loop. The output is something both people understand because both people were together when decisions got made.

Nobody inherits a component that looks done and isn't.

When both people are making decisions collaboratively, both are more invested in the outcome. That changes what gets built and how carefully it gets built.

Yes, it's scheduling-dependent. It's slower to set up. It requires both disciplines to treat each other's constraints as real.

Even so, that's the workflow I'm building toward. The back-and-forth it eliminates shows up faster than you'd expect. So does the cost of the alternative.

The canvas doesn't close the context gap. The conversation does.

Nobody defends code reviews at 11pm

Jeremy Andrews — Tue, 09 Jun 2026 19:38:01 +0000

"How could you let this happen?"

I've been in that conversation. On both sides of it, at different points.
It's a versatile question.

The first time I heard it from above, we'd shipped something that shouldn't have shipped in the state it was in. Bugs that a proper code review would have caught. QA that got compressed in the final days because another part of the project ran late and the deadline didn't move.

Nobody decided to skip code review. Nobody said "let's just ship it broken." What happened was simpler and more predictable: the deadline was fixed, the timeline snowballed, and the back of the chain got squeezed. Code review and QA are always at the back of the chain. When time runs out, they're where the time comes from.

Everyone agreed at the start of the project that they mattered. Someone always raises it at the end, too. They're not wrong, but the deadline is rarely swayed by a good point.

I've done the same thing in how I talk about work. For a while, I praised speed without understanding what was being traded to get it. "You turned that around fast." Said with genuine appreciation. Received as instructions.

When I realized it, I tried to correct it.
Refused to let reviews be where the time came from.
Ensured they stayed in the planning estimate.
Made them a line item, not an afterthought.

It held until the next hard deadline, which arrived on schedule. Then the timeline snowballed again, for reasons that had nothing to do with code review, and the question was: what do we compress?

Same answer as always.

Engineers respond to incentives. We already know what happens when quality controls live at the end of a compressed schedule: they get cut. Critical thinking is increasingly vulnerable to the same pressure.

I know, because I've been the person setting those incentives. I didn't mean to. I praised speed.

Timelines were slipping long before anyone knew what a token was, but AI has made the path of least resistance feel productive. When you can offload work and still hit the deadline, it's genuinely hard to argue against in the moment. Especially when the alternative is staying late, losing the argument, and watching the code review get cut at 11pm anyway.

The obvious fix is to hand the review to AI.
Faster than a human.
No one has to stay late.
The process technically still happens.

Except AI reviewing AI-generated code means nobody has actually looked at it. The thing that slips through under pressure isn't always a syntax error. Sometimes it's the change that broke an assumption nobody documented.

The path of least resistance isn't laziness. It's what you get when you've asked people to be excellent under conditions designed to prevent it.

Speed pressure keeps building.
People get more depleted.
Exhaustion makes the easiest options more attractive.
The easiest options still hit the deadline.
Speed gets praised.

The loop runs itself, quietly, while everyone's still arguing about who let this happen.

One of the fixes I keep coming back to isn't structural.
Protected reviews.
Line items in the estimate.
I've tried those.
They tend to last until the next deadline, which is to say they don't last.

What I think actually sticks is what gets named. I'm not talking about a process doc. When someone pushes back on a compressed timeline and catches the thing that would have shipped broken, that has to come up in the next 1:1. It needs to be praised and I have to be the one to tell that story.

Process follows incentives. It's never the other way around.

What interests me isn't whether people are making bad choices.

They're humans. I know they are.

It's that the system reliably produces the outcome it claims not to want.

Everyone agrees code review matters... until the deadline, at which point it becomes a philosophical position.

Everyone agrees judgment can't be outsourced... until the velocity report.

And when something breaks, someone inevitably asks the question.

The mercy of hard things

Jeremy Andrews — Mon, 08 Jun 2026 01:27:10 +0000

The other day I watched an engineer spend three days on a piece of the codebase nobody had touched in two years.

Should've been a four hour fix, except...
The senior who built it was gone.
The documentation was sparse.
The code only made sense if you'd been in the room when the decisions were made.

They could've asked me to rewrite it. I would have.

Instead they sat with it.
Read through the git history.
Traced the logic forward and backward.
Built a mental model of why each piece was there.

By the end, they didn't just fix the bug. They understood the system.

I asked them why they didn't escalate it.

"I needed to know how this worked," they said. "If I'd just had you fix it, I wouldn't know."

I checked in twice that week. Both times they were still in the thick of it. I had a deadline breathing down my neck and a fix I could've written before lunch.

I'm not going to pretend it was easy to watch.

That three-day tax on understanding used to be everywhere in engineering. It still is, but it's getting rarer and we're very proud of that.

The logic is tempting. Why spend three days when AI could spend three minutes? Why put junior engineers through the pain of understanding when they could generate a fix instantly? Why not move faster?

Three minutes gets you a fix. Three days gets you something else.

Systems have shapes.
Those shapes have reasons.
Understanding the reason is the actual work.

That's the thing that separates someone who can patch code from someone who can steward it. I've been both, sometimes in the same week.

Those three days weren't a gift I was giving them by staying out of the way. They were the part of the job that was changing my developer.

There's an argument going around that if you have an idea and Claude can build it, you have no excuse for not shipping. That's true, as far as it goes.

But the grind isn't dead weight. It's a filter. The person with a vague idea about "an AI agent for our workflow" and the person who's traced where the data goes and what breaks when the API times out are not the same person.

It used to be obvious before anything shipped, because nothing shipped until you'd earned it. That felt like a feature at the time, but mostly it was called a blocker.

AI isn't making excellence easy.
It's making adequacy cheap.

That's a different crisis than anyone's talking about.

When execution was hard, you had to believe in the thing before you built it.
You had to think through the architecture.
You had to anticipate problems because debugging would be expensive.
You had to write documentation because the code would outlive your memory.

These weren't best practices.
They were necessities.
Having no shortcut made them automatic.

I complained about this at the time. The week of planning before writing a line of code felt like overhead. It wasn't.

Now you can spin up a system in an afternoon that would've taken weeks, held together with prompt engineering and middleware and a lot of hoping nothing breaks in production.

Not because you're lazy. Because you can.
Because nothing forces the hard architectural thinking upfront.

I've done it. Shipped a workflow last month that I couldn't fully explain if someone asked me to trace a failure through it.

It worked.
The demo was clean.
The tests passed.
I moved on.

This wasn't a failure of AI. It was a failure of understanding. My failure.

Once you fully understand how a system works, AI becomes a force multiplier. It can write the documentation you should have written. It can turn tribal knowledge into markdown. It can help build the skills and guardrails that make the next engineer productive faster.

But those tools only become predictable once someone has done the hard work of building the mental model first, then translating it into something the system can reliably use.

That's the work AI can't replace. It can describe what it sees and preserve what we understand, but it can't verify whether that understanding is real.

That's the part that should worry me more than whether the engineer took three days.

The engineer could've used AI on day one. For the fix itself, they probably should have. They didn't, at least not until they understood what they were looking at.

I told them as much after the fact. They nodded, then asked if they could walk me through what they'd found. They were excited about it.

We were on a call five minutes later.

This is the mercy of hard things.
AI didn't create this moment. It just made the choice visible.

Three minutes could have built a solution.
Three days built an engineer.

When the right answer is a smaller project

Jeremy Andrews — Sun, 07 Jun 2026 21:20:36 +0000

"I'd hate for us to throw the experience away when we just spent so much time and effort building it."

I heard that sentence a week after the data came in on a project we'd spent six months building. We still hadn't fully processed what the numbers meant yet.

I recognized it immediately. Not because it's inherently wrong, but because I've said versions of it myself over the years.

We set out to build a personalized recap landing page for a big annual conference. The kind of thing that felt like the event actually remembered you were there. Which sessions you attended. Which topics kept pulling you back. A tailored summary of your individual event experience.

Real engineering ambition.
Real design work.
Six months from a team that cared about getting it right.

But somewhere along the way, the API access we needed to do it right fell through.

No individual user data meant we couldn't actually personalize based on your unique experience. So we pivoted to segmentation: figure out which session topics someone attended most, assign them a persona.

You attended a lot of AI sessions? You're an AI Persona. Here's your badge.

In fairness, the badge was accurate. The segmentation worked. The problem was that accurately telling people something they already knew about themselves was not exactly the vision we'd pitched six months earlier.

The original idea kept getting diluted. We shipped it anyway. Given where we were, that was the right call.

The data came back thin.

Not zero. Not embarrassing. Thin enough to tell you something honest about how many people in that audience actually wanted this kind of experience.

That's a finding about appetite, not execution. The API falling through hurt the product, but I don't think it changed the fundamental signal.

I was still sitting with those numbers when the first conversations about next year started, and that's when I heard the sentence.

I understood the instinct completely. Six months of genuine effort from real people. Treating that as sunk cost and moving on feels like dismissing the work (and the people who did it).

But I kept turning it over. And eventually I landed on what was bothering me: the six months are already gone. We can't un-spend them. The question the data is actually answering isn't whether to throw the work away. It's what size of opportunity we were building for.

Thin numbers have a pretty clear answer to that question.

That context changes the next planning conversation significantly. Or at least it should.

It doesn't mean we do nothing next year. It means we need to ask seriously: what does this opportunity actually warrant?

Because there's a version of this project that takes two weeks. A lighter integration. Simpler segmentation. Something that ships fast and still tells you everything the six-month version told you, except you get nearly half a year back to spend somewhere else.

When the data tells you the opportunity is smaller than the investment, the answer probably isn't "let's just build it better."

Sometimes it's: right-size the project to match what we know.

The tricky part is that sunk cost reasoning almost never announces itself as sunk cost reasoning.

It announces itself as loyalty. As not wanting to waste good work. As giving a team's effort the respect it deserves.

These are real and reasonable feelings. They belong somewhere in the conversation.

They're just not planning criteria.

What six months of work actually produced was a finding: this opportunity is smaller than we thought going in. The smart move is to let that finding shape the next decision, not work around it because it's uncomfortable.

Have you been in a room where the data pointed one direction and the planning cycle went another?

I'm curious whether right-sizing ever actually won, or whether the room kept reaching for the six-month vision because walking away from the experience felt worse than ignoring the data.

Share your experiences below!

Notes from a hammock

Jeremy Andrews — Sat, 23 May 2026 02:55:33 +0000

I am writing this from a hammock.

Not metaphorically. I've been spending more and more of my time away from screens, trying to remember what thinking feels like without a notification interrupting every four minutes. I have a Remarkable tablet now. E-ink, no Chrome tabs, no Slack unread count haunting me from my peripheral vision. I read on it. I take notes on it. It is, embarrassingly, one of the better decisions I've made in the last few years.

This writing started there. Not as any sort of content strategy, but as a quiet place to muse.

I have a sociology and psychology background that I use every single day, which often surprises people to learn since I'm an engineering manager. The path wasn't linear. I graduated into a bare job market, picked up where I left off the previous summers at the NC Department of Transportation, doing everything from data entry to assisting with fatal crash investigations (you know, normal job stuff).

I eventually ran into an old friend at a poker game, someone I hadn't seen in years, who needed someone he could trust on a two-man dev team after his partner abruptly left the company. That conversation landed me at an agency for nearly a decade doing website optimization, A/B testing, and personalization. Which is, when you think about it, the applied science of understanding how humans make decisions and designing systems that help people get where they're trying to go.

The sociology degree wasn't a detour. It was the whole point.

Now I manage a development team and spend a meaningful portion of my days watching the AI conversation unfold, feeling a specific kind of unease I've been trying to articulate. Here's my best attempt.

Judgment is a muscle. A functional capacity that gets stronger the more you use it and weaker the more you outsource it. Psychologists call this cognitive offloading: the habit of shifting thinking onto external tools. The research shows it doesn't just change what we do, it changes how we approach problems even when the tool isn't there.

When people repeatedly have decisions made for them, they gradually stop trusting their own judgment. Not because they become less capable, but because the loop gets interrupted: making the call, sitting with uncertainty, being wrong and recalibrating. The muscle doesn't disappear overnight. It quietly becomes less reliable, and eventually you stop reaching for it even when you could.

We've already run a version of this experiment. We handed our attention spans to engagement algorithms for fifteen years and then wondered why it became harder to sit with a complex idea. The systems weren't designed to destroy depth. They were designed to maximize engagement, and it turned out that depth was friction, so the systems smoothed it out. The result isn't that people became lazier or less intelligent. It's that the environment stopped requiring them to sustain attention, so sustaining attention got harder.

AI is a different technology with a different purpose, but the dynamic is worth taking seriously. Every time someone outsources a judgment call they were perfectly capable of making, about tone, about approach, about whether something is actually a good idea, that capacity gets just a little smaller.

One call doesn't matter. Millions of calls, across a workforce, over a decade, and you haven't built a more efficient society. You've built one that is very good at reviewing AI outputs and not much else. Which is, coincidentally, a workforce that is significantly easier to manage, to commoditize, and to eventually replace.

I'm not anti-AI. I'm building agentic systems right now, and I think the version of this future where machines absorb the tedious, grinding work and people get their time back for things that actually matter is real and worth building toward. That future requires deliberate thinking about which judgment calls we hand off and which ones we protect.

Right now that deliberateness is mostly absent from the conversation. The race is to automate. The question of what we're training people out of along the way tends to get scheduled for a later meeting that never happens.

So that's what this is. A place to read carefully, think slowly, say the uncomfortable thing without dressing it up, and openly ask what we're actually optimizing for and who pays when the optimization is wrong.

The hammock helps. Sometimes the best thinking happens when the machine isn't in the room.