# Open to discussion/ideas/learnings

When I was thinking about how to setup an intuitive AI powered DS System, I drew an initial version of this diagram (before any setup)

A lot of the content I see, info from colleagues in the DS space and even my observation within a company I recently worked with, many seem to be using AI to do specific parts of this system in fragmented & isolated ways.

The diagram attached is an example of how I think design systems and AI should work together. A proper stack

The pink boxes are the bet: if the documentation is good enough, AI output should stop looking well... 🫠

I've been building toward this map for a while. A few things I've learned already:

• The brain (ds-brain) sits in the middle - not Storybook, not the component source files
• You maintain docs once - skills, rules, indexes, and Storybook fragments fall out of a generator
• Storybook is a consumer of the brain, not the other way around
• The IDE/Cursor path is where I've shipped and measured the most so far
• AI inside Figma still needs love - I'm exploring options (MCP? CLI?). This should be interesting.

For me it's not enough to say "I designed the system - use it." I'm running tests and tracking metrics:

• Scoring outputs against a rubric
• Counting when agents invent components that don't exist
• Accounting for contamination - Running trials in isolated environments so experiments don’t poison retrials.
• ... and much more

So far, some scores made me proud. Some stung. All of them taught me the same lesson:- Don’t start with the AI box. Start with the documentation package. Everything else is plumbing.

I'll share more of what I'm learning over the next few weeks - the wins, the misses, and what actually moved the needle. If you have any ideas, observations, please feel free to share :)

Hey everyone!

I've been building a frontend library focused on UI behaviors called Nagare (流れ), and I'd really appreciate some honest feedback from other developers.

The idea is simple: instead of splitting a single interaction across CSS, Tailwind classes, event handlers, animation libraries, and state management, everything for that interaction lives in one place.

Example:

soul("button") .hover({ onStart: { tw: "scale-105 shadow-xl", css: `border-radius: 20px`, js: function () { console.log("hovered") } }, onEnd: { tw: "scale-100 shadow-none", css: `border-radius: 12px` } })

Each behavior (hover, click, tap, longpress, swipe, drag, scroll, onVisible, onIdle, networkChanged, etc.) can contain:

• "tw" for Tailwind classes
• "css" with inline "@if/@else"
• "js" for custom logic
• shared state, templates, presets, delays, and more

I'm not trying to replace React or Tailwind—Nagare is focused on giving interactions a single home.

I'd really love feedback on:

• Does the API feel intuitive?
• Is this something you'd actually use?
• What feels unnecessary or confusing?
• What would you change before a stable release?

Repository: https://github.com/Mizumi25/nagare

Showcase: https://nagare-nu.vercel.app/

npm: https://www.npmjs.com/package/@nagarejs/react

I'm mainly looking for honest criticism, not compliments. Thanks!

I'm the founding designer at Kestra, and for years our design token workflow was painfully manual: tweak color variables in Figma, export JSON with a plugin, paste it into VS Code, then DM a frontend dev to run the generation script and open a PR. A one-line color change could take an hour and always depended on someone else's availability.

I finally automated the whole path. Now a small Figma plugin POSTs the tokens to a webhook, and a flow clones the repo, regenerates the SCSS themes, and opens (or refreshes) a single bot-managed PR, then notifies the team on Slack. If nothing changed, it does nothing.

The part that actually took the longest wasn't the automation, it was the diffs. The webhook re-serialized the JSON with arbitrary key order every time, so Git showed 400-line diffs when I'd changed one gray by 2%. Reviews were impossible. The fix was normalizing the JSON before regenerating: rebuild each object in canonical key order, sort colors by name, pretty-print. After that, one color change = one line in the diff.

Full writeup here if useful: https://medium.com/kestra-engineering/from-pixel-to-pipeline-shipping-my-figma-color-tokens-to-github-with-kestra-8fe865f85733?sharedUserId=ncallens

Curious how others handle the Figma-to-code token handoff. Do you keep a designer in the loop for the PR, or is it fully automated on your side? And for those doing it automatically, how do you deal with the noisy-diff problem?

AI has revolutionized the software development industry by fundamentally changing how software is designed, developed, and maintained. It has made a highly positive impact on coding productivity. However, AI adoption also brought several negative effects that are pushing software development to a breaking point.

Problems AI Created for Software Engineering

Loss of Source Code Control

