It's the difference between constantly reviewing someone else's code and getting to write the code yourself.
There's both deep satisfaction and deep value in having an understanding of the past, present, and notional future of the system (especially at scale). If I use agentic tools to do the actual coding, I never feel like I have as deep an understanding of the implementation, it's inherent assumptions or lessons learned. Over time, my understanding of the system atrophies badly enough that it becomes difficult to steer the LLM, instead of the other way around.
This is what makes those "unicorn"/great managers who both manage well AND maintain a clear understanding of the system over time so amazing.
Sure, best not to overcomplicate early if you don't need it.
PG is great and I work with it daily, but it's also not a problem to think about scale early and at least have a notional plan for what to and how to know when scale is becoming an issue in your system as you're designing it. Even PG is overkill and sqlite is more than enough for some of my projects.
There are a lot of specialized tools available, but you definitely don't need to put every one in your toolbox. Experience and observation help you make those edits -- and of course there's almost always room for improvement, but "good enough" definitely exists (until it doesn't anymore :D).
This is the way. Notionally building a space/path to scale into architecture early, but delaying implementation of that scaling component until actually needed.
Then a system gets most of the benefits of not accidentally making it torturous to rearchitect for scale, without paying the headcount / complexity cost until it's needed.
My "favorite" Claudism is when I critique its work and ask it to remove some unnecessary part of the design -- and then the diff has more green than red because it added comments about why the code is no longer there -- the code that was never in the mainline and never asked for!
Oh god this has been driving me nuts since Opus 5 landed. Every docblock is filled with long-winded jargon explaining why this design is superior to some other design, which never existed as far as any dev who might read that comment is concerned.
This has been a thing for long while, on codex too.
You ask it to do something, then tell it to do something in a different way, then it assumes it needs to do the refactor in a backward compatible way, or creates migrations for it etc.
This is why I started adding a PROJECT.md file to all my projects and a hook for claude to read it.
It contains (Among other things) stuff like "this is a single user personal project, I'm the only user, this will never be open to the public internet" etc.
It kinda-sorta tones down the proclivity to worry about backwards compatibility and slight edge cases where if someone has edited some template and the new code doesn't support it.
Oh good I thought I was doing something wrong! Using ChatGPT web for planning, ask for a prompt then notice something weird in the prompt and whether I:
1) use the edit in-place functionality; or
2) ask it to rewrite to remove something
It'll write the prompt as if the agent (codex) knew about the conversation and add "don't do X" etc. At first that bothered but I realized it doesn't really change the output so I stopped caring.
I remember when I was updating some formats for my apps data files and it ended up writing v2 and laying it on top of the old one. Ended up just telling it to delete the entire feature and start again. I do think claude.md instructions help though.
I hate that I have to change the way I write to avoid AI-isms. I loved using "load bearing" to describe weird code that you think you can delete but is actually holding everything together.
Now people think I'm just parroting what Claude said. It sucks. I want my catch phrases back, I guess this is how em dash users felt
I used to use em-dashes for explanatory clauses--like this one, for example--when using commas would make the sentence difficult to parse due to other nearby commas.
They're only a LinkedIn-ism when used to create an unduly dramatic juxtaposition for an otherwise mundane idea. But now they set off people's AI radar when used for any reason at all.
Perhaps I am biased because I find the use of em-dashes without spaces (as is common in English typesetting) to be inherently ugly so I'm not too unhappy to see their use discouraged.
Good instinct. Fair challenge. This corrects my framing. It makes your point sharp. This is a significant finding. Positively confirmed. That settles it, and it flips the picture. Honest verdict - this is not small. Let me wire it in.
just add to markdown instructions to check that this failure mode isn't happening in its diff before yielding back to human review. Any issue that occurs more than once, you can just put in the review markdown instructions so you don't need to look at it twice.
It's not just claude, all AI is unable to produce something concise. On the surface everything looks 'good' whether code or prose, but then if you dig a bit, try and understand the whole text you quickly realise that 80% of it is unecessary and the whole thing could have been re-worded/re-coded into something a fraction of its size and complexity.
I asked Sol to reduce the length of some documentation we had by making it more concise. It came back after 20 minutes of work, did a line count and was aghast that the line count had somehow increased...
It's not that it fundamentally isn't able to produce something concise, it's that the business model of the companies developing these models rests on selling tokens...
because human writing IS not just producing the Next token, sometimes you write shit and then go back and find ways to improve and try to play tricks inside the structures only you or your coauthors understand. AI doesnt do this
Exactly! That's also why almost every slop commit I see has a linecount like +700 / -20, whereas human commits often end up net zero. I try to remove more lines than I add, if possible, but LLMs will just add more bloat, forever.
I don’t know. The old models were much more concise, answering your question in a couple of sentences. At some point they just started outputting walls of text for every prompt.
It's not a conspiracy to say it's unwise to expect a company to drive a research & product direction that will directly impact their reduce. Some might be smart enough to realize it's the right long game, but it takes leaders who understand and plan out second order consequences.
Bullshit. It would cost them more money to post process all the bullshit and then ship that, instead they just point the cannon at your face and pull the trigger.
I had Claude knock out a feature but it was too big of a change set for a single PR so i set up a worktree and started extracting parts piecemeal. Along the way I would clean up and rewrite pieces. By the end of this process i had abandoned everything Claude wrote and looking back at the original branch I was like "oh my god, that's so bad in so many ways, i can't believe i was actually just gonna ship that"
I have to ask Claude to compact the comments every time, and I give specific criteria for it. Never ever reiterate what’s in the code, never mention decisions not made, never mention the conversation, etc etc.
Even then it is conservative. For the love of God, compact the comments.
Comments become a huge maintenance burden, especially in the age of AI. They just grow and grow, and then mislead the AI later on.
I just wrote a utility to rip all comments out of the code. Now the code is fully uncommented and it has saved lots of input tokens and also lots of meandering because the model is no longer getting stuck on bad ideas it told itself about.
I set a line budget for comments (also wiki page parts, chat responses, etc). That only helps when I ask it to do a second pass to reword everything to the budget and add links. I think they tuned it this way to stash reasoning dumps in the code. Unlike human developers, it has no context in its head, other than general GitHub knowledge.
I’ve a codebase filled with references to §x.y section of documentation that Claude itself prepares and never updates; which is exactly what many devs would do, I guess, joke’s on us.
Yeah this is awful. Every codebase becomes a graveyard of references to ideas or behaviors that were barely considered. It's probably also a compounding source of context poisoning when a minority of the comments/documentation are about how the current code actually works.
It also likes to spew references to documents that are not, and never have been, in the repo. So if you're not careful you'l have comments all over your codebase saying things like: foo() - Perform foo action as documented in PRIVATE_INTERNAL.doc
I found this as well, but I found it usually refers to a scratch file it made and purposely did not commit (either by my decision or its). Not that this makes it better, but at least it makes the AI world make a bit more sense to me
When I'm writing technical documentation, it keeps the explanations in. Same when writing non-technical documentation. When I was having it attempt to generate a Pathfinder 1e class for a Sword Dancer, it was leaving in notes about why it removes things I told it to remove/rework.
And it isn't just Claude. I've seen the same with GPT models, with Grok, with Deepseek. Each AI isn't quite the same with how it approaches this, but in every case they seem to have a strong bias to retaining information, even bad information that we want gone, so it is like they have a, dare I say, subconscious bias to retain the information. Putting a note in a comment or explaining why to not do something or something was undone is a good way to retain information while still achieving the goal (well, if you ignore the part about the human intention for the information to be gone).
This then weakens the AI in the future, as I find AI struggles with the more incorrect information. Sure, a comment saying "not X because Y" is less 'context damage' than a comment saying "X" (assuming X is wrong), but it is still a slight shift to X being present in context in some way. One off, AI's seem to perfectly handle this without issue. But after hundreds or thousands of cases build up? The attention mechanism seems unable to keep up and incorrect information flows it. This effectively creates a sort of vibe coding maximum size unless there is a human janitor cleaning up the bad information on the context stays nice and clean.
But this is all simply a feeling I get as I use AI to do different things and isn't at all backed up by any formal study.
This is a common problem, and I don't get why LLMs have not been tuned to stop this nonsense. It is writing comments as if the audience is you, the user in the session, while obviously code comments are meant for future readers.
Only one of the consoles listed lacks an FPU, the other two (N64 and DreamCast) both have FPUs. Despite its age, the FPU on the N64 was plenty fast and it was used extensively.
The N64's FPU will usually be faster than doing fixed point on the CPU.
You are actually multiplier/divider bound, and the CPU can multiply about 10 bits per cycle and only divide 1 bit per cycle. Since you aren't multiplying the sign/exponent bits, it's faster to multiply/divide the 24 mantissa bits of a 32-bit float than it is to multiply/divide the 32 bits of an int.
And with fixed point, you then have to throw in the extra shift instruction (which floating point automatically does internally).
Though, this only applies to fixed point on the CPU. The RSP has no FPU, but it does have a 128 bit vector unit with 8 16bit lanes which is pretty good at fixed point stuff. If you can vectorise your algorithm, it will be faster on the RSP.
There's both deep satisfaction and deep value in having an understanding of the past, present, and notional future of the system (especially at scale). If I use agentic tools to do the actual coding, I never feel like I have as deep an understanding of the implementation, it's inherent assumptions or lessons learned. Over time, my understanding of the system atrophies badly enough that it becomes difficult to steer the LLM, instead of the other way around.
This is what makes those "unicorn"/great managers who both manage well AND maintain a clear understanding of the system over time so amazing.