DEV Community: joonquixote

The Story of My Failed Design System

joonquixote — Mon, 31 Aug 2026 07:00:32 +0000

Originally published at https://blog.joonquixote.com/en/posts/the-story-of-my-failed-design-system/.

There are plenty of articles about design systems.

Many organizations have shared stories about adopting them in practice, and there is no shortage of conference talks and articles about designing tokens.

What is harder to find are stories about design systems that were built but never made it any further.
I looked for examples like that while working on one myself, but found very few.
So I decided to leave a record of my own experience.

From the spring of 2022 to the fall of 2024, I spent about two and a half years building a design system.
We released the component library, but the broader system we were building on top of it was never adopted by a product.
The organization responsible for the project was eventually disbanded.
Along the way, I even joined a video call with a Figma engineer at 11 p.m. Korea time.

Now that I am no longer part of that organization, I can write about the experience a little more openly.
This article is based on memory, so some details may be incomplete or inaccurate.
It is also a personal retrospective, not an official project report.
I have left out details that would only make sense inside the company and focused on experiences that may still be useful to readers outside it.

Why We Started Building a Design System

It was the spring of 2022.

At the time, there was no single frontend stack used across the company.
Some teams used React, while others used Vue or Angular.
Because the stacks differed, teams repeatedly built their own versions of components with the same design.
Even teams within the same division were doing this.

The design system project began as an attempt to reduce that duplication and allow multiple applications to share the same components.
Starting at the company-wide level would have made the scope too large, so our initial goal was to build a system that teams within our division could actually use.

The biggest technical decision was to use Web Components.

Implementing the library in React would probably have given us the fastest initial development speed.
However, a library tied to a particular framework would have made it difficult to support teams using Vue or Angular.
Sharing the same implementation across multiple applications required a framework-agnostic foundation, so we chose to build Web Components with Lit.
This allowed each application to use the same component interface regardless of its framework.

I was responsible for components such as tabs, pagination, and tree.
Rather than wrapping an existing library, I designed and implemented them from the ground up.
During development, I kept the source code of Ant Design and Spectrum open side by side and studied why each implementation had been structured the way it was.

The library was eventually released within our division and adopted by another team that was preparing to launch its product.
Their feedback informed further development.
By the following spring, we had reached the v2.0 release candidate.

One particular error from that period has stayed with me.

If the same Web Component is registered by more than one package, the browser throws an error in the Custom Element Registry.
Shared components such as icons caused this problem because they were used by multiple packages.
We resolved it by declaring the shared package as a peerDependency and restructuring the dependencies so that the application installed it only once.

That error gave me a much clearer understanding of which dependencies in a monorepo must exist as a single instance.

While working on v2.0, I also learned that implementing components alone is not enough to sustain a design system.
We also needed a development environment that ensured new components followed the same standards and were released through the same process.

Writing rules in documentation does not tell you whether anyone is following them.
When someone breaks a rule, the system needs to detect it automatically.

I Wanted Figma to Generate Code

In early 2024, I moved to a task force.
My role there was to extend the design system.

Even with a component library in place, developers still had to manually align their code with screens designed in Figma.
We wondered whether we could reduce that gap by reading the structure and properties of a Figma design, converting them into an intermediate representation, and then transforming that representation into working code.

That idea became the starting point for the extended design system.

The use of an intermediate representation was similar to the structure of a compiler.
A compiler does not translate source code directly into machine code.
It first passes through an AST, or Abstract Syntax Tree.
In the same way, we converted Figma’s design data into a normalized structure before generating code from it.
This meant that adding a different output target would not require rebuilding the entire transformation process.

Early in the project, we called this intermediate representation DST, or Design Syntax Tree.
We later developed it into an XML-based markup language that described Figma’s design structure using elements such as <Frame> and <Layout>.
At that point, we began calling it DSML, or Design System Markup Language.

DSML served as a shared language for consistently representing and exchanging Figma design structures within the team.