Enormous velocity of code production by AI has a significantly negative side-effect: software developers are getting overloaded with PRs they need to review, understand and approve. However, developers experience a huge pressure from the management demanding manifold performance gains to justify implementation of AI in an organization. As a result, many PRs are either approved quickly without thorough review, or they are not reviewed at all and approved automatically.

The biggest problem of such approach is a snowball effect: once review quality start to slip – it is very hard to get it back because it would require developers to re-read source code to understand the current state of the codebase. Developers will not be able to fully understand impact of new incoming changes without clear picture of the current codebase. On the other hand, they are under pressure to deliver productivity gains while re-reading all code would take significant time developers just do not have. So, nobody does it and once review quality starts slipping, there is no way back and the team loses control over source code.

As a result, the team understands its own code less and less with every AI-produced change. At the end, only catastrophic incident on production might wake up the management to the fact that the working knowledge of the source code is gone.

AI Fails on Complex Requirements

AI code production starts with specification. Several sentences of a text prompt will be enough for case of a simple application. However, anything more complex would require prepared specification document. Creation of such document is not easy, and it requires special skills. However, let’s assume we have a complete document fully describing what we want in unambiguous way. Would it be enough for AI to produce code exactly to supplied specification? The answer is – it depends on size and complexity of specifications. The more complex and larger the spec is – the more deviations and hallucinations AI makes when generating the code.

Also, there is a phenomenon formally known as the "Lost in the Middle" effect. AI models have a strong positional bias, meaning their performance follows a U-shaped curve: they are highly accurate when relevant information is placed at the very beginning or end of a document, but struggle significantly with the middle. Unfortunately, this is a very nature of the current LLM models and there is not much we can do to change it.

At some level of specifications complexity, the quality of generated code becomes so poor that it is not worth time to do post-generation fixes. Therefore, it becomes faster and easier to throw everything out and re-write manually.

So, what is the solution? It is simple – generating only application scaffolding and/or base-level software primitives easily explainable to AI, while the rest continues to be completed incrementally, one prompt at a time. However, that approach defeats the whole purpose of AI. Developers are forced back to iterative AI-assisted text coding, as AI cannot follow spec without human guidance.

AI Brought Us Security Armageddon

AI reached level of sophistication when it can find vulnerabilities in open-source code in seconds, giving everyone an ability to easily find vulnerabilities and exploit them, whereas before it required high-level experts to do that. This situation becomes even more critical if we consider the fact that modern AI models are stochastic, meaning that if one person run model and found some bugs in certain codebase, another person running same model for the same codebase does not necessarily find same bugs (or any bugs at all). It means someone can accidentally find serious zero-day bugs no one else was able to detect.

The first solution is closing open-source projects. That might help for some time, but there is another way to search for vulnerabilities - dynamic probing of endpoints. AI can tremendously help to compose special requests for server probing. On the other hand, open-source brought significant benefits to software development community. Closing it does not solve the problem fundamentally while it would kill all benefits.

Another solution is speeding up process of software patching. This will quickly become a race between velocity of vulnerability discovery and the speed of software patching. The most likely outcome is that vulnerabilities will be discovered much faster than patching of corresponding bugs, because AI models are constantly improving while patching process has its limits. These limits are imposed by fundamental flaws in both phases of patching – detection and resolution.

Detection is mostly based on analyzing production logs. However, the information gets into the logs from the code and developers must explicitly add these log statements into the code. Today, it is a common practice to have logs statements added to code frequently from the beginning, but they are added only in specific places where developers see their importance. However, many other places are not covered. It means that detection does not see anything not present in logs because log statements were not added for such cases in source code. That makes detection blind in many aspects. To start logging new information, the process assumes full redeployment after adding more log statements. If there is still more logging needed – another redeployment is needed, etc. This makes the process of adding new logs long and complex. This is especially critical for debugging process that often involves an exhausting and repeating cycle of adding/changing logs followed by redeployment when investigating a problem.

Another aspect of patching is resolution – preparing and applying the fix. The first question is how the vulnerable system is going to work while the team is waiting for the patch. Does it need to be brought down or kept online in hope nobody will not exploit this vulnerability while the fix is on its way? In first case, the business might suffer due to limited or disabled functionality. The second case involves risks that exploiting the vulnerability by a malicious third-party might result in real data theft or loss.

