Doesn't CLI use MCP (if need-be) ? I think you might attempting to say "Neat, discrete buckets of work?" (i.e., MCP - similar to HTTP in that work is broken into discrete canonical buckets), or "Virtually unbounded work made available via various CLI utilities?".
I would pick the second option. CLI.
However, for CRUD B2B SaaS I think MCP works fine (if not better than CLI).
Things are time bound by instruction creation - at some point you still need a human to dictate the instructions that the orchestrated agents use. From there I've found that -- (1) derive a goal from the instructions (2) break that goal into tasks (3) order those tasks into a DAG (5) spawn the agents to work via the DAG -- seems to be doing everything I want it to do.
Working the same, the nature of the work has changed. Less time spent on the minutia of syntax and project scaffolding. More time spent on how the minutia compose into a larger system.
I'm personally tired of getting stuck in config/deployment hell every time I want to deploy a long-lived web service. Sure I eventually learned how to use systemd, but systemd has SO many things baked into that I simply don't need. systemg is a lightweight process supervisor that features everything you'd typically want when running/managing production web services in the wild.
True, but I think the point I'm trying to make is that when it comes to deploying (what are more often than not) web services, getting to the point with systemd where it "just works" requires more pain than I'd like - especially with regard to production deployments (reading logs, checking service status, wondering why my env vars aren't being read, etc).
If at the time when I was cutting my teeth on systemd, I had access to something more lightweight and "do one thing well", I think I would've gotten a lot more sleep :)
I have rarely in my 11+ years of professionally writing software, met someone who could _really_ "write code", but couldn't build software. Anecdotal obviously. But I'd say the opposite tends to be the case IMO - those who tend to really know "the code", also tend to know how to effectively build software (relatively speaking).
It kinda makes sense - "knowing how to code" in modern tech largely means "knowing how to build software" - not write single modules in some language - because those single modules on their own are largely useless outside the context of "software".
If you want to migrate off Spotify but are worried you’ll lose your library, feel free to checkout my tool Libx (libx.stream). It’s a tool to export your entire Spotify library to a nice and neat CSV file
I like minimalistic websites, but I feel like that's too far. No information what so ever about anything at all, just a "Login with Spotify" button. What happens once you're logged in? No one knows.
I suppose there's a lesson in there that they could write an explanation of what happens when you log in on the page but you'd still have no actual knowledge of what happens. No explanation is honest.
reply