I suspect most of the critique even back then was around teaching from static written text, not the writing itself. In my experience that aligns well with modern education theory.
I bet there's an awful lot of servers out there that will happily take CORS requests from any host because someone didn't understand why their second domain couldn't talk to the same API.
Conceptually this is wrapping an agent harness in an LLM call API. I wonder if this format is more digestible than the agent building tools the big labs are rolling out.
A CLI or authenticated web endpoint requires somewhat arbitrary terminal or code access. MCP wraps the functionality in a way that doesn't require nearly the same permissions. Doesn't that enable a whole different class of users?
Interesting how much the post sounds like an AI prompt itself. Are we all going to start talking like that? Think hard, make a plan, and only reply after deep consideration.
There was a post from Github a few weeks ago showing commit volume exploded from linear to exponential growth about 6 months ago. I don't know for sure, but I think they weren't ready for the scale out. Whether that means actual scaling issues or cost cutting because of the scale out, who knows.
Feels like this is missing some of the key points of using generic bucket storage for me:
1. Archive pricing for really large old documents.
2. Cross-provider backups; especially for critical documents.
How much did they end up costing? We do a similar PCB medallion every year for another event and haven't been able to get quite that fancy due to cost. We usually only manage to get some LEDs and a processor in our lower budget range.
We've been doing this with simple mkdocs for ages. My experience is that rendering the markdown to feel like public docs is important for getting humans to review and take it seriously. Otherwise it goes stale as soon as one dev on the project doesn't care.
I went through a similar transition. Used to spend hours in dark table each shoot, but for a hobby it got tedious. Eventually I got my in-camera configuration right enough and haven't touched a raw in months. I'll still sort and crop; but no need to fiddle with things the camera is good enough at already.
I think that's sort of what I got from the article - open the right tools for what you're actually working on, not everything you might need for all the tasks in your backlog.
I actually agree that the code is one of the most important things to get right at a software company. Still. I would argue very few companies win on code merit alone either though. Strategy, customer communication, market timing, etc on the business side; design, system architecture, dev velocity on the technical side. So many factors are important beyond the quality of the code.