Open up Twitter/X for 10 seconds and you’ll see a half dozen folks bragging on their new “command centers” for their business. They’ll show off a screenshot or two of a data dashboard that is pure AI slop. Overexplained text everywhere, weird color highlighting, and the occasional made up data point. It’s no good, and I think it’s time we hold our vibecoded dashboards to a higher standard.
I’m not saying that you should use Tableau or code the dashboard yourself. What is this, 2023? Stick with your AI of choice. For me, it’s Claude. I still find that Claude does the best with dashboard designs still (even with OpenAI’s Astra tearing up the benchmarks).
So here’s the three most critical tips to keeping Claude on task and helping you design the dashboard of your dreams.
1. Use the best models, and use them right
Everyone is tempted to drop their model selector down to Sonnet or GPT 5.6 Terra, but don’t. A data dashboard, especially one you’re planning on using for critical business information communication, is worthy of pulling out the big guns. I don’t build any of my dashboards with anything lower than Opus, and ideally you’d be willing to throw Fable or GPT-6 at it.
That’s not to say the weaker models are bad at dashboards. They’re alright. But I find I can’t rely on them to get the data right. Fable- and Astra-tier models are really good at validating data, which helps bring hallucinations in these kind of builds down near zero (but please, please still be checking your data points for accuracy before sending it off to the boss with a promotion request). In general, this is due to the greater intelligence of these models, but its also a benefit of their harnesses. Beefier models are more prone to use deterministic scripts to run the data analysis and check the data instead of relying on their internal reasoning. Smaller models make that mistake more often.
Basically, the more agentic the model is the better it is at data analysis and building out data dashboards.
If I’ve got credits to spare, I’ll even turn on modes like Ultracode for these types of tasks. These types of harnesses have baked in validation steps that go back over the data multiple times to ensure that everything is correct.
2. Iterate on the design (don’t just set it and forget it)
I see this issue a lot outside of dashboard design as well. Frontend vibecoders have a tendency to have Claude or ChatGPT generate everything and then just immediately publish it live. This is a mistake. This isn’t something you should even do with human design, let alone AI. You need to serve as the overseer of the design and ensure it looks great before shipping it out. If you don’t have design skills, or have a bad eye at this stuff, then you may be doomed to ugly designs anyways. But if you’ve got a knack for design (or are willing to learn!) and work with the model, this iterative step is crucial.
Once the initial design is out, just sit with the model and go back-and-forth and tweak every little thing. Here are the biggest things to look out for:
Too much text
Even the smarter models like Opus are prone to overexplaining and generating tons of words that just don’t need to be there. Show rather than tell. Cut down on unnecessary subtitles and explanation subtext.
Weird AI design quirks
You may know what I’m talking about. There are certain designs that you can look at and tell it was AI generated immediately. Soft purple glows, weird left side color highlights on dashboard cards, you know the vibe. Work with the model to remove these, and even better, try and put some of your own flair in there with unique design traits. Get creative.
Build the dashboard to your audience
This is more UX. It doesn’t matter how fancy your dashboard looks if its built in a way that falls completely flat in front of the intended audience. If you’re building a dashboard for your C-suite boss, he doesn’t need to know or see the nitty gritty technical datapoints. Make sure you frontload the dashboard with some strong KPI’s that really speak to who you intend the audience to be. You can always add the more technical and detailed data into a little drop-down at the bottom of the dashboard. Less is more.
You can also read this on the Handy AI Substack.
Once you’ve landed on a look you actually like, don’t make yourself re-explain it every session. Write the rules down (“Please no left side highlights, use this font, this one accent color for the KPI that matters, no subtitles under the cards,” etc) in a CLAUDE.md or a skill file in the project folder. Every dashboard after this one will then start from your taste instead of the model’s, and you can spend the back-and-forth time on new stuff rather than re-fighting the same three battles.
3. Source the right data
This one will look pretty different depending on what you’re building. The data needs for a personal workout stats dashboard is very different from the data needs for corporate’s next big marketing push.
The rule underneath both is the same, though. The model should never be the source of the numbers; it should be the thing that fetches, cleans, and charts the numbers from somewhere trustworthy. Those made up data points I mentioned at the top almost always come from someone pasting a screenshot of a spreadsheet into the chat and asking for a dashboard. The model grabs the image, guesses at a few cells, and then confidently builds a (really nice looking) chart around a number that doesn’t even exist.
Give it the actual file. Better yet, give it the actual database.
Giving it your data
For the personal stuff, that just means export everything. Strava, Apple Health, Whoop, your bank (be careful here), etc, all have CSV export options in the settings (Strava’s export takes about a minute). Grab the file, drop it into a project folder, and tell Claude to write a script that parses it. In general with data work, the more you can convince the models to utilize scripts the better, and they’ll rely on the tools to validate the data instead of their error prone assumptions.
Keep the raw export sitting in the project, no need to delete it. That way every time you tweak the design, the numbers get rebuilt from the source instead of from whatever the model remembers from three prompts ago.
Giving it your database
For the business stuff, skip the export entirely and connect the model straight to the source. Claude Code and Codex talk to Postgres, Google Sheets, HubSpot, and just about anything else with an API through MCP now. Database providers like Supabase even have official Claude connectors that you can turn on in a couple clicks. Slapping on a connector and throwing Fable onto Ultracode results in hallucination-free, beautiful dashboards that you can iterate on within a few minutes. No copy paste step means less chance for human errors (don’t forget about those!).
Also: make the model show its work. Ask for the query or the script that produced every datapoint on the page and tuck it into that drop-down at the bottom of the dashboard I mentioned earlier. When Mr. Manager asks where a number came from (as a good boss should), you’ll have an answer instead of a blank stare.
Connectors and live data MCPs also help immensely with data freshness (which, hopefully, is important for your job). A dashboard built off a one time export is stale, forever. If you or your boss are going to look at this thing weekly, wire it up to a live source. If that’s not an option, automate that data export step from earlier and have the model load in new data on a schedule. If you stick to refreshing it by hand, it won’t get done.
Select any passage to give it a thumbs up or down. Humans and agents both welcome.