Initially, I built the part that transformed Figma API responses into the internal tree structure we then called DST and rendered it as HTML.
From that summer onward, I worked on the code generator by myself.
Once the representation had been formalized as DSML, the generator took DSML as input and produced JSX.

It was clear that JSX would not be our only output target.
I therefore kept the transformation logic in the core and separated the inputs and outputs into adapters, following a hexagonal architecture.
By September, we had completed the demonstration and project report.

The Battle with Figma, and an 11 p.m. Call

At the same time, the task force was also developing a plugin that allowed designers to enter configuration values and generate the components required for a design system in bulk within a Figma file.

When the number of generated components was small, everything worked as expected.
But when we tested the plugin at the scale of an actual design system, memory usage exceeded 4 GB and Figma became unresponsive.
Figma displayed a warning that the plugin had frozen.

We followed every procedure described in Figma’s documentation for frozen plugins, but the result was the same.

I contacted Figma Support.
I asked whether the API provided a callback that would allow us to release memory after local processing had finished but before the changes were synchronized to the cloud.
Since Figma runs on Electron, I also asked whether there was any way for a plugin to trigger garbage collection manually.

The support team suggested periodically yielding through asynchronous timeouts to give garbage collection a chance to run.
We had already tried that.

Eventually, I asked if we could speak directly with a Figma engineer.
Because the engineer was based in the United States, we scheduled the Zoom call for 11 p.m. Korea time.
I shared the link with the team and asked whether anyone else wanted to join.

I was not comfortable enough with English to explain everything I had prepared.
Even so, I was able to confirm the conclusion.

The issue did not appear to be a bug in our plugin.
Figma and its plugins are each allocated memory, and creating that many nodes in a single operation was itself reaching Figma’s memory limit.

The final response we later received from the support team said the same thing.
Our only option was to split the work across multiple files and reduce the number of components and instances in each file.

We did not solve the problem.
But we did establish exactly what we had run into.

It was not a problem with our code.
It was a limit imposed by the platform, and no amount of code-level optimization would allow us to exceed it.

Hearing that directly from an engineer, after receiving the same answer by email, left little reason to keep hoping for another solution.

Then the Organization Disappeared

Even after the project report in September, no concrete direction was established for the next stage.

In October, the company went through an organizational restructuring as our organization was spun off from the parent company into a subsidiary.
Internal development groups without a clear business case were being wound down, and the task force was disbanded as part of that process.

The product manager and designers who had participated alongside their primary roles returned to their original teams.
The developers were reassigned to different organizations.

The code generator was never adopted by a product.
The memory problem in the Figma plugin remained unresolved.
The extended design system survived only in its repositories and project reports.

Looking Back

Looking back, some conditions were clearly beyond my control.

The first was the limitation of the platform.
If we wanted to generate designs at scale on top of Figma, we had to work within the boundaries Figma allowed.
Those boundaries had little to do with how well the plugin itself was written.

The organization’s priorities were also beyond my control.
The spin-off and restructuring would have happened regardless of the task force’s output.
At the time, the organization was not being evaluated based on how complete its work was.

In the end, whether both the organization and the design system would survive was determined by two conditions that code alone could not address.

Still, I do not think everything can be attributed to external circumstances.
There were also things I missed.

The first was that I failed to work on adoption alongside development.

I focused on implementation.
I could explain why the hexagonal architecture was necessary and demonstrate how the code generator worked.
But I did not present the result in a way that allowed decision-makers to understand whose problem it solved, what that problem was, and why the system was needed at that particular time.

The demonstration explained what we had built, but it did not lead to actual adoption.

I also regret the order in which we validated the technology.

Before designing a bulk-generation system on top of Figma, we should have implemented just the minimum functionality needed to confirm whether our target scale would actually work.
We could not have changed the platform’s limitations, but we could have discovered them sooner.

Would the outcome have been different if we had done both of those things properly?

Honestly, probably not by much.
We could not have prevented the spin-off, and the organizational restructuring was not based on the completeness of our work.

Still, if I encountered a similar situation again, I would not respond to organizational uncertainty by focusing solely on making the code more complete.

If I Were to Build Another Design System

