CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits.
MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases.
I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon).
Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too.
CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't.
For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev.
So my summary is:
CLI - Great for out of the box, things that are well known, where you want to verify the output
API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold.
MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate.
I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.
The way I see it is AI collapses hierarchy. Abstraction layers will become more flat both in software and in society. Because ultimately software and layers of heirarchy in society exists to serve a function. But now those functions are being replaced.
Imagine this you used to need a library for common things in your software project. Even if you just need one function but because it was easier to just import a library that would have been the standard practice. But now the AI will just go “I can just implement that thing you need in 10 lines”. You used to need things like react native or flutter if you wanted to build cross platform apps. Now not anymore you just need to tell the LLM and it does it in both, and you get better results too.
In society we also had all these layers of abstractions and hierarchies that we used to need but will become more and more irrelevant collapsing the hierarchy.
There is a saying “as above so below, as below so above” I think this applies here. It will propagate all through our social construct, software, society.
Or it actually entrenches hierarchies.. and it's just that so many CS majors got caught up in the discursive pleasure of poopooing social sciences that they don't actually have a good graspe on how power operates in society..
Right. Because the owners of capital will let you have access to the largest models, without which you can't compete with them.
I think that there is a high probability of increased inequality, just like the how the added productivity in the past led to large gains for the capital holders, and next to no gains for the other 90%.
Why do they even need to do that? It could be all open and you still can’t compete. The models could be all completely open weight forever and you still can’t compete with capital.
How are you going to pay for the models or the electricity or the hardware? How are you going to compete against a swarm of ai agents that were spun up 6 months before you with 100x the capital whatever small amount of capital you scraped together doing one of the last few human jobs? Not with your human intelligence, which is now useless compared to machine intelligence. Maybe with luck, but at that point we’re all just at the casino.
Maybe not all AIs, but LLMs benefit immensely from abstraction. They are trained on human code, and human code usually uses very high abstraction - so high abstraction is overrepresented in training data compared to low level implementations. It also drastically reduces number of tokens, and that has downstream effect of better utilization of context window and whatnot. We are not yet at the point where AI can use low-level code as building snippets the same way it can use high-level libraries; most likely we won't be for a long time.
If what you're trying to build is a perfect match for the full set of abstractions React provides then it's gonna be cleaner to use React than have AI re-invent it. But most cases I run into don't fit that description.
Note that even "plain" JavaScript is very high-level with tons of abstractions. Most website features are one-liners that call into browser APIs where the actual implementation lives.
I am honestly _astonished_ that the current crop of agents are not all written natively for every platform.
I tried porting a moderately complex workout app that I’ve built over years (and which includes a whole agentic loop) from web to iOS native. It took me a couple of evenings.
There is now no excuse to not offer a native experience for every supported platform when you are a bigger company.
Make one of the platforms using good coding practices. Vibe code the others from the source using a proper test battery.
Because it’s too complex and not worth the effort. Most users will not care about or perceive the benefit. If they delegate that responsibility to Google via Electron, they can focus on features/bug fixes that move the needle.
This is exactly how a company would act when they notice millions of people downloading and using their ram-hungry electron app. There is just no reason to not act this way.
What effort ? I’ve started seeing this attitude more and more. We had a thing that took a week to do before. Now it takes a morning. So we refuse to spend half a day polishing it because it’s too annoying.
Once the initial port is done, keeping platforms in sync is fast. Not to mention that a harness that would automate this would be valuable.
I run codex on an old rpi, it eats 190M of ram for what essentially is a telnet client.
If you actually try to implement the same app in multiple platforms from the same spec, you'll notice very quickly that AI makes the best quality UIs out of typescript electron or direct web. It accomplishes it's task the fastest, with the least lines of code and with the least bugs. Also hot patching updates works best with web.
And I say this as a person who isn't a web dev, but a mobile dev. This is why.
AIs are also really good at translating one complete app from one language to another where nothing changes. You'll also notice that new features will be implemented better in typescript web than iOS going further. I think this is why OpenAI changed their native swift chatgpt desktop app into web electron too.
As I said. I did a large migration from a PWA to iOS, with a pretty custom UI. It took a while, but it only took days. A full rewrite would be months of work the old way.
I have a question about web to iOS native. How do you distribute that app? I’m assuming you’re paying $99 yearly to distribute through the App Store? Is this app meant just for you or for anyone to find?
Reason I’m asking is because I’d like to make native iOS apps just for myself rather than progressive web apps. But I haven’t understood the best way to distribute.
No it means that libraries that chose the wrong level of abstraction will die out, particularly the ones that have an insufficient number of levers to pull.
This is because of the rationale that makes you ignore the library:
AI lets you build a competitor, but there is no rule that says you have to. You build the library because the existing one makes what you want impossible, otherwise you would have just let the AI write on top of it.
That probably means Fable doesn't have enough understanding of what AirBNB is in order to build a clone.
If you think about it, people don't really write much about how an app like that actually works. They write about the impact on travel, the impact on property prices, how to use it to book a vacation, and a bit about how it's a two-sided market place app, but not so much about what it actually does.
I assume that Fable has no access to it apart from the listing pages so it can't see behind the scenes to the property management side or the AirBnB admin stuff. The code isn't open so Fable isn't learning from that. There's probably a bunch of clones on Github but quality will vary.
If you want a clone of an app like that you'll need to build a large amount of context first, and even then you'll probably miss a lot.
There is still a lot of work do be done surrounding the systems AI integrates for us, and as a sibling comment mentioned, AI's ability to use various abstractions is incredibly beneficial, as it results in fewer tokens (not reinventing the wheel) and can provide more consistent/predictable polished results. If you're building something trivial like a basic web page or a very simple one-off script, sure, abstractions would be overkill. But if you're building something that needs to scale and interface with many other systems and work perfectly on every available platform, we still need abstractions that AI can work with.
I don't think we've seen the end of the library/framework churn from the last few decades before AI, but I do think we will eventually settle on an "optimal approach" where the average developer no longer has to consider tool A versus tool B for basically every common use case. Future libraries and frameworks will be designed specifically for AI to "understand". Most LLM training data is based on the old way of building software, and while it is pretty good at it, I think we'll see major improvements (and counterintuitively, less AI slop) as the underlying abstractions and AI models adapt to the new paradigms and workflows enabled by AI.
The one you're describing is the pull down. The AI doesn't need the library as a comprehension aid, so it drops a layer and writes the ten lines it actually needs. There's a second reason it might do this: it doesn't trust code written by other AIs, and pulling the functionality in-house shrinks the surface area it has to reason about.
But there's also a pull up. Writing code is getting cheap; making it hardened may not, and that gap doesn't close just because token prices do. If that holds, the economical arrangement is that someone (OSS or SaaS) ships vetted blocks and each user grows their own feature layer on top with their own agent.
Which means the stack gets taller rather than flatter. The top layer is bespoke per user instead of shared, and the bottom layer matters more, not less, because everyone is depending on the same small set of audited pieces.
Grok, Claude, GPT. This is it folks, it's been good knowing you all. I have enjoyed this community, but our days are numbered. The machines are uprising.
I'm not sure about all these benchmarks, I did some very simple tests (I have my own benchmarks https://upmaru.com/llm-tests) and these models fail, not sure if it's the inference provider or the model. They seem to be optimized for benchmarks more than real use cases. Do anything outside their distribution (even if it's not complex) they fail.
I Compared Deepseek V4 Flash 0731 (low) to Gemini 3.5 Flash Lite (minimal) and GPT 5.6 Luna (no reasoning) and Deepseek V4 Flash 0731 gets it wrong alot, where as Gemini and 5.6 Luna just gets it done.
I’m comparing same / similar settings between models. I can’t use high on one and low on others it’s not a fair test.
Not sure why I was downvoted. But seems the downvoter is quick to downvote anything that doesn’t fit the narrative they’re looking for. I’m just reporting my findings.
Low, High and Max, obviously, can't be compared across models. They only mean the model is likely to spend less reasoning effort (~output tokens) with Low than High on the same, *single shot* task.
But even in this very post, you can see that Max was actually cheaper than High.
If you are using API, you should be comparing based on end-to-end cost or speed or whatever blend of those two matches your cost/time budget.
I'm not sure it's a fair test either to compare the "low" setting of one model with the "low" setting of another. They're completely different settings that just happen to have the same name.
They want you to buy their hosted service, that's where the convenience is sold. If they give you a one liner script you can paste in or a docker compose that does everything from scratch they cannot sell their hosted services.
I watched this movie recently, and the same thought crossed my mind. I was going to write a blog post about it, but was too afraid to read the responses. I'm glad you did. If I meet you I'd buy you a cup of coffee, we'd talk and we'd become friends.
"When you see that in order to produce, you need to obtain permission from men who produce nothing - When you see that money is flowing to those who deal, not in goods, but in favors - When you see that men get richer by graft and by pull than by work, and your laws don’t protect you against them, but protect them against you - When you see corruption being rewarded and honesty becoming a self-sacrifice - You may know that your society is doomed." ― Ayn Rand, Atlas Shrugged
Thank you for publishing this. I've been following Paul Graham and his works for a long time. It's refreshing to see everything written down in a document like this. This is the bible for startups. Honestly, it's beautifully simple but not easy.
Do you have similar math for the flash-lite variant of the models? I'd be curious. Based on my testing / benchmark i think it's around the 100-120B mark.
With the Pro variant being around 600B - 800B
My testing is comparing it's performance / output to other models in the same size range, so not as scientific as yours.
MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases.
I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon).
Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too.
CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't.
For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev.
So my summary is:
CLI - Great for out of the box, things that are well known, where you want to verify the output
API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold.
MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate.
I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.
reply