Published on: 4/9/2026

Last edited on: 5/23/2026

So firstly what are ClaudeHeads? They are people who have claude in place of their head. They literally think LLM is the only answer and can only think using them, they are just straight up bad at individual thinking, but that doesn’t matter, cause LLM can solve everything given right context, given all the information in the world about thing which exists.

For me this is a problem. I joined database industry cause I could not bear writing HTTP APIs for the rest of my life. I am not smart enough personally, but there are horrible software engineers out there, you would find shitty code in all parts of the software stack. But for something which is performance critical, needs to correct always, and is always the black box for programmers, that would need highest and purest levels of programmers, right right??? Well it seems I could only enjoy this dream for sometime, cause LLMs have given birth to ClaudeHeads. We use an open source project named datafusion and have based our database on it. Its not a direct stock integration, we have had to make a lot of changes according to our needs, and it seems distribution is still an unsolved problem there. Also main IP of planner stays with us, single execution is not a solved problem, but open source projects are very very good!

Well, given that it is open source, of course LLMs are trained on it. Now, that is one part of the equation, in recent months they have also become good enough to interact with private parts of our codebase. Migration to a datafusion based engine is a recent enough project and we had been working hard to get performance on TPCDS-like benchmark[1], TPCH-like benchmark, Clickbench, and a bunch of internal benchmarks. We were very very slow as compared to our good old internal custom developed Java engine, as compared to Databricks, as compared to Snowflake. Whole team was heads down working on getting perf better than all of the above combined. As me and other senior colleagues took an “old school” methodological approach of looking at heap profiles, CPU flamegraphs, custom metrics collected by us, finding gaps in our understanding of the system, as not whole codebase was familiar to us yet. Here enters my ClaudeHead hero, who downloads research papers of Datafusion/Arrow etc, keeps them in a folder, keeps all TPCDS queries, their flamegraphs, heap profiles and metrics together, and send the agents to “find perf improvements”. The result was pretty shit with earlier models, but what about recent ones? You leave them for a night and they conjure up a bunch of things. Tho how do you test them?

So, incidentally someone in my company developed a easy to use benchmark setup. What was left now, multiple branches started getting created, purely vibe coded and benchmarked in parallel. What ever improved perf was posted as it is after “understanding from Claude summary” to the channel and merged to main. Well the problem is “understanding” part is absent, if asked to reason about the change from different angles, like architectural correctness, my friend would turn around and just ask Claude. There’s no head working there, it’s just Claude. Well how do I know this? Cause I have asked questions around why some part of it didn’t make sense in larger scheme of things. Why even tho metric shows there’s nothing to optimize, you keep repeating there’s an optimization in a specific region, without backed by proof, just because Claude said that. What’s worse, this is a junior engineer just entering the field. Not good at coding, not good at databases, not good at CS fundamentals. But given LLMs, he can keep on posting perf optimizations and get them merged. One could argue, if those don’t make sense why can’t you prove them wrong? Well here comes the main point of article, my views on ClaudeHeads and how they are correct at times, but expert bullshitters at times. Back in the days, when no LLMs existed, if someone bullshitted, they had to put a LOT OF EFFORT to even get something remotely good out, btw this is considering that it was still considered easy, Brandolini’s law. During the process, they learned 100s of things and would definitely come out as a much better engineer, but now? Tell LLM to fire off and conjure stuff, what if that does not make sense in grand scheme of things and would literally break in just a different environment (someone shares my feelings). Well that’s benchmaxxing. But what if you could keep benchmaxxing again and again for each dataset. That’s not exactly what’s happening, but I am thinking through scenarios.

Not understanding what changes you are making to me is the biggest risk of all time, and it breaks what I thought about before starting to work on databases. It’s not a race of understanding, now it’s a race of trying random folder structures with random bits of information to get the best output out of LLM models. Oh guess what, I am still stuck in the old model, and this has caused a big disadvantage to me. Not only am I slow now, I am also losing learning opportunities myself, just because someone decided to not understand them and rely completely on LLMs. I can pick up LLMs to speed up my work, but all I have ever learnt is, slow and steady wins the race. I believe it to my heart, mental models are the biggest factors of a product. That’s the reason when someone who understands codebases deeply leaves, new team gets in frenzy. That’s the reason losing a product person who understood product deeply, is such a big loss. They are hard to replace. Code was never the moat, mental models were the actual secret sauce. But in this case, trash out the mental models, we will just use LLMs to not just write code, but also think, not build mental models, just straight up outsource thinking.

Writing code is amongst the best way to build mental models, slow, deliberate thinking is what dials down core ideas of anything. This applies to product building as well as programming. Having faced the “friction”, and letting mind battle with it is the best way. I recently read a blog post in similar vein, but talking about astrophysics: https://ergosphere.blog/posts/the-machines-are-fine/. It’s an excellent read, do go through it.

But yeah, this is my problem, sorry I am not slow, I am just not a ClaudeHead.

[1] I say TPCDS-like cause I remember how badly PlanetScale was thrased in an official blog post when the data generator used by them did not actually comply with TPCDS specifications :upside_down: