apf6

> But this was never the hard part. Not even close.

This is revisionist history. Coding was definitely one of the hard parts!

This is maybe a little less revolutionary than people are treating it? A lot of large tech companies (Google, Facebook, Microsoft) have already built their own homegrown SCM (or have implemented custom extensions to Git), because Git and other SCMs don't handle their scale. Most interesting thing about Scion is how quickly it was deployed.

Hey Odibert, so it runs processes in the background, like other process manager tools such as `pm2`.

The benefits of that are that you can launch all your project's services with a single call to `candle start`, you don't need to open terminal tabs for each one.

Then once the service is running, you can look at the service's output with commands like `candle logs <service>` and `candle watch <service>`. For example you could open a new tab and use `watch` to see the live logs. And if you aren't watching logs, you don't need to have a terminal tab for it.

It also has a builtin rule of only launching each service one at a time, so you won't accidentally launch the same service twice.

If you don't know the name, Sindre Sorhus is a very prolific open source developer who maintains over 1,000 libraries.

He'll still accept issue reports but not PRs.

Posting it because I think this is the beginning of a trend for how open source works. A lot of hard parts about being an open source maintainer are just solved when they control the coding agent.

"It simply makes no sense for me to spend time reviewing and going back and forth on a low-quality PR when I can generate, verify, and ship the fix myself 10× faster."

> That's just volume though

If we sorted through all those new apps and ignored all the crap, I'm pretty sure we would find an overall increase in actually useful apps. I just shipped a new app myself, and I think it's useful, and I wouldn't have finished mine without AI assistance.

> products with a real userbase that couldn't exist or be scaled pre-AI?

Coding hasn't been the bottleneck for product creation for a while. So I don't think there are going to be many examples that fit that exact criteria. Any app idea was 'possible' before, it just took more developer hours to do it. So now teams are doing more things that were weren't worth the effort before, but are a lot more feasible with AI assistance.

Article is focusing too much on tool use over HTTP. One of the good things about MCP is that it's the same protocol whether the tool is implemented with HTTP or using stdin over a local process. And it doesn't make sense to talk about HTTP headers with stdin.

> There are still some issues, like CLIs returning machine-readable responses (JSON/XML, etc.), which tend to be very verbose and heavy on token usage, but we have ways to fix this.

This problem is also solved by MCP.

Anyway, when building a new tool, I personally try a CLI based tool first, then I'll fall back on MCP if the CLI is not working.

One big reason I see for needing to switch from a CLI to MCP, is if the agent needs to send a lot of data to the tool, and it has to pack and format all that input data as CLI params, and you can start seeing problems with the Bash command syntax being improperly escaped. That problem is solved by MCP thanks to using JSON-RPC over stdin.

Summary.. you shouldn't use MCP for everything, but there is a time and a place for it. Which is what the experienced devs have been saying about MCP for over a year now.

you don't have to compare whether stochastic fuzzing or agentic testing is the best. You can just do both of them. They both have enough ROI to be worth the trouble. That's why I said "in addition to".

It reminds me of how AI will estimate that a coding project will take "4 weeks" and then proceed to finish the task itself in 15 minutes.

AI models are changing the world much faster than their own training can keep up with.

It’s 2026, so another basic technique that every team should add to their testing strategy (in addition to proven techniques like fuzzing) is agentic user simulation. Set up an AI agent with access to the product, and prompt it to use the thing in hundreds of realistic use cases, and to report any possible bugs. It will catch a lot of ‘blind spot’ bugs that were previously things that were only caught by humans.

Yeah I think this is a good approach. I’m pretty AI-optimistic when it comes to making code changes. But reading AI generated descriptions (including pull requests) is absolutely the worst. That content really needs to be human written. Not just for the benefit of the reader, but it also helps the writer exercise their understanding.

Slowing down development is the wrong goal. I see a desire for slowness come up a lot with developers. If you pursue that goal all the way to its logical conclusion then eventually you would stop all coding completely. Which would prevent new bugs but obviously we can't do that and keep our jobs.

By all means add tons of quality gates to your SDLC pipeline. But thinking about slowness purely for the sake of slowness will not solve your problems.

old and inaccurate knowledge..

- Skills do take up space in the context. The name and description of every skill goes into the system prompt. You can't add unlimited skills without context pressure.

- MCP context spam is less of a big deal now that there is deferred tool loading.

- If you work with the agents long enough you'll run into situations where using bash CLI tools suck and an MCP works better.

- MCP is not dead and has never been dead, it's the right solution in certain cases.