There are two types of software engineers: Those who do and then think, or those who think and then do. Claude Code seems to strictly be for the former, while typically the engineers who can maintain software long-term are the latter.

Not sure if we have any LLM-tooling for the latter, seems to be more about how you use the tools we have available, but they're all pulling us to be "do first, think later" so unless you're careful, they'll just assume you want to do more and think less, hence all the vibeslop floating around.

▲

viraptor 2 hours ago | parent | next [-]

> Claude Code seems to strictly be for the former, while typically the engineers who can maintain software long-term are the latter.

Given the number of CC users I know who spend significant time on creating/iterating designs and specs before moving to the coding phase, I can tell you, your assumption is wrong. Check how different people actually use it before projecting your views.

	▲	embedding-shape 2 hours ago \| parent [-]
		Yeah, I wasn't trying to say "These are the people who use CC, for these purposes" but rather what the intention seems to for Claude Code in the first place. I'm using CC from time to time, to keep up to date with what tooling is available, and also know people who use CC every day and plan a lot up front, sorry if I gave the impression that I meant that everyone using CC is doing that, was trying to get at what the purpose of the tool seems to be, which seems to be true today too, as the models continuously seem to steer you to "doing" and moving faster, not stopping and thinking.

▲

prescriptivist an hour ago | parent | prev | next [-]

This seems like a real coarse and not particularly accurate binary, but even if it were true, the thing about Claude Code and agentic coding like this is the cost of making a mistake or the cost of not being happy with a design and having to back it out is getting smaller and smaller.

I would argue that rapidly iterating reveals more about the problem, even for the most thoughtful of us. It's not like you check your own reasoning at the door when you just dive head first into something.

▲

rafaelmn 3 hours ago | parent | prev | next [-]

This isn't a binary thing - even if you prefer to build maintainable systems very often the trade-off is - you don't ship in time and there's no long term - the project gets scrapped.

So even if it comes at the expense of long term maintainability - everyone should have this in their toolbox.

▲

Wowfunhappy 3 hours ago | parent | prev | next [-]

I find it often helps me to see a feature before I evaluate if it was really a good idea in the first place. This is my failing--but one thing I like about Claude is that it's now possible to just try stuff and throw away whatever doesn't work out.

	▲	darkerside 2 hours ago \| parent [-]
		Was always possible. Now just easier.

▲

thinkindie 3 hours ago | parent | prev | next [-]

I usually have conversations with Claude for clearing my mind and forming the scope of a project. I usually use voice transcription from Claude app to take notes and explore all my options.

	▲	kzahel 2 hours ago \| parent [-]
		Same. When I can't be at my desk, my projects don't stop -- I just do the tasks that work well enough on the phone. Brainstorming, planning, etc. Or tasks that the agent can easily verify. Having access to my local repository and my whole home folder is much easier than dealing with Claude or ChatGPT on the web. (Lots of manual markdown shuffling, passing in zipfiles of repositories, etc).

▲

ubercore 3 hours ago | parent | prev | next [-]

I agree in your basic framing but not your conclusion. Met plenty of do-ers before thinkers that are self-aware enough to also maintain software longterm.

▲

tayo42 35 minutes ago | parent | prev | next [-]

These coding tools work better when you think and play first before doing...

▲

mhalle 2 hours ago | parent | prev [-]

I would definitely disagree.

Claude Code and similar agents help me execute experiments, prototypes and full designs based on ideas that I have been refining in my head for years, but never had the time or resources to implement.

They also help get me past design paralysis driven by overthinking.

Perhaps the difference between acceleration and slop is the experience to know what to keep, what to throw away, and what to keep refining.