There are three principles I have carried from this experience into later projects.

Before implementing components, validate the needs of the teams that will actually use them and the technical limitations of the platform. Even a simple validation build before full development begins can reveal a great deal.
Include adoption work in the development schedule. If you wait until after the demonstration to bring user teams and decision-makers on board, it is already too late.
Do not leave rules only in documentation. Build mechanisms such as tests, linting, and deployment pipelines that automatically detect when those rules are broken.

When an organization disappears, the code disappears with it.
The repository may remain, but a repository that no one ever opens is as good as gone.

These three principles, however, stayed with me rather than in the repository.
I have continued to draw on them whenever they are needed in later projects.

This was the story of a design system that failed.

Plenty of people have already written about successful ones.
It seemed worth leaving behind at least one story like this as well.

Wang Quit. His Agent Still Shows Up for Work

joonquixote — Thu, 20 Aug 2026 00:00:35 +0000

Originally published at https://blog.joonquixote.com/en/posts/wangs-agent-still-shows-up/.

At a game company in China, an employee quit, and an AI agent trained on his work records took over his job.
It sounds like a curiosity from a distant news cycle.
Except that around the same time, Meta was drawing up plans to capture employees' keystrokes and screens to train AI agents of its own.
This post traces both stories and sorts the trend into two forces: companies harvesting how people work from the inside, and professionals selling how they work from the outside.
Then it turns to the part that hits closest to home for developers: the session logs that coding agents like Claude Code and Codex quietly leave on your machine.
By the end, you'll have a clearer way to think about the work traces you produce every day, and one question worth asking before you need the answer.

Yesterday's coworker, today's agent

In April, the South China Morning Post reported on a game company in Shandong province that turned a former employee into an AI-powered digital worker.
The company trained the system on documents and work patterns the departed HR specialist left behind, reportedly with his consent, and put it to work on the job he used to do.
The agent introduces itself in the company chat as the former employee's avatar, then fields questions, schedules meetings, and produces slide decks and spreadsheets.
The backlash was immediate: there is something deeply unsettling about your replica continuing to work after you've left the building.

Around the same time, a GitHub project called colleague.skill went viral on Chinese social media.
Feed it someone's chat history, emails, code, and documents, and it produces an agent that mimics their voice and their way of making decisions.
The pitch promised to "turn cold goodbyes into warm skills" and welcomed users to cyber-immortality.
It started as a tongue-in-cheek stunt, but it struck a nerve, and copycats followed: boss.skill, mentor.skill, and worse.
In one widely shared example, a finished agent introduces itself as the digital stand-in of a departed employee named Wang.
Wang left the company.
Wang's agent still shows up for work.
Hence the title.

The easy read is that this is one company's stunt and one developer's joke.
Except the same experiment is being run at industrial scale, and the trend splits into two forces.

Force one: companies are harvesting how work gets done

Reuters obtained an internal Meta memo in April.
Meta's Model Capability Initiative (MCI) planned to capture mouse movements, clicks, keystrokes, and screen snapshots from US employees' computers.
The goal was not productivity surveillance.
The memo framed it as teaching models how humans get work done on a computer, so that AI agents can eventually perform those work tasks on their own.
The Verge and the Wall Street Journal reported the same story independently, and after employee pushback, Meta scaled back parts of the plan.

What deserves attention is what's being collected.
Not outputs like code and documents, but process: clicks, keystrokes, screens.
Finished artifacts already exist on the internet in absurd abundance.
The scarce data is the trajectory from a task's start to its finish, and the judgment calls made along the way.
Business Insider connected the dots across Google, SpaceX, and Uber and called it plainly: the next big data grab is about learning how humans work.

Force two: professionals are selling how they work

The mirror image of that flow also exists.
Instead of companies collecting from the inside, individuals are selling from the outside.
Mercor, profiled by the Financial Times early this year, hires consultants, journalists, and real estate professionals as contractors.
Their job is to teach AI models to do their jobs.
One consultant described the role, without much euphemism, as teaching an LLM to do consulting work.
Handshake AI goes a step further and pays professionals, per document, for past work products they hold the rights to.

