“ AI isn’t just serving as implementer.
It becomes a collaborative design partner.”
You’re completely right!
Turning Claude Code into my best design partner
71–80 of 87 posts
Re: Turning Claude Code into my best design partner
#72Earlier quoted context omitted.
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 i…
> Most people do not spend thousands of hours building something "not knowing what they're building."
They sure do in my experience.
> On the contrary, in my experience it's much more important to "play" with a concept and see it working...
I agree with all that. That's the point: figure out what you're trying to do before building it. Of course you will not know everything up-front, and of course you would try things out to learn and progress, and, for anything that it's tiny, of course it makes sense to do this iteratively, working from the most pressing/important/risky points earlier.
Or, at least, it seems obvious to me.
Re: Turning Claude Code into my best design partner
#73has anyone figured out how to make claude code improve design? It usually spit out the same css that i have that is not really beautiful already
Re: Turning Claude Code into my best design partner
#74This seems similar to the way I use Visual Studio Code/ChatGPT5(preview) {I think it's being payed for by my github copilot subscription, but I'm not actually sure these days}
Having tried non-agent LLMs for code, things tend to break and quickly devolve. The agent mode of working with LLMs to build code is a step change improvement for me. I'm not a python programmer, but have been working on a pile of new code that it's built for me, and I'm fairly impressed at what's been achieved in the past week.
Once I get done, and can run a small LLM in my emulated BitGrid, then I'll back off and try to grok the code. It's been a series of small exploratory steps, with a few corrections on my part to keep the overall design going where I want. I'm much more hopeful about the future of "LLM as programming buddy", now that I've actually used an agent like this.
Does anyone else here use the Visual Studio Code/ChatGPT5 combo?
Re: Turning Claude Code into my best design partner
#75Earlier 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…
thats a great way to put it. the LLMs can't design things, thats way too above their capabilities. they can pretend to design things and even fool people, but they're jsut regurgitating other designs from their training data (and for a todo app, thats enough). but it we do the design for them, they're really really good at putting meat on that skeleton
>they're jsut regurgitating other designs from their training data
I'm deep into the crank/lone genius territory with my BitGrid project, doing things with code that nobody else would be silly enough to waste time on. If it's just copy/pasting code from some latent space, I have no idea where it's getting it.
When's the last time you wrote code to directly handle all the bits to multiply two floating point numbers? I've never done it.
Re: Turning Claude Code into my best design partner
#76Earlier 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.)
This is what Naur, 1985, Programming as Theory Building is about!
https://pages.cs.wisc.edu/~remzi/Naur.pdf
The act of programming is building the theory of what the program does, so that you acquire new knowledge of doing things. It's not just text production.
>"[...] not any particular knowledge of facts, but the ability to do certain things, such as to make and appreciate jokes, to talk grammatically, or to fish."
Which is why re-building a program from scratch is so tempting: you've figured out the theory as you went along, now you can build the real thing.
Re: Turning Claude Code into my best design partner
#77Earlier quoted context omitted.
Well waterfall is how we built the old world. Piece by piece, module by module, roads, bridges, buildings, boats.
I got intrigued by your comment, I couldn't wrap my head about a process just changing. Got AI to throw out this table, but I think its of interest: Waterfall ~1970, Agile ~2001, Continuous (DevOps) ~2015, Autonomous Dev ~2030, Self-Evolving Systems ~2040, Goal-Directed Ecosystems ~2050+
~1985 Iterative Development.
That waterfall was what everyone did before agile is a myth. AI produces the recent popular viewpoint as truth whether it is true or not.
Re: Turning Claude Code into my best design partner
#78Earlier 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.
Roughly how many test on average would you write before beginning implementation?
Re: Turning Claude Code into my best design partner
#79Earlier quoted context omitted.
I got intrigued by your comment, I couldn't wrap my head about a process just changing. Got AI to throw out this table, but I think its of interest: Waterfall ~1970, Agile ~2001, Continuous (DevOps) ~2015, Autonomous Dev ~2030, Self-Evolving Systems ~2040, Goal-Directed Ecosystems ~2050+
What do you think about “goal-directed ecosystems” mapping to Mulder’s Collaborative Agent Maturity Model (CAMM)?
terribly interesting! Thank you
Re: Turning Claude Code into my best design partner
#80Over the last 2 weeks (evenings only) I've spend a lot of time crafting the "perfect prompt" for claude code to one shot the project. I ended up with a rather small CLAUDE.md file that references 8 other MD files, ranging from project_architecture, models_spec, build_sequence, test_hierarchy, test_scenarios, and some other files. It is a project for model based governance of Databricks Unity Catalog, with which I do…
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…
[dead]