maherbeg

Yes, that's true, but in the post, they even mention that building the spec is the scarce resource.

  For that to work, the swarm has to actually follow the spec, which is what much of this post is about. We gave the swarm 835 pages of prose and it came back with a database. What was scarce in this experiment, and what we expect to be scarce in software engineering going forward, is the right description of intent.

Yeah, agreed. It makes everything else look pretty bad. I still like to manage my work in a more structured form, but Codex can just rip on a goal end to end in the same thread.

You also might like https://github.com/nicobailon/pi-boomerang that lets you effectively do some work, compact that section with a summary and continue on.

I'm pretty annoyed with how fast this feels. Wish MacOS was this fast launching things.

oh yeah, sorry, I should've started my comment with "this is awesome" because it is, you did a great job explaining all the layers and the interactions within. I love stuff like this even if it's not necessarily prod ready by default!

A few of us built nearly the exact same thing for a Hackathon which was fun. This definitely can work. There are a couple of other approaches too that are interesting like

  - xata - https://xata.io/blog/xatastor-zfs-nvme-of-for-millions-of-postgres-databases
  - neon - which has a more sophisticated architecture that builds abstractions at the Postgres layer

This is really pretty, but I'm surprised it doesn't have a microphone. I know it's just rebranding the existing work louder creator keyboard, but a mic would really, really help with this product. Especially one that is really effective at Wispr Flow-type speaking.

What's better about the dedicated player out of curiosity?

I wouldn't care where my data went if it was to help my children.

I would say one thing I've enjoyed about the latest frontier models from US labs is that you just work at a higher level of abstraction. You can talk about the end goal and it'll just rip. You'll add scaffolding to constrain the patterns etc, but I do way less baby sitting than I expected on 5.6 vs 5.4 vs Deepseek v4 Pro.

I wouldn't call this minor. The 2 big features seem to be integrated memory + ambient proactiveness. This requires pretty intense tuning to not be annoying.

I've found the prompting needs are drastically different from the latest frontier models to the latest open weight models. I can be much more vague and talk about an end goal with the frontier models vs needing to be more prescriptive + have a workflow on the open weight models. This gap continues to close, but the level of abstraction I'm working on with the latest models continues to move much higher.

Cursor had a specific licensing agreement that allowed them to brand it how they want.

I wonder if new models will be trained with speculative decoding as a core feature allowing fewer experts to be needed for a pass.

I'm a big PGDog fan! It really helped us scale our connection proxy needs pretty substantially and it has great features like auto mode to support Aurora failovers neatly. It's infra that just works.

Happy to chat about this, but we use the AWS secrets manager flowing into External Secrets Operator to generate a pgdog_users.toml. We then kick off a workflow to refresh things, but our rate of change here is much smaller than a super dynamic multi-tenant system.

You could also build a watcher side car that watches for changes of the pgdog_users.toml and have pgdog refresh itself then too with this combination. We thought about that but prefer to control the reloads for our needs.

iOS 27 supports devices all the way down to the iPhone 11, so I think they're doing pretty well here.

Great post! There are some neat tricks around completion initing that I'll have to grab. I use fish shell and have done a bunch of optimization around async git statuses too.

for sure! but there are lots of incremental shareable primitives that could help. I think about go's built in testing tools that can get extended as an example

Very happy for them, they made excellent tools and I hope they can continue their work!

I do believe though that these tools (formatting, linting etc.) should be built into the language like Go, and I really hope the Node team can just absorb the best ideas and make solid primitives that can be built on top of as the ecosystem evolves (think golang's http interfaces, or test interfaces)

In addition to this, the labs are all building managed cloud agents, where they can tune better models and better harnesses. If you want the best performance, you'll eventually have to use their platform with their secret alpha baked in.

There will always be a gap, but what's interesting is that because new models are constantly coming out, we as an industry never spend any time extracting the maximal value out of an existing model. What if there are techniques, and harness workflows that could be optimized for a singular model end to end? How far can that push the state of the art.

An example is https://blog.can.ac/2026/02/12/the-harness-problem/ for just improving edits.

Or if we could really steer these open source models using well structured plans, could we spend more time planning into a specific way and kick off the build over night (a la the night shift https://jamon.dev/night-shift)

This is so sick. I'm really curious to see what focused effort on optimizing a single open source model can look like over many months. Not only on the inference serving side, but also on the harness optimization side and building custom workflows to narrow the gap between things frontier models can infer and deduce and what open source models natively lack due to size, training etc.

I also don't think a lot of people know some of the more advanced context management tricks like /rewind /fork /tree to take advantage of prefix caching

Zed has a "turn off all AI features" checkbox if you want to use that

It works well but there are a lot of missing features * skill auto complete * custom agents * sub agents * background process management

pgbackrest is awesome, truly. Thank you so much for the work you've put into this project over the years, and I'm sad the crunchy data acquisition couldn't keep the project alive.

We actually have one of these between our group of friends and their kids and it's awesome. The kids call each other to chat and setup play dates or to go run around in the street. Our kids will call back home to let us know they made it to the other persons house, or let us know they're coming back home too.

The tactility is incredible, and it's so just so cute to watch them chat away (5 year olds!)

Honestly, they can keep waiting for another year or two for on-device models at the size they're looking for to be powerful enough.

The way we solved it is by checking the lsn on the primary, and then waiting for the replica to catch up to that lsn before doing reads on the replica in various scenarios.