Rendered at 13:08:09 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
kristopolous 5 hours ago [-]
I've been working on something in a similar class for about a year called llcat
It was born out of the lack of LLM-native unix-friendly tools that work like cURL, awk and sed.
I couldn't find any so I wrote one myself.
I knew I wanted a reference that is stateless, explicit, low-level, and composable without modal settings.
For instance, instead of config files, llcat can index into files with built-in jq-syntax and line numbers. Then it can the save invocations for later:
llcat --load invocation.json { ... parameters you want to override ... }
It's easy to send to colleagues over chat or keep them invocations in a shared network folder.
Conversations are also just JSON files. You can have a different input and output one. This means you can do stuff like
for i in *; do
# use a non-mutable conversation
# apply it over a group of files with standard unix pipes
cat "$i" | llcat --load settings.json -cr context.json > ../results/"${i}.output"
# or use attachments
llcat --load settings.json -a "$i" -cr context.json > ../results/"${i}.output"
# or save the whole context
llcat --load settings.json -a "$i" -cr context.json -c ../results/"${i}.output" > /dev/null
done
Cool product :)
I'm still so gun-shy on using any llm tooling in prod for sysadmin, devops, etc. but frontier models walk circles around me in bash at insane tok/s. cURL and cat + json sounds nice
isodev 5 hours ago [-]
Wait, wasn't codex the "openai cli"?
Their product names are so confusing (chat, vs. work ?!).. almost like the whole thing is vibecoded.
haaz 4 hours ago [-]
Both serve different purposes and I think it's a reasonable distinction to have between products. One is for managing your openai workspace, API, etc, the other is a consumer product. Reasonable to expect an admin to whitelist the openai cli tool but not codex
robertlagrant 4 hours ago [-]
> One is for managing your openai workspace, API, etc
Well, from the page:
> openai images generate --prompt "A tiny orange robot" saves images to ~/Downloads/gpt-images/ and prints their paths, including in pipes.
That doesn't look like "managing the API". It looks like "a consumer product".
I think the real answer is Conway's Law.
raddan 2 hours ago [-]
Codex is interactive. This appears to be batch.
oblio 5 hours ago [-]
It's the logical conclusion of having as the ultimate goal vibe managing a business.
cyanydeez 2 hours ago [-]
i still do not understand the critique of "vibecoded" when talking about organizations and products that are clearly LLM based.
mi_lk 7 hours ago [-]
When should I use this over Codex? Is this supposed to be called by other tools/agents?
imdsm 7 hours ago [-]
Codex = agent harness
OpenAI CLI = wrapper around API
theanonymousone 7 hours ago [-]
> wrapper around API
aka curl? :-/
mohsen1 5 hours ago [-]
to be fair `gh` works so much better for me than crafting curl requests (even with LLMs)
tomrod 57 minutes ago [-]
Showing some grey hairs here -- is gh here the github cli or something else/newer?
istjohn 43 minutes ago [-]
Yes
BikiniPrince 6 hours ago [-]
Curl with token usage so it’s better.
NothingAboutAny 6 hours ago [-]
that was my assumption, maybe you use Claude but want it to use OpenAI image generation or something.
this got a physical shrug out of me.
guyuedumingx 5 hours ago [-]
The claim that the name alone explains the tool is weak: a CLI wrapper still needs one line stating what problem it solves and who should use it.
hahahacorn 7 hours ago [-]
I imagine the play is RL your model to solve problems using your own tools which it knows how to use most efficiently until it defaults to using services like managed agents, etc.
Honestly surprised this wasn't available sooner.
bluegatty 5 hours ago [-]
2 trillion dollar company can't put 1 single sentence describing what something is, why it's useful, what it's for - instead barfs technical jargon.
It's like if someone handed you an arcane set of page 20-40 of an IKEA assembly manual and expected you to be excited.
About what? Exactly?
Traster 5 hours ago [-]
To be fair, I don't think they do want you to be excited. They have a REST API. It does the obvious things a REST API would do with OpenAI - lets you interact with openai models via a REST API. This is a CLI for it. There's really nothing to describe that isn't in the name, it's the CLI for the OpenAI Rest API. If you don't already care about the REST API then this isn't really for you.
bluegatty 5 hours ago [-]
There is no conscientious reasoning here on their part - it's not 3D chess it's 0D chess.
It's lazy at a guttural level.
This is 'totally absent product management, even the utterly basic things a regular developer would think to do without professionals to support them'.
This would not even pass muster as Open Source for friends, or internal use.
whh 5 hours ago [-]
It's very likely come out of necessity. It doesn't need to look pretty.
bluegatty 3 hours ago [-]
No, this is not 'missing helpful information' - it's missing 'essential information'.
It takes about 10 minutes of focus and attention from someone who understands the product to make a quick coherent introduction and overview, which is essential and very valuable.
There is no time/value trade-off equation where it doesn't make sense to provide that.
* This is from a company trying to convince us that their AI can automate many jobs *
It's almost disturbing is that people could see this otherwise.
"Our AI will dramatically improve your productivity but we can't even leverage it to do the most rudimentary and basic things" is a message that implies a lack of credibility.
5 hours ago [-]
hk__2 2 hours ago [-]
It’s right there in the description: "Official CLI for the OpenAI API". There’s nothing to be excited about, it’s just a CLI for an API.
logicallee 5 hours ago [-]
it's a zero dollar company. OpenAI is a virus. It's a liability. The code almost certainly contains some trivial backdoors, since their entire infrastructure is backdoored.
(just the first file I looked at.) it's obviously half of a backdoor. Some other process somewhere happens to give the other half.
arbll 5 hours ago [-]
bru what ? This is just a standard `go run` wrapper to run the CLI lol
ckx 3 hours ago [-]
So it's just Codex?
qeternity 2 hours ago [-]
No, this is an account/workspace management CLI.
Traster 5 hours ago [-]
It's kind of interesting that they're releasing this, because anyone with access to the OpenAI RestAPI has probably already vibe coded an equivalent to this. It's a trivial thing to bootstrap.
bluegatty 5 hours ago [-]
It's easy to vibe code a kind of messy thing that works, very had to maintain and improve pure vibed stuff.
SOLAR_FIELDS 3 hours ago [-]
Is it actually hard to maintain a REST wrapper though? I think it is actually quite easy to maintain and improve something as simple as this as a pure vibe code project. I do it all the time
bluegatty 2 hours ago [-]
Yes, for pure 1:1 mappings should be possible.
albert_e 6 hours ago [-]
Does this consume the monthly flat rate subscription quota or API credits.
Does Anthropic have something similar.
I understand "claude -p" has been unreliable to use with subscription quota and often required "extra usage" credits.
walthamstow 4 hours ago [-]
claude -p has never actually been charged as extra usage. They announced a plan to do so then shelved it quietly.
5 hours ago [-]
bobm_kite9 4 hours ago [-]
Amazing that they're able to vibecode this kind of stuff together in a couple of days, but how is it possible there's no API for organising my ChatGPT chats at all?
Welcome to a new kind of lock-in I guess
throw20261022 7 hours ago [-]
Be careful getting too deep in OpenAI tooling because they end up deprecating almost everything in under two years, sometimes without even a formal notice.
Everything they make these days looks to be strongly vibecoded without a decent review or functional testing. This leads to basic avoidable bugs that annoy vast numbers of users.
Not only this, but when you point out an issue to them on GitHub, they have a history of blocking the reporting user instead of tackling the technical issue.
eddythompson80 6 hours ago [-]
At this point, it’s safe to assume all net-new software is vibecoded. Who in their right mind would take a month to create an MVP when a bot can spit it out in an afternoon? Existing software isn’t necessarily immune, but there are still individuals that are fighting (or resisting the change) to keep their code base human readable. It’s a losing battle. Eventually those people are either gonna change their minds, leave or be pushed out. Then the agents will be unleashed upon those code bases too.
kikdij 6 hours ago [-]
Saying "surely, everybody does X" is a sure way to be wrong. You're even spectacularly failing at making your own point by acknowledging in the very same comment that there are, in fact, people not doing it. Some people are different from you, deal with it.
That being said, it's true than we can assume most of new software are generated. No need for hyperbole on that. An interesting fact is that it makes grandfather's concern moot: people who are generating their code don't care much if a dependency goes unmaintained, they can have it replaced by an other one in matter of minutes.
There's an other objection to openai-cli we could raise, though: why use a generalist developer tool, containing probably hundred of features we don't need, when we could make a bespoke specialized version, perfectly fit to us, in like 25 minutes? I can get that there are audiences where this would not even come to mind to the users, but we're talking about a developer tool, here. The value of that is questionable. And ironically, those who might from benefit it the most are those who don't want to generate their code.
bryanrasmussen 5 hours ago [-]
they didn't say "surely everybody does" they said "safe to assume all", when really what they should have said is "safe to assume any" meaning any that you encounter and consider using.
I think it makes sense as a reasonable heuristic going forward, assume the MVP was vibe coded or nearly vibe coded (a weeks worth of human / agent work together, then initial release)
kikdij 5 hours ago [-]
Considering that "it's safe to assume everybody does X" while perfectly knowing "there are actually many people who don't, but who cares" is honestly kind of militant conformism. You can expect it without assuming.
eddythompson80 5 hours ago [-]
You put it better than me
Chyzwar 6 hours ago [-]
This is not unique problem to vibecoding. Google was killing products before LLM and forcing you into deprecation churn loop for years. Problem is companies without strategy trying things and then moving to next shiny thing.
I am still salty about anthropic killing Claude design in December.
yuchi 5 hours ago [-]
Claude Design was/is absolutely brilliant. The embedded skill in work and code is capable but the experience of Claude design was so much cleaner.
5 hours ago [-]
5 hours ago [-]
anonymous908213 6 hours ago [-]
> Who in their right mind would take a month to create an MVP when a bot can spit it out in an afternoon
The people who need something more than an MVP, I would suppose. Bot sure does spit out a prototype faster than any human can, but actually building on that dogshit prototype becomes slower than someone with a clue writing by hand.
roncesvalles 5 hours ago [-]
There is a difference between wanton "vibecoding" and AI-assisted coding.
The latter still gives you many-X productivity improvement while the quality is pretty close to handwritten code.
LLMs are still not good enough where you can unleash it upon a huge codebase and get good results btw. Quality goes to shit once a context uses up around 50k-100k tokens. That's often only enough for one feature change and whatever validation the LLM wants to do for it.
It's fair to say that most new software is written with AI help, but that doesn't mean someone just prompted a few things and pressed deploy.
tmp10423288442 3 hours ago [-]
> LLMs are still not good enough where you can unleash it upon a huge codebase and get good results btw.
Let’s just say that both OpenAI and Anthropic strongly disagree with this, in theory and in practice.
pianopatrick 6 hours ago [-]
Yeah, but then you get the user's side. Will users really trust and rely on software that was vibe coded in an afternoon? Maybe for games, but for something like a CLI you would depend on - do you want to depend on someone's vibe coded in an afternoon project?
eddythompson80 5 hours ago [-]
I don't know the answer. I suspect the answer today is yes for any "boxed" products like CLIs, desktop apps, mobile apps, simple client side apps, SDKs, etc. Complex services that have a livesite and deployment orchestration and numerous moving parts are still struggling, but everyone is pushing there too anyway.
As for users, I think it depends on the individual users. A lot of the time users abstract your software as a blackbox. It either works or it doesn't, and as long as you can fix it quickly and they get every bizarre feature ask answered quickly, that's all what some care about.
Personally, I have an all times low trust in the software I run. I used to cruise Show HN, /r/selfhosted, and GitHub Trending for cool new software to play with, learn from, or get inspired by. I don't anymore because I see what agents generate at work all day long.
There used to be this old joke among us programmers that we think it's insane that people trust their life to software when we all know how buggy it all can be. It was true, but also we knew that we can eventually get decent enough software. This is also out of the window now. Everything on all those places is a vibecoded thing generated in a couple of hours and no one knows what code is in there. It'll only get worse.
pianopatrick 5 hours ago [-]
Personally I think the Debian model of software distribution looks more and more appealing.
I.e. I think I could trust vibe coded software more if it had been version frozen to bug fixes only and used by a lot of people for a few months or so.
aenis 5 hours ago [-]
Sure they will. Case in point: Claude Code. I think its being vibe coded every afternoon, and indeed lots of programmers gladly take it with its various and often-changing quirks and small bugs. No biggie, it still gets the job done.
ky-hy 5 hours ago [-]
99% of people don't care, it's us programmers that are living in a bubble thinking that other people prioritize same stuff as we do. So yes, people won't care and will depend on someone's vibe coded apps, just like they use Windows, Adobe and whatnot even though those suck.
rkuodys 6 hours ago [-]
While I agree with the premise, I would argue with the conclusion. Yes agents can and do code fast. But if you're integrating software in business where people work in some patterns, more often than not there are "real life" happening. You learn that only by operating a system long enough to know these things. And competence accumulates, and the value of provider increases with the learned patterns. I think many devs live in tech world which is sometimes detached from physical world, world where people actually has to do some work, which takes time and system working in technical sense, doesnt work in practical sense.
orphereus 6 hours ago [-]
This type of comments is making me insane.
eddythompson80 6 hours ago [-]
I don't really know what to say tbh. I feel insane at times too but I'm being a realist and a pragmatist. I think I'm in the "changed their mind" camp because I got tired of fighting and can't deny reality. It is a losing battle. All approaches to manage changes in a traditional way also don't work. I have seen people who left because they can and I might follow suit too.
Like I think (or know) code reviews are also over. Someone asks me for a 10-11am brainstorming meeting regarding a concept they are working on, at 11:15 they have a "design doc" ready, at 1pm they ping me if I had a chance to review it yet, at 3pm I approve it, at 3:30pm they send a 7k line PR... "dude, that's not ok. I'm not reviewing 7k line change" so they say "oh yes absolutely sorry about that. that makes a lot of sense. Do you want 7 1k-line PRs? or 14 500-line PRs?" "hey Claude, split this into 10 commits and open 10 stacked PRs" :|
solyin 5 hours ago [-]
> Like I think (or know) code reviews are also over.
Whatever the size of code review chosen, merging totally unreviewed code to prod is still totally insane. There are a few AI code review products out there. The one I've used is fairly decent at picking out issues, though there's definitely some shortcomings vs a human reviewer with additional context (especially since not everything is written down for the bot to access). So I wouldn't say they are over. Even though the AI review isn't perfect, we all know human reviews aren't either.
As AI improves it'll be able to hold more of the codebase as context, enabling better, quicker reviews.
raddan 2 hours ago [-]
Whether code review is inportant or not probably depends on whether the problem someone is solving is important or not. But when it is important, I think we should be putting the onus on the person who filed the PR instead of burning our own neurons trying to understand volumes of stuff. Tell me what you asked the AI to do. Why is that a good idea? Once I hear that answer (because many junior programmer ideas don’t even get past that point), let’s look at the code together. Tell me why you think the code you submitted does what you say. Did you look at the code? Did you write tests? Did you check for test coverage? Maybe you’re a little smarter than that. Did you think through pre- and post-conditions? Corner cases? Are certain undesirable behaviors impossible? How do you enforce that? Types? State machines?
Even before slop coding good code review was hard, because verification is a hard problem. But we have many tools at our disposal to increase confidence without having to go full-on mathematical proof. Human understanding has always been the bottleneck, and as long as the thing you are doing is for humans, humans will have good reasons to want to understand it, so they will remain the bottleneck. This is ok. It’s ok for humans to be the rate-limiter. But don’t go it alone and fry your own brain.
skydhash 52 minutes ago [-]
> Even before slop coding good code review was hard, because verification is a hard problem. But we have many tools at our disposal to increase confidence without having to go full-on mathematical proof. Human understanding has always been the bottleneck, and as long as the thing you are doing is for humans, humans will have good reasons to want to understand it, so they will remain the bottleneck.
When people rally agains AI, that is why. AI hypers think it’s about the actual coding. It is not. It’s about the understanding and what you built is logically sound, conceptually and concretely. The code aspect matters only for maintenance sake and verifying the logical structure.
Which is why good devs are burning out on this. The PR authors don’t care, management don’t care, so to not be between a rock and an hard place, you just LGTM the review. And then users are suffering with insane bugs.
stavros 4 hours ago [-]
Yeah but who writes totally unreviewed code nowadays? Everyone I know doesn't commit until a model has reviewed the code that another model wrote.
frevib 6 hours ago [-]
This type of comments gives me the impression that HN is riddled with AI marketing bots.
oblio 3 hours ago [-]
Amusingly, you can use LLMs to analyze a user's posting history to try to determine if they're a shill.
redanddead 6 hours ago [-]
Most people are practical
jiggawatts 6 hours ago [-]
Reality is making you question your sanity.
The comments are just accurately describing that new, insane reality.
rusticpenn 5 hours ago [-]
There are different ways of using AI. Experienced software developers can easily still test their "vibe coded" app for most common bugs.
>Eventually all the people who hate this kind of thing are going to be dead, and the ones who use it are going to be in control.
The West has fallen.
eddythompson80 5 hours ago [-]
There was a generation of programmers who obsessed about memory alignment, bit packing, SoA vs AoS, memory arenas, handwritten assembly, etc. For well over a decade now, a todo app would take 800MB in RAM, but it has really cool mark-done animation so people would use it. If it's slow on your machine, get the new i7 or M58 mac to experience this awesome todo app.
vasco 6 hours ago [-]
I'm so curious what you do when the providers go down. Do you tell your boss you can't fix the incident because your token quota is out?
bojan 6 hours ago [-]
Sort of, that's the mindset you get because you've no clue how the app actually works.
We have a 100% vibe-coding team, and yes, when they couldn't pass through the CI/CD at some point, they contacted the Ops team and literally said "the agent said the problem is on your side".
geraldwhen 6 hours ago [-]
…yes? This is the equivalent of an electrician showing up to your house without tools.
It would be faster to setup a deepseek locally hosted instance or glm than try and build by hand, assuming all hosted providers were down somehow.
Which is to say, there is no token quota. If you run out you buy more.
kikdij 6 hours ago [-]
How many times have you heard "we can't work because GitHub is down?". This has nothing to do with AI, and yes, it's commonplace.
Not to mention the "yes, there's a bug. We opened a ticket to the maintainer. Now we wait".
ilteris 6 hours ago [-]
This reminded me my dad's story. "In highschool we used to tell our teachers we couldn't do our homework because lights were out." Take anyway you want.
Lucasoato 5 hours ago [-]
In MacOS there are two ChatGPT apps. The new one and the old one called ChatGPT classic. No matter how hard I try, I can’t get the new one to work with either the “live” realtime mode or the vocal transcription feature.
It’s absurd, I have the latest OS version, a M4 MacBook, but the new app seems to be buggy as hell.
Is this the new software quality standard we should expect from a company that is worth billions (if not trillions)?
oblio 5 hours ago [-]
> Is this the new software quality standard we should expect from a company that is worth billions (if not trillions)?
For a while, yes.
BikiniPrince 6 hours ago [-]
It’s all greenfield and I’m not surprised to see deprecation. Eventually tooling will distill into what works.
krm01 5 hours ago [-]
This has become the new standard, better get used to it. You have to stay on your feet no matter what technology you use. The time of picking one and sticking with it for years is long gone.
lionkor 5 hours ago [-]
> You have to stay on your feet no matter what technology you use
This was said about web technologies and crypto and every other hype cycle, and it's never been true at all. The vast majority of people are okay just picking something reasonable or a default, and sticking with it.
It's not difficult to imagine that pi.dev will be around in 10 years, and it's not difficult to imagine that vim, visual studio, vscode, linux and ext4 will still be around in 10 years.
I don't know what kind of massive innovation you see here. This is like flying cars; every couple years there's a demo of a flying car of some variety, some people immediately short mercedes, and 5 years later mercedes is still around, making slightly more modern cars than before.
If you really believe that the tech-news hype cycle reflects reality, I urge you to go solve an advent of code in a normal programming language, maybe that'll help get you back on track.
solyin 4 hours ago [-]
The reality of that is that ChatGPT in 2022 wasn't very good at Advent of Code. In 2025, it's much more capable. (AoC officially recommends not using AI at all. Which you shouldn't, so your brain gets exercise.)
> it's never been true at all.
Like, at all? The problem with "never" is entire platforms get deprecated and people get laid off. So sure, you can have a job in $technology for as long as you've got that job, but if you get laid off but $technology is deprecated, you're in for a bit of a rough patch.
For reference, here's a couple of $technologies that, 10 years ago, you have gotten a job in, but if you were laid off recently, you'll have a tougher time finding a job in:
(Not saying it's impossible, just that you said "never" and "at all" so you'd have to get really lucky.)
lionkor 2 hours ago [-]
That's precisely the result of jumping on "the shiny new thing", yeah! That's my point!
xnickb 7 hours ago [-]
Makes sense. Very hard for humans to keep up with LLM-generated code. But LLMs/Agents have no problem with this. So they are using the dev style that would drive their business towards generating more money. A funny concept for a non-profit organization.
ywvcbk 7 hours ago [-]
I don't see how buggy software directly leads to generating more money? A company being successful doesn't somehow magically make them infallible, 100% rational or immune to making mistakes (as you are implying).
XenophileJKO 6 hours ago [-]
I don't know why people keep harping on buggy software.. it really is the average not the exception. I mean we see this with all the defects in existing software that agents find.
I love how people all pretend that they and most engineers are god like programmers. Sure, some people are really good. My 30 years of experience say that is like 5%, maybe if you are at google or a really good start up, that can creep up to 30-50%.
By far the majority of engineers are not elegant or even really craftsman like. Add to this that unless you are working on a pet project you are usually neck deep in something that has had teams working in it for years.
It creates situations where most engineers don't really know what the code base does below the surface area where they are making feature changes. So work gets cobbled on or patched in where people are comfortable making changes.
All I can say is I would much rather have 3 open Opus 5.5 instances than a team of 3 working for me if we are only talking about delivering high quality code. I don't think that is the only value of engineers, but I think we are at a point where the models have way exceeded average engineer ability. There are still tendencies for "compatability everything" and "don't rock the boat" in the current frontier LLMs that can create architectural issues, but if you know what to look for when working, it isn't generally an issue.
I mean just remember how mush everyone complained about buggy games or MacOs or whatever before LLMs even came around.
6 hours ago [-]
xnickb 5 hours ago [-]
> as you are implying
I am not implying that at all. All I'm saying is that humans can't keep up with LLM/agent rates of code generation but agents come, so what is unusable for humans is ok for LLMs.
And LLMs being required is very profitable to those who sell LLMs.
Never did I imply any bugs
lionkor 5 hours ago [-]
> Very hard for humans to keep up with LLM-generated code
Not at all. It's hard to keep up with lines of code per day, i.e. quantity.
It's not difficult for humans to keep up with the quality, and produce far superior quality code by writing it themselves or instructing an LLM what exactly to implement, down to each function's API surface (if typing is the bottleneck).
A lot of you people are forgetting that there's an engineering aspect to programming, and LLMs are really really really terrible at it out of the box.
Let's say you can let AI design and 3D print 1 large real-life bridge per week. Would you say that humans can't keep up? Or would you point out that there's a difference between what civil engineers do and what an LLM with a 3D printer does?
6 hours ago [-]
Yokolos 5 hours ago [-]
It's sort of nuts how bad the Codex app is. In a month, I've "vibe-coded" my own replacement which does everything I care about significantly better, especially their remote chat functionality which just feels completely half-baked and broken. And I'm not getting a 6 figure salary to work on it. I don't understand what they're doing.
It was born out of the lack of LLM-native unix-friendly tools that work like cURL, awk and sed.
I couldn't find any so I wrote one myself.
I knew I wanted a reference that is stateless, explicit, low-level, and composable without modal settings.
For instance, instead of config files, llcat can index into files with built-in jq-syntax and line numbers. Then it can the save invocations for later:
and then It's easy to send to colleagues over chat or keep them invocations in a shared network folder.Conversations are also just JSON files. You can have a different input and output one. This means you can do stuff like
One of my favorite patterns is this one: Since there's no hidden state you can use llcat in shell scripts and get operational guarantees.I've put a lot of effort into it and use it daily. If you can give it a go and give me feedback and file bugs, I'd love it.
https://github.com/day50-dev/llcat
Well, from the page:
> openai images generate --prompt "A tiny orange robot" saves images to ~/Downloads/gpt-images/ and prints their paths, including in pipes.
That doesn't look like "managing the API". It looks like "a consumer product".
I think the real answer is Conway's Law.
OpenAI CLI = wrapper around API
aka curl? :-/
Honestly surprised this wasn't available sooner.
It's like if someone handed you an arcane set of page 20-40 of an IKEA assembly manual and expected you to be excited.
About what? Exactly?
It's lazy at a guttural level.
This is 'totally absent product management, even the utterly basic things a regular developer would think to do without professionals to support them'.
This would not even pass muster as Open Source for friends, or internal use.
It takes about 10 minutes of focus and attention from someone who understands the product to make a quick coherent introduction and overview, which is essential and very valuable.
There is no time/value trade-off equation where it doesn't make sense to provide that.
* This is from a company trying to convince us that their AI can automate many jobs *
It's almost disturbing is that people could see this otherwise.
"Our AI will dramatically improve your productivity but we can't even leverage it to do the most rudimentary and basic things" is a message that implies a lack of credibility.
Edit: look at this crap for example:
https://github.com/openai/openai-cli/blob/main/scripts/run
(just the first file I looked at.) it's obviously half of a backdoor. Some other process somewhere happens to give the other half.
Does Anthropic have something similar.
I understand "claude -p" has been unreliable to use with subscription quota and often required "extra usage" credits.
Welcome to a new kind of lock-in I guess
Everything they make these days looks to be strongly vibecoded without a decent review or functional testing. This leads to basic avoidable bugs that annoy vast numbers of users.
Not only this, but when you point out an issue to them on GitHub, they have a history of blocking the reporting user instead of tackling the technical issue.
That being said, it's true than we can assume most of new software are generated. No need for hyperbole on that. An interesting fact is that it makes grandfather's concern moot: people who are generating their code don't care much if a dependency goes unmaintained, they can have it replaced by an other one in matter of minutes.
There's an other objection to openai-cli we could raise, though: why use a generalist developer tool, containing probably hundred of features we don't need, when we could make a bespoke specialized version, perfectly fit to us, in like 25 minutes? I can get that there are audiences where this would not even come to mind to the users, but we're talking about a developer tool, here. The value of that is questionable. And ironically, those who might from benefit it the most are those who don't want to generate their code.
I think it makes sense as a reasonable heuristic going forward, assume the MVP was vibe coded or nearly vibe coded (a weeks worth of human / agent work together, then initial release)
I am still salty about anthropic killing Claude design in December.
The people who need something more than an MVP, I would suppose. Bot sure does spit out a prototype faster than any human can, but actually building on that dogshit prototype becomes slower than someone with a clue writing by hand.
The latter still gives you many-X productivity improvement while the quality is pretty close to handwritten code.
LLMs are still not good enough where you can unleash it upon a huge codebase and get good results btw. Quality goes to shit once a context uses up around 50k-100k tokens. That's often only enough for one feature change and whatever validation the LLM wants to do for it.
It's fair to say that most new software is written with AI help, but that doesn't mean someone just prompted a few things and pressed deploy.
Let’s just say that both OpenAI and Anthropic strongly disagree with this, in theory and in practice.
As for users, I think it depends on the individual users. A lot of the time users abstract your software as a blackbox. It either works or it doesn't, and as long as you can fix it quickly and they get every bizarre feature ask answered quickly, that's all what some care about.
Personally, I have an all times low trust in the software I run. I used to cruise Show HN, /r/selfhosted, and GitHub Trending for cool new software to play with, learn from, or get inspired by. I don't anymore because I see what agents generate at work all day long.
There used to be this old joke among us programmers that we think it's insane that people trust their life to software when we all know how buggy it all can be. It was true, but also we knew that we can eventually get decent enough software. This is also out of the window now. Everything on all those places is a vibecoded thing generated in a couple of hours and no one knows what code is in there. It'll only get worse.
I.e. I think I could trust vibe coded software more if it had been version frozen to bug fixes only and used by a lot of people for a few months or so.
Like I think (or know) code reviews are also over. Someone asks me for a 10-11am brainstorming meeting regarding a concept they are working on, at 11:15 they have a "design doc" ready, at 1pm they ping me if I had a chance to review it yet, at 3pm I approve it, at 3:30pm they send a 7k line PR... "dude, that's not ok. I'm not reviewing 7k line change" so they say "oh yes absolutely sorry about that. that makes a lot of sense. Do you want 7 1k-line PRs? or 14 500-line PRs?" "hey Claude, split this into 10 commits and open 10 stacked PRs" :|
Whatever the size of code review chosen, merging totally unreviewed code to prod is still totally insane. There are a few AI code review products out there. The one I've used is fairly decent at picking out issues, though there's definitely some shortcomings vs a human reviewer with additional context (especially since not everything is written down for the bot to access). So I wouldn't say they are over. Even though the AI review isn't perfect, we all know human reviews aren't either.
As AI improves it'll be able to hold more of the codebase as context, enabling better, quicker reviews.
Even before slop coding good code review was hard, because verification is a hard problem. But we have many tools at our disposal to increase confidence without having to go full-on mathematical proof. Human understanding has always been the bottleneck, and as long as the thing you are doing is for humans, humans will have good reasons to want to understand it, so they will remain the bottleneck. This is ok. It’s ok for humans to be the rate-limiter. But don’t go it alone and fry your own brain.
When people rally agains AI, that is why. AI hypers think it’s about the actual coding. It is not. It’s about the understanding and what you built is logically sound, conceptually and concretely. The code aspect matters only for maintenance sake and verifying the logical structure.
Which is why good devs are burning out on this. The PR authors don’t care, management don’t care, so to not be between a rock and an hard place, you just LGTM the review. And then users are suffering with insane bugs.
The comments are just accurately describing that new, insane reality.
>Eventually all the people who hate this kind of thing are going to be dead, and the ones who use it are going to be in control.
The West has fallen.
We have a 100% vibe-coding team, and yes, when they couldn't pass through the CI/CD at some point, they contacted the Ops team and literally said "the agent said the problem is on your side".
It would be faster to setup a deepseek locally hosted instance or glm than try and build by hand, assuming all hosted providers were down somehow.
Which is to say, there is no token quota. If you run out you buy more.
Not to mention the "yes, there's a bug. We opened a ticket to the maintainer. Now we wait".
It’s absurd, I have the latest OS version, a M4 MacBook, but the new app seems to be buggy as hell.
Is this the new software quality standard we should expect from a company that is worth billions (if not trillions)?
For a while, yes.
This was said about web technologies and crypto and every other hype cycle, and it's never been true at all. The vast majority of people are okay just picking something reasonable or a default, and sticking with it.
It's not difficult to imagine that pi.dev will be around in 10 years, and it's not difficult to imagine that vim, visual studio, vscode, linux and ext4 will still be around in 10 years.
I don't know what kind of massive innovation you see here. This is like flying cars; every couple years there's a demo of a flying car of some variety, some people immediately short mercedes, and 5 years later mercedes is still around, making slightly more modern cars than before.
If you really believe that the tech-news hype cycle reflects reality, I urge you to go solve an advent of code in a normal programming language, maybe that'll help get you back on track.
> it's never been true at all.
Like, at all? The problem with "never" is entire platforms get deprecated and people get laid off. So sure, you can have a job in $technology for as long as you've got that job, but if you get laid off but $technology is deprecated, you're in for a bit of a rough patch.
For reference, here's a couple of $technologies that, 10 years ago, you have gotten a job in, but if you were laid off recently, you'll have a tougher time finding a job in:
Apache Mesos -> Kubernetes. Xamarin (mobile dev). Hadoop -> Databricks. Ember.js.
(Not saying it's impossible, just that you said "never" and "at all" so you'd have to get really lucky.)
I love how people all pretend that they and most engineers are god like programmers. Sure, some people are really good. My 30 years of experience say that is like 5%, maybe if you are at google or a really good start up, that can creep up to 30-50%.
By far the majority of engineers are not elegant or even really craftsman like. Add to this that unless you are working on a pet project you are usually neck deep in something that has had teams working in it for years.
It creates situations where most engineers don't really know what the code base does below the surface area where they are making feature changes. So work gets cobbled on or patched in where people are comfortable making changes.
All I can say is I would much rather have 3 open Opus 5.5 instances than a team of 3 working for me if we are only talking about delivering high quality code. I don't think that is the only value of engineers, but I think we are at a point where the models have way exceeded average engineer ability. There are still tendencies for "compatability everything" and "don't rock the boat" in the current frontier LLMs that can create architectural issues, but if you know what to look for when working, it isn't generally an issue.
I mean just remember how mush everyone complained about buggy games or MacOs or whatever before LLMs even came around.
I am not implying that at all. All I'm saying is that humans can't keep up with LLM/agent rates of code generation but agents come, so what is unusable for humans is ok for LLMs.
And LLMs being required is very profitable to those who sell LLMs.
Never did I imply any bugs
Not at all. It's hard to keep up with lines of code per day, i.e. quantity.
It's not difficult for humans to keep up with the quality, and produce far superior quality code by writing it themselves or instructing an LLM what exactly to implement, down to each function's API surface (if typing is the bottleneck).
A lot of you people are forgetting that there's an engineering aspect to programming, and LLMs are really really really terrible at it out of the box.
Let's say you can let AI design and 3D print 1 large real-life bridge per week. Would you say that humans can't keep up? Or would you point out that there's a difference between what civil engineers do and what an LLM with a 3D printer does?