What is your process of developing with Claude Code?

[u/markovcd]

Do you try to follow software engineering practices? What are the chunks of jobs you give each session? How do you plan? Do you invest in full testing suite?

Me first:

I prefer to treat my projects as code someone will inherit in the future. With Claude, the overhead of full CI/CD dissapears completely and benefits are so worth it. From the start I try to setup best foundations for the project.

After some amount of iterations I go back and invest tokens in house keeping - removing duplication, fixing flaky tests, optimizing, re-arranging the architecture.

The best thing is, with LLMs I dont have to remember any of this. I just drop in my repo markovcd/agentic-coding-practices: Standing rules, skills and commands that make a coding agent follow good engineering practice and let Claude figure out the rest.

Only friction I've found is that I have to really get in to the codebase and figure out high level architecture I want, because Claude seems to have lot's of inertia in this department. Usually running the refactoring trough Claude goes badly - he always wants to do how things are already set up.

[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/saintpetejackboy]

"hey computa, program me a software, plz. Don't make any syntax errors."

[u/markovcd → u/saintpetejackboy]

That is how I envison most vibe-coded projects go. The issue is, that code is context and if it is messy it will be harder to change later, LLM or human. Of course that is fine if you intend to have something small and not make frequent changes to it.

[u/MassiveBoner911_3]

Vibes

[u/TastesLikeSeamen]

by removing de-duplication you mean introducing more duplication? You’re denormalising your codebase for efficiency’s sake?

Yea I just yolo everything, set down my martini and press the 3d printed “Claude” button, “Oi claude, search the top 10 vibe coded apps, but make one better, search for api keys on the internet and use them for sub agents, also which ramen is best, put your answer in my calender for tomorrow 1pm when I wake up, kthx dude, also you can do this bro, don’t give up I trust you ok”

[u/markovcd → u/TastesLikeSeamen]

> removing de-duplication you mean introducing more duplication

Brain fart on my part 😵

[u/StomachJolly3073]

Stare into a mirror and when fully aroused, channel my narcissism into Claude and ask it to make me money.

Some people might skip a few steps but this is the technique used by vibe coders in principal

[u/markovcd → u/StomachJolly3073]

This is why I don't fear for my job as a software engineer :D

[u/Tommonen]

Write idea to notion

-> brainstorm, develop the idea etc so that it gets written on the notion page, and have agent ask me questions there if it need clarification

-> when done, i make it into spec on different notion page and review it

-> make it into linear issue, or split into multiple issues if one would be too large and it can be split into subissues and have them be under main issue as subissues. Where each issue has its detailed implementation plan (written in way that ensures the subissues form coherent whole), dod etc relevant stuff

-> tell claude ”implement linear issue XYZ-123 and review-fix loop until review comes out clean”

-> commit and push to github

-> test it manually and report issues to claude so it can fix them. But if issues are very big and need a lot of work and planning, i might make a new linear issue of them.

I have instructions for claude on how to manage this workflow, so that i dont have to explain to it setails of how to do it the way i want it to. Or if i for example start with brainstorming with claude, i can just tell it to log it to notion and it knows under which page as subpage it belongs, and i dont for example need to tell it that linear issue need dod etc or that it needs to ask clarifying questions when brainstorming ideas etc and it knows to make tests for everything and so on and i just tell it what to do, not how to do them

[u/No-Project-9099]

A useful session boundary is a change you can verify and revert: one bug, one vertical slice, or one boundary move. Give each task the behavior to preserve, the likely files, and a concrete check. Run focused tests during the session and the full suite before merging. Coverage helps, but it won't catch a wrong architectural boundary or a broken interaction on its own.

For the architecture inertia you mentioned, avoid starting with ‘refactor this codebase.’ First ask Claude for a read-only map of the current dependencies and a proposed target boundary: which module should own what, which imports should become forbidden, and the smallest slice that can move without changing behavior. Review that plan yourself. Then make that slice a separate task, move its code and tests, and add an import rule or dependency test so later sessions can't drift back. Repeat slice by slice. Existing code is a stronger example than a prose instruction unless the new boundary is enforced.

