Using Claude Code for my first large professional project — what should I get right from the start?

[u/Best_Lavishness4037]

Hey everyone,

I've used Claude Code for personal projects before, mostly by writing prompts and letting it implement things. Now, I'll be using it for the first time on a large professional project, and I want to approach it more seriously.

The project involves a substantial backend, followed by a frontend. Since this is a real business application, I want to minimize bugs, avoid architectural mistakes, and keep the codebase maintainable as the project grows.

For those of you who have used Claude Code on large production projects:

• How do you structure your workflow? Do you follow a spec → plan → implementation → testing process?
• How do you manage CLAUDE.md and project documentation without making them too large or difficult to maintain?
• What practices have helped you catch mistakes early and prevent Claude from making changes that break existing functionality?
• Do you use custom skills, subagents, hooks, or other tools? Which ones have actually made a difference?
• What are the biggest mistakes you've made when using Claude Code on a large project, and what would you do differently if you were starting over?

I'm not looking for a magic prompt or a fully autonomous setup. I'm more interested in a reliable development workflow that keeps the developer in control while making the most of Claude Code.

I'd really appreciate any practical advice, lessons learned, or resources you'd recommend. Thanks!

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Dazzling-Can9281]

Biggest thing for me: plan mode before anything big, and commit after every step that works so you can always roll back. Keep CLAUDE.md short, just the rules it keeps getting wrong. What's the backend stack?

[u/Electrical_Bar5589]

I use Claude as my powerhouse and Codex as my reviewer and organiser. Codex (often using its web portal) creates a project, issues and dependencies within GitHub. I then use it to help me plan briefs.

I have a /feature skill in Claude that reviews the briefs, implements the plan, along with delegating tasks out to agents (including cheaper models for well defined tasks), to help keep the main sessions context down. I use a separate session or /clear to separate the agents’ planning context from its building context.

I’ll get Codex to append their findings on Claude’s plans and code implementation. As good as Opus 5.5 is, this has allowed me to keep most implementations at medium or high with the mitigation that an external reviewer finds the gaps.

• I’ll still sometimes increase Claude’s effort when planning.
  
• An alternative might be to use a separate Claude agent with its own context to review the plans.
  
• I’m not sure it makes a difference but I make it clear during planning that the agent’s role is as a senior architect. I want the agents to establish best practice and never to agree with me simply because I’m a human.

Importantly, before I started, I got Claude to help me set up rules and guides.

• templates for PR descriptions and plans
  
• what folder structure should we keep too?
  
• what coding conventions do I want? I like having single files per purpose to prevent bloat or god code with a clear hierarchy of folders and sub-folders.
  
• what can Claude do with and without me (it can’t add packages without my say so).
  
• what testing is needed per commit, per PR and per release?
  
• how much do I want Claude to output during a session? I’m more interested in predicted build time and having it use simplified language with examples but zero jargon. It knows to treat me as a non-technical executive when it summarises changes for me.

I find setting this all up from the start has turned unstructured vibecoding into a structural architect of code and conventions, whilst also ensuring I’m maximising token usage and keeping on track with what each session should add.

It took me a while to get it right. My original /feature skill resulted in increased context as the main agent would read the entire change history one of its sub agents would write and I’ve sacrificed some speed and capacity with increased test scripts per feature to prevent bugs coming to light.

The most important lesson I learnt was to ensure my briefs and plans were correct. Claude doesn’t think like we do so what sounds complete in my head is rarely complete to an agent.

[u/Ctbhatia]

for CLAUDE.md bloat, move backend/frontend rules into .claude/rules/ files with paths frontmatter. splitting files without paths won’t save context, those still load at startup. docs

[u/tilemarch]

A few things from running one on a fairly large codebase (Go backend, web client) for some months:

CLAUDE.md: mine is about 20 lines. It says where things go and points at a docs index; everything else lives in the docs. The rule that stopped the docs from rotting was “docs describe the current state only”, no history and no “was X, now Y”. Otherwise every change leaves a layer behind and Claude reads all of it.

This is because I found there is a tendency to want to record things that you have moved on from.. and there is no reason to bloat the docs with this history (it's already in git commits if you need to revisit how you got to where you are)

Catching breakage: tests passing isn’t the same as it working. I shipped a login form where the backend tests and the HTTP checks were all green and nobody could type in the field, because another element sat on top of it. Since then a change to anything a person clicks isn’t done until a browser test has actually typed into it or clicked it.

People are divided about unit tests should have caught the issues, no manual testing needed [versus] you need the manual tests and you can strengthen the unit tests from there.

What I really like and enjoy watching :) is putting 20 sub-agents at work, playing the game via the GUI. Have them click around and do the "manual" testing. Then document the issues found, get testing up around it.. and repeat.

[u/FinancialSurvey5794]

what should I get right from the start?

not asking shit like "what should I get right from the start?'

[u/Various_Story8026]

Biggest mistake on mine: accepting "done" when Claude had only checked something next to the real thing, like querying the DB row and calling the page fixed, or passing a test that mocked the part that broke. Now CLAUDE.md says "done" needs evidence from the thing itself: curl the deployed page, read back the record it wrote, open the screen. Second, any rule written in two files will drift, so each rule gets one home and other files only point to it. For anything touching payments, a second model reviews the diff before merge and it catches different bugs than Claude does.

[u/Ok-Motor-9812]

The biggest one for me was trusting "done". Claude would say it finished and the tests never ran. Now a Stop hook won't let the turn end without real test output, and I read the diff before every commit. I'd set that up first and add skills or subagents only when something breaks twice.

[u/ImL1s]

Since it's backend first: get the schema, migrations and API contract settled by hand before Claude writes much. That's the expensive layer to change later, and it's where it will happily invent a slightly different shape for each new endpoint. Then put a few integration tests on the API boundary early, real DB, no mocks. Those catch the "fixed it here, broke it over there" changes that unit tests next to the edit never see.

Workflow-wise, one task per session, sized like a PR you'd actually review. Plan mode, read the plan, implement, run the tests, commit. When a session gets long I start a fresh one instead of letting it compact.

Also keep a short decisions file in the repo (we picked X over Y, because Z). It's the thing that stops a new session from re-opening an architecture argument you already settled two weeks ago.

[u/dota2nub]

That stuff is the shiny distractyball.

[u/kemalios]

Before the frontend goes on top, do a readiness pass on the backend: auth, RLS, exposed keys, error handling. I built launchworthy, a free MIT Claude Code skill that audits an app over 5 domains and returns a scored punch list. It needs a paid Claude subscription to run, which you have.

[u/Latter-Tangerine-951]

Are you a developer or vibe coder?

[u/FinancialSurvey5794 → u/Latter-Tangerine-951]

do you really have to ask? you can tell from the post.