Its like a lot of people really want pgrust to fail.
There maybe a chance this was cheating or it may have been a misunderstanding. But now since there is an open source version, why is there still this strong sense of negativity.
I'm also not going to cheer on database projects that can't be 100% transparent and honest.
Who the hell is going to trust their data to a people can't even be honest on benchmarks. What do you think will happen if (or when) there's a data corruption bug. What evidence do you have to think these same people will behave any better?
They failed themselves, we're just watching it happen.
Do you not believe their explanation for the accusations? To me it seems like if the released version is hitting or beating the allegedly cheated benchmark numbers then it seems unlikely they were dishonest in the first place.
I have been working in Climate Tech for a while but not as long as you.
Unfortunately my conclusion is that Climate Tech companies in general have been delusional thinking the mission is enough and there is no requirement to be a business.
The reason I am saying this is not to discourage from working in Climate Tech. The reason I say this is to please not go in with eyes closed which is all too common.
Climate Tech needs to grow and be sustainable both for the mission as well as a business. And for far too long I feel business smarts have been missing completely in this sector.
This ignores the big wheezing elephant in the room: climate action is fighting extremely entrenched and monied interests that are betting on dying before the bill for their action comes due and are ready to lie on almost unimaginable scale.
Saying it is simply a "branding failure" is about as accurate as saying "planning failure" is why around 80% of Ukrainians lost power in 2024.
This is not true, it's fossil fuel propaganda that has been very successful. The overwhelming majority of people are concerned about the climate but assume that they are in the minority. See https://ourworldindata.org/climate-change-support for example.
"Fight pollution" is the old approach, it doesn't work as well because greenhouse gases are generally invisible and cause no noticeable short-term impacts, and because in the US the industry has been successful in distorting the law such that greenhouse gases do not legally count as pollutants.
Climate change and renewables are broadly popular causes.
It might not seem like it if you live under a broken political system that can ignore what people want and so that doesn't translate into action.
When you point this out people say, "well it's not as important as cost of living or health or migrants from hot countries or getting out of wars in the middle east" despite it helping with all of those too.
The data says climate change is not broadly popular in the US. If it was, people (broadly speaking) would not have tripped over themselves buying bigger and higher vehicles and bigger houses in further flung suburbs. Not to mention the fierce political opposition to higher fossil fuel prices, which would be the easiest and most direct mechanism to combat carbon emissions.
Opened the link and it immediately shows how it generates so many files.
And my issue is always, how do I review so many files. Is the purpose just to go from 1 requirement prompt to so many spec files? How do I know the specs actually reflect the requirement?
I always feel I come away from projects like this even more confused.
I actually think I would like to use OpenClaw but everytime I go to the docs I give up.
It feels so intimidating. There's so much stuff going on. Maybe it is good for agents who can just motor through that volume, but me personally, I would want something simpler, maybe an `OpenClaw-lite`
When I tried OpenClaw it quickly turned into a lethargic mess which I really didn't see myself wanting to maintain long term. I looked at other alternatives which were similar enough to do what I was looking for (mostly scheduled tasks using data on my computer and some API data). I saw a mention of nanoclaw which I looked at but didn't try personally. I eventually settled on trying picoclaw[1] because it was extremely small, fast, and had enough features to do the job for me. It is under 10mb, fairly straight forward go codebase, and works with multiple model providers or locally hosted.
I’ve concluded that if you already use a coding agent then openclaw adds very little (at least the multiple rounds I’ve tried it since mid Jan), it mainly brought the power of do-everything coding agents to your phone, available everywhere. But you exchange a low quality messaging interface for that ease of access.
Just to be clear, I’m not advocating that people that benefit from openclaw move to coding agents. This isn’t a “dropbox is just SFTP” comment, more that if you are already using coding agents, it feels like they do most of what I saw from openclaw at least a few months ago.
Am I missing something? Would love to be proven wrong.
It's not only that, all this complexity leads to stuff breaking with every update. For a tool that's supposed to just answer chat messages it's impressive how crappy and unstable this software feels. I have it running since the release and my primary usecase seems to be to use the CLI to fix whatever broke this week.
Would not recommend running this, it's the antithesis of the Linux philosophy.
I built an agent to work with local Ollama models, and it will keep working and iterate on a goal until finished, but it doesn't do sub-agents or or any of the "just burn a million tokens but finish this" pipelines that seem to be the trend now.
It's a simple D executable that basically consumes no resources in your local machine.
There's a lot of similar projects out there that are closer to what you're looking for. For example, I used nanoclaw for a bit before switching to Hermes.
In my use, DeepSeek v4 Flash (which replaced the quite excellent MiniMax M3) lags behind GLM 5.2 & Muse Spark 1.2 (let alone Kimi K3). Also, K3 is a much bigger multi-modal model, while Flash is text-only and likely optimised for coding tasks.
Yep, and the v4 flash final is about 2.5x slower than preview making it no longer a fast model, in fact slower than Luna and bigger models in many cases.
Spark is actually the interesting one imo. It's significantly better, also significantly faster. If you are ok with letting Meta soak up your data (which DS does too) it's also the same price.
I've been using this DeepSeek model the whole day today after building with 5.6 Luna extensively over the last week and I would disagree, at least for Rust + OpenGL.
DeepSeek just spend almost 2 hours trying to figure out why terrain textures were not working. It tried everything over and over again, it even had reference code for meshes on how to setup the rendering with materials, and it could just not do it.
I finally gave up and gave it to GPT-5.6 Luna instead, and figure out in a single prompt after 20 seconds, that the terrain mesh was being initialized with None in the material slot.
Other tasks it has managed to figure out at least, but it is significantly slower than GPT-5.6 Luna and it requires a lot more iterations.
That's roughly my experience. Luna is extremely efficient and at higher levels of reasoning and longer running tasks more capable.
Reading the DS reasoning is wild, it's constantly going in circles. The most minor lack of clarity in your prompt and it will spend ages going back and forth on what you meant. It reasons 5x longer than the preview which makes it really slow now as well. We did a lot of work to nudge it to be decisive and improve our evaluation setup to there's more clarity, and it helped but only marginally.
Ours is a full-stack app one shot test so it includes backend, frontend, design, and QA/testing. It's graded by Opus xhigh and Sol xhigh and the grades are averaged.
DS4 preview would finish in 20 minutes flat on high reasoning and grades 6/10. Luna high gets 9/10 in about 30 minutes. DS4-final is crazy - at high thinking it's taking over an hour and getting ~8 but only had one successful run as I got tired of waiting so long after many early abort/retries trying to debug why thinking was so long. The lowest thinking still takes over 45 minutes, and with thinking off it actually is finally closer to preview in time but actually get's a much more varying result anywhere from incomplete to 6 it seems.
Costs per run DS4 is best but not actually by a lot as it's spending 10x the tokens with all the reasoning and mistakes. It's a very brute force model and I really preferred preview in many ways for how predictably fast it was.
Side note, Spark 1.2 is a nice model for this test, best in frontend design and fastest to get results together, though not nearly as efficient as Luna. Grok scores similarly to Spark but at like $50/run vs the contributor Spark costing $1.50.
Edit 2: btw it tests a team of agents working together in a special harness and stack. So 20 minutes is for 8 agents essentially. That said everything was built around DS as it was the cheapest to iterate against so even with that advantage the new one struggles.
I kind of get what the article is saying. But I am looking at it from a different perspective.
The same set of things like skills, and custom tools etc can actually be used to get faster to the a product that kind of fits 1000 customers. But the change is that one can build even more custom things for some customers with those skills and tools.
Last year I built a custom integration for a customer in 2 weeks. Now I can probably do it in 2 days. What does that mean for the future, I have no idea, but surely getting custom solutions like this would be more of a moat not less.
Universities use all kinds of hard to setup stuff which are often custom built. Slurm configs, custom configured HPC servers etc. All of this pays off though if you need to do heavy computations which a local machine won't do.
IMO it would be better to make Claude build out something that makes interacting with the HPC much easier. A web UI, Tailscale whatever.
I call this junk "meta-agentic engineering", it reminds me of people who have the coolest nvim configs, spend hundreds of hours customizing it but ultimately get less work done than the guy with minimal workflows, if any at all.
I look on twitter and it's just people building tools for agents to use agents, some weird customization loop going on in the LLM space right now. Ultimately these are trends pushed on us from model providers because they 10x token consumption. Its literally just BS trends to increase revenue at these companies, most of it is largely useless.
Some of this stuff is ludicrous. I finally tried /loop last week and discovered every loop iteration passes the entire context history to the model. So pretty quickly you're running a full 1M context window, without cache, likely just to check if something is ready or needs to be done. It's miserably terrible engineering unless your entire and only goal is to burn tokens.
"On a Claude subscription, Claude Code requests the one-hour TTL automatically. Usage is included in your plan rather than billed per token, so the longer TTL costs you nothing extra and only affects how long your cache stays warm.
If you’ve gone over your plan’s usage limit and Claude Code is drawing on usage credits, you are billed for that usage, so Claude Code automatically drops the TTL to five minutes."
I never liked the term "ricing" with window managers, but this is definitely veering into LLM ricing territory sometimes. And people are getting rich off of it.
I think many of us engineers (including myself) are suffering from AI-induced procrastination. Fixing that pesky bug in production isn't fun. Building a harness/workflow that detects and fixes pesky bugs in production on its own is way more fun (especially when your employer pays for tokens), and it feels just as important, if not more! So what if it didn't actually fix that pesky bug in production on its own...
I'd rather anyone using llms to fix pesky bugs in production gets fired and I work at a shop that cares about quality and craftsmanship. There are handmade swiss watchmakers, and then there are assembly line workers in China also making watches, which worker do you think goes home happier at night (and who's company is actually beloved), you have a choice.
I don't think there is a lot test harness, given there is a golden implementation (sqlite3), with clear interface (SQL, and sqlite3 db files). Once you slop crappy implementation, then you can create one group of agents finding gap where slop doing wrong vs golden, and another group of agents filling the gap meeting the conformance.
I assume they did similar, as long as test case(or spec) can be parallelized. Having parallel execution / testing environment is crucial if we need 1000 commits/second throughput.
I would not surprised they have 1+ millions of specs.
I would bet they won't release generated specs - actually this will be a valuable asset like https://sqlite.org/th3.html
Its like a lot of people really want pgrust to fail.
There maybe a chance this was cheating or it may have been a misunderstanding. But now since there is an open source version, why is there still this strong sense of negativity.
reply