Another possible solution is hardening security of open-source libraries. For example, IBM and Red Hat announced Project Lightwell and committed $5B to secure software supply chain. That will improve their protection. However, will they be able to match the speed of vulnerability discoveries and the fact that certain zero-day bugs might be accidentally found just one time during “lucky” AI code analysis rerun nobody else can rediscover? Also, what about mostly domain-specific private and limited distribution libraries? What about vulnerabilities in business logic layer on top of common libraries, especially closed-source code? There are many questions, and Project Lightwell does not provide answers to many of them.

The conclusion of this analysis is that we need more fundamental and long-term solution to these problems brought by AI.

Root Causes of These Problems

Before we dive into the solution, let’s try to identify root causes of the specified problems.

Problems of source code control loss and AI failure to follow complex requirements have the same root cause – the human limits in comprehension of text information. In first case, developers are overloaded with huge amount of text code they need to review. In second case, they need to come back to text-based coding due to LLM-based AI flaws in understanding documents and following its guidelines.

The root cause of limited detection and resolution capabilities is low granularity of modern software. It means that we deploy software in large modules: adding new logs and replacing compromised code both require redeployment of the whole module. There are attempts to increase granularity of software – for example, via plugins or microservices. However, all attempts to split software to smaller components resulted in sharp increase in overall complexity of managing the entangled graph of component interactions. For example, many companies concluded that microservice architecture is too complex for their projects that might easily be re-implemented as a monolith as a much cheaper alternative in terms of software complexity management.

Why do we need high granularity? This is because we can get direct access to a single small component that we can fix, update, isolate, measure or debug in-place at runtime, instead of going full long cycle of adding logs or updating a compromised component followed by redeploying the whole module.

Three problems AI created for software engineering and why visual programming languages are the solution.

Why Visual Programming Is the Solution

There is a technology that provides both the best human comprehension and maximum granularity – visual programming. Visual representation is a clear winner comparing to text and that makes logic perception much easier for human brain.

Maximum granularity provides multiple benefits:

• In-place component fixing, update or isolation at runtime – every visual block is directly accessible during execution, meaning a compromised or underperforming component can be fixed, updated, or isolated in production without recompilation or redeployment.
• Dynamic telemetry collection by connecting to inputs/outputs in real-time without the need to add logs into source code and redeployment – any block can be probed directly at runtime by connecting to its inputs and outputs, eliminating the need to add log statements to source code and redeploy just to start collecting new diagnostic data.
• Painless debugging by direct probing of any component at runtime – debugging becomes trivial as every block can be interrogated directly at runtime, replacing the exhausting cycle of adding logs, redeploying, and inferring what happened with direct observation of what is actually going on.

Some of these benefits allow almost instant reaction to attempts to breach security, especially if application self-healing engine is involved in the process of collecting telemetry and reaction to application security breaches. In fact, visual programming is the perfect match with self-healing engine that can react on threats instantly. Text-based application forces self-healing engine to wait for a full cycle of source code fix and CI/CD redeployment, making it impossible to react to threats in real time.

The next question is what specific visual programming language we can use. There is the wide selection of them: LabVIEW, Node RED, Simulink. However, all of them tend to shift in one direction: they are either simple but general-purpose or sophisticated but domain specific. We need a visual language that is both general-purpose and sophisticated, because this is the quality of all text-based language we intend to replace with visual diagrams. There is one such recently introduced visual language: Pipe (see pipelang.com). This is general-purpose visual programming language designed specifically to be able to replace text-based code.

Why Pipe Is The Best Candidate

Visual programming language Pipe implements multiple unique concepts that makes it a pretty sophisticated language. I will mention just some of them because they are relevant to the topic of this article.

Execution nodes of Pipe are called runlets, and each of them may contain other runlets inside. As a result, runlets compose tree-like structure with leaves containing text-based code. Such structure is ideal for gradual migration from text-based code to visual diagrams: code gradually recedes in tree leaves while Pipe runlet structure grows upwards, absorbing more and more logic from text-based code. Eventually, leaf nodes will contain only a thin layer of text code handling external intercommunication, while all business logic lives in the visual structure above. Pipe provides full formal API for integration with text-based languages as a part of language specification, making it possible to integrate Pipe with almost any text-based programming language.

Another relevant Pipe feature is designed to solve very painful problem of reconciling interfaces between different components. Pipe solution is providing binding model based on concept of domain – tree-like data structures similar to JSON. When output of one Pipe component is connected to input of another one, output and input generally have different assigned domains. To reconcile them, only data between domain tree nodes with common paths in both domains are transferred – this process is called domain overlap. Domain tree nodes on receiving end without match in domain from sending side take explicit or implicit default value. Overlap represents the case of extremely loose coupling while supporting data type safety: matching domain nodes must have compatible data types for domain connectivity to be valid.