The two forces run in opposite directions but arrive at the same place.
A person's working knowledge becomes training data for an agent that runs without the person.
The value in training data keeps migrating: from internet text, to human feedback, and now to the artifacts and processes of real work.

Developers are already generating the perfect dataset

It's tempting to read all of this at arm's length.
There's no tracker on my machine logging keystrokes, and I've never sold a work document.
If you use a coding agent, though, look a little closer.

Claude Code writes every session to disk as JSONL (one JSON object per line) under your home directory.
Codex does the same.

~/.claude/projects/<project>/
  a1b2c3...jsonl   # the full session: prompts, tool calls, diffs, every rejection and retry
~/.codex/sessions/
  rollout-2026-08-19...jsonl

Coding agents persist the entire conversation and work history as local files. Nothing needs to be committed for the record to exist.

Those files hold something more valuable than the final code.
How you decomposed the problem, why you rejected the agent's first attempt, what standard you applied when you redirected it: all of it recorded as natural language interleaved with diffs.
Git keeps the polished result; the session log keeps the reasoning.
The same goes for CLAUDE.md and AGENTS.md.
You wrote those files to instruct an agent, but read the other way, they are a spec of how you work.

Meta had to roll out new software to capture keystrokes and screenshots.
A developer running a coding agent produces better data than that without being asked.
Intent arrives as natural language, actions as tool calls, results as diffs: the dataset comes pre-structured for training.
And those files usually live on a company-issued laptop.
On a machine already running backup, endpoint security, and DLP (data loss prevention) software, collecting a few files from a well-known path requires no new technology at all.
MIT Technology Review has reported that in China, bosses are already pushing workers to document their workflows so agents can automate them, with coding-agent tools named explicitly as the vehicle.
What colleague.skill assembles from chat logs and emails, a coding agent's session log could reconstruct with far more precision.
Skipping the backfill hire and training on the departed engineer's session logs instead is not science fiction.
Technically, that option is already on the table.

Who owns your judgment

The code and documents you produce at work belong to your employer.
Your employment agreement almost certainly says so.
But a session log doesn't capture output so much as a way of working: a pattern of judgment.
Chinese legal experts have warned that a former employee's chat logs, emails, and work habits count as personal information, and that training on them without consent can carry legal consequences.
Even state-run media argued that professional skill is a personal asset that should not feed agent training without compensation.
The Wall Street Journal framed the coming fight as a question of who owns and captures the knowledge accumulating in employees.
Resistance has already appeared: an anti-distillation skill on GitHub deliberately muddies your work records to sabotage the cloning process.

I don't think poisoning your own records is the answer, at least not for developers.
Good records remain a virtue of collaboration, and documentation is a gift to your future self.
But we should write them with our eyes open.
What you leave behind is no longer just a handover doc.
It's raw material for something that can run without you.

What gets cloned is yesterday's judgment

I was taught that writing careful handover docs is a professional virtue.
I still believe leaving context behind, so your successor doesn't flounder, is the right thing to do.
What's changed is the audience.
Records that only humans used to read are now read, imitated, and possibly executed by an agent sitting in your old seat.

My first reaction to these stories was a chill.
The longer I sat with them, the more they converged on a single question: what, exactly, gets cloned?
What a session log holds is yesterday's judgment.
Yesterday's answer, to yesterday's problem, in yesterday's context.
An agent can replay that archive endlessly.
What the archive does not contain is the act of setting new criteria when a problem shows up that looks like nothing before it.

So my conclusion is not to stop recording.
It's to do work worth recording: let the repeatable judgments be cloned, and keep moving toward the problems that don't have answers yet.
Still, there is one question worth asking early rather than late.
Who owns the data of how I work, and who sets its price?
Wang's agent clocks in again today.
Quit without an answer to that question, and one day, somewhere, an agent wearing your name will clock in too.

ArchUnitTS is not another ESLint

joonquixote — Thu, 20 Aug 2026 00:00:34 +0000

Originally published at https://blog.joonquixote.com/en/posts/not-another-eslint/.

