CharlieDigital

...Do they just want to force you to keep busy

Given functionally unlimited access to tokens with frontier models, there is really no "force you to keep busy"; it should just bake overnight. We're talking about a rather simple and well-defined specification; not something novel and complex.

Anthropic were the progenitors of the Model Context Protocol. Claude Code does not fully implement the client end of the protocol. A protocol; a literal pre-defined spec that an agent should be able to one-shot. Neither does Codex. Codex does not implement MCP Prompts.

(I want Codex to implement MCP Prompts because then we have one central way to ship skills from a server).

The fact that neither platform can implement a protocol given what is functionally infinite frontier model tokens really says a lot. I do not care what kind of random project some influencer can ship with a swarm of 1000 agents. If you cannot make the basics work, it is a farce.

Pink Lady, Snapdragon, Sweetango are all probably closer to alanced compared to Cosmic Crisp. Cosmic Crisp being more tart than Sugarbee, but still definitely more sweet than tart in flavor profile IMO.

Sweetango and Pink Lady are probably what I would consider balanced sweet and tart.

    > And you cannot keep doing high concurrent DROP TABLEs to run your large scale CRUD app

A few things are not clear to me from reading through docs and examples:

    df.wait_for_schedule()

For this[0]:

    -- Wait for human signal (5 minute timeout)
    ~> (df.wait_for_signal('approval', 300) |=> 'sig')

    ~> df.if(
        $$SELECT NOT ($sig::jsonb->>'timed_out')::boolean
            AND ($sig::jsonb->'data'->>'approved')::boolean$$,

Also not immediately clear: how to handle errors/exceptions?

[0] https://github.com/microsoft/pg_durable/blob/main/examples/i...

Really good talk that goes over this: https://corecursive.com/vue-with-evan-you/

Totally worth the listen.

    > We are shipping more features

If you increase your spend -> ship more features -> no correlated increase in revenue, that's just burning money.

If a team of 10 spends 1 extra headcount ($180k/year) and ships features with no corresponding growth in revenue, what does that mean?

There was probably a reason it was on the backlog (because it didn't really have value).

Even if the laptop costs $5k and you upgrade it every year with the latest hardware and run local models (assuming your workload can tolerate smaller models at slower tok/s), you win.

That's because for some of these folks, the cost of the tokens doesn't have to match the value of the output; the hype from the story is all they need.

Normal people have to produce something of value from that spend. So starting 100 agents and then waking up to something cool but useless just means you spent a few thousand dollars and created nothing of value............

You're a content creator; you define your revenue stream.

Uber engineers do not define their revenue stream; the product leadership team does.

$1500/mo of AI spend by engineers does not equate to revenue. They need to figure out revenue first before zeroing in on AI spend.

Consider rewiring your perspective: getting an edge doesn't really matter; the only thing that matters is will customers pay for this? Is this a useful, valuable problem to solve?

Coding faster doesn't really solve that.

Uber makes more money if people buy more rides, order more food, have some breakthrough in autonomous driving. They can save money if they can optimize some ops or spend somewhere. Is there any evidence that with the spend on AI that they achieved any of this? If they did, I'm sure we'd hear about it in some engineering blog.

This is what all "platform engineers" have to do once things are working nicely: you have to keep inventing work.

I don't know; I'm a Ron Popeil "set it and forget it" kind of guy. Make the dumbest, simplest thing that's going to work with some clear path for scaling. Then go do valuable things instead.

About the same ~40 FTE team. We're doing the same thing. Smattering of internal tools, but no net gain in external revenue. Who knows which of those tools will have any value or ppl are just doing it because it's cool now to make fancy dashboards.

OK. I guess that's good, too.

$1500/mo is $18,000/seat/annum.

Maybe Microsoft and Nvidia are on to something.

128 GB machines that can run local LLMs are a bargain even if priced $5-8k. Yes, tok/s is not quite there, but that's probably OK since the bottleneck really isn't the code; it's WTF did Uber build with all of that spend? How did it meaningfully impact their revenue in a positive direction?

I rather like Ace better because the key problem right now is teams not working together and shipping the wrong things. When AI can generate the code, then it feels like product should be bringing the functional vocabulary and grammar while the engineering team provides the technical grammar to build the right thing.

This app is just another "let me talk to product, copy their convo, go off and build this in isolation with an agent" which I think is directionally wrong.

The "rooms" or "streams" should be multi-player instead of product looking at it at the end saying "no, go fix that" and dev copies text from one source and pastes into another.

    > ...add something like apache AGE, but arguably that is also a small ecosystem (at least IMHO as I never heard it until I actually started looking for Neo4J alternatives)

I appreciate having the option, but for most use cases on Pg, you are better off just using JOINs or switch to Neo4j for your graph workloads. I switched some workloads back to using different approaches of approximating "connectedness" in Pg (e.g. using Jaccard similarity)

If you do go down this route, the easiest way to get coding agents to figure out AGE is actually their regressions SQL tests: https://github.com/apache/age/tree/master/regress/sql

This has a lot of examples for the agent to know what will/won't work with AGE versus Neo4j Cypher.

    > [falconetpt] We now have a tacking system where people were forced to send telemetry from codex/claude into the servers and people are auditing each session

Engineering leadership in orgs is in a weird place right now.

That's because you're not thinking about how teams and enterprises work. You're thinking about how individuals work.

An enterprise has 20 services that each have a secret key (Datadog, Snowflake, etc). I want my team to have access to those services via coding agents. How do I guard those keys from both developer and agent? Put it behind MCP; neither dev nor agent ever sees the key. If developer leaves, revoke one OAuth cred.

I want to add access to internal and external services from one entry point without developers across hundred of teams having to sync or update their workspace. Put it behind one MCP interface.

I have enterprise skills and resources that I want to standardize and deliver to every team. But it has to vary in 10-15% of the skill body. Think same heuristics, but different specifics. MCP delivered prompts and resources can do that by dynamically templating them.

I want telemetry and data on how skills and tools are being used and I want to capture them using standard tooling like OTEL regardless of agent harness because I don't want to have to rebuild a solution on hooks if I charge vendors. MCP does that because I can capture all of the telemetry there.

    > jsonschema, openapi, all of it is a better integration point than MCP.

Your argument feels like asking why do we need OAuth and OIDC when we already have usernames and passwords. They solve different problems. A simple service can just use a secret key or username + password. But more complex enterprise scenarios need the structure and flow of OAuth, SAML, and SCIM.

Sure. It would be great if they were portable as well.

To make them interoperable so that the APIs have similar surface areas and can just be used without special skills, we could even come up with a standard API surface area and create a...protocol.

If you squint, the SKILL.md and the context that it takes up is literally the same thing as the MCP server and tool description. They are literally the same thing except one is server delivered and one is not.

MCP is "Let's use Google Sheets and have a server-managed experience". Everyone sees the same thing on the server in real time.

Skills is "Let me download the Excel and send it back to you". Why? How is this better? Every time I update the Excel, I have to add a `.2026.final.final2.xlsx` and everyone updates their copy...how is this the superior experience?

MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two.

Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills.

MCP also has a few other under utilized mechanisms: elicitation[2] on the client side and completions on the server side[3]. It is an API of sorts, but specialized for agent harness <-> server interactions.

[0] https://modelcontextprotocol.info/docs/concepts/prompts/

[1] https://modelcontextprotocol.info/docs/concepts/resources/

[2] https://modelcontextprotocol.io/specification/2025-11-25/cli...

[3] https://modelcontextprotocol.io/specification/2025-11-25/ser...

It would be really, really great if Codex could support MCP Prompts[0]

This would allow us to deliver standard prompts across the team without having to sync manually or with scripts; keep everyone up to date. Even allow per-user customization of "skills" via server rendering of the prompts.

AFAIK, Codex is the only major harness to not support this.

[0] https://github.com/openai/codex/issues/5059#issuecomment-453...

This one? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/

https://github.com/dotnet/Open-XML-SDK

First party from Microsoft; feels like it would be the way to go.

It will regress to the mean.

The default output of any agent is going to be Transaction Script, for example. It will never on its own accord start writing Domain Model.

As it produces more Transaction Script and sesles its own Transaction Script, it will regress to this paradigm.

You can get it to write Domain Model, but that is not its default.

I liken it to examples in docs: they are always intentionally the simplest case.

I don't think this is comparable.

It's more like a restaurant. You give an order and a little while later, a finished dish appears.

The difference between a Chipotle and a Michelin starred establishment is that Chipotle is just assembling a mass produced good. A Michelin chef knows their ingredients inside and out; knows the science of how those ingredients work; knows varied techniques to extract flavors, create textures, etc.

Anyone can work in a Chipotle; few can achieve a Michelin star.

    > Surely the desired state isn't that nobody knows how to write code any more right?

I still look at code and find that agents work best when I write the foundation and then vibe on top of my hand-written code. Works extremely well because agent picks up my style accurately.

It's a shame because to guide a coding agent, you need to have the right grammar and vocabulary to describe what you want and how you want it to be built. Junior devs should read not because they need to know how to write the code, but they need to know the vocabulary and the grammar to guide the agents.

    > And you think forcing blockbuster's software teams to use the Web would have changed that?

If it were that simple and obvious, Blockbuster would have beat everyone to streaming. Sears would have digitized their catalog and used their vast brick-and-mortar stores as fulfillment centers for same-day shipping.

None of these shifts were obviously the right bet and many organizations lost because they missed the opportunity. Now orgs are on the same horizon and I can see why they don't want to miss this window.

    >  I would prefer to search for new usages in a more strategic way

Looking back at the Internet, who would have thought that it would eventually create a Netflix, Amazon, Shopify, Spotify, Google Maps, etc. Just wild the things that ended up coming out of pushing bits over a wire with few simple protocols.

In an ideal world, you make strategic bets, but I can also see the case for the opposite this early in the lifecycle of a technology. You just don't know until you try.

Mid/late 2023, it wasn't at all obvious that it would take over coding that fast.