Together, runlets and domains make Pipe uniquely suited for the post-AI era: runlets provide the granularity needed for runtime observability and surgical fixes, while domains ensure that the connections between components remain type-safe, auditable, and comprehensible to human reviewers.

Why High Granularity Works in Pipe But Not in Text Code

The obvious question is: if high granularity is so valuable, why did microservices and plugin architectures fail to deliver it without massive management overhead? There are three reasons why Pipe is different.

The first is topology. Microservices create an arbitrary dependency graph – any service can call any other, and as the system grows, this graph becomes impossible to reason about. Teams that went all-in on microservices often found themselves building expensive internal platforms just to manage the complexity, or quietly migrating back to monoliths. Pipe's runlet hierarchy is a tree between workflows – each composite runlet contains only its direct children, and you always work at one level at a time. The structure above and below stays out of the way.

But that raises an obvious follow-up: what about inside a single workflow? Connections between components within a diagram can form an arbitrary graph – and that is true. The difference is that you can see it. Every connection is drawn on the diagram in front of you. In a microservice system, understanding which services are talking to which requires log tracing, dependency maps, and usually a dedicated observability platform. In Pipe, the complexity is visible and bounded within a single diagram. You are never looking at the whole system at once – just the level you are working on.

The third is coupling. Classical APIs require both sides to agree on a shared contract. Change one side and you risk breaking every consumer. Pipe's domain overlap works differently – each component defines its own domain independently, and data flows only where those domains share compatible paths. Components can evolve without coordination. That is a qualitatively different kind of loose coupling, not just a variation on what microservices already do.

Conclusion

AI brought not only positive changes to software development industry, but also many new challenges. Their severity requires rethinking the whole approach of software development. Problem analysis points to visual programming as the best long-term solution. Visual programming language Pipe provides the best set of features for transitioning to new post-AI world.

The GUI revolution made computers accessible to everyone. Visual programming is the second half of that revolution – making the act of programming itself comprehensible, auditable, and secure by design. Pipe is being built to be that language. Learn more at pipelang.com.

🚀 Introducing LunaOS

After months of planning and development, I'm excited to share the vision behind LunaOS—a custom operating system being built entirely from the ground up.

This isn't another Linux distribution. The goal is to build every core layer ourselves, including:

• 🖥️ Custom Kernel
• ⚙️ Custom Init System
• 📦 Custom Package Manager
• 🧠 Local-First AI Integration
• 🎨 Modern Cyberpunk-Inspired Desktop Experience
• 🔒 Privacy-First Architecture
• ⚡ Performance-Focused Design

LunaOS is being built around a simple philosophy:

Own Every Layer.

Instead of relying on existing operating system foundations, we're exploring what a truly modern, AI-native operating system could look like—one designed for developers, creators, and power users from day one.

This is still the beginning, and I'll be sharing the journey publicly as LunaOS evolves.

I'd love to hear your thoughts and connect with others interested in operating systems, systems programming, kernels, AI, and open-source software.

#LunaOS #OperatingSystem #SystemsProgramming #KernelDevelopment #OpenSource #Linux #ArtificialIntelligence #LocalAI #SoftwareEngineering #SoftwareDevelopment #Developer #Programming #BuildInPublic #CyberSecurity #Innovation #TechStartup #ComputerScience #FutureOfComputing

A while back I shared uicraft, an open-source (MIT) design system I've been building. The idea isn't "another CSS component library" — it's a bridge: one JSON source of truth generates both a Figma library (a plugin with round-trip theme.json) and ready-to-ship CSS, so design and code stay in sync instead of drifting.

I just shipped a sizeable update — here's what changed:

🎨 Color, rebuilt from scratch
– split raw color scales from the semantic palette
– brand scale generates itself
– smoother gray ramp with readable mid-tones
– proper surface hierarchy in dark mode

🔤 Tokens
– on-color tokens per accent, so text on colored buttons no longer loses contrast
– full type scale
– size + spacing grid up to 96px

🛠 Figma plugin
– regenerated component structure with all states included

One deliberate design decision worth flagging: I keep the palette intentionally small. It's a restraint-by-design choice — the fewest colors that still cover the most cases — because in my experience palettes that grow a new color for every edge case eventually turn into a mush nobody can reason about. You may disagree with where I drew that line, and I'd genuinely like to hear it.

