Most active commenters
  • dotancohen(5)

←back to thread

548 points kmelve | 15 comments | | HN request time: 0.237s | source | bottom
Show context
ale ◴[] No.45109875[source]
It’s about time these types of articles actually include the types of tasks being “orchestrated” (as the author writes) that aren’t just plain refactoring chores or React boilerplate. Sanity has quite a backlog of long-requested features and the message here is that these agents are supposedly parallelizing a lot of the work. What kind of staff engineer has “80% of their code” written by a “junior developer who doesn't learn“?
replies(6): >>45110352 #>>45111148 #>>45111902 #>>45112019 #>>45113025 #>>45116018 #
1. mindwok ◴[] No.45111902[source]
IMO “junior developer who doesn't learn“ is not quite right. Claude is more like an senior, highly academic engineer who has read all the literature but hasn't ever written any code. Amazing encyclopaedic knowledge, zero taste.

I've been building commercial codebases with Claude for the last few months and almost all of my input is on taste and what defines success. The code itself is basically disposable.

replies(4): >>45112275 #>>45112775 #>>45112856 #>>45113726 #
2. all2 ◴[] No.45112275[source]
> The code itself is basically disposable.

I'm finding this is the case for my work as well. The spec is the secret sauce, the code (and its many drafts) are disposable. Eventually I land on something serviceable, but until I do, I will easily drop a draft and start on a new one with a spec that is a little more refined.

replies(2): >>45113350 #>>45114422 #
3. globular-toast ◴[] No.45112775[source]
If the code is disposable then where do all the rules and reasoning etc live apart from in your head?
replies(1): >>45113354 #
4. baq ◴[] No.45112856[source]
> The code itself is basically disposable.

This is key. We’re in mass production of software era. It’s easier and cheaper to replace a broken thing/part than to fix it, things being some units of code.

5. dotancohen ◴[] No.45113350[source]
I just like to add that the database design is the real secret sauce, important even more than external APIs in my opinion.
replies(2): >>45114289 #>>45117683 #
6. dotancohen ◴[] No.45113354[source]
In the spec.
replies(1): >>45115374 #
7. sanitycheck ◴[] No.45113726[source]
Eh, Claude is like a magical spaniel that can read and write very quickly, with early-stage alzheimers, on amphetamines.

Yes it knows a lot and can regurgitate things and create plausible code (if I have it run builds and fix errors every time it changes a file - which of course eats tokens) but having absolutely no understanding of how time or space works leads to 90% of its great ideas being nonsensical for UI tasks. Everything is needing very careful guidance and supervision otherwise it decides to do something different instead. For back end stuff, maybe it's better.

I'm on the fence regarding overall utility but $20/month could almost be worth it for a tool that can add a ton of debug logging in seconds, some months.

8. mattmanser ◴[] No.45114289{3}[source]
Well, not DB design really, you can achieve the same thing by defining your POCOs well. I switched entirely to code-first design years ago. If you haven't worked with a good ORM, you're really missing out, though I admit there was quite a bit of friction at first.
replies(1): >>45114641 #
9. bjornsing ◴[] No.45114422[source]
So how do you best store and iterate on the spec? One way I guess would be to work on a branch an modify Claude.md to reflect what the branch is for. Is that a good approach? Are there others?
10. dotancohen ◴[] No.45114641{4}[source]
No, I really am talking about how the database is organised. Tables representing objects, normalisation, etc. Whether or not it is accessed through the application with an ORM.
11. globular-toast ◴[] No.45115374{3}[source]
Hmm... my code is the spec. It just happens to be executable. Is writing a precise spec in English easier than in a programming language?
replies(1): >>45116315 #
12. dotancohen ◴[] No.45116315{4}[source]
The spec contains ambiguities and the code contains bugs. Clarifying ambiguities in the spec with stakeholders, allows one to reduce bugs in the code.
replies(1): >>45117508 #
13. caseyohara ◴[] No.45117508{5}[source]
If you repeat this process until all ambiguities in the spec are eliminated, aren't you essentially left with code? Or at least something that looks more like code than plain English?
replies(1): >>45118643 #
14. all2 ◴[] No.45117683{3}[source]
This is something that I've stumbled into as well. DB models AND dataflow. Getting both of those well spec'd makes things a lot easier.
15. dotancohen ◴[] No.45118643{6}[source]
No