It's not reasonable for us to frame 'return to office' as a class issue, it's a productivity issue - moreover, the general point is not implausible but a bit conspiratorial.

It's odd that we conflate that somehow 'return to office' is inherently more productive and that somehow 'dumb corporations acting against their interest'.

I don't think that's true, and if it were, well, we should all be in a position to take advantage of it.

Sure, FT is part of the 'corporatocracy' for sure but they're not working to 'create narratives'. Individual journalists are actually writing about things they see.

My bet is the real reason is that companies just don't want to hire juniors, and that's it.

I still drink the water, I just can’t stand the texture with creatine added. So I swallow the creatine with as little water as possible and drink nice fresh water afterwards :)

Parent says it's washing it away with water

That's a big odd - because creatine seems to be the universally beloved thing and that it's a bit natural and has positive effects with zero negative side effect. Not a criticism but aside fro proten, creatine seems to be 'the natural thing'. Pun intended.

There's two sides to this.

1. That's because it's true. Creatine is extremely well studied and the studies pretty much all tell you that Creatine is safe, it's great at what we know it's great for, and it turns out it might be good for things we didn't expect. So when people all say "wow it's so amazing" they're right.

2. Because of (1) being so blatantly true, if you want to push some other supplement, it adds a lot of legitimacy to say "Creatine is the number one supplement, but here's something that takes things to the next level". Since the Creatine claim is well supported and you're already marketing to a group that's taking a supplement (Creatine), it is likely good marketing to piggyback on that.

But this doesn't change the fact that Creatine is shockingly well supported as a supplement.

For me, besides creatine which has been genuinely transformative at age 50, I've gained a lot more from the stuff I've dropped (dairy milk, ~2/3 of my caffeine (mostly by drinking reduced-caff coffee or tea and eliminating soda), sweets of course) than stuff I've added. But of the latter, I'd say fiber and fruits have been the biggest additions, partly in themselves and partly that they make it easier to avoid the bad stuff. I tried experimenting with a few other supplements, but most of them were meh at best.

So, "take things to the next level" with some pears and oatmeal and chia seeds! Now I just need a sponsor.

The point about interruptions is valid.

'Waiting for AI to finish' - even if it's only 1 minute segments, is real, especially if we are delegating. (Maybe I'm interrupted right now!)

But this - it's not the fault of the tool that you're not focused on building something useful, long lasting or material.

That's an entirely different question - and I think if you look into most people's 'experiment' folders, that tendency was always there. Just more code now.

That's on us.

If it were a matter of 'enjoyment' then the OP would have made his point.

There should be a material difference between the tools.

There is.

vim / emacs / jetbrains - different tools to produce code.

Codex and Claude are different.

" You cannot simply make a claim that (model + harness) X is better than Y, but then have no discernible difference in the output"

Sorry I think this misses the mark.

Because it's not the output but the process.

And sometimes the outcomes are not always discernable.

Codex and Claude are very different.

I use them for different things.

Their behaviour difference is obvious.

Of course it'd impossible for anyone to tell by looking at my code base 'how it was written'.

You need to see the response in light of the original discussion. Referencing here for clarity since I should have included it in the first place: "We used the claude code and codex harness and I implemented some prs they needed with gpt5.5 and opus4.7 and asked them to identify which came from which only from the code."

So the same person, was using similarly competitive tools, and showing that the output was hard to discern (indirectly the implication was also that implementation was fairly trivial in both of those). A better analogy would not be different process and widely different tools but for example two power drills. Sure, folks could still prefer one over the other, but that's a different claim that saying X is objectively better than Y when both are directly competing on very similar dimensions.

Assuming you meant Claude code: I'd love to learn more about "Codex and Claude are very different" because maybe I'm assuming just based on my use case where I use both of them interchangeably for the same thing (coding web and mobile apps)

It's not reasonable to compare results from two different tool sets, especially as they are guided by humans.

The only way a reasonable comparison could be made, would be to compare completely automated results from either technology - that would be useful.

For example - creating a 'per-baked script' and running on both to see the output.

Codex and Claude are obviously very different, though it's hard to characterize how those differences might apply exactly to a given problem.

Two 'very different power saws' will ultimately build the same home.

"and the one they're using." no it's not.