Unfortunately Reddit doesn't let me attach video and screenshots here, and there's honestly a lot more I'd love to show — so if you've got a few minutes, take a look at the project itself and tell me what you'd change. Especially on the palette philosophy and the spacing/naming side, which I still don't think anyone has fully solved. Repo and live demo: getuicraft.com

Figma Plugin: https://www.figma.com/community/plugin/1610343587499165100

Thank you for your attention, I will be happy to respond to your comments.

I've been building a component library (Vue 3, Tailwind v4, Headless UI) with a token-first theming approach, and I wanted a way to actually test how it holds up under different palettes when it's doing real work, not just rendering swatches.

So I built a playground. Edit any semantic token, or pick a preset, and the whole thing reskins live: not just isolated components, but full composed pages like a login screen, and a pricing page.

Playground: https://dlbcodes-playground.vercel.app/
Docs: https://my-design-system-beta.vercel.app/

How the theming is structured, since that's the part I'd most like to discuss:

Two token layers. A primitive palette feeds semantic tokens (--color-bg-surface, --color-text-primary, and so on). You theme by overriding the semantic layer, so "brand color" or "surface" is a single override, never a find-and-replace across components.

Pages are composed from the same components. The login and pricing pages are built entirely from the library's primitives (Panel, Field, Button, Disclosure). The playground's own customizer UI is too.

Runtime CSS variables. Overrides apply instantly with no rebuild, which is what makes the live reskin possible and keeps theming out of the JS layer.

I'll be upfront about where it's at: the component set is still maturing (no Table or dark mode yet), and the API will move between versions. Not pitching it as production ready.

What I'd genuinely like feedback on:

Does the two-layer approach (override semantic, leave primitives alone) match how you'd architect theming, or would you structure it differently?

When you build real pages from a design system, what makes components feel like they compose well versus fight you?

Anything in the playground that breaks or looks wrong under a custom palette?

Last thing, low stakes: it's currently called my-design-system, which is a placeholder. If anyone has a name that isn't terrible, I'm listening.

Tried the free Figma MCPs out there to redesign part of my portfolio

It was nice being able to quickly explore different layouts, colors, and themes instead of getting stuck on the first idea. Ended up testing a bunch of variations before settling on the current design.

The MCP I finally used was my own lol AI Connect MCP and i'll tell you the reason. One thing I noticed was that existing Figma MCPs generated a lot of small tool calls, so I added a batch update operation that sends an entire design update in a single call. It reduced token usage quite a bit and made the workflow feel much smoother.

Still a work in progress, but I'm pretty happy with how it's turning out. I'll share the portfolio later. Will share MCP codebase in the comments.

To be clear, the aim is not to promote my mcp or something, sharing if it helps someone as it did for me. The source is open anyways.

Pic 1 & 2 are websites and Pic 3 & 4 are on figma.

The work for real designers cannot be replaced by an MCP but for casual development this helps.

A few months ago, I became convinced that Design Systems would need to become easier for machines to understand.

I started auditing my DS manually.

Component by component.
Variant by variant.
Description by description.

At first it was useful. Then it became painfully time-consuming.

I realized I was spending more time collecting information than improving the system itself.

So I built a tool for myself.

The idea was simple: Export a Design System once, then generate an audit covering things like:

• naming consistency
• component structure
• variants
• documentation coverage
• descriptions

That project eventually became System Lens.

I'm now looking for Design System teams willing to test it.

In exchange, I'll provide a free audit report pdf and would love honest feedback on:

• whether the findings are useful
• what feels missing
• what would make the tool genuinely valuable

If you're responsible for a Design System and would be interested in trying it, I'd love to hear from you.

I've been working on a Figma plugin called Spool DS, and I'm at the stage where I'd really value some outside eyes on it.

What it does: you give it a handful of core colour roles and it generates a full design token system for you. Colour variables with proper OKLCH ramps, transparency ladders, text styles, and sizing tokens. There's a review step at the end so you can see and adjust everything before it writes anything into your file. The idea is to save the hours you'd normally spend building out ramps and naming variables by hand.

It's completely free, published on the Figma Community: https://www.figma.com/community/plugin/1642485097589548816

If a few of you could try it on a real or throwaway file, I'd be grateful for any thoughts on:

• anything that felt confusing or unclear
• whether the output is something you'd actually use
• tokens or naming you'd expect that aren't there

I'm still learning and just trying to make it genuinely useful, so any advice is welcome. Thanks so much to anyone who gives it a go.