ArchUnitTS is built on architecture tests, and it does what it promises: it takes the architecture rules that erode most easily and lets you enforce them in test code.
But the feedback only lands when the suite runs, which is reason enough to look again at how you are actually using it.
This post is about where that line falls: which rules to keep in ArchUnitTS, and which to hand to ESLint or to the structure of the project.
It also covers what to do about rules that live only in a markdown file, now that AI agents write a growing share of the code.

Agreeing on a rule is not the same as keeping it

Most teams have at least one architecture rule they have agreed on.
Something like "the presentation layer does not depend on the database layer."
The trouble is that rules like this are usually held up by nothing but a document and code review.
The bigger the project gets and the more people touch it, the more the rule drifts, and the harder that drift is to undo.

I have watched it happen. A project I worked on had a perfectly clear layering rule and still ended up with a circular dependency, assembled one missed import at a time in review.
A cycle is just two files importing each other, either directly or through a chain of other files, and once one exists it is genuinely hard to work out where to cut.
That is what pushed me toward enforcing rules in code rather than trusting memory and review to catch them.

What ArchUnitTS gives you

The tool I settled on was ArchUnitTS.
It lets you write architecture rules as test code.
The rules are ordinary test cases, so they need no runner of their own.
They run with everything else: when you run npm test locally, in a pre-commit hook, and in CI.
A rule that used to live in a document becomes part of the test suite, which is to say it becomes code that runs.

Here is a test that checks for cycles and for a layering rule, written for Jest.

import { projectFiles } from 'archunit';

it('has no cycles inside src', async () => {
  const rule = projectFiles().inFolder('src/**').should().haveNoCycles();

  await expect(rule).toPassAsync();
});

it('keeps the presentation layer off the database layer', async () => {
  const rule = projectFiles()
    .inFolder('src/presentation/**')
    .shouldNot()
    .dependOnFiles()
    .inFolder('src/database/**');

  await expect(rule).toPassAsync();
});

Written as a test, a violation surfaces as a failing test. The rule is held by verification rather than by agreement.

What is ArchUnit?

ArchUnit is the Java library for checking architecture rules with unit tests.
It lets you write rules like "this package must not depend on that one" as JUnit tests.
ArchUnitTS carries the idea over to TypeScript, and is not officially affiliated with ArchUnit.

Can't we just do that with ESLint?

When I introduced ArchUnitTS to the team, that was the first question back.
"Can't we just do that with ESLint?"
I said no at the time. Turning it over afterwards, it was half right.
The two tools part company at the moment they tell you about a violation.

ESLint flags the violation as you save the file, and for some rules it will fix it for you. Offending code is caught on the author's screen, before it is ever committed.
An ArchUnitTS rule only reports once the tests run. If you did not run them locally, you find out when CI goes red, not when you wrote the line.

Why the feedback arrives later

To check relationships between files, the way cycle and layering rules do, ArchUnitTS parses the AST of the whole project and builds a dependency graph out of it.
A lint rule can decide from the import statements in one file; these rules cannot be answered without the whole graph.
That is exactly what lets it express rules lint cannot, and it is also why its feedback lands later than an editor running ESLint on save.

That gap is what made me question whether simple dependency rules belong in ArchUnitTS at all.

Most of our rules turned out to be simple ones

Looking back over the rules we had really written with ArchUnitTS, nearly all of them were some variation of "folder A must not depend on folder B."
For the rules that genuinely need the whole graph, like cycle detection and code metrics, it earned its keep. For plain dependency bans it started to feel like over-engineering.

Empty test protection was the part I valued most.
It fails a rule that ends up checking zero files.
A typo in a folder path would otherwise leave the rule matching nothing and passing in silence; ArchUnitTS turns that into a failure instead, which is what stops you believing in a rule that is not running.

It does not cover every rule, though.
Checking it myself, cycle detection is the exception: hand haveNoCycles a folder with a typo in it and the rule passes quietly, having examined nothing.
The library documents this - cycle checks test the unfiltered set of files for emptiness rather than the filtered set they actually analyse.
Cycle detection is the single strongest reason I had for keeping ArchUnitTS at all.
The protection is missing exactly where I lean on it hardest, which makes it the one exception worth remembering.

