159 karma · joined August 31, 2014
They pinpointed the problem of over-coordination to the messenger (coordinator) instead of the teams demanding final approval over launches (coordination).
Won't merging different teams under a single owner only push the problem further down the org chart?
One gap I'm noticing in these comments and in the current sandbox landscape is Windows. Every platform mentioned in these comments like E2B, Daytona, Fly Sprites, Sandflare appears Linux-native. Makes sense for coding agents targeting Debian environments, but a real category exists to automate Windows-specific workflows: enterprise software, ERP systems, anything that runs only on Windows.
If anyone wants to run agents in Mac or Linux and need to access Windows for computer use, Dexbox could be helpful. [github.com/getdexbox/dexbox]
I launched an open source developer tool called Dexbox to run agent workloads that quickly provision and run Windows desktops. It's a CLI and MCP experience that's different from Freestyle, but slightly closer to our Windows-specific production infra, Nen. I like Freestyle's cool UI that shows off the unique technical approach and developer friendliness. Nen's a bit closer to that experience.
Would love to hear from others with more Postgres than I.
OpenAI the company may not be responsible, but there are elites in the OpenAI sphere who might be.
Seems like "annoying" refers to a user interface annoyance.
I'm guessing the following since I couldn't tell what structured editing is like from the article:
Keyboard entry is immediate, but prone to breaking the program structure. Structured editing through specific commands is an abstraction on top of key entry (or mouse), both of which add a layer of resistance. Another layer might come from having to recall the commands, or if recognizing them, having to peruse a list of them, at least while learning it.
What does the developer's experience with incremental parsing feel like?
Seems healthy to me.
It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat.
Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does.
I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.
I discovered the joy of Go from dealing with JavaScript promises while writing an API service in Node. So many painful runtime errors uncaught or unlogged because promises don’t (or didn’t) require the catch callback.
I think inverting the programming perspective to default to sync instead of async is more productive for web services development, than perhaps for UI.