philipbjorge

Wow, I would love to read an interview series based on this!!

It’s been 25 years since I was in school and this was my experience. Unsure if it’s changed…

I’ll second this, I had to send this message…

based on our discussions so far, I think we’d only need... Which they appear to have but I can't dig in on mobile.

I'll go further and note that some of the optimizations I've seen in rtk for things like `git status` have actually bubbled up into the model layer -- Codex is regularly making tool calls like `git status --short` instead of `git status`.

I can't find the relevant issues in their repo, but I've been somewhat skeptical of their tool over-reporting token savings and there are many issues to that effect in the repo.

I'm not likely to install it again in my latest configuration, instead applying some specific tricks to things like `make test` to spit out zero output exit on unsuccessful error codes, that sort of thing. Anecdotally, I see GPT-5.5 often automatically applying context limiting flags to the bash it writes :shrug:

I've done some pretty incredible things with LLMs. If this were sqlite with its exhaustive test suite... OK, I can see it.

It's hard for me to see this not becoming a pile of slop, but hey, maybe I'm wrong

Been loving pi and codex lately. Good to build resiliency and self sufficiency into these systems.

Can you fill me in on how this impacts conductor? How are they using `claude -p`?

Tracking with `ccusage`, I pretty easily hit $2000/mo in API equivalent credits and while I'd consider myself a power user, I'm a responsible one that's generally always in the loop. If I were using `claude -p`, this would effectively be a kneecapping.

This seems like less of a today thing and more of an ancient human tendency.

A lot of Buddhist practice is basically trying to train against immediately collapsing reality into self/other, right/wrong, craving/aversion.

Practicing this with Elon Musk is effectively ultra hard mode.

--

Though I do think there’s a subtle irony here too — the original commenter may simply be describing their own emotional reaction/disillusionment, while your response risks collapsing them into "part of the problem."

Feels like everybody in the thread is pointing at the same tendency from different angles.

I haven't really shared what I use, I'm still deciding if that's something I want to do.

To get an idea of what I'm talking about, you could install https://github.com/obra/superpowers/ into both Codex and Claude Code -- You'll find that the behavior is remarkably similar if you A/B compare them on the same problems. CC occasionally misses things that Codex gets and vice versa.

Overall the output structure and final code is remarkably similar... Which is pretty different than if you just run them with their default system prompts. I'd throw codex out the window with its default outputs.

Ahh good point -- I've handled this by switching my harness to `pi` but recognize that may not be for everyone and doesn't directly address OP's question.

What I found was that I *strongly* preferred Claude Code with its defaults. Codex was almost unusable to me -- It would spit out a 4-5 page plan where it kept repeating itself, where Claude would give me a crisp 1-2 pager I could actually review.

*But* I don't work with the defaults -- I work with my own prompt framework based off of superpowers.

Given sufficient prompt scaffolding, I've found the models relatively interchangeable -- _I might_ be getting some of this for free by basing my own system off of superpowers which is used across various harnesses -- In other words achieving this kind of portability may be a lot harder than it looks and I'm benefiting from other people's work.

You might search for a concept like `/handoff` that's in ampcode. I'm sure someone's built a skill for just this.

So happy to have diversified my model providers this past couple of weeks. GPT-5.5 has had no trouble slotting into Opus workloads. Will be fun to try out more of the models as time goes on to build some resiliency into my engineering workflows :).

I’ve been comparing Claude Code and Codex extensively side by side over the past couple of weeks with my favorite prompting framework superpowers…

From my perspective, Claude Code is decidedly not better than Codex. They’re slightly different and work better together. I would have no issues dropping CC entirely and using codex 100%.

If you’re working off of “defaults”, in other words no custom prompting, Claude Code does perform a lot better out of the box. I think this matters, but if you’re a professional software developer, I’d make the case that you should be owning your tools and moving beyond the baked in prompts.

gpt 5.4 has been performing great in my harness.

This looks remarkably similar to https://github.com/vercel-labs/agent-browser

How is it different?

Until it's happened to you, it sounds unbelievable

Sorry about all the broken plastic on the trim -- That's also very familiar...

We asked for a bill with the standard CPT codes. No reply. Asked again. “Oh, we meant to send it. We upgraded our computers five months ago and nothing works.” Uh-huh. Finally got the CPT codes.

