I build a lot of side projects with AI coding tools. Mostly Claude Code. A few months ago I noticed something that kept bugging me. Every site I sh...
For further actions, you may consider blocking this person and/or reporting abuse
"When you don't give a model a design direction, it picks the average of the internet." That sentence explains a pattern I couldn't name until now.
I'm a non-developer building internal tools for a hospital with AI, and every screen I ship carries a house style — one font (Pretendard, since it's Korean), one blue, sidebar-plus-topbar, light/dark. It wasn't a taste decision at first, honestly; it was self-defense. Left to its own averages, the AI gave me a slightly different-looking app every single time, and 20-something tools that each look like a different company is its own kind of broken for the people who have to use all of them daily. Locking the constraints upfront didn't just make them prettier — it made them feel like one system, which for internal software matters more than beauty.
Your "constraints make AI output better, not worse" is the counterintuitive core, and I'd push it one step further: the constraint also makes the AI faster. Once the palette and layout are fixed, the model stops re-litigating them on every screen and spends its effort on the actual logic. I didn't plan that; I just noticed the builds got quicker once I stopped leaving design open.
And the 40%-wrong-eyeballs line is the real gift here. I've been approving contrast by eye like an amateur. Handing that judgment to a WCAG script — a thing that doesn't have a bad day or a favorite color — is exactly the "let something without feelings check it" discipline I keep re-learning everywhere else. Adding that check to my own house style this week.
Great to know that you are putting the effort into doing all this. I used to do all these manually as well. Used to define my pallet and the storyline and when building a focused product, that is really necessary. But there are a lot of people who are still shipping sites which looks like ai-slops and they don't know how to really improve them. So, I built these skill using all the things I learned from my experience so, that everyone can create professional sites from the getgo instead of building their own branding or color pallet from the beginning.
Again thanks a lot for checking this out. Hope you can try this out, would love to know your feedback regarding this skill and ways to improve this.
Your mission is the part I connect with most — "professional from the get-go instead of building branding from scratch." I build internal tools for a hospital as a non-developer, and I've watched capable coworkers ship things that work perfectly and look like ai-slop, then have no idea why it feels off or how to fix it. Taste is the invisible tax on people who were never taught it, and packaging it into something installable is genuinely useful work.
Here's the concrete thing I owe you: your "my eyeballs were wrong 40% of the time, the script was right every time" line didn't just resonate — it made me go build the thing. Today I wrote a small WCAG contrast checker and ran my whole house palette through it. The surprise matched yours exactly: the parts I'd fussed over (status badges) were fine, and a link color I'd approved by eye months ago was sitting at 3.44:1 — quietly failing, invisibly, the whole time. I'd never have caught it by looking. That one paragraph of yours paid for itself the same afternoon I read it.
I'll try Tastemaker and send real feedback. One honest note up front on where my case might bend it: my work is Korean-language internal apps — Pretendard font, dark/light, a sidebar-plus-topbar app shell — rather than marketing sites. So I'm curious how much of the palette/font/motion locking survives that context versus how much quietly assumes a landing-page shape. That's exactly the edge worth reporting back on: a tool meeting a use case its author didn't build for is where the most useful feedback usually lives.
This feedback is really helpful. One major thing to add in my skill is multiple language support. Thanks for this idea. Will keep the other ideas in mind as well.
Thanks a lot for sharing this again, hope you find the skill useful.
That's the one I'd have picked too. One thing that might save you time when you get to it: CJK (Korean/Japanese/Chinese) isn't just "swap the font" — the whole pairing logic shifts. Latin design leans on pairing a display font with a body font, but Korean UI usually rides a single well-built family across all weights (Pretendard is the go-to) because mixing families reads as messy in Hangul. Weight rendering and letter-spacing behave differently too. So the taste-lock for CJK might be less "font pairing" and more "one family, locked weights, correct line-breaking" — the same idea in a different shape. Happy to be your test case whenever you want eyes on the Korean side.
Woahh thanks for the insights. These are really helpful and interesting. Will definitely make my updates accordingly and it will be great, if you could test it out.
Appreciate your comment.
It's a cool thing, but your installation path didn't work, and one off your images are broken. However, here's what I built with it :)
I added it as a skill to Magic Cloud, and the system did the rest. Impressive ^_^
Wow, this really looks good. I have updated the site with each and everything. I am sure that it will work now.
Thanks a lot for using it. Hope you find it useful.
Loved it, feel free to play with my stuff too ==> github.com/polterguy/magic
yeah definitely will check it out
Psst ... ;)
10 minutes worth of work with Claude and Magic Cloud, connected over MCP, using your skill 😇
My prompt; "I want you to use the Magic connector and create a new app named "crm5". I need a database with 3 tables, CRUD web API, the ability to send emails to contacts, and a kick ass modern designed frontend at "crm5". Use the "magic auth" workflow and only allow users belonging to the role "guest" to invoke the API."
The system created my database, API endpoints, secured them, the frontend, etc. Then when done, it used the headless browser to verify everything is 100% perfectly working, even did a couple of "intrusion attempts" to bypass the authorization requirements (no security holes).
The system allows you to do CRUD towards your contacts, contains a pipeline, and the ability to send emails to individual contacts.
This looks so clean. I really love what you have built here. If you could share a link of your product that you have built, I would definitely love to showcase it on my site.
Locking the palette, font pairing, assets, logo, and motion rules before UI code turns "taste" into an interface contract instead of a vague preference. The contrast check is the strongest engineering detail here: two of five presets looked fine by eye but failed WCAG, which shows why visual systems need automated constraints as well as judgment. For a solo builder, this also creates a cheap review surface-before polishing components, you can ask whether the page still obeys the chosen system or has quietly drifted back toward the default indigo template.
Yes Marcus exactly. Instead of starting from the default purple gradient website, this skill give you a great starting point and builds your site with the best practices built in. After that point everyone can alter the sites according to their own taste.
The WCAG story is doing more work than you think, and it actually undercuts the "5 presets" framing. Contrast ratio is pairwise — text-on-background, border-on-fill, disabled-on-surface. A preset that passes for your locked heading-on-hero can still fail the moment the model uses one of your palette colors as a badge background with white text, which it will, because you handed it a palette and no contract for how each color gets used. You checked the combinations you designed; the AI improvises combinations you didn't.
So the durable version of this isn't "5 presets that passed once." It's shipping the contrast check as a token-level constraint the model has to satisfy for every new pairing it invents — semantic roles (text, muted, accent-on-accent) with required ratios attached, not just hex values that happened to test clean. Otherwise you've moved the indecision from "what colors" to "which of these five approved colors can touch which," and the model is back to guessing on the part that actually breaks readability.
The broader point I'd pull out: your eyeballs weren't wrong because taste is subjective — they were wrong because contrast is a computation your eyes don't run. Those are different failures, and only the second one generalizes into a script.
Thanks for your feedbacks, really appreciate it.
And yes the model has the 5 pallets at disposal but its not bound by it and i have given the skill the ability to actually do a contrast test based on WCAG on every iteration so, that whenever a site is generated, it actually tests the score and modify it accordingly. Setting the presets of which color goes where might limit the creativity of the agent and be more restrictive. Bt definitely more improvements can be done here.
One point that really stands out is that AI doesn't eliminate the need for architectural thinking, it actually makes it more valuable. At IT Path Solutions, we've seen that when teams invest time in defining architecture, constraints, and success criteria upfront, AI-assisted development becomes far more predictable, maintainable, and scalable.
Yeah, I completely agree with this. If you put more context into what you are building and what you are doing, it will always be much, much better at what AI does. And the more context you give in, the more data that you give it, the more directional and refined output you will get.
The detail that sticks with me is 2 of 5 palettes failing your own contrast checker. It captures something I keep running into with AI generated interfaces, my own eye is a worse judge than a script that takes five seconds to run, yet I default to trusting the eye because it feels like taste. What I have found works is treating constraints like yours as gates rather than guidelines, so the agent cannot proceed past a failed check instead of me catching it later in review. Curious whether Tastemaker enforces the WCAG check automatically or if that is still a manual step you run after generation.
Glad you find it relatable. It's completely automatic, you don't need to do any manual prompting or anything. From the get-go, it will check the WCAG.
After this post, I have made a lot of updates. Now, instead of five presets, it will automatically generate a color palette that will suit your brand the most. All the color palettes that are generated are perfect score, and it will look great on your brand. Hope you check this out, and let me know if you have any feedback.
This hits the spot so well. The generic indigo gradient with rounded cards has definitely become the official signature look of AI-generated web apps lately.
When building client-facing platforms in custom software development services, setting strict design systems, color tokens, and accessibility constraints upfront is essential before writing a single line of code. Letting an AI model improvise design choices always leads to that average internet look.
Testing contrast ratios programmatically was a smart move too. Automated accessibility checks save so much time compared to trusting visual judgment alone.
Really cool project, thanks for making it open source!
Thanks a lot for the appreciation. And yes, the problem that you have faced, I have faced the same problem too. Maybe that is one of the reasons why I made this project open source, because I believe that everybody should have this for free, so that they could create a site that is truly professional and can be worth sharing without paying any money.
This hits the nail on the head! The "average of the internet" design bias is so real almost every AI starter kit right now defaults to that same indigo gradient and standard Tailwind card style.
Your takeaway about scripts beating eyeballs (the 40% failure rate on WCAG contrast) really resonated with me. While building Synctoolo (a suite of 25+ free browser-based developer and AI utilities), I constantly ran into the challenge of keeping the UI clean, readable, and fast without falling into the "AI-slop" aesthetic. Having an automated gatekeeper for contrast and design tokens before writing code is such a smart move.
Great open-source contribution! Definitely starring the repo to test out the WCAG automation in my own workflow.
Thanks a lot for the appreciation, and thanks a lot for the star. I am constantly making a lot of updates. Hope you check the new one out, and let me know what you think.
The WCAG part is what makes this more than a style preference.
Taste can get you close, but checks make it reusable and safe. A palette that looks good but fails contrast is not a design system yet, it is just a vibe with unreadable text.
Yep, absolutely. And after the post, I have made a lot of updates. Now instead of five presets, you get a lot more.
Now the skill will generate a specific color palette based on your brand. Every site would look much cleaner and professional.
I hope you use the skill and make good use of it. Literally, share any feedback that you have
As a backend dev, I just have to say frontend is such a beast and design is harder than it looks. and yes, everything DOES look the same nowadays. Even taste is no longer original.
Yes, absolutely. That's why I have built this site.
As a backend developer, I hope you can use this skill and make your frontend look much, much better. To be very honest, I am a backend developer too, so I really know the pain of building a good frontend. But with this skill, I believe it will really help you in doing that.
looks cool
Thanks a lot for the appreciation. I hope you can use this, and let me know of any feedback that could make this better.
So no more 'cyberpunk glassmorphic', that's a relief 😂
yes no more cyberpunk glassmorphic 😅
only premium sites
Great Post!
Thanks a lot for the appreciation
The fourth lesson about design debt starting at line one is the one that catches teams in practice. There is a second drift point worth planning around in Tailwind setups specifically: even with palette tokens locked in the config, the model reaches for arbitrary bracket values the moment it is uncertain. Locked tokens stop drift at the configuration boundary but not inside component files, because AI can generate a class with an inline hex value and the design system has no signal that the lock was bypassed. Grepping for bracket patterns before any generated file merges is the lightweight gate we added. Does tastemaker catch those or does it only enforce at the token definition layer?
The 40 percent story is the actual argument, and it reaches past taste. Your eyes were a judgment you could bargain with. The script was a check that runs at a fixed point and does not care how confident you felt. Writing the preference down is what converted the first thing into the second. That is the whole move, and it is the same one whether the domain is color or anything else you would rather improvise: a locked decision is not better because your taste is good, it is better because it stops being negotiable.
Where I would push, building on wrencalloway's pairwise point rather than repeating it: the check ran on the combinations you thought to enumerate, at the moment you authored them. Contrast is combinatorial in space, which is his point, but the lock is also a write-time artifact in time. The five presets pass today. The day someone adds a semantic color, or uses a locked hex in a pairing the original run never listed, the lock still reports green while the new combination fails, because nothing re-fires the check on the extension. The lock certifies the palette as authored, not the palette as used.
So the reusable thing you built is not the locked system, it is the runnable check. The value holds only as long as the check keeps firing every time the system grows past what it originally covered. Otherwise the locked palette becomes its own quiet average, one person's taste frozen at authoring time, drifting out of true exactly the way the indigo gradient did, just slower and with better fonts.
@codeswithroh If you've already got a WCAG check running on every iteration and the model modifies until it passes, then you've actually built the durable version — the contract lives in the check, not in the presets. That's the part that generalizes, so you're in good shape.
On the creativity worry, I'd push back a little: attaching required ratios to semantic roles doesn't tell the model which colors to use, it only tells it which ratio a given pairing has to clear. Accent-on-accent needs 3:1, body text needs 4.5:1 — the model still picks freely, it just can't pick something unreadable. That's less "restricting creativity" and more "defining the goalposts," and honestly a runtime check that regenerates until it passes is doing the same job as roles-with-ratios, just at a different point in the pipeline.
The one thing I'd watch with the iterate-until-it-passes approach is how it fails — when the model can't satisfy the check, does it degrade the design gracefully or just keep flailing on the same pairing? That's usually where the interesting bugs hide.