Thread

1. nullbio · 1789977454 · focus · HN ↗

   I think a great use case for these will be when they have large context windows and are able to enforce styling rules for frontend development, and component creation rules for react. You can then ditch the styles guides and styling skills and create a decision tree for enforcing styling, so that you can't run into drift issues or duplication issues. That's where I'm wasting most of my time right now, constantly correcting all of the UX/UI issues that are created for every single feature.

   1. spockz · 1789980870 · focus · HN ↗

      Back in the good old days we would prevent these ux/ui issues by rigorously enforcing the use of our own stylesheets and classes. Later that grew to only using the company ux components. This was very successful in keeping everything neat and tidy. The only drawback was creating and curating new elements and getting consensus. But otherwise it works wonders.

      Try constructing reusable components out of what you are doing instead of building everything up from basic building blocks. This also allows more concrete testing of individual parts and then if you want to change the look you can change it in one place and have it apply everywhere.

      Agentic development doesn’t mean “throw all what we learned out of the window”, the same practices that helped speed up and improve quality of work of humans also helps agents. In fact, the multiplier is even bigger. You will notice it in development speed and reduced cost due to avoiding churn.

      1. nullbio · 1789994008 · focus · HN ↗

         I use reusable components but the issue is that the model rarely checks to see if a component already exists. Or it will use the wrong one. Or if the component strays from the reusable component it doesn't extend it in a generalized way and will special case inline styles, or it'll create a new component. Rarely does it intelligently figure out the correct course of action.

         I've also built up a suite of linter rules to catch the same mistakes the model makes over and over. Still, there are a lot of gaps. I think it's mostly because my codebase is massive at this point. It was easy when the codebase was small and didn't require context gathering to make good decisions.

         1. spockz · 1790003040 · focus · HN ↗

            Start by adding more descriptions to the help and documentation docs of the components. Create an index. Forbid the llm to use any other component than on that list. Let another llm review the work. Forbid it to make custom html.

            Then every time it tries to do so ask it why it didn’t use one of the ones from the list. Update the list with more ifthenusethis texts. Also negatives, if such then use y instead.

Unofficial Hacker News client; not affiliated with Y Combinator.