- I plan everything in ChatGPT. I provide project trees and create an execution plan for Claude Code, Codex, or Copilot agents. - I clearly say I do not want the agent to explain what it will do or what it did. I only want "I finished". That saves extra tokens. My projects include tools to gather file contents in bulk. A single command like bun copy-paste FILES=" " lets the agent collect many files into one file. - I also provide a bun create-empty-files command so the agent can create all needed files at once instead of one by one.

With this setup, I managed to build 4 major features (more than 80 file edits or creations) using the 3 daily resets on a standard plan.

You can have a nice component with all the cases, type-safe, and apply few utility classes to produce more maintainable code.

What happens if that well-paid engineer decides they no longer enjoy software development? What if they need more than a year to deliver results? What if they produce something useless for the market?

This Keynesian approach is full of unknowns—it looks great on paper, but we've already run these experiments in the past, and they simply didn’t work.

"At first blush a utility class system might seem like a boon to a design system, but when applied to the markup we quickly see the problems: being unable to represent components easily in markup leads to a design system looking for other solutions such as providing markup with attached class names to represent a component - which usually results in the design system implementing components across a multitude of frameworks."

In this era of component frameworks, looking at HTML and its classes is the least of our problems. Our real challenge is to build an additional architecture on both the component side and the CSS side. Additionally, both components and CSS can have (or end up with) more than just styles; they can include behavior, animation, and effects, which adds complexity, making the entire project difficult to memorize, scale, and maintain. OOCSS projects often result in unmaintainable code, with developers ending up with large CSS files and creating more specific classes to implement new features. FCSS (Functional CSS, or Atomic CSS as exemplified here) solves this problem by separating concerns and removing the mental load from the equation.

The problem with Atomic CSS, Tailwind and others I just the syntax. It takes time to master Tailwind toolset of classes. At first it may seems easy and intuitive but it’s deceiving. FCSS has natural language https://www.fcss.club/syntax and it’s hundreds of times more intuitive.

The only real issue of FCSS or Tailwind is achieve inheritance only using CSS inheritance model. Let me give you an example:

.color—blue { … }\ .color—red { … }

In this situation, you might expect the text to be blue, but it will actually be red due to inheritance weight. This issue can be resolved on the component side easily with JavaScript https://www.fcss.club/customization, providing a more controlled solution.

“There are a plethora of other issues with the Utility CSS methodology, and with it a plethora of articles. If you consider this a suitable solution, I'd encourage you to invest time researching the pitfalls, but I don't want to spend too long on this."

I’ve been reading dozens of articles regarding the atomic approach and I didn’t find any phletora of issues. The only thing I found was a bunch of arguments in favour of OOCSS, all of them listed here. https://www.minid.net/2019/8/12/in-defense-of-functional-css