> But this was never the hard part. Not even close.
This is revisionist history. Coding was definitely one of the hard parts!
98 karma · joined October 13, 2025
This is revisionist history. Coding was definitely one of the hard parts!
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.
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."
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.
For the question where are the alternative OSes? Here is one that I've seen. There's probably more - https://www.reddit.com/r/ClaudeAI/comments/1wfpydl/i_asked_c...
For that other stuff you mentioned like the right click menu. Those huge corporate projects suffer more from layers of institutional dysfunction and will be very very slow to show any improvement. Their dysfunction can't be solved with just faster coding.
Using AI to build more features is easier than using AI to improve existing projects. People will gradually figure out how to do latter too, it'll just take longer.
> 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.
AI models are changing the world much faster than their own training can keep up with.
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.
- 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.
1) the minimum number of employees it takes to maintain the core product
Vs 2) All the employees that it makes sense to hire for revenue and market expansion.
Internet comments usually assume that (1) is the goal. But think of say the sales department. If every salesperson you hire brings in new company revenue that’s greater than their salary + overhead, then why not hire 1000 of them?
There's no scenario where AI goes away completely.
I don't think the "major AI services go away completely" scenario is realistic at all when you look at those companies' revenue and customer demand, but that's a different debate I guess.
There's wildly different reports about whether the cost of just inference (not the training) is expensive or not...
Sam Altman has said “We’re profitable on inference. If we didn’t pay for training, we’d be a very profitable company.”
But a lot of folks are convinced that inference prices are currently being propped up by burning through investor capital?
I think if we look at open source model hosting then it's pretty convincing - Look at say https://openrouter.ai/z-ai/glm-4.7 . There's about 10 different random API providers that are competing on price and they'll serve GLM 4.7 tokens at around $1.50 - $2.50 per output Mtokens. (which by the way is a tenth of the cost of Opus 4.5)
I seriously doubt that all these random services that no one has ever heard of are also being propped up by investor capital. It seems more likely that $1.50 - $2.50 is the "near cost" price.
If that's the actual cost, and considering that the open source models like GLM are still pretty useful when used correctly, then it's pretty clear that AI is here to stay.
I've never worked at a company as large as Google but in my experience things can be a little more optimistic than the post. When earn enough trust with your leadership, such as at the staff/architect level, you'll be able to tell them they are wrong more often and they'll listen. It doesn't have to be a "$50,000 check" every time.
That leads to a very important question - Why doesn't leadership always trust their engineers? And there's a very important answer that isn't mentioned in the blog post - Sometimes the engineers are wrong.
Engineers are extremely good at finding flaws. But not so good at understanding the business perspective. Depending on the greater context there are times where it does make sense to move forward with a flawed idea.
So next time you hear an idea that sounds stupid, take a beat to understand more where the idea is coming from. If you get better at discerning the difference between ideas that are actually fine (despite their flaws), versus ideas that need to die, then you'll earn more trust with your org.
And of course Claude Code has custom slash commands which are also very similar.
Getting a lot of whiplash from all these specifications that are hastily put together and then quickly forgotten.
Yeah I don't know about that, the model providers like OpenAI, Anthropic, etc, literally sell intelligence as a product. And their business model is looking a lot more stable in the long term than all the startups built on top.