CLAUDE.md in my projects only has coding / architecture guidelines. Here's what not to do. Here's what you should do. Here are my preferences. Here's where the important things are.
Even though my CLAUDE.md is small though, often my rules are ignored. Not always though, so it's still at least somewhat useful!
Anecdotal, but I've been locked to Sonnet for the past 6-8 months just because they always seem to introduce throttling bugs with Opus where it starts to devour tokens or falls over. Very interested once open models close the gap to about 6 months.
100% agree, and I think that's sort of what was intended with a lot of democratic government setups. What we fail to realize though (or maybe just remember) is that these systems will ALWAYS be under attack by those who want more power always looking for attack surfaces. (We seem to be under attack by almost all, if not all, current billionaires!)
For example in the US, the executive order is a massive problem. Citizens united as well. And for all democracies the natural appeal of strongman politics is a huge problem.
Every attempt at government overreach really needs to be questioned. I don't say rejected, just questioned. How will it be used by future powers? Is the tradeoff worth it? Can it be temporary? Do we even have a way to claw it back if it turns out to be detrimental? Is it too subtle and nuanced that the majority will miss seeing it? etc.
> these systems will ALWAYS be under attack by those who want more power
I think this is an inherent human problem that prevents us from overcoming it... history has proven that the more equal everyone is, and the less individual ownership they have, the lazier and more bored they get.
Look at the previous attempts at socialism... people stop caring when there's no goal to work towards, they can't all be doing the same thing and just be happy, because humans are naturally competitive. We desire things other people don't have, like possessions, money, or power.
People don't become "lazy". They're lazy from the beginning. Laziness is something they overcome for personal gain. And if the system promises fewer personal gains for overcoming laziness, then why bother?
But of course success is relative to some cultural values. We could just as well wonder about success and failure in implementation of any political system.
The most remarkable trait of humans is cognitive plasticity, so determining any natural tendency that would be more inate than acquired is just a game of pretending there are hypothetical humans living out of any cultural influence that would still exhibit predominent behavioral traits.
Competition is a social construct. There are people out there whose biggest concern is keeping focus on enjoying what they are, freeing their attention from the illusion of possession, avoiding any financial/material bounds they can and staying away of contingent hierarchical servitudes.
They are also many people who holds desires for both of these perspectives, or any interpolation/extrapolation that they can suggest.
We aren’t inherently competitive, we just want nice things. It takes a very special mindset to want others to have less, and society should actively discourage such lines of thought by countering them with examples of how things never end well.
This said, I wasn’t suggesting socialism or equality or anything like that - only minimizing long-term unhappiness. That’s the only thing that I could not think an argument against - like why would anyone rational ever want others to be long-term unhappy?
Is there a way to accept but also limit greed that is reliable and durable?
Like a pragmatic meritocracy. We accept that there will be cheaters, and we won't catch or stop them all, but we have some hard limits. Do we care if you stop working so hard once you hit $1b? Maybe we'd even prefer that you did stop working (against societies interest!)?
This wouldn't even remotely resemble the communism bugaboo. It's basically saying, yes greed can be good, but at some point it gets ridiculous.
Except it's very easy to "sell" government overreach. Whenever a plane flies into a tower, or flu season is extra scary, people will clamor for strict government authority. With every such event, the government gains capabilities and tendencies that always end up with a few people having outsized power over the masses.
Yes, but I don't think it's so straightforward. I think there are bad actors marketing this overreach. Like the surveillance industry for the Patriot Act (tech, defence, telcom, maybe compliance vendors?). I don't think their goal is to create a distopia, but we should always be looking at incentives for large government programs.
> But it's also likely that these tools will produce mountains of unmaintainable code and people will get buried by the technical debt.
It's not just likely, but it's guaranteed to happen if you're not keeping an eye on it. So much so, that it's really reinforced my existing prejudice towards typed and compiled languages to reduce some of the checking you need to do.
Using an agent with a dynamic language feels very YOLO to me. I guess you can somewhat compensate with reams of tests though. (which begs the question, is the dynamic language still saving you time?)
You can (and probably should) still do tests, but there's an entire class of errors you know can't happen, so you need far less tests, focusing only on business logic for the most part.
Static type checking is even faster than running the code. It doesn't catch everything, but if finding a type error in a fast test is good, then finding it before running any tests seems like it would be even better.
I still do this, but when I'm reviewing what's been written and / or testing what's been built.
How I see it is we've reverted back to a heavier spec type approach, however the turn around time is so fast with agents that it still can feel very iterative simply because the cost of bailing on an approach is so minimal. I treat the spec (and tests when applicable) as the real work now. I front load as much as I can into the spec, but I also iterate constantly. I often completely bail on a feature or the overall approach to a feature as I discover (with the agent) that I'm just not happy with the gotchas that come to light.
AI agents to me are a tool. An accelerator. I think there are people who've figured out a more vibey approach that works for them, but for now at least, my approach is to review and think about everything we're producing, which forms my thoughts as we go.
What they are redacting is pretty questionable though. Entire pages being suspiciously redacted with no explanation (which they are supposed to provide). This is just my opinion, but I think it's pretty hard to defend them as making an honest and best effort here. Remember they all lied about and changed their story on the Epstein "files" several times now (by all I mean Bondi, Patel, Bongino, and Trump).
It's really really hard to give them the benefit of the doubt at this point.
My favorite is that sometimes they redact the word "don't". Not only does it totally change the meaning of whatever sentence it's in, the conspiracy theory is that they had a Big Dumb Regex for redacting /Don\W+T/i to remove Trump references
Maybe some day, but as a claude code user it makes enough pretty serious screw ups, even with a very clearly defined plan, that I review everything it produces.
You might be able to get away without the review step for a bit, but eventually (and not long) you will be bitten.
I use that to feed back into my spec development and prompting and CI harnesses, not steering in real time.
Every mistake is a chance to fix the system so that mistake is less likely or impossible.
I rarely fix anything in real time - you review, see issues, fix them in the spec, reset the branch back to zero and try again. Generally, the spec is the part I develop interactively, and then set it loose to go crazy.
This feels, initially, incredibly painful. You're no longer developing software, you're doing therapy for robots. But it delivers enormous compounding gains, and you can use your agent to do significant parts of it for you.
> You're no longer developing software, you're doing therapy for robots.
Or, really, hacking in "learning", building your knowhow-base.
> But it delivers enormous compounding gains, and you can use your agent to do significant parts of it for you.
Strong yes to both, so strong that it's curious Claude Code, Codex, Claude Cowork, etc., don't yet bake in an explicit knowledge evolution agent curating and evolving their markdown knowledge base:
Unlikely to help with benchmarks. Very likely to improve utility ratings (as rated by outcome improvements over time) from teams using the tools together.
For those following along at home:
This is the return of the "expert system", now running on a generalized "expert system machine".
I assumed you'd build such a massive set of rules (that claude often does not obey) that you'd eat up your context very quickly. I've actually removed all plugins / MCPs because they chewed up way too much context.
It's as much about what to remove as what to add. Curation is the key. Skills also give you some levers to get the kind of context-sensitive instruction you need, though I haven't delved too deeply into them. My current total instruction set is around ~2500 tokens at the moment
Reviewing what it produces once it thinks it has met the acceptance criteria and the test suite passes is very different from wasting time babysitting every tiny change.
True, and that's usually what I'm doing now, but to be honest I'm also giving all of it's code at least a cursory glance.
Some of the things it occasionally does:
- Ignores conventions (even when emphasized in the CLAUDE.md)
- Decides to just not implement tests if gets spins out on them too much (it tells you, but only as it happens and that scrolls by pretty quick)
- Writes badly performing code (N+1)
- Does more than you asked (in a bad way, changing UIs or adding cruft)
- Makes generally bad assumptions
I'm not trying to be overly negative, but in my experience to date, you still need to babysit it. I'm interested though in the idea of using multiple models to have them perform independent reviews to at least flag spots that could use human intervention / review.
Sure, but non of those things requires you to watch it work. They're all easy to pick up on when reviewing a finished change, which ideally should come after it's instructions have had it run linters, run sub agents that verify it has added tests, run sub agents doing a code review.
I don't want to waste my time reviewing a change the model can still significantly improve all by itself. My time costs far more than the models.
you give it tools so it can compile and run the code. then you give it more tools so it can decide between iterations if it got closer to the goal or not. let it evaluate itself. if it can't evaluate something, let it write tests and benchmark itself.
I guarantee that if the criteria is very well defined and benchmarkable, it will do the right thing in X iterations.
(I don't do UI development. I do end-to-end system performance on two very large code bases. my tests can be measured. the measure is very simply binary: better or not. it works.)
Linux development has a blueprint they could follow. Like the principle of least privilege. These aren’t cutting edge concepts.
Also I’m not sure the tradeoffs of adding security to an editor are that big of a deal. Are we really seeing revolutionary stuff here? Every now and then I check out VS Code only to realize Vim is still 10x better.
No doubt, but I (and I suspect many others) rarely update plugins and I have a very select list of plugins that I use (mostly from one guy), and I just use git to manage them. I never see churn, but that might just be me.
I assume you could probably do the same with VSCode, but I suspect there's a cultural difference that pushes you to always update? Do things stop working because of churn?
reply