CharlieDigital

hace 19 díasdiscuss

> ...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.

CharlieDigital

hace 19 díasdiscuss

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.

CharlieDigital

hace 25 díasdiscuss

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.

CharlieDigital

hace 26 díasdiscuss

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

In this kind of use case/design, I would assume it would make use of partitions to make this more palatable in which case it would seem that you would bypass this issue of "high concurrent DROP TABLE". Large scale CRUD app just points to recent-ish partitions. Old partitions are either going to be low or on access and can be dropped easily or transformed/transferred into some long term/cold storage.

CharlieDigital

el mes pasadodiscuss

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

    df.wait_for_schedule()

How does this call work? Is it idempotent if I call it from an application? If I run it 2x with the same parameters, does it double tick? Am I invoking this manually from a query console to only do this one time? Am I running this as part of a migration script?

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$$,

Is the `timed_out` a fixed constant that is returned on timeout?

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

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

CharlieDigital

el mes pasadodiscuss

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

Totally worth the listen.

CharlieDigital

el mes pasadodiscuss

    > We are shipping more features

That's not really the important question; the important question: is it generating revenue.

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).

CharlieDigital

el mes pasadodiscuss

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.

CharlieDigital

el mes pasadodiscuss

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............

CharlieDigital

el mes pasadodiscuss

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.

CharlieDigital

el mes pasadodiscuss

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.

CharlieDigital

el mes pasadodiscuss

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.

CharlieDigital

el mes pasadodiscuss

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.

CharlieDigital

el mes pasadodiscuss

$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?

CharlieDigital

el mes pasadodiscuss

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.

CharlieDigital

el mes pasadodiscuss

    > ...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)

Outside of the most trivial use cases, I've found that AGE will not get anywhere near Neo4j in terms of performance and there's a lot of edge cases that just flat out won't work. The interesting types of queries you'd want to do in the graph end up being quite limited in AGE openCypher; I could not write very complex Cypher that would otherwise work well in Neo4j.

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.

CharlieDigital

el mes pasadodiscuss

    > [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

CTO did the same on my team. While a the same time chastising some of the more senior engineers for not always using frontier models.

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

CharlieDigital

el mes pasadodiscuss

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.

MCP is schema + interaction model. If MCP were built on OpenAPI, it would still need another layer to describe interaction. It is effectively JSON schema + interaction flow + standard surface area.

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.

CharlieDigital

el mes pasadodiscuss

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?

CharlieDigital

el mes pasadodiscuss

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...

CharlieDigital

Submissions

MCP is dead; long live MCP

How Mindset Shapes Engineering Success at Startups

comments