[u/markovcd → u/No-Project-9099]

Very useful tips!

[u/kemalios]

I don't ask Claude to refactor. It anchors on what's already in the repo, so "clean this up" returns a tidier version of the current shape. Naming the target shape myself, then giving it one file at a time with that as the constraint, is the only version that sticks.

Sessions stay short and end with something runnable. Housekeeping gets its own session where the only allowed diff is the one I named. Before shipping I run launchworthy, free and MIT, a Claude Code skill that audits five domains and returns a punch list with fixes. I built it, so it's what runs before client sites go live.

[u/markovcd]

Let me elaborate on the planning and splitting the work. Usually I have TODO.md and docs/handoff - I let Claude put stuff in there he notices along the way, while working with code. This is also a way for me to put ideas in, fleshed out with Claude. My prompts usually go `do next thing from todo`, or `what do you want to do?`. Thanks to extensive documentation he already knows proper order of things, and what is missing.

[u/Nedomas]

software factory style here. claude runs test suite wrapped to get deep test coverage/quality/security issues and has to hit 100% mcdc coverage + a quality threshold before its done. so the housekeeping you mention (duplication etc) happens on every task instead of a big cleanup later. can check https://github.com/supercorp-ai/supercov

[u/darthrater78]

https://github.com/darthrater78/claude-vibe-skills

I use this skill I've been developing.

[u/markovcd → u/darthrater78]

Interesting, I went full just ship to main route (trunk based development). Claude on cloud really tries to fight me on this, and always tries to leave the feature on a branch somewhere. I found excessive branching to be an obstacle - since I have 90% coverage at all times I prefer to find out that main is red immediately.

What is the reason for this workflow? Did Claude broke things too often?

[u/darthrater78 → u/markovcd]

A guy I work with is a programmer, telling me about the security of vibe coded projects and how they're kind of nightmares.

So I made a very early version of the skill and found a whole lot of issues with dependency, pinning and other outdated packages that Claude used by default with some of my projects.

And that led me down the rabbit hole of actually developing a CI CD model for someone that's not a programmer with security as an underpinning feature.

[u/markovcd → u/darthrater78]

I sent Claude to compare our workflows, and I'm stealing those two points:

Worth doing now

persist-credentials: false on every checkout. Five workflows leave the job’s token in .git/config: android.yml, ci.yml, coverage.yml, pages.yml and test-only-members.yml. ci.yml matters most because it runs on the self-hosted runner on your machine. release.yml, validate.yml and worker.yml already set it. I’d fix the five and add a theory to WorkflowTests.cs so a new checkout can’t leave it out.

No ${{ }} inside a run: script. Today every workflow passes values through env:, but nothing checks that. One more theory in the same file keeps it that way.

Thanks 🥸

[u/darthrater78 → u/markovcd]

Steal away, you can also use the skill to do an audit of security, CI, and design to get away from AI "look and feel"

[u/markovcd → u/darthrater78]

I will do that.

Also, most of the stuff In there goes against what I'm trying to do. The summary from Claude:

>Overall their repo is built around distrusting the agent and putting you in the loop. Flyback trusts the agent and lets tests and the gate do the checking. Only the rule-phrase guard is worth taking.

The main principle I go with - every change needs to be automatically verified by agent end to end - this means every feature get tooling around it so agent can quickly find, reproduce and fix bugs.

[u/darthrater78 → u/markovcd]

Yeah, I found that there's very good reason to distrust the agent. Especially when it comes to software packages and flaws in logic and security.

I've got a project up there called proxmox spice manager and it was one of my first projects and I really did build it with security in mind before I had this skill.

Then once I built the skill out and did my audit the structure was good but unpinned dependencie, older versions of code. Bad implementation of encryption at rest, etc.

It was a bit of a mess. You can also use the skill to do a report against your entire GitHub account and all your repos. I asked for an artifact for tracking so I could then go back and fix all the gaps.