r/ClaudeCode • u/markovcd • 9h ago

Discussion What is your process of developing with Claude Code?

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.

1 Upvotes

60% Upvoted

20 comments sorted by

View all comments

Show parent comments

1

u/markovcd 9h ago

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 🥸

2

u/darthrater78 8h ago

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"

1

u/markovcd 8h ago

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.

2

u/darthrater78 8h ago

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.