The only changes I see are colors but what if I want eg a different border radius on buttons or margin on labels or specific fonts on elements etc? I don’t find changing only the colors of components particularly valuable but would like to see more variance in the actual shapes and looks of things.
Global border radius is editable, that setting is at the bottom of the sidebar. The challenge with global shadcn theming is that you're limited to adjusting the css variables they provide. I believe there is a global spacing variable, but it is not so specific that you can target e.g. just label spacing. That would be something you could modify directly within your shadcn input components via adjusting the tailwind class(es).
I can't say as I'm not familiar with Preact signals, but I do know the Angular team brought on the author of SolidJS to implement signals in Angular. Though I think I remember reading at some point that Preact signals were essentially directly ported from SolidJS, so they're likely similar if nothing else. (Someone correct me if I'm wrong)
Neither of those things are true to my knowledge... I can find absolutely no evidence of Ryan Carniato being involved with Angular Signals (nor did I hear anything whilst they were being developed) and Preact Signals certainly weren't a port of Solid. Same name but internals share nothing and if anything, Preact's signals most closely resemble Vue's refs in API (though completely different internals -- there was no porting).
You don't have to do anything. But as you say, they are the one in the position of power. If you are working on some side quest they don't see as valuable, it may not end well for you. Doubly so if you are shirking what they see as a high value task for your side quest.
It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")
Hey kentonv, this looks really neat. How would you go about writing API documentation for something like this? I really like writing up OpenAPI YAML documents for consumers of APIs I write so that any time someone asks a question, "How do I get XYZ?" I can just point them to e.g. the SwaggerUI. But I'm struggling to understand how that would work here.
For public-facing APIs, I would strongly recommend writing the TypeScript interfaces in a separate file from any implementation, and using JSDoc comments. There are various documentation generators that can turn that into a web page, though personally as a user I tend to prefer to just look at the actual TS file.
The agent I’m developing is designed to improve or expand upon "old codebases." While many agents can generate code from scratch, the real challenge lies in enhancing legacy code without breaking anything.
This is the problem I’m tackling, and so far, the approach has been effective. It's simple enough for anyone to use: the agent makes a commit, and you can either undo, squash, or amend it through the Git UI.
The issue is that developers often skip reviewing the code properly. To counter that, I’m considering shifting to a hunk-by-hunk review process, where each change is reviewed individually. Once the review is complete, the agent would commit the code.
The concept is simple, but the fun lies in the implementation details—like integrating existing CLI tools without giving the agent full shell access, unlike other agents.
What excites me most is the idea of letting 2–3 agents compete, collaborate, and interpret outputs to solve problems and "fight" to find the best solution.
That’s where the real fun is.
Think of it as surgeons scalpel approach rather than "steam roller" approach most agents take.