Agents are just making REST calls and that's it.

The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.

'MCP' is frankly a hurdle.

Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .

MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.

It could very well entrench itself however.

It's that extra amazon box that wrap the actual box that wrap the thing you ordered. Except you're doing the wrapping.

I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches:

    * Internal services that never had real APIs are getting them retrofitted via the MCP layer
    * MCP servers can run with dedicated service accounts that assume-role to a safe(r) subset of the calling user's permissions

The first one is a business benefit. Enterprises tend to have a lot of data siloes, and coordination between teams/departments/units just to learn that a given data set exists takes a LOT of time - even before you start to arrange suitable access to any of them.

The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.

MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:

> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.

"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.

I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.

So this is thoughtful - but - MCP isn't actually a very good solution for corporate automation either.

Corporate automations face the same problems human driven agents use:

+ The 'tool' section of the chat is not the right place, and it's too limiting + The very concept of MCP server introduces a brittle layer - for what purpose?

CLI for local calls, REST for remote.

That's it.

We build security around that the same way we would otherwise.

Now -> 'better / standard' json type calling for both of those!

Sure! 'Agent Calling API' or something. Yes.

'Agentic Identity Standard'? Yes to that as well.

But MCP was 'the right solution for a period in LLMs that has been superceded.

If MCP did not exist today - we would not invent it. That's the strongest argument I think.

That mimetic thing…

I remember 10s of HN submissions where handlers were trying to get conversations about MCP going on HN back when there was almost nothing known about it and nothing to say.

It was always about tricking people into thinking there was authentic interest in it and it still is.

It's not 'who is building' but 'who is using' that's the concern.

AI is a bandwagon tech, a lot of people will 'build because others are' adhering to an ostensible standard.

Most of the people that I know are moving away from MCP in favour of skills where the advantage of MCP goes away if the REST API is clear enough.

Also - I'm sorry to say but MCP management on Codex (and Claude) is just really bad. Everything from discovery, to management, to context window, to documentation - it feels unfinished as a 'feature' even if the protocol is supposed to be narrow.

1) I have a big popup and yellow warning every time a window is opened or a sub agent is launched warning me that 'SkySomething Computer Use' does not work. I had to Google to find out that has something to do with Codex MCP. So already the externalizations of problems, resolutions ... not very well done.

I'm not even sure what to do - and I'm honestly not interested in 'fixing' something I didn't cause, I'm not sure of, and don't want to deal with.

2) Just listing the current MCPs, knowing really what the are for (clearly, concisely) is hard.

This is what you get if you type /mcp in Codex:

/mcp

  MCP Tools

  • No MCP tools available.

  • codex_apps
    • Auth: Bearer token
    • Tools: (none)

  • computer-use
    • Auth: Unsupported
    • Tools: (none)

What's that supposed to mean? What is 'codex_apps'?

As presented - it resolves to 'nonsense gibberish'. Those are things that I did not even install.

Do you expect people magically know what 'codex_apps' is?

Here is what 'AGI!' Codex 5.5 answered when I asked about 'codex_apps' is:

====

" codex_apps appears to be Codex’s own internal cache/tooling area, not part of J1 (my project).

"I only found it under .codex, e.g.:"

" I did not find it referenced by the J1 source. So unless you saw it somewhere specific, treat it as Codex runtime metadata for app/tool integration, not project code."

====

So even Codex itself has no idea what it's own MCP tools are, and after a full '1 minute of thinking' on 'xhigh' it responded with nonsense.

This whole experience fundamentally deflates my perception of AU, OpenAI, Codex and MCP.

This is supposed to be the 'future' but it feels like 1982 dialup.

This is where 'traditional UX' really starts to show it's value obviously, but you really need to consider enhancing this experience, possibly with some traditional ux mechanisms.

3) Knowing the 'state' of the MCP is totally opaque. Is the 'MCP server' running? Can I restart it? That might be outside the scope of 'Codex' but you're offering the product so all of the underlying stuff is essentially 'your responsibility' as well at least from a UX perspective. Why isn't the 'state' of the MCP listed.

4) How can I not just easily enable/disable individual MCPs so they don't chew up context?

