> produces better results than just... talking to one strong model in one session?
I think the author admits that it doesn't, doesn't realise it and just goes on:
--- start quote ---
On projects where I have no understanding of the underlying technology (e.g. mobile apps), the code still quickly becomes a mess of bad choices. However, on projects where I know the technologies used well (e.g. backend apps, though not necessarily in Python), this hasn’t happened yet
No, this misunderstands what MCP is for and how it works.
Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house?
Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol your bulbs use, to be able to control them. Claude needs to support your specific lightbulb stack, and some kind of routing software would need to be added in your home to connect the external network to the internal devices.
But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs or have some custom routing thing for your home. You just need to run an MCP server that talks to the lightbulbs... which the lightbulb company should make and publish, so you don't have to do anything but download the lightbulb MCP server and run it. Now Claude can talk to your lightbulbs, and neither you nor Claude had to do any extra work.
In addition to the communication, there is also asynchronous task control features, AI-specific features, security features, etc that are all necessary for AI work. All this is baked into MCP.
This is the power of standardized communications abstractions. It's why everyone uses HTTP and doesn't have their own custom application-specific tcp-server-language. The world wide web would just be 10 websites.
No, that's not MCP. That's a pleasant idea that MCP has been shoehorned into trying to solve. But MCP the spec is far more complicated than it needs to be to support that story. Streamable HTTP transport makes it much more workable, and I imagine was designed by real people rather than the version prior to that, but it's still much more than it needs.
Ultimately, 90% of use cases would be solved by a dramatically simpler spec which was simply an API discovery mechanism, maybe an OpenAPI spec at a .well-known location, and a simple public-client based OAuth approach for authentication and authorization. The full-on DCR approach and stateful connections specified in the spec is dramatically harder to implement.
> But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs
Except the fact that it has to "know" about that specific manufacturer's bespoke API aka "tool calls" for that specific lightbulb. If the manufacturer provides an API for the lightbulb.
MCP is a vibe-coded communications protocol. There's nothing more standard or re-usable in MCP than HTTP, or any protocols built over that. Hell, using GraphQL would be a more standardized, re-usable and discoverable way of doing things than MCP. Fielding ddescribed and architecture for machine-discoverable APIs in 2000
> It tries to standardize the auth, messaging, feedback loop where API can't do alone.
If it tried to do that, you wouldn't have the pain point list.
It's a vibe coded protocol that keeps using one-directional protocols for bi-directional communication, invents its own terms for existing stuff (elicitation lol), didn't even have any auth at the beginnig etc.
They did the right thing in hindsight: leave security open until clear patterns emerge, then solidify those patterns into a spec. The spec is still in draft and currently, they are trying to find a simpler solution for client registration than DCR, which apparently ephemeral clients seems to solve for now.
If they had made the security spec without waiting for user information they would most certainly have chosen a suboptimal solution.
Isn’t this just something that any IDE has built-in these days? Maybe I’m missing something, but how is this fundamentally different from the built-in git timeline view from something like VSCode or Jetbrains?
> Isn’t this just something that any IDE has built-in these days?
In most IDEs I feel that Git integration is an awkward badly integrated afterthought. They are also very much tied to the whatever IDE offers them in terms of available shortcuts, layouts, controls etc. (this applies to Magit, too).
I upvoted you because you were unfairly downvoted. I don't even use a Mac any more after 20 years of exclusively using them but it's actually hilarious how bad magit is compared to this. It's all well and good making the most of limitations that are self imposed but people need to remember to look outside their own bubble.
It may be prettier looking. I've seen many Git GUIs that are prettier than Magit.
But none of them that I've tried have ever come close to the workflow.
I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.
Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
So no, I haven't tried that one because it's Mac only, but I'm not really seeing from the screen recordings the kind of workflow that I find so powerful in Magit.
> I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.
I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts.
My most common workflow besides staging anything is (to make sure history is clean):
- split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit)
- move new commit up/down the branch (doesn't require interactive rebase in GitUp)
- squash up/down
(undo/redo from time to time)
As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent
> Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2]
However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason.
In my city there are segments where I can see several kilometers ahead, including the traffic lights and their associated roads and traffic.
If you can't understand the fact it's safe to run a red light when you can see the roads are clear for several kilometers ahead of you, then I simply don't know what else to say.
Even police does this while roaming about on patrol.
Honestly, these arguments sound like cartoon logic. Guy looks both ways and sees the roads are clear but on the exact second he starts to cross the street 10 cars materialize out of nowhere at 200 km/h and nearly run him over just to teach him a lesson. This isn't how the world works.
>A vehicle will materialize out of nowhere and crash into you.
God I hate these sort of responsibility shirking opinions and their peddlers.
I do this several times a day in a major US city for close to a decade now and I've never had a close call closer than the "two people trying to pass each other in the hallway" routine with a driver trying to take a right on red.
Vehicles and everything else on this rock flying through space obey the same laws of physics.
If the traffic on a road goes X miles per hour, then simply don't cross it where you don't have a sufficiently long line of sight. If crossing where the lines of sight are sufficient is not tractable due to traffic volumes or road construction then cross at a marked crossing, intersection that interrupts traffic flow or use proper body language and someone will stop for you.
Sure, you might get exceptionally unlucky and choose to cross at the exact minute some car that's a few standard deviations above the norm but you might also get hit by lightening.
> I do this several times a day in a major US city for close to a decade now and I
I, I, I
> Vehicles and everything else on this rock flying through space obey the same laws of physics.
Yes. Yes they do.
That's why some countries (e.g. Sweden) actually have this in drivers ed: how fast a vehicle travels, how long it takes for the driver to react, what the stopping distance is for a vehicle etc.
They even teach things like "parked cars are a double problem because you can have people especially kids suddenly appear from behind them".
Or things like "at night you only see this far, and judging distance to things becomes harder".
But all that, including laws of physics, is invalidated by a litany of "I, I, mine, my, me".
I'm not special. I'm fairly normal. Hundreds of millions of people manage to walk and drive as uneventfully as I do. The presence of some few number of people who can't manage to jaywalk decently and not run reds when it matters doesn't justify saddling the literal entire rest of society with some automotive flavor of 1984 anymore than some small number people robbing convenience stores to pay for their drug addiction justifies subjecting all of society to pervasive surveillance and the war on drugs fueled police state.
Obviously. Don't take risks near pedestrians, near schools, near parked cars. Don't make assumptions in low visibility conditions where you can't actually see what's ahead of you. Use your judgement.
To cover Europe's need you only need to build 70 1.5 GW hydroelectric stations at a cost of $92 billion (in reality much higher) while greatly damaging ecology in large areas.
This source also offers an option of $1 Trillion USD to do it with battery storage.
All of Europe. $1 Trillion USD. Oh, and that figure has already fallen by 1/3rd in reality and the article claims it should drop by half again.
And that seems to be assuming you only have wind power as input. The long lull periods that drive the high storage requirements are, as that article claims, caused by large high pressure air masses. High pressure systems like that often come with clear skies! Indeed, go look at weather history for that same 2015 period and you see that the skies were calm and clear, and precipitation was about half the "normal" amount for that time of year. While there is perfect correlation between a windless day and a night without sunlight, battery to get you through the night is trivial and solved far more cheaply than this article seems to understand. Enough battery to maintain 24 hour output for a solar farm is cheap enough to compete with fossil fuels. Long term, wind and solar do not correlate, so it's very rare to have long lulls in both at the same time.
So this article is leaving out important details and also is way more pessimistic than even it admits is true.
That also ignores that even in the "lulls", wind never seems to go to zero, so even in lulls, you can always just have more wind. Building 10x as much wind as you need is not as feasible as building 10x as much solar as you need though IMO.
Oh, and a very very very important fact: Renewable generation is almost entirely a one time cost, or one time every 30ish years on average. OPEX per kilowatt hour is dramatically lower than fossil fuels. In fact, today Europe imports 10 million barrels of crude oil a day, and at $100 a barrel (a number which will rise quite a bit in the coming months), Europe spends $1 Trillion every few years.
Europe's current energy spend is to buy an entire continent's worth of energy storage and just turn it into CO2 every few years. Every single day of crude oil import, Europe could instead pay for one of the Coire Glas model plants this article is doing the math with.
Storage is beyond feasible and will reduce energy costs.
Note: This article is about making wind energy constant over month long time scales, not about building enough storage to power Europe durably, so that explains some of it's misses, but also doesn't really explain much. The 2.1 TWh of storage it suggest would be enough to power all of Europe for 8 hours a day.
I think the author admits that it doesn't, doesn't realise it and just goes on:
--- start quote ---
On projects where I have no understanding of the underlying technology (e.g. mobile apps), the code still quickly becomes a mess of bad choices. However, on projects where I know the technologies used well (e.g. backend apps, though not necessarily in Python), this hasn’t happened yet
--- end quote ---
reply