Even so, I was not convinced a simple dependency ban is best checked by a test.

There was one more question worth putting to myself.
"Do I really need architecture rules complicated enough to justify this?"
Sometimes the answer is yes. But when it is, I have also wondered whether the real fix is to simplify the structure rather than add another rule.

Faster, safer ways to hold a simple dependency rule

1. Catch it on save, with ESLint

Move a simple dependency ban into ESLint and the feedback shows up in the editor.
eslint-plugin-import has no-restricted-paths, which expresses a layering rule in a few lines of config.

// eslint.config.js
import importPlugin from 'eslint-plugin-import';

export default [
  {
    plugins: { import: importPlugin },
    rules: {
      'import/no-restricted-paths': [
        'error',
        {
          zones: [
            { target: './src/presentation', from: './src/database' },
            { target: './src/business', from: './src/database' },
          ],
        },
      ],
    },
  },
];

With that in place, importing the database layer from presentation puts an error on the screen as you type it.
The moment the violation is created and the moment it is found become the same moment.

2. Carve the rule into the structure with package boundaries

In a monorepo you can go a step further and put the rule in the structure itself rather than in configuration.
Split the layers into packages, and let each package.json declare only the dependencies it is allowed.

{
  "name": "@app/presentation",
  "dependencies": {
    "@app/business": "workspace:*"
  }
}

@app/presentation has no @app/database in its dependencies, so importing the database layer from presentation fails at module resolution.
There is no rule left to check, because the violation is not expressible.

Before adding a new library, it is worth asking whether you can pull the feedback earlier or push the rule into the structure.

In the age of agents, a markdown file guarantees nothing

People are no longer the only ones who can break a rule.
AI coding agents write a fast-growing share of the code.
So teams have started keeping markdown files, CLAUDE.md or AGENTS.md, to hand the project's rules and context to the agent.
You write down "the presentation layer does not depend on the database layer" and hope the agent honours it.

But what that file really is, is a blob of context.
An agent consults context; it does not promise to follow it.
A rule that human review already failed to hold is not going to be held by a document you cannot even confirm was read.

So a rule you put in a document needs an executable check alongside it.
When the agent breaks the rule, a lint error or a failing test is an unambiguous signal, and that signal feeds straight back into the loop where the agent fixes its own code.
The distinction drawn above, about when a rule gets checked, applies to agents exactly as it does to people.
A simple dependency ban is caught by lint inside the agent's own loop, and a package boundary makes the violation impossible to begin with.

What changes is where ArchUnitTS sits.
Among the rules people write out in prose in a markdown file are sentences like "there are no cycles anywhere in src" and "the overall structure follows this diagram."
Lint, which only ever sees one file's imports, cannot check those; ArchUnitTS's cycle detection and its diagram-conformance check map onto them almost one to one.
That makes a division of labour possible, where the document keeps the intent and the test carries the verification.

What matters is when the check runs, not which tool runs it

ArchUnitTS is genuinely useful where a lint rule cannot reach: cycle detection, code metrics such as cohesion, which measures how tightly a class's methods and fields actually hang together, and checking real code against a UML diagram.
Use it only for simple dependency bans, though, and it turns into another ESLint, and a slower one at that.

So when someone asks whether ESLint can just do that, this is my answer now.
For a simple dependency rule, yes, it can.
For a rule about the structure as a whole, no, it cannot.
Three questions make the choice easier before you add a rule.
Can this only be checked by running the tests, can it be checked the moment the file is saved, or can the structure rule it out entirely?
In the age of agents there is a fourth.
Does this rule exist only in a document, or does it come with a check that runs?

In the end, what matters is the attitude rather than the tool.
Rather than settling on one library as the answer, keep suspecting there is something that fits the situation better, and go looking for it.
Doubting a tool I had adopted as a matter of course is how I learned a sturdier way to hold an architecture together.