It's really interesting seeing all the comments from cyclists regarding Waymos. I currently live in a Waymo-less city and they weren't common enough in SF when I was biking there to be a big factor but I remember some harrowing moments with human drivers (without precious cargo - that sounds extra scary!). I'd be curious to try it again and am pleasantly surprised to hear it makes such a big difference!
I thought the emphasis on test-driven development or at least writing tests first and writing high-quality integration tests in this was really interesting. We don't often associate "vibe coding" with "great testing" these days, but it's such an essential guardrail for production-grade software.
"Reducing pager volumes isn’t just about better sleep for on-call engineers (though that’s a wonderful benefit). It’s about building a culture where fixing root causes takes precedence over quick patches, where system understanding is valued as highly as feature delivery, and where we recognise that reliability is a feature customers value even if they don’t explicitly ask for it.
We’ve learned that you must intentionally prioritise technical excellence to achieve it. It can be challenging to maintain these standards as you scale, but staying focused means that things can fall back into place."
Appreciated the conclusion, although was a little surprised at how lowly feature work (falling under "everything else") got prioritized relative to other engineering work.
I also found this surprising! I think a lot of UIs are sort of still just riffs on ChatGPT type products but with some exceptions/improvements (v0 stood out here).
"Software simulations" is a working title but it is sort of a new kind of thing we're trying to do and describe - definitely room to improve.
Our goal is to simulate every function and aspect of your application and in doing so provides both a test suite and demonstration artifacts. it's akin to an intelligent, semantically aware fuzzer that is creating both good and bad results (vs. a fuzzer just creating bad results with the intent of breaking things).
It is connected to your code via a GitHub app with read permissions and the ability to comment on PRs when analysis happens.
Let me know if this helps (or doesn't!). I think it's a little different from what you're envisioning but you're not far off.
That's a good catch - sorry we missed including the links initially and thanks for including them here. The blog post has been updated to include links in a dedicated section.
The history of middleware in this and the predictions for MCP based on past outcomes is really interesting.
"Middleware never quite lives up to these promises in practice. MCP, if history is any guide, will go down one of two paths:
1. Everyone will use it.
2. Everyone but one key platform will use it
When (1) happens two things will be true. First, no one will effectively monetize it. Second, every vendor will also add unique aspects to how they consume (client) or produce (server) the exchange. This is internet networking, TCP/IP or HTTP. For (1), the feature is low level enough that all the interesting things will happen on top. This happens as something goes from "new and cool" to building out broader capabilities.
When (2) happens that is because one platform is the leader and our industry has a long history of "everyone but.." APIs/protocols that are used by everyone but the leader. Usually by the time this leader "comes around" to being a first class citizen, it no longer matters as the industry has moved on to the next big thing as a center for innovation."
