A: Devs with an online presence stop using Anthropic models
B: Anthropic catches up to OpenAI in terms of per-token efficiency, and average token total for final-output
We will continue to see posts such as this generate lots of interaction. This is not a skill to stop "coding agents" from burying the answer. This is a skill to stop coding agents backed by models which have a tendency to bury answers, from burying the answer. Stop trying to patch the downstream behavior, and look at the root cause.
I'm a developer at a company who has signed contracts to use Claude. I wish I had a choice in model providers, especially considering I spend around $4k in API tokens each month, my company as a whole is around a million. I desperately wish I could use OpenAI models or open weights, Claude's writing style is definitely contributing to my sense of burnout.
I'd be burned out too if 48k of my comp went to what amounts to a facilities spend. Crazy. You think the models actually give you ROI, or this is a sort of jumping with the lemmings thing your company is doing, and you could probably deliver the same output working in "The Old Way" with another 48k on top your base?
My output is easily 2-3X what it was two years ago. With the introduction of Claude to everyone in the company (HR, finance, marketing, product, dev, etc), so came the expectations of what used to take 2 quarters can now be done in a couple sprints. I would be even more underwater working in "The Old Way" regardless of comp, with how deadlines are being set now. That being said, I don't know how long this will last, I'm not the only 'top talent' at the company facing warning signs of burnout.
Longterm, I believe my total output would be higher working with minimal AI when you consider the impact to motivation and how long I anticipate staying with the company.
>Longterm, I believe my total output would be higher working with minimal AI when you consider the impact to motivation and how long I anticipate staying with the company.
That makes sense. The increased theoretical output certainly makes it tempting to squeeze the developers for all they are and to keep testing how close deadlines can be made. But of course, to what end? A lot of dev work, probably most of it if we are being honest beyond building the initial product-market fit function, doesn't really impact sales at all, and sometimes too much can even hurt sales. And as you say you hit a point where this burns out your talent and makes them seek greener pastures.
Factory sort of thinking towards a job that is not really analogous to a factory anyhow. I'm not saying dev work is one of those 'bullshit jobs', but lets be honest about the job and its role in the business model. Your customers are probably going to be there all the same if you fix the bug today or next month, and you also won't get more customers fixing the bug today vs next month. Feature shipment might be a little different but even then it would take the right feature and the right customer for that one function to really drive the needle in sales compared to being lost in the changelog, and that isn't what a coding model solves for you after all.
That's not really how it works. I'm able to get 5-10x more work done, perhaps more, it's a significant accelerant to those that know how to be productive. The problem is more for those who don't - and we bring them up to speed or help them pivot to other work.
How does that shake out for your company? Are you growing 5-10x in sales? I'd guess not and that is sort of the rub with all this. Yes we can push more frequently to the git repo but that wasn't the limiting factor of scaling the business.
I work across multiple companies, but in general company profits are up across the board. Salaries are not. The larger enterprises are the ones that move the slowest and are the furthest behind. It's not just one thing (productivity), there's all of capitalism at play.
I am not using MCP in be production- but, my team is. My team also produces MCP servers for other teams, and I find it a bit maddening. I wonder if anyone can relate to my experience here.
It feels like there is a significant amount of baggage with MCP. It had first mover advantage- coming in at a time when the frontier looked much different. Models were significantly less predictable, would consistently screw up tool calls- and couldn't quickly find a good path to interfacing directly with an API.
Things are much different now- and I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution for getting data in front of a model. Everyone uses Claude Code (cli, desktop; I also am frustrated that so many people use CC over alternatives- that's another rant) and thus, everyone has an harness that'll happily leverage shell + skills to get things done precisely. So- why? Why is it that I see my team-mates all using the same Atlassian MCP server that's flawed- which we don't control the tool surface of? Why not point an agent at the API spec? If the answer is that it's too slow to startup, having to read the API spec to figure out what to do- then, point it at your .claude/.codex/.whatever directory- find where the agent has used tools from the MCP server, and create skills or some thin client surface.
And I will grant that yes, I have observed that a well-engineered MCP server can offer better performance than giving an agent a loosely defined task to perform with an API. However- 'well-engineered' is not easy to achieve. You must run many iterations of benchmarks and evaluations, observe trajectories, and improve the tool surface over many iterations. You also cannot predict users- so you need to monitor the usage, and improve over time. It's a heavy lift.
Additionally- no-one is benchmarking this stuff. They throw MCP at the problem, and call it a day once an agent can achieve the task. Frustrating.
I tried for a while to speak up and suggest that maybe MCP might not be worth the effort compared to improving the UX (or, AX) of API surfaces, or instead putting cycles towards better data storage and presentation. But I find that I'm starting to feel like a dick for bringing vocalizing this consistently when MCP is mentioned.
I realize this is deep into rant territory by this point. However, anonymous posting on the internet can be good for the soul. Anyway- it generally feels as though others are not as interested as I am in eating their pride, generating research, and improving what we know, and how we do things. This goes back to CC- I am the only member of my team that is not using CC as their daily driver. Again- I feel like a dick, but my god, I sound like a broken record suggesting that others try different models and harnesses. I hear constant half-complaints about verbosity of output, or churn- and barely anyone has been willing to give OpenAI models a spin.
I can't bear to hear a group pity-party about how model output is exhausting to read- when the complaints are exclusive to Anthropic models, and no-one has even read the prompting guidance which states clearly how to drop the verbosity/density/flowery-ness of output.
And for the love of god. Stop trying to make models from other providers work in CC. It is not impossible; but it is by nature, a hacking-unfriendly platform. I promise you that CC cli is not the only coding-agent cli tool that you will feel comfortable using. Actually- I'm willing to double down and bet that you will loathe CC cli once you see what the grass looks like out of that orange walled garden. Bah!
> "it makes things a tiny bit easier than interfacing directly via api"
By what metric? I would expect that a thin API client (with readable code) is generally going to out-perform a tool-surface which you don't have the ability to manage/edit.
This is what I don't get often when people say "ai will be the ui". Like pressing a button to get an action done for me will always be quicker than asking an LLM to do an action and then waiting for it to understand and do that action. Why will I not prefer to just press the button?
I run a lot of services to track my life and work and theoritically I could hook up their apis or mcp if supported to a harness and pretend like "oh its a talking computer that can do whatever i ask" but in reality, I can go through the native ui of those services esp with things like hot-keys for a faster and more ergonomic experience than talking to a jarvis and having to recorrect it if its wrong
This is moreso about the (human-intended) tools, data, and environments you have available to you. Wanna do defense? Get more telemetry. Wanna do red? Get solid test-bed environments. Mature infosec programs are benefiting the most, good-guy-side wise, at the moment; because they've got these things in order already.
As far as harness engineering goes, it boils down to your ability to clearly define goals or success criteria, and safely facilitate the necessary access via the harness. There is no easy single piece of advice here, sadly. Though it would be helpful if you said what 'for Cyber-security ... other user-cases' means in your case.
I think its moreso ChatGPT desktop is the platform, and the split is Chat, vs Codex/Work. Codex and Work being largely the same thing, but with UI and tool surface differences geared towards SWE vs Business work. But yes; terrible UX and discoverability on OAI's part.
I think so too, but visually, the parent switch in the macOS application is Chat GPT <-> Codex, and within ChatGPT, there is Chat <-> Work (and within Work, there is "on your computer" and "in the cloud"). I'd naively not expect ChatGPT -> Work to share state with Codex, but this is the case for "on your computer" tasks.
Also, there's still "Codex Cloud", much older and entirely separate from all of this (I think it might even predate Codex the local app?), and this also seems to live in the "Codex" parent tab on a project by project basis.
None of this seems to be documented either. I literally had to start a "Hello World" project in each category to figure out what's going on.
A: Devs with an online presence stop using Anthropic models
B: Anthropic catches up to OpenAI in terms of per-token efficiency, and average token total for final-output
We will continue to see posts such as this generate lots of interaction. This is not a skill to stop "coding agents" from burying the answer. This is a skill to stop coding agents backed by models which have a tendency to bury answers, from burying the answer. Stop trying to patch the downstream behavior, and look at the root cause.
reply