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.
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.
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.
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" :|
> 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.
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.
> 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.
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.
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".
> 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.
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.
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.
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)
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.
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?
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.
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.
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.
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.
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.
> 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.
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:
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.
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)?
I'm sorry but who expects an AI workflow to behave the same for 2+ years? Do you remember the state of LLMs and agentic tools two years ago? If you are expecting stability you are in the wrong segment of tech. Come back in 5 years when things have matured and you'll start to see stable, boring releases.
My experience matches your claim, but I've seen others recently claim cli use (shelled out from another harness though) showing clear extra-data billing.
And I'm fairly sure Anthropic did implement that though, at least for Claude SDK (which is/was a wrapper around claude -p); I was using the sdk for a product, and had a demo to show/ensure it was billed via subscription. I basically unset any API env vars, ensured the cli credential was in place, and spawned agents and watched the logs. When I re-ran it during that time period, it clearly went to extra data (there are messages in response logs calling it out).
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
It's a generic insult that a lot of people throw out, but when they're using the term seriously, they mean that the code doesn't get properly reviewed by a human. It probably still gets QA'd by a human, but in the final form, not reading the code.
AI-assisted generally means that a human is reviewing the code, though there's a lot of doubt about how well that can really be done with the amount of code an AI can output. It's generally capable of being as fast or faster than a human can review it.
> but when they're using the term seriously, they mean that the code doesn't get properly reviewed by a human
"vibecoded" is also a synonim for incomplete, messy, lacks cohesion, vision. In this case, I think OpenAI partially duplicates without superseding one of the CLIs with another (and same for their different chat modes... remember they had 3 not long ago).
How is the difference not obvious to you just from the name? Do you think that every CLI is an interactive agentic application? Sorry, but this is baffling.
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
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.
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?
For a site focused on technical users, seems like a lot of people in this thread are completely lost at the idea that a single service may offer multiple pieces of software dedicated to specific use-cases.
codex: OpenAI's agent harness. The thing you typically want to interact with when you want an agent powered by OpenAI models to do stuff on your machine. Abstracts the low-level functionality of their API so you don't have to worry about it.
openai-cli: A simple CLI exposing low-level operations against OpenAI's REST API. The thing you'd use for creating lower-level scripts to directly call the completions API, administer accounts, etc.
Honestly, this is obvious by the name alone. If it's not clear to you, then this isn't for you. No need to get worked up about OpenAI releasing a piece of software where you're not the audience.
The difference is clear for some humans. I dig it.
This is not AX (agent experience) friendly (and for some humans here too).
There is no "why" or "when" to use it in the documentation. We humans need to figure out why this is needed at what occassion to AIs.
So my point here is the bad README.
If there is an ambiguous in the doc, and what you conside ris "obvious" is not obvious for some. It's a bad doc.
-----
If I were to use this, I first have to instruct, hey Codex, for low-level API calls to bypass your harness,
1. Read docs on OpenAI CLI: (and you provide why Codex would need it)
2. install OpenAI CLI
3. Call low level APIs: instruct when to do this over going thru codex harness
It supports json/jsonl output and verbose command/subcommand help; there's a lot of churn in "how do I create clis for AX" right now, I don't know if you can point to what's good or bad beyond "machine/digestible and progressively disclosed".
Recently did a quick experiment using four python cli libraries with codex, fairly big cli surface, well-typed code with docstrings, and the differences were negligible- it came down to those two qualities specifically, and the means to those ends didn't really matter. Obviously anecdata though.
The "neg diff" you see is either your harness is so well done that it takes that crappy REAME without an issue or So bad that your Harness doesn't make a diff.
You need try another experiment with more better/specific README to see if it makes a diff. If it does, then yes, README sucks else your claim would be correct.
As your experiement was "quick", I cannot really buy into your experiement yet.
The code examples from their own website show the use of cURL and this CLI are roughly as verbose. Not sure I understand the need for maintaining a CLI.
openai responses create \
--model gpt-6-astra \
--input "Write a short bedtime story about a unicorn." \
--raw-output \
--transform 'output.#(type=="message").content.0.text'
Versus
curl https://api.openai.com/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "gpt-6-astra",
"input": "Write a short bedtime story about a unicorn."
}'
The interesting thing is that the cost of implementation is low for everyone, not just OpenAI. You could vibe code this project in maybe 10 minutes with a $20 Codex subscription, and a couple scheduled prompts a week would keep it up to date. So is it still valuable? Probably, but the economics of tools like these are definitely not the same anymore.
What's the point to provide it with Apache 2.0? It's likely going to get sucked into the LLM training or inference process sooner rather than later. By that time license is no longer going to matter.
101 comments
[ 1.5 ms ] story [ 13.5 ms ] threadHonestly surprised this wasn't available sooner.
OpenAI CLI = wrapper around API
aka curl? :-/
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.
The comments are just accurately describing that new, insane reality.
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.
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.
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".
Not to mention the "yes, there's a bug. We opened a ticket to the maintainer. Now we wait".
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.
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.
I didn't hear about this, is Claude Design being killed?
>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.
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.
Let’s just say that both OpenAI and Anthropic strongly disagree with this, in theory and in practice.
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.)
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)?
Does Anthropic have something similar.
I understand "claude -p" has been unreliable to use with subscription quota and often required "extra usage" credits.
And I'm fairly sure Anthropic did implement that though, at least for Claude SDK (which is/was a wrapper around claude -p); I was using the sdk for a product, and had a demo to show/ensure it was billed via subscription. I basically unset any API env vars, ensured the cli credential was in place, and spawned agents and watched the logs. When I re-ran it during that time period, it clearly went to extra data (there are messages in response logs calling it out).
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.
AI-assisted generally means that a human is reviewing the code, though there's a lot of doubt about how well that can really be done with the amount of code an AI can output. It's generally capable of being as fast or faster than a human can review it.
"vibecoded" is also a synonim for incomplete, messy, lacks cohesion, vision. In this case, I think OpenAI partially duplicates without superseding one of the CLIs with another (and same for their different chat modes... remember they had 3 not long ago).
OpenAI are trying stuff out to see what sticks. The big goal product vision is AGI, not the purity of the interfaces to it.
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?
If that’s not clear then you’re probably not the target audience for this.
It came out of a lack of their being an LLM-native tool that feels like cURL or other unix-friendly things such as awk or sed.
I wanted something stateless, explicit, low-level, and composable without "settings" just like you don't with grep or sort.
Instead, you can index into files with jq or line numbers and save invocations for later for instance
and then Conversations are stored as JSON files and you can have a different one input and output. This means you can do stuff like And use a non-mutable conversation to apply the same context over a group of files.Since there's no hidden state you can use it in shell scripts and get operational guarantees.
For instance, I have this line in a separate project
I've put a lot of effort into this and use it daily. I really wish people would give it a go and give me feedback and file bugs!https://github.com/day50-dev/llcat
> The official CLI for the OpenAI REST API.
Did you read the readme?
Welcome to a new kind of lock-in I guess
codex: OpenAI's agent harness. The thing you typically want to interact with when you want an agent powered by OpenAI models to do stuff on your machine. Abstracts the low-level functionality of their API so you don't have to worry about it.
openai-cli: A simple CLI exposing low-level operations against OpenAI's REST API. The thing you'd use for creating lower-level scripts to directly call the completions API, administer accounts, etc.
Honestly, this is obvious by the name alone. If it's not clear to you, then this isn't for you. No need to get worked up about OpenAI releasing a piece of software where you're not the audience.
This is not AX (agent experience) friendly (and for some humans here too).
There is no "why" or "when" to use it in the documentation. We humans need to figure out why this is needed at what occassion to AIs.
So my point here is the bad README.
If there is an ambiguous in the doc, and what you conside ris "obvious" is not obvious for some. It's a bad doc.
-----
If I were to use this, I first have to instruct, hey Codex, for low-level API calls to bypass your harness,
1. Read docs on OpenAI CLI: (and you provide why Codex would need it) 2. install OpenAI CLI 3. Call low level APIs: instruct when to do this over going thru codex harness
Recently did a quick experiment using four python cli libraries with codex, fairly big cli surface, well-typed code with docstrings, and the differences were negligible- it came down to those two qualities specifically, and the means to those ends didn't really matter. Obviously anecdata though.
The "neg diff" you see is either your harness is so well done that it takes that crappy REAME without an issue or So bad that your Harness doesn't make a diff.
You need try another experiment with more better/specific README to see if it makes a diff. If it does, then yes, README sucks else your claim would be correct.
As your experiement was "quick", I cannot really buy into your experiement yet.
https://developers.openai.com/api/docs?lang=curl
But given the cost of implementation is low, why not do this!
Good job OAI!
Generate an image and save it locally
...Export API data for a script