Has anyone figured out an elegant way to add front-end design to a process like this? Every implementation I see people use includes either vague references to front-end frameworks, or figma images. It doesn't feel like a cohesive design solution.
Turning Claude Code into my best design partner
61–70 of 87 posts
Re: Turning Claude Code into my best design partner
#62I have been using exactly author's approach with "great success: (quote Borat) over the last two months. The first month with CC was also mainly nudging it along and that only gets you so far. But since then I have come to have it always write ARCHITECTURE.md and IMPLEMENTATION.md when doing a new feature and CLAUDE-CONTINUE.md. All three live in the resp. folder of the feature (in my case, it's often a new crate or…
What is the distinction between IMPLEMENTATION.md and *.rs source code files?
Implementation has the details for what is being implemented.
Details what algorithms/approaches to use etc. The reason is that often a single context is not enough and when CC continues the CLAUDE-CONTINUE tells the model What it should do. Not Why (architecture) and How (implementation).
The architecture file is usually more abstract/high level and may also contain info about how the stuff integrates with other parts of the codebase etc.
Re: Turning Claude Code into my best design partner
#63Earlier quoted context omitted.
TDD fizzled because not enough emphasis was put on writing high level tests which matched user stories and too much emphasis was put on it as a tool of design.
No, TDD failed because it assumed you could design a perfect systems before implementation. It’s a totally waste of time to do TDD to only find out you made a bad design choice or discovered a conflicting problem.
This is precisely the problem I alluded to which is solved by writing higher level tests with TDD that make fewer assumptions about your design.
TDD ought to let you make a bad design decision and then refactoring it while keeping the test as is.
Re: Turning Claude Code into my best design partner
#64Earlier quoted context omitted.
I feel we're developing something like what made Test-Driven Development so strong: TTD forced you to sit down and design your system first, rather than making it all up on the fly. In the past we mapped the system while we were building the code for it. This kind of AI-driven development feels very similar to that. By forcing you to sit down and map the territory you're planning to build in, the coding itself become…
Test-driven and prompt-driven development aside, I never understood why people (and groups) spend many hours (or 1000s, or 10000s of hours) building things when they don't really know what they're building. (I've certainly seen it done though, with predicable result.)
Do you mean people that build something without a plan? Some people have an idea (or vision) but not a plan and they figure things out along the way. Other want to / need to plan everything ahead of time first.
In my anecdotal case: I behave like the former in some cases (crafting) and the latter in others (travel planning)
I wouldn't say one way is always better than the other.
Re: Turning Claude Code into my best design partner
#65Earlier quoted context omitted.
I feel we're developing something like what made Test-Driven Development so strong: TTD forced you to sit down and design your system first, rather than making it all up on the fly. In the past we mapped the system while we were building the code for it. This kind of AI-driven development feels very similar to that. By forcing you to sit down and map the territory you're planning to build in, the coding itself become…
Test-driven and prompt-driven development aside, I never understood why people (and groups) spend many hours (or 1000s, or 10000s of hours) building things when they don't really know what they're building. (I've certainly seen it done though, with predicable result.)
Most people do not spend thousands of hours building something "not knowing what they're building."
On the contrary, in my experience it's much more important to "play" with a concept and see it working. Too many engineers think they're going to architect a perfect solution without ever getting code on the page.
A slapdash prototype is worth the weight of 100 tests and arch diagrams.
Note: I'm not saying the latter is not important. My comment is, it's ok (and encouraged) to do potentially throwaway work to understand the domain better.
Re: Turning Claude Code into my best design partner
#66Earlier quoted context omitted.
What is the distinction between IMPLEMENTATION.md and *.rs source code files?
Implementation has the details for what is being implemented. Details what algorithms/approaches to use etc. The reason is that often a single context is not enough and when CC continues the CLAUDE-CONTINUE tells the model What it should do. Not Why (architecture) and How (implementation). The architecture file is usually more abstract/high level and may also contain info about how the stuff integrates with other par…
I'm very curious about how you do ARCHITECTURE.md. What level of description is allowed? What are the guardrails?
I have something similar to that where all I do is list out the key types, structs, enums and traits, accompanied by comments describing what they are. I broke it down into four sections corresponding to different layers of abstraction.
But I noticed that over time the LLM will puff up the size and start putting implementations into it, so some prompting discipline is required to keep things terse and inline.
Is your ARCHITECTURE.md similar to mine or is it more like a UML diagram or perhaps an architectural spec in a DSL?
Re: Turning Claude Code into my best design partner
#67That is another post praising the waterfall model. What Claude Photocopier does here is steal from hundreds of similar projects. It does not design anything and neither are you.
Re: Turning Claude Code into my best design partner
#68I’ve recently tried out Claude Code for a bit, I’ll make sure to give the suggested approach a go! It sounds like a nice workflow. But I’m negatively surprised with the amount of money CC costs. Just a simple refactoring cost me about 5min + 15min review and 4usd, had I done it myself it might have taken 15-20min as well. How much money do you typically spend on features using CC? Nobody seems to mention this
> had I done it myself it might have taken 15-20min as well. Could you spend that 15-20min on some other task while this one works in the background?
Not really, or I guess I could if i let it run wild. But I wanted to check what it was doing and had to steer it in other directions sometimes.
I treat it as pair programming with a junior programmer on speed!
Re: Turning Claude Code into my best design partner
#69Does anyone know how to get support from Anthropic? I purchased the Claude.ai Pro sub to try it out and disabled auto-renewal, then tried to remove my payment method from my account, just in case.
You can't.
So I tried to reach support. There's no email, no phone number, just a THIRD-PARTY AI chatbot.
Well guess what, the Send Message button in the text field is disabled.
This is infuriating and puts me off the whole product and maybe I'll just file a chargeback.
Re: Turning Claude Code into my best design partner
#70Earlier quoted context omitted.
I feel we're developing something like what made Test-Driven Development so strong: TTD forced you to sit down and design your system first, rather than making it all up on the fly. In the past we mapped the system while we were building the code for it. This kind of AI-driven development feels very similar to that. By forcing you to sit down and map the territory you're planning to build in, the coding itself become…
> "TTD forced you to sit down and design your system first, rather than making it all up on the fly" It's interesting because I remember having discussions with a colleague who was a fervent proponent of TDD where he said that with that approach you "just let the tests drive you" and "don't need to sit down and design your system first" (which I found a terrible idea).
Yeah, your colleagues opinion is kinda inline with how it was usually pitched - at least around 2010 when I learned about it to a degree that it wasn't just a fuzzy concept to me.
One of the goals I remember was to think from the outside to the inside: you first create a test which asserts your most outter API as a unit test with inputs as you want to use it.
Now you keep adding functionality until it passes, creating new tests whenever you make a new boundary/function/API
This supposedly makes it easier to design it well, because you don't have to keep everything in scope and instead only tackle one layer at a time - like an onion from the outside to the core. And you always design the APIs as they make sense, not as is technically easiest because you can just define it however you want, and then think about implementing it.
E.g. https://www.infoq.com/presentations/tdd-ten-years-later/