You claim "very high quality" but can't even get the basic UI working properly. You wrap tmux and a container in 2k lines of code and claim quality, I think the comment above was aimed at this claim.
I did not much more than a cursory glance too, but found "./sandbox/create.go", a ~1300 lines long file with so much duplication even within just itself that I stopped counting.
Now it was a long time ago I did Go professionally, but I'm also in the camp of "That doesn't really count as high-quality", although I know for a fact you can get quality code out of LLMs, but I don't think that's a good showcase of that.
> I did not much more than a cursory glance too, but found "./sandbox/create.go", a ~1300 lines long file with so much duplication even within just itself that I stopped counting.
Really? What duplication did you actually find? I count a few small ones in buildMounts and ReadPrompt, maybe 20 lines or so, but hardly anything worthy of such an epithet.
Admittedly, the parsing & escaping code and some utility functions could be moved outside to shrink the file, but otherwise I'm having trouble finding issues with the code.
The duplication I'm seeing isn't just "same text repeated" but structural duplication. Doing a quick 5 minute look again just to give you some pointers; runtime.MountSpec construction in buildMounts, Workdir vs aux-dir mount-mode handling, repeated one-off mount append blocks, overlay detection and so on, the list goes on. Just those should account for 200+ lines.
Look for slight variations of the same thing but with different paths, variables, or modes and I think you'd be able to spot the rest as well.
I've noticed that the bar for "quality" when people judge AI is often significantly higher than what they'd hold a human to. I'm not saying GP et al are doing this (I haven't looked myself), but it is a widespread pattern I've noticed both professionally and personally. I don't know why it is.
The bar isn't any higher. There's just no grace given. No one is judging a hobby project made by a human on quality, and the person who the hobby project belongs to will rarely say that their code is high quality. And in a professional setting, I think people are fine with "good enough" but they're not going to claim anything is high-quality.
But people are so quick to label their vibe-coded codebase as high quality and no grace is going to be given to a machine.
What comments are you seeing that are calling code from humans high-quality?
Grace shouldn't be given though. The code from vibe coding should pass the review bar as-is. If you need to iterate, you've defeated the purpose.
Because the end result is people committing bad code. For some random hobby project, sure who cares. But people are using this at work. The codebase is rotting in a new innovative way.
Either the bar has to be set at "actually good code comes out of vibe coding" or you have to accept that codebases are going to steadily become less usable by human coders who use their fingers to type in emacs.
Suddenly every dev needs an agent to even work with the slop. Seems like an outcome Anthropic would love though....
People who use AI set the bar themselves when they claim they generate "very high quality work using Claude". Humans more rarely make such claims about the code they write themselves, but when they do, I expect they face similar scrutiny.
AI code is competent, but it's not great or high quality unless you have a good enough eye for quality to steer it with an iron hand. But if you do, you know the quality comes from proper guidance, so you still wouldn't say AI code is great. If you do say exactly that, it comes across as having low standards (which is fine if you own it) and people are going to jump on that just to bring you down a peg.
> "I've noticed that the bar for 'quality' when people judge AI is often significantly higher than what they'd hold a human to."
Because that is literally the hype being fed to us by the marketers at the AI companies and HN users promoting AI.
- AI promoters: "AI is doing Ph.D level work! LLMs are not just a token predictor, it is actually thinking and reasoning! It will replace all developers, including _you_, so get on board the AI hype train now!"
- AI promoters when confronted with blatant mistakes and reasoning errors from cutting edge models: "Why are you holding LLMs up to higher standards than humans? That's not fair or reasonable."
I have seen it too. The answer is easy - they don’t like AI. I've seen similar things with some people that don’t like women in tech or certain minorities - they suddenly critique at an extremely high level. I also haven’t looked at this particular case, but it wouldn’t surprise me to be the same thing here.
> I also haven’t looked at this particular case, but it wouldn’t surprise me to be the same thing here.
Be surprised then, because me, who left the critique, probably exclusively programmed with agents for the last year or so, so unlikely I think the code is bad because I "don't like AI". I don't love it either, but wouldn't call myself a AI-hater by any measurements, would be weird to write articles like this if so: https://emsh.cat/en/one-human-one-agent-one-browser/
Again, I wasn't reacting specifically to you (as noted, I wouldn't be surprised if so, but I also wouldn't be surprised if not). I was making a more general statement.
Dude, are you for real? We've had the supposed inevitability of AI rammed down our throats since the minute LaMDA convinced Blake Lemoine it was sentient, we've watched CEOs hype up AI as if it were production-ready while it was still barely beta quality, LLM-driven chatbots have been stapled to the side of every product no matter how little sense it makes since OpenAI published an API, and we've been told to prepare for the inevitable "agentic future" even as Claude 3.5 had to have its hand held more than a wet-behind-the-ears freshman summer intern. We're told that this technology is going to eat the entire world economy and render human labor obsolete, starting with our jobs, but if it's genuinely supposed to do that, I think it's more than reasonable to expect it to write superhumanly perfect code, not just code that's incrementally better than the last model release but still bad; extraordinary claims require extraordinary evidence, after all. To liken AI skepticism to the obstacles faced by women and minorities in tech is a category error that trivializes actual human struggles against human prejudices.
https://github.com/kstenerud/yoloai/blob/main/runtime/regist... <- `Register` embeds a copy of the code from `IsAvailable` because of the locking; that could be replaced with a private `isAvailable` that has no locking that both use (after doing their own locking)
Just out of curiosity, I enabled some other linters and it looks bad. Excluding test files, there are 110 functions with a cyclomatic complexity over 10 and 7 that are _over 50_. The worst is at 86, which is mind-boggling.
Could probably find more, but you get the drift. I'm sure it runs, but stylistically this is more along the lines of what I would expect an intern to do.
This is also sort of nit-picky, but like half the stuff in https://github.com/kstenerud/yoloai/blob/main/docs/dev/backe... isn't idiosyncratic, it's just the way those things work and a lot of them aren't even tricky. The one linked is particularly blatant; that's not limited to os.Stat that's literally just how permissions work. Denying permission on inodes is a property of the folder, not the file.
Claude Code will automatically "dumb" the TUI down a bit when it can't properly detect certain terminal capabilities, to avoid potential font rendering issues.
Likely there are some terminal caps that aren't being properly preserved inside of the sandbox. It's never bothered me since the agent itself works fine.
Did you not expect someone to actually look and critique it?
Whether the visual bugs are a deal breaker or not isn’t the point.
The point is that’s not high quality code, it may work. But it’s not code I would ship at my job and therefore it’s not high enough quality for anyone serious
Hey that's fine. You're free to make whatever judgment you wish.
But I still stand by the quality of my code, including here. You and I don't need to agree.
What decades of managing codebases (public and private, huge and small) has taught me is that there will always be an endless list of bugs and feature ideas and nice-to-haves and technical debt pressures in any given project. You'll never get to them all, so you prioritize (as I have done here). Functional bugs usually trump visual ones unless they're actually interfering with work.
Will I fix this bug? Probably, now that I'm aware of it. But there are more important matters to attend to first.
Edit: Turns out the bug comes from a mismatch with the terminal I'm using. With other terminals it looks fine. Term caps are surprisingly complicated, especially when you have multiple layers!
> You aren’t having a disagreement with a person. You’re having a disagreement with reality.
How so? Are you going to instruct us all on how a termcaps mismatch bug is an indicator of poor code quality, rather than an unfortunate bug emerging from within the chaos of the many layers of disparate technologies that must somehow be stitched together (along with their idiosyncrasies) in order to make a project like this work?
Because you won’t listen to a word anyone says lol.
You had a visual bug right at the top of the repos README. Then insisted you hadn’t noticed it before.
Whats important is not that specific visual bug, it’s what that bug says about the rest of the code.
How can we believe that this code is high quality if we see a glaring issue 5 seconds into opening the github?
We didn’t seek out your repo and start lobbing critiques at it. YOU POSTED IT as an example of high quality generated code. I’m telling you I am unimpressed
Really? So the discussion leading to the theory that there's likely a problem with termcaps disparity between layers didn't happen?
> Whats important is not that specific visual bug, it’s what that bug says about the rest of the code.
Really? So you can tell from a single cosmetic bug which doesn't affect its ability to perform its task, that the rest of the codebase is deficient? That's a pretty damn impressive skill!
Hater's gonna hate, I guess ¯\_(ツ)_/¯
The otherwise timid pack always circles after they sense a single drop of blood, no matter how small and insignificant.
Dude, you have a glaring visual bug that is immediately obvious, as the first thing shown in the repo, and also would be seen every time you tested the tool, but you didn't notice it at all. That does not bode well for you noticing other aspects of quality in the tool. Maybe that's the only quality issue, but we all very seriously doubt it.
I think you can fix that by setting an environment variable (regarding the terminal?) but it was a while since I checked. (I was running Claude as a subprocess and had similar issues.)
Also this reminds me of a principle I learned from a mentor. "People are visual buyers. If it looks good, people will think the code is good."
Unfortunately it doesn't matter whose fault the janky TUI is, people will see that and associate it with your software.
It's more along the lines of: Anyone with an axe to grind will find something to grind it on.
Early stage products will have some rough edges. We've seen that in Docker, Kubernetes, AWS, Azure, LXC, KVM, etc. And people griped and raged about the sheer incompetence of the maintainers and utter lack of quality, but they still used those tools even before the rough edges were polished away and folks finally settled down.
The less one pays for something, the more entitled one feels to whinge and heap on abuse.
I've been down this road so much now that it's no biggie if a few Karens want to blow off steam at my expense. I'm not above exposing their silliness though ;-)
It tackles similar kinds of problems, dealing with idiosyncrasies in Linux distros (and Mac), docker, containers, kata, firecracker, seatbelt, tart, tmux, Claude, the various terminal emulators out there, and trying to herd those cats such that it doesn't blow up in your face.
"This is, unfortunately, how narcissists behave. It's simply impossible for a narcissist to be wrong. They truly believe themselves to be right, all the time, and will even distort reality around them to "make" it true. And they do it all unconsciously." - kstenerud
That's not what this product is; merely a tool it uses.