Most active commenters
  • colordrops(3)

←back to thread

548 points kmelve | 11 comments | | HN request time: 0s | source | bottom
Show context
swframe2 ◴[] No.45108930[source]
Preventing garbage just requires that you take into account the cognitive limits of the agent. For example ...

1) Don't ask for large / complex change. Ask for a plan but ask it to implement the plan in small steps and ask the model to test each step before starting the next.

2) For really complex steps, ask the model to write code to visualize the problem and solution.

3) If the model fails on a given step, ask it to add logging to the code, save the logs, run the tests and the review the logs to determine what went wrong. Do this repeatedly until the step works well.

4) Ask the model to look at your existing code and determine how it was designed to implement a task. Some times the model will put all of the changes in one file but your code has a cleaner design the model doesn't take into account.

I've seen other people blog about their tricks and tips. I do still see garbage results but not as high as 95%.

replies(20): >>45109085 #>>45109229 #>>45109255 #>>45109297 #>>45109350 #>>45109631 #>>45109684 #>>45109710 #>>45109743 #>>45109822 #>>45109969 #>>45110014 #>>45110639 #>>45110707 #>>45110868 #>>45111654 #>>45112029 #>>45112178 #>>45112219 #>>45112752 #
MangoCoffee ◴[] No.45109684[source]
I've been vibe coding a couple of personal projects. I've found that test-driven development fits very well with vibe coding, and it's just as you said break up the problem into small, testable chunks, get the AI to write unit tests first, and then implement the actual code
replies(3): >>45109837 #>>45111012 #>>45112453 #
1. yodsanklai ◴[] No.45109837[source]
Actually, all good engineering principles which reduce cognitive load for humans work for AI as well.
replies(2): >>45109935 #>>45110199 #
2. colordrops ◴[] No.45109935[source]
This is the big secret. Keep code modular, small, single purpose, encapsulated, and it works great with vibe coding. I want to write a protocol/meta language similar to the markdown docs that Claude et al create that is per module, and defines behavior, so you actually program and compose modules with well defined interfaces in natural language. I'm surprised someone hasn't done it already.
replies(2): >>45110171 #>>45110483 #
3. drzaiusx11 ◴[] No.45110171[source]
Isn't what you're describing exactly what Kiro aims to solve?
replies(1): >>45111080 #
4. BoiledCabbage ◴[] No.45110199[source]
This is what's so funny about this. In some alternative universe I hope that LLMs never get any better. Because they force so much of good things.

They are the single closest thing we've ever had to objective evaluation on if an engineering practice is better or worse. Simply because just about every single engineering practice that I see that makes coding agents work well also makes humans work well.

And so many of these circular debates and other best practices (TDD, static typing, keeping todo lists, working in smaller pieces, testing independently before testing together, clearly defined codebase practices, ...) have all been settled in my mind.

The most controversial take, and the one I dislike but may reluctantly have to agree with is "Is it better for a business to use a popular language less suited for the task than a less popular language more suited for it." While obviously it's a sliding scale, coding agents clearly weight in on one side of this debate... as little as I like seeing it.

replies(2): >>45111739 #>>45112303 #
5. adastra22 ◴[] No.45110483[source]
My set of Claude agent files have an explicit set of interface definitions. Is that what you’re talking about?
replies(1): >>45111085 #
6. colordrops ◴[] No.45111080{3}[source]
Possibly, I've never heard of Kiro, will look into it.
7. colordrops ◴[] No.45111085{3}[source]
Are Claude agent files per module? If so, then I guess so.
replies(1): >>45112394 #
8. shortstuffsushi ◴[] No.45111739[source]
While a lot of these ideas are touted as "good for the org," in the case of LLMs, it's more like guard rails against something that can't reason things out. That doesn't mean that the practices are bad, but I would much prefer that these LLMs (or some better mechanism) everyone is being pushed to use could actual reason, remember, and improve, so that this sort of guarding wouldn't be a requirement for correct code.
replies(1): >>45112333 #
9. kaffekaka ◴[] No.45112303[source]
Well put, I like this perspective.
10. kaffekaka ◴[] No.45112333{3}[source]
The things GP listed are fundamentally good practices. If LLMs get so good they don't need even these guardrails, ok great but that is a long way off, and until then I am really happy if the outcome of AI assisted coding is that we humans get better at using these ideas for ourselves.
11. adastra22 ◴[] No.45112394{4}[source]
Per source code module?