5) How can I not discover MCPs from codex itself, so that I can find solutions to problems? MCPs are all a bit different, and awkward to install and manage. Like with VS Code, we can 'discover plugins'. Even from the Web we can search and discover plugins.

While I realize that most of this rant is oriented around MCP tooling management, and not the standard, I do feel that these issues are 'fundamentally at the crux' of the situation.

Our team has moved away from MCP into Skills - and after doing so, it's hard to see why MCP is going to be valuable - other than plausibly as defining some 'jon calling conventions'.

There's a lot of obvious things to improve, please do that.

OpenAI should hire you.

This is not even 'basic product design' - it's just 'product common sense'.

That the 'smartest people in the world' have $100 Billion and are are totally scattered on so many issues completely blows my mind but it speaks to how systems are organized.

They don't need to hire anyone for this stuff, they need to have some basic product discipline and prioritize it, that's all.

If they don't do that, all the money in the world and all the best product people wouldn't be able to help.

I totally respect that 'Codex is young' - but it's been kind of a year now. That's a long time - and AI is supposed to 'accelerate time scales' and make people 'super productive' remember?

I hope they improve.

It's the way that it occupies the context relatively permanently, that it doesn't come along with nice install/uninstall or discovery etc. is the problem.

'Skills' should all be based on MCP, they should load on demand, be very easily manageable and discoverable by humans and by AI, and then it would work

The scope was too narrow, given how it ended up being applied.

If they layer something on top of it, it may yet be revived.

You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.

Yes, MCP taking the form of 'skill' because MCP serves no purpose.

The concept of 'mcp server' is a brittle abstraction that need not exist.

A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.

MCP is a JSON-RPC + a fixed auth/discovery handshake + a fixed tool schema protocol for backend endpoints.

Your skills or CLIs still need to call a backend endpoint at some point. MCP is just a standard server JSON-RPC protocol. Having a standard for that is really nice, you get standardize auth, discovery, API shape, etc.

Is it the greatest RPC design ever, no, most annoying is how it's based around a statefull session. But it's really awesome that we have a standard. Otherwise you'd just have a bunch of random servers all doing their own things that you'd have to figure out how they work and all, it would be much worse.

You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.

A 'skill' is generic concept - as short set of right-sized instructions for a given cli or api call, it can be applied in any context.

If MCP did not exist today, we wold not invent it.

We'd probably hormonize in basic conventions around json calls, and not much more.

The rest would just be api use / instructions.

LLMS to day are exceedingly good at calling RESTful APIs, the MCP standard provides little advantage.

The advantage of 'skills' is that they are more generic - an Enterprise LLM can evoke 'capabilities' which may or may not involved rpc type calls, and if they do, there will be varying level of instructions provided.

There's almost not point to MCP.

Yea so your answer is to build something that’s like MCP basically. You’d standardize conventions around json, great, now standardize auth. Oauth is nice right? That’s MCP. MCP is literally a restful API using JSON with OAuth.

You’re arguing against MCP but have nothing to offer that isn’t nearly the same thing.

Agreed, not sure what people arguing against MCP are even arguing against. The only valid critique of MCP is that you think the RPC protocol isn't ideal, sure, you could argue about the protocol design, for example I wish there was better support for stateless calls. But why wouldn't you want a protocol for back-end API calls? Otherwise you need custom clients for each possible backend you want to invoke.

'Deskilling' is totally fine if it's replaced by people who have skills at a higher level of abstraction.

Often - the people who are replaced don't recognize the inherent skills of the people who operate the machines that do their work.

But there are often non-obvious tradeoffs.

Having Ikea means we can have vastly, vastly more selection and choice in the things we put in our homes.

And the 'quality' is usually fit for purpose (just because it's not made of Oak, doesn't mean it won't last a very long time).

But when you see a winding staircase or those custom moulds .... well you realize 'what we've lost'.

There's always a trade-off even if the net positive is there.

That 'externalized craftsmanship' sure does add up though ...

> Often - the people who are replaced don't recognize the inherent skills of the people who operate the machines that do their work.

It's not so much the people who _operate_ the machines as the people who _build_ the machines.

A very, very long time ago, at my first job, the people who used anything other than C were considered 'fake' developers and were resentful that everything was shifting away from C for most things. I felt that :)