I work in healthcare RCM. I have no trouble believing the staff here that nothing in their system works.

We had a similar realization here at Thoughtful and pivoted towards code generation approaches as well.

I know the authors of Skyvern are around here sometimes -- How do you think about code generation with vision based approaches to agentic browser use like OpenAI's Operator, Claude Computer Use and Magnitude?

From my POV, I think the vision based approaches are superior, but they are less amenable to codegen IMO.

Important is subjective — In the healthcare space, I’d make the claim that most applications don’t expose themselves correctly (native or web).

CV and direct mouse/kb interactions are the “base” interface, so if you solve this problem, you unlock just about every automation usecase.

(I agree that if you can get good, unambiguous, actionable context from accessibility/automation trees, that’s going to be superior)

If you're looking to test an LLMs ability to solve a coding task without prior knowledge of the task at hand, I don't think their benchmark is super useful.

If you care about understanding relative performance between models for solving known problems and producing correct output format, it's pretty useful.

- Even for well-known problems, we see a large distribution of quality between models (5 to 75% correctness) - Additionally, we see a large distribution of model's ability to produce responses in formats they were instructed in

At the end of the day, benchmarks are pretty fuzzy, but I always welcome a formalized benchmark as a means to understand model performance over vibe checking.

devcontainers extension was a year out of date up until the last month or something? sorry, this is from memory, but definitely not 100% compatibility.

I haven't followed this closely, but I assumed it was related to a foreign entity having the ability to hyper-target content towards said 17 year olds (and the entire userbase in general) -- A modern form of psychological warfare.

The latest research I’ve pulled suggests that DEXA scans are fairly inaccurate and aren’t a reliable way to measure body composition even for the same person across time.

MRI is the gold standard, everything else is pretty loosely goosey.

Sorry, no references but this comes up pretty often in the science based lifting communities on Reddit and YouTube if you want to learn more.

They report that they trained the model to count pixels and based on accurate mouse clicks coming out of it, it seems to be the case for at least some code path.

When a developer tasks Claude with using a piece of computer software and gives it the necessary access, Claude looks at screenshots of what’s visible to the user, then counts how many pixels vertically or horizontally it needs to move a cursor in order to click in the correct place. Training Claude to count pixels accurately was critical.

I work in this space and Claude's ability to count pixels and interact with a screen using precise coordinates seems like a genuinely useful innovation that I expect will improve upon existing approaches.

Existing approaches tend to involve drawing marked bounding boxes around interactive elements and then asking the LLM to provide a tool call like `click('A12')` where A12 remaps to the underlying HTML element and we perform some sort of Selenium/JS action. Using heuristics to draw those bounding boxes is tricky. Even performing the correct action can be tricky as it might be that click handlers are attached to a different DOM element.

Avoiding this remapping between a visual to an HTML element and instead working with high level operations like `click(x, y)` or `type("foo")` directly on the screen will probably be more effective at automating usecases.

That being said, providing HTML to the LLM as context does tend to improve performance on top of just visual inference right now.

So I dunno... I'm more optimistic about Claude's approach and am very excited about it... especially if visual inference continues to improve.

Keep an eye out for the "Jump to Recipe" button found on most sites. (It's still terrible UX IMO, but figured I'd share the above tip as it's saved me some frustration)

My context has been startups with engineering teams of 15-60 engineers.

In general, I've found CI/CD templates, IAC templates and app templates to be an anti-pattern. It goes to the heart of scalable vs replicable.

Put simply: something replicable can be copy-pasted (with variations as needed) to grow impact linearly in relation to effort and cost. Something scalable can create impact at a rate that increases faster than the rate at which your effort and costs increase.

In the contexts I've worked in, templates enabled us to rapidly grow and expand our business and technology in unmaintainable ways.

We scaled to 100 services, but our revenue and headcount didn't scale linearly to support the services over time.

---

In general, I lean towards solutions that facilitate distributing and updating templates over solutions that facilitate copying/pasting templates.

- Kubernetes this meant a common Helm service chart for the organization -- Now we could distribute and update kubernetes manifests to the org - CICD this meant building plugins that we distributed to teams - Application templates I've historically moved folks back into monoliths but the microservice chassis pattern looks like a solution here -- https://microservices.io/patterns/microservice-chassis.html

Your calculus might look different depending on your internal capabilities and resources. Good luck!