I’ve also found that Claude and friends are eerily good at using classic Unix CLI tools so I build mine in the same style, not unlike the `gh` CLI from GitHub, though with an agent-first design shape.
Usually I’m returning TSV as a default format and I add a `help-all` subcommand to list every available command at once when needed. Another thing that helps is adding just-in-time context-sensitive hints, such as: user has just run a list query with at least one result. Add a one-liner to the response explaining the command shape for getting the detail view of the first response.
In terms of skill files, I like to have my CLI generate them dynamically at runtime by walking their own current command tree and then feeding that through a text template.
Yeah the CLI can provide schema for commands via the usual ‘—help’ syntax, so agents are able to discover + explore commands on their own.
As for an example: if our agent wants to book a journal entry to cash accounts for a client, it MUST provide receipt and directly link the transaction from the clients bank feed, if it attempts to do so without the requisite information we deny the tool call and ask the agent to escalate back to the client for proof of receipt.
Often times this results in the agent not doing the work and instead sending a message back to the client asking for proof of the transaction.
For humans on our platform there may be valid situations where we’d want to allow this, but for our agent this is a hard guardrail thus why it’s not just standard validation for any JE posting on our platform.
if our agent wants to book a journal entry to cash accounts for a client, it MUST provide receipt and directly link the transaction from the clients bank feed
It’s actually encoded in an abstraction that we call “gates” which run before any tool call an agent makes, this allows us to prevent the tool call from happening and return a cited code + explanation on why their tool call was not executed
Oh wow! That review was incredibly useful. I had seen there was a second edition and was eager to buy it next I came to the US - but was hesitating on dropping so much money on it.
Looks like it may be a useful read after I've mastered the first edition more :)
The FFT and SVD chapters have actually ended up being the basis of a few research projects I've done. The writing really has a way of reframing concepts in very insightful ways.
Fully loaded employee cost is typically around 2x their actual salary. Junior employees making only $60k/yr is absolutely nothing. It’s lowish even in most parts of the western world.
You can also get cheap devs in Central or South America or Eastern Europe too. Doesn’t make it untrue that large parts of the world have junior devs much more expensive than that.
The software development world and ecosystem. I’d say all of the US, major parts of Canada, and major parts of Europe constitute a large part of software developers.
They were talking about what it costs the company, not just the salary. There are taxes, insurances, equipment costs, etc.
10k might be a bit too high, but it's far from "absolutely ridiculous" amounts of being too high. An employee with a 5k salary can easily cost the employer 7-8k
In the US, it’s really difficult to live a middle class lifestyle if you’re not making at least low to mid 100k. I don’t see any starting software salaries at good companies below 100k even in the Midwest.
Sure in the US. But people are throwing token caps in 500, 1000, 2000 dollar range here. That is a very significant expense on top of salary, taxes and benefis. It's only justifiable if they observe 20% 30% or more productivity increases across the board.
If you have huge salaries, yeah sure 500 dollars its okay even if you only get 5 10% more productive.
For someone who has not tried these desktop apps: what is the the advantage versus cli codex with some MPCs and multiple folders each one with their context files?
The same as an OS with a UI. Discoverability, fewer actions per activity, easier navigation, faster to learn/lower skill floor, etc. Some highlights:
1. Much better multi-agent orchestration. The app supervises many agents, with different project views and built-in git worktrees, so agents can work on isolated copies of the same repo. It's easy to jump between tasks and see changes. I recall OpenAI wrote that CLI was not designed around this style of work.
2. The app combines multiple terminals, file previews, PR-review workflows, SSH connections, an integrated browser, and page annotations. For front-end stuff, Codex can run the app in Codex for mockups/prototypes, then iterate inside the app. IMHO I think this is a much faster, more intuitive flow.
3. For long-running and recurring agent workflows, I think they're much easier to manage in the app. You get automations, review queues, persistent conversation context, future schedules, and auto resume for longer running tasks. E.g. CI failure summaries, issue triage, and release briefs.
You can do some of the above, to some degree, with varying levels of success in the CLI, but I think it's miles ahead in the app.
> The app supervises many agents, with different project views and built-in git worktrees, so agents can work on isolated copies of the same repo. It's easy to jump between tasks and see changes.
This is mostly true with Codex and Claude Code Desktop, but gets a bit trickier with 3rd party tools.
I tried out some others and both Paseo and Kepler felt a little bit clunky especially around sub-agents and workflows (even if they let me have both OpenCode and Claude Code with different providers in the same UI). And OpenCode is plain lovely in the terminal but sorta okay in the browser: compare its display of sub-agents to what Claude Code does, for example; their tabbed interface also feels a tad less pleasant than the vertical menu of projects + sessions that most others are settling on, not their old look with icon per project, that was worse. There's definitely ample room for better tooling, then again early IDEs were far worse, so hopefully ADEs will get more polish eventually!
Still, regardless of what you use and across how many providers, it's nice to have everything in a single familiar interface, if you need that.
You get GUI niceties: a nice presentation of the output like inline markdown rendering including tables and images in a nice font. Input supports drag & drop, and I can actually navigate the input field the way I am used to (pointing and clicking, using keyboard shortcuts to jump to beginning of words / sentences).
Not sure what the most modern CLIs support, but for me just the ergonomics of a GUI text field alone are superior.
I guess to each their own, as I find the GUIs to be clunky and a net negative to my workflow. Admittedly, I should give them another chance, and see how they have matured lately.
I'm a long-time CLI/TUI lover, but the Codex GUI has converted me for at least this use case. It has most of the positives of a TUI plus some that would be hard in a TUI.
I'm not ready to try this yet, since after some recent experiences[1] I've decided not to be at the cutting edge of new tools and models for a few weeks or months.
However, from the screenshots and description, I expect that you would have these advantages:
- History. Currently, if you type into the CLI (TUI) your intention and requests are captured in some transcripts, but not in conversational turns. If you want the history of what you typed into the cli/tui you would have to datamine it from transcripts. By contrast, on the screenshots you can see it is a simple conversation that's saved and easy to return to.
- Multiplatform. As per the announcement "Use Codex across ChatGPT, your editor, and the terminal", meaning that you could open the ChatGPT app on your phone and continue to interact with this. While this might not matter to you if you exclusively code while sitting in front of your computer, still, it helps you be able to stay on top of things if you are on mobile.
- Background tasks and autonomous work. It says you can schedule it to do things in the background (issue triage, alert monitoring). At the moment, it would only do this if you've asked either codex or another agent to build a harness for it that does so. (i.e. you could ask Claude to build a harness that calls Codex on some schedule or interval.)
These all seem pretty good and I look forward to starting to use it once it's been more battle-tested.
[1] notably, on the Anthropic side the Opus 5 regressions - I had to downgrade to Opus 4.8 as I found Opus 5 was unreliable. I currently use Opus 4.8 and Codex Sol 5.6.
For me the main one is in-app browser with feedback you can do that's native to its elements lika a network inspector. All "real" browsers felt too broken when I tried them.
The bad part of the setup is: you still have to tell it to ssh into your dev container and make changes there (since that's where the linux running dev server is). Most work still via cli, which is faster and much more lightweight in token usage.
Touch billing, touch medical data, be at a B2B company that needs to catch all the ISOs to have a chance to land bigger contracts. I don't think it's uncommon.
It might be an unpopular option, but I think the regulatory regimes that control medical and financial privacy as they interact with software are significantly lighter touch than e.g. the regimes that control material quality for bridges and tunnels, much less airplanes.
Not in tech, so does the authority granting license to proceed do code reviews?
Because when I submit building plans, they are manually reviewed and approved (or denied) by registered architects, engineers, and planners employed by the authority for just this purpose.
Gaming Commissions oversee gambling machines and will audit code to ensure the RNGs are accurate, return to player meets the expected requirements, and so forth.
I'm sure other highly regulated industries also have their code audited.
Not really. In those safety-critical areas, the code really is no different. What is significantly different is the surrounding process.
I had to make some software changes to an old medical device this year. The overwhelming majority of the effort was understanding what the customer wanted and giving them feedback into how that would change the existing system and the risks associated. Then, creating a plan to follow the necessary standard (IEC62304) and creating the associated documentation and getting it reviewed and approved.
The actual code that changed was probably only around 100 LOC but the project took several months. Heck, the code was simple enough that an intern could have done it.
I left out the code on medical devices for a reason! And similarly for avionics software.
(The distinction I’m making is between the code that operates the medical device and the code that operates the app I make doctors’ appointments in. The latter is subjected to a different - and lighter - regime than the former.)
It's questionable though how much the programmer is operating under it. The programmer's work may need to comply, but there are a bunch of things that can reduce how much the programmer themself deals with it.
There are the executives, the lawyers, the product managers, sometimes the designers, who to varying degrees determine this before they land in the requirements the programmer sees. But there are also the libraries and APIs the company pays to handle compliance so that the company and the programmer doesn't. The programmer implements the library (and may not even had a say in or necessarily care which one was chosen).
Even if you get a crispy set of requirements from all parties you are still responsible for implementing all of then while making sense of the existing system (and from my experience significant issues arise at this stage when the full extent of requirement implications ia better understood). On top of that you might also be responsible for operating the thing, participate in compliance doc writing and do ongoing maintenace.
Yes, these things reduce (not necessarily how to zero) how much compliance the programmer is doing. They aren't figuring out how to get a car legally on the road, they're still figuring out how to get a car to do car things. The compliance questions the engineer sees are largely engineering questions. Sometimes hard engineering questions.
It is. And the quality is on par with any us eng. People here forget that the big comp packages are a minority even in the US. The cost tho is much higher than just salary.
Western Europe is mostly consultancy, and the rate paid by client is usually higher, and doesn't matter if it's eastern Europe, Portugal or even India.
Could you give an example of an accounting guardrail you created?
reply