Hacker Newsnew | past | comments | ask | show | jobs | submit | Loeffelmann's commentslogin

> locally coherent but structurally incoherent

Perfectly summarizes what I hate about AI code. The diff looks fine but if you take a step back its an absolute mess. I mean have you looked at the Claude Code or Openclaw codebases? that is the result of full on vibecoded. A bloated unattainable mess that no one understands.


If you ever work with LLMs you know that they quite frequently give up.

Sometimes it's a

    // TODO: implement logic
or a

"this feature would require extensive logic and changes to the existing codebase".

Sometimes they just declare their work done. Ignoring failing tests and builds.

You can nudge them to keep going but I often feel like, when they behave like this, they are at their limit of what they can achieve.


If I tell it to implement something it will sometimes declare their work done before it's done. But if I give Claude Code a verifiable goal like making the unit tests pass it will work tirelessly until that goal is achieved. I don't always like the solution, but the tenacity everyone is talking about is there


> but the tenacity everyone is talking about is there

I always double-check if it doesn't simply exclude the failing test.

The last time I had this, I discovered it later in the process. When I pointed this out to the LLM, it responded, that it acknowledged thefact of ignoring the test in CLAUDE.md, and this is justified because [...]. In other words, "known issue, fuck off"


Tools in a loop people, tools in a loop.

If you don't give the agent the tools to deterministically test what it did, you're just vibe coding in its worst form.


tenacity == while loop


> If you ever work with LLMs you know that they quite frequently give up.

If you try to single shot something perhaps. But with multiple shots, or an agent swarm where one agent tells another to try again, it'll keep going until it has a working solution.


Yeah exactly this is a scope problem, actual input/output size is always limited> I am 100% sure CC etc are using multiple LLM calls for each response, even though from the response streaming it looks like just one.


Nope, not for me, unless I tell it to.

Context matters, for an LLM just like a person. When I wrote code I'd add TODOs because we cannot context switch to another problem we see every time.

But you can keep the agent fixated on the task AND have it create these TODOs, but ultimately it is your responsibility to find them and fix them (with another agent).


Using LLMs to clean those up is part of the workflow that you're responsible for (... for now). If you're hoping to get ideal results in a single inference, forget it.


An AI version of ls and fzf bringing your file system to the AI age


> you can always do C-x C-e in bash/zsh (M-v in Fish).

Thanks I didn't know!


Some one apparently figured it out. The first system message has to include

"You are Claude Code, Anthropic's official CLI for Claude."

https://github.com/link-assistant/agent/pull/63


Lol a formatting error in a change log breaking the entire thing


You can use subscriptions.

I like it but I am not too deep into the whole agentic coding business.


Why do all these AI generated readmes have a directory structure sections it's so redundant because you know I could just run tree


It makes me so exhausted trying to read them... my brain can tell immediately when there's so much redundant information that it just starts shutting itself off.


comments? also reading into an agent so the agent doesnt have to tool-call/bash out


It's mainly about showing how low the odds actually are. I think everyone understands they are low but it's ridiculous how low exactly.


this looks like one of those things where it completely breaks apart if you want to do anything custom or out of line to what is intended by the framework. Causing way more headaches down the line then if you just did it yourself from the start.


I understand that gut feeling. I've worked with many such systems. iommi is not like that though, because we HATE systems that have a nice two line demo but then immediately falls apart.

We consider any failure to scale up customization a high priority bug.

How do we handle this in practice? Nice defaults, easy to do deep customization with zero boilerplate, AND escape hatches of various forms. So if you need to just render your own template for an entire table row of form input field or whatever, you can do that. Always.


Actually, how it behaves with special cases was one of the initial requirements when it was built. A design goal has always been that there should be escape hatches. For example almost all settings can be a call-back if the value is not known up front.


From my experience with similar things built around Rails (ActiveAdmin and others) being based in a dynamic language helps and allows to accomodate a lot of customizations.


It can. But it doesn't necessarily mean that. Or maybe it means you CAN work around it, but it's cumbersome/bad to do so. Imo the Django Admin is like that: lots of ad-hoc and random customization options and lots of missing options, and it's a pain to override etc.


Agreed. When you use a web framework you are somehow trusting the ability of the creators to ship something reusable and extensible. When you use something like this now you have two groups of creators to trust that they are not only good and coding but also good at making opinionated decisions. Or, better said, you switch your trust from the framework --after all it's battle tested-- to a new group.

If one is a seasoned Django developer I guess they can take a look at the source code and judge if it suits your needs. But if it does, there is a lot of development speed to be gained.


As one of the developers of iommi I can confidently say that seasoned Django developers will be very confused by the iommi code base heh. We do things quite differently, for good and ill. I wrote about this here: https://kodare.net/2024/09/30/why-iommi-is-weird.html


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: