491–500 of 656 posts
Earlier quoted context omitted.
"still" isn ghecorrect word. They always be having hallucinations
"Still" means "it always had hallucinations, and it still does , despite people thinking that it doesn't anymore". People think we've moved past that. We haven't.
Yep. The only people I've heard saying that generated code is fine are those who don't read it. The problem is that the mitigations offered in the article also don't work for long. When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big, like a certain grand architecture, and sometimes it’s small, like the selection of a data structure. You can tell the agent what the…
I'm generally in agreement with everyone here. - Some code is ephemeral - it's generated to do the thing, thrown away end of session and the csv was imported successfully (or whatever). Make sure you have at least some testing of the output or you may find the email is in the last name field for some rows. If possible, have an API your agent uses with rich domain types and validations that force it to do things right…
For example, I had Claude generate a language server for TLA+ so I could have nice keystrokes in Neovim. For things like this, I really do think there is such thing as "good enough"; a language server doesn't have to be perfect, and the stakes are pretty low, where I think the worst case scenario is that it screws up my code, but that should be relatively easy to catch in Git.
I have been trying to mostly have Claude generate code from specifications; either a Mermaid diagram for simpler stuff, and TLA+ for more complicated stuff. I usually supply a lot of surrounding context about how I want these specs to be implemented, and it will usually get me about 90% of the way there, but I've found that I still need to hack against it to get over the hump.
It makes me feel a little valuable; I finally have an excuse to use formal methods for things.
Earlier quoted context omitted.
And the solution is the same, as when it was outsourced- and the "patch" was fix it by writing spec. Thus i conclude my TED talk with the statement: LLMs are the new outsourcing and run into the same problems.
Don't outsource either then
Earlier quoted context omitted.
I heard a talk from a VP at NVIDIA a couple of months ago and he echoed this. Essentially their policy is "you are still fully responsible for the code you ship, whether AI helps with it or not"
Does anyone out there working with AI coding agents not have this policy?
Will be interesting to see if / when enforcement happens given management is currently being pushed to encourage AI use
Earlier quoted context omitted.
That doesn't quite work, and precisely for the reason I mentioned: You can definitely tell the AI to follow some strategy, but at some point the strategy will need to change, and the AI won't tell you that (even if you tell it to). Unless you read the code every time you won't know if the AI is following the strategy and producing good results or following it and producing bad results because the strategy has to chan…
This is reductive. What you're describing already happened in codebases without AI. LLM's just speed up thing because they are a great calculator and not a replacement for human input.
Countless individuals/companies unfortunately do believe it is a replacement still and are unlikely to change their minds.
Earlier quoted context omitted.
> And humans produce 100% reasonable code or what? Humans can be held accountable for their own slop > The kind of mess me and everyone I've worked with produces by hand is the inverse of that Yes, it's frustrating to work with isn't it? So why are you so excited to make higher volumes of this low quality slop using AI?
I hear you. You're frustrated. Some people are having success with it. What have you tried to do with it? > Humans can be held accountable for their own slop If you're a human and AI writes code for you you are ultimately responsible.
Earlier quoted context omitted.
Juniors learn. Some juniors are potential good seniors. Over time they will internalise good architecture and be able to make good judgments on their own. Micromanaging LLMs is like having Dory from Finding Nemo as your colleague. You find ways to communicate, but there is no learning going on.
Juniors don't always learn.
And it's really someone's fault for hiring a bad junior. Someone did interview them, right? Maybe the person that hired them is the problem. And maybe the person that decided to go all-in on AI is also the same problem.
Earlier quoted context omitted.
I let agents break things 30 changes down the line. If something breaks, I add a check to my project validator and start over, with the validator providing instructions on what was wrong and how to fix it. It's all automatic, and now I have a guard against the exact same error in the future. Some of these checks have caught thousands of the same error, even with the latest Opus 4.7 writing the original code.
You proved that testing is a good idea, not that vibe coding is a good idea.
You don't actually think I look at the code, do you?