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.
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.
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.
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
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.