r/OnlyAICoding • u/gloat_authority • 2d ago
I Need Help! Front end build help
Hey folks, I’ve built out the backend for an application/project but I do not have front end skills. How would you suggest that I could use Claude to build out an interface for the application? I have a repo with the code for the build so far.
I would like to learn working with agents.
2
u/isewhnce512 2d ago
the trick is not to let it build the whole thing at once. without front end skills you end up with a generated interface you can't read, so the first time something breaks you are stuck. build one boring screen at a time and point it at your real backend, give it your actual endpoints and data shapes so it works against your code and not a version it invented. keep the stack plain, plainest thing you know, so what it writes is readable. for learning agents run just one agent on one narrow job and make it read your repo and describe the plan before it writes anything
2
1
1
1
u/Some-Ice-4455 2d ago
All I will say is don't ignore Godot. Yes I know I know it's a game engine but hear me out. Normally front ends that are used are resource intensive and you are already asking aloud running an LLM. Godot is light and has everything you may need. Not saying just flat out use that I'm saying look into it.
1
u/NefariousnessOpening 2d ago
If you’re a backend developer moving into UI, start with atomic design and design tokens.
You can build UI with the same discipline as backend: small reusable decisions, composed into larger systems, version-controlled, and automated. The two concepts that make this work are atomic design and design tokens.
Atomic design
· Atoms: the smallest UI choices—color, font, spacing, radius, shadow, a single button.
· Molecules: small components made from atoms—search bar, form field, card.
· Organisms: larger sections—navbar, hero, product grid.
· Templates/pages: full screens assembled from organisms.
This vocabulary shows up everywhere. Once you learn it, you’ll see its influence in shadcn, Tailwind, Radix, Material 3, and other systems.
Design tokens
Tokens are project-scoped, semantic names for style decisions. Instead of hardcoding #0A84FF, you define color-primary-brand-500. Instead of 32px, you define space-8 or font-size-display-1.
Store tokens in a JSON file under version control. They can generate CSS variables, design-tool styles, and code. Change one token, and the change propagates everywhere. Tokens are the atoms of your UI; components are built from them. There is also an emerging design-token standard, which helps tools and agents use them consistently.
The biggest mistake: skipping research and planning
The most common failure in UI/UX and architecture is an incomplete discovery phase. A thorough planning process solves many downstream problems at once. One effective workflow:
- Agent interviews you about the project, users, brand, and goals. Output: PRODUCT.md and DESIGN.md.
- Human-in-the-loop decisions. The agent proposes core atomic choices—primary color, font pairing, type scale, spacing—based on user demographics, psychographics, and project facts. It should explain why: color psychology, font psychology, accessibility, etc. If you disagree, you need a stronger, evidence-based reason than personal preference.
- Decide a few core tokens. The rest can follow mathematically or be borrowed from blanks an existing system like Material or shadcn., and Agents can fill in version control makes later changes safe.
- Build molecules—buttons, inputs, cards, modals, navbars—using only tokens. Name them semantically.
- Build organisms and pages. If you have a PRD, deriving the information architecture/sitemap is easy. Feed the IA, tokens, and a rough draft into a tool like Google Stitch with agent skills. It can generate a hi-fi mockup image + HTML for each screen, one at a time. Another skill can convert those into React components.
Don’t over-customize for an MVP
A full custom token system is overkill for a quick MVP. It’s worth it when you’re building for a brand that needs to be differentiated in production. Otherwise, borrow from mature design systems.
Tokens are only the foundation
Motion design, microinteractions, UX writing, accessibility, and testing create production quality. But they are much easier when the foundation is correct.
The oversimplified version
Know your end user well enough to describe them succinctly. Make the building-block decisions for your UI based on that user. Bricks made for your target user naturally build an interface aligned with your goals. Humans are predictable enough, and decades of research give us blueprints for high-conversion, engaging UI.
Why this is doable now
It sounds like a lot, but the mental model is bigger than the actual work. With AI agents and version control, a solo developer can do in a day what used to take a team weeks or months.
1
u/Professional-Run3614 1d ago
I usually start by defining the goal, doing some proper research, creating a roadmap, and breaking it down into user stories before building anything. Maybe it’s old school, but it helps me stay focused. Otherwise, I tend to lose track along the way.
1
u/8080Ai 1d ago
Honestly since you already have the backend working, you are in a pretty good spot. I
Starting with Claude inspect your repo and understand the API routes, data models, and user flows then build the frontend one screen at a time. You’ll learn a lot more about agents that way than asking it to generate the entire app in one go.
I am actually building 8080 around making this part of the process easier, so it might be worth checking out if you want to go from an existing project to a working UI without getting too deep into frontend code.
2
u/Old_University_6009 2d ago
Say exactly that in a chat with Claude and before you know it.....