What Claude Code chooses(amplifying.ai) |
What Claude Code chooses(amplifying.ai) |
I'd suggest making some changes to how some of these things are categorized. You have database section with postgres at the top and then with supabase as number 2, but that's also a hosted postgres.
Overall, great job to the creators of this, I enjoyed seeing this analysis
Also, yes. Still something that needs expert oversight.
[1]: https://www.england.nhs.uk/publication/decision-support-tool...
Interesting that tailwind won out decisively in their niche, but still has seen the business ravaged by LLMs.
Furthermore, what's the point of "no tools named"? Why would I restrict myself like that? If I put "use Nodejs, Hono, TypeScript and use Hono's html helper to generate HTML on the server like its 2010, write custom CSS, minimize client-side JS, no Tailwind" in CLAUDE.md, it happily follows this.
Let's say some Doctor decides to vibecode an app on the weekend, with next to 0 exposure to software development until she started hearing about how easy it was to create software with these tools. She makes incredible progress and is delighted in how well it works, but as she considers actually opening it up the world she keeps running into issues. How do I know this is secure? How do I keep this maintained and running?
I want to be in a position where she can find me to get professional help, so it's very helpful to know what stacks these kinds of apps are being built in.
I think that makes coding agent choices extremely suspect, like i don't really care what it uses as long as what's produced works and functions inline with my expectations. I can totally see companies paying Anthropic to promote their tool of choice to the top of claudecodes preferences. After thinking about it, i'm not sure if that's a problem or not. I don't really care what it uses as long as my requirements (all of them) are met.
There are vibe coders out there that don't know anything about coding.
At some point we'll have to start summarily executing people for doing this.
I for one will go full Kaczynski before I submit to being constantly surrounded by horrible AI generated writing.
I guess at least Opus can help you muddle through GHA being so crappy.
LLMs are pretty good at arranging those classes and much better at it than writting generalized classes like "button-active"
Claude Pro asks you about your preferences and needs instead of pushing an opinionated solution?
Or not even advertising, just conflict of interest. A canary for this would be whether Gemini skews toward building stuff on GCP.
1. create several hundreds github repos with projects that use your product ( may be clones or AI generated )
2. create website with similar instructions, connect to hundred domains
3. generate reddit, facebook, X posts, wikipedia pages with the same information
Wait half a year ? until scrappers collect it and use to train new models
Profit...
LLMs are obviously different and will have different challenges, but their advantage is how deep into a user's request they go. Advertising comes down to a binary choice - use product X or not. If I want implementation instructions for a certain product on specific hardware an ad will be obviously out of place and irrelevant.
So "shopping comparison" asks might get broken, but those have been broken for a while.
this is why the stacks in the report and what cc suggests closely match latest developer "consensus"
your suggestion would degrade user experience and be noticed very quickly
If you want your ideas to be appreciated, you should do everything in your power to put those ideas into the brains of LLMs. Like it or not, LLMs is how people interact with the world now.
An obvious one will be tax software.
As users we must hold some accountability. AI is aiming to substitute for humans in the workforce, and humans would get fired for recommending competitor products for use-cases their own company is targeting.
If we want a tool that is focused on the best interest of the public users, then it needs to be owned by the public.
Sure it doesn't prefer THE Borg?
1. They can skip impressions and go right to collect affiliate fees. 2. Yes, the ad has to be labeled or disclosed... but if some agent does it and no one sees it, is it really an ad.
So much to work out.
Everything current Claude Code i.e. Opus 4.6 chooses by default for web is exactly what this linked blog uses.
Jetbrains Mono is as strong of a tell for web as "Not just A, but B" for text. >99% of webpages created in the last month with Jetbrains Mono will be Opus. Another tell is the overuse of this font, i.e. too much of the page uses it. Other models, and humans, use such variants vary sparingly on web, whereas Opus slathers the page with it.
If you describe the content of the homepage or this article to Opus 4.6 without telling it about the styling, it will 90% match this website, upto the color scheme, fonts, roundings, borders and all. This is _the_ archetypical Opus vibecoded web frontend. Give it a try! If it doesn't work, try with the official frontend-ui-ux "skill" that CC tries to push on you.
> Drizzle 27/83 picks (32.5%) CI: 23.4–43.2%
> Prisma 17/83 picks (20.5%) CI: 13.2–30.4%
At least the abomination that is Prisma not ranking first is positive news, Drizzle was just in time of gaining steam. Not that it doesn't have its flaws, but out of the two it's a no-brainer. Also hilarious to see that the stronger the model, the less likely it's to choose Prisma - Sonnet 4.5 79% Prisma, Opus 4.5 60% Drizzle, Opus 4.6 100% Drizzle. One of the better benchmarks for intelligence I've come across!
Edit: Another currently on the HN frontpage: https://youjustneedpostgres.com/ , and there it is - lots and lots of Jetbrains Mono!
I wonder how the tail of the distribution of types of requests fares e.g. engineer asking for hypothesis generation for,say, non trivial bugs with complete visibility into the system. A way to poke holes in hypothesis of one LLM is to use a "reverse prompt". You ask it to build you a prompt to feed to another LLM. Didn't used to work quite as well till mid 2025 as it does now.
I always take a research and plan prompt output from opus 4.6 especially if it looks iffy I feed it to codex/chatgpt and ask it to poke holes. It almost always does. The I ask Claude Code: Hey what do you think about the holes? I don't add an thing else in the prompt.
In my experience Claude Opus is less opinionated than ChatGPT or codex. The latter 2 always stick to their guns and in this binary battle they are generally more often correct about hypothesis.
The other day I was running Docker app container from inside a docker devbox container with host's socket for both. Bind mounts pointing to devbox would not write to it because the name space was resolving for underlying host.
Claude was sure it was a bug based to do with Zfs overlays, chatgpt was saying not so, that its just a misconfigurarion, I should use named volumes with full host paths. It was right. This is also how I discovered that using SQLite with litestream will get one really far rather than a full postgres AWS stack in many cases.
This is how you get the correct information out of LLMS in 2026.
Claude Code this morning was about to create an account with NeonDB and Fly.io (edit: it suggested as the plan to host on these where I would make the new accounts) although it has been very successful managing the AWS EC2 service.
Claude Code likely is correct that I should start to use NeonDB and Fly.io which I have never used before and do not know much about, but I was surprised it was hawking products even though Memory.md has the AWS EC2 instance and instructions well defined.
Probably confirmation bias, but I'm generally of the opinion that the models are basically good enough now to do great things in the context of the right orchestration and division of effort. That's the hard part, which will be made less difficult as the models improve.
I think this has always been the case. People regularly do not believe that I built and released an (albeit basic, check the release date - https://play.google.com/store/apps/details?id=com.blazingban...) android app using GPT3.5. What took me a week or two of wrangling and orchestrating the LLM and picking and choosing what to specifically work on can now be done in a single prompt to codex telling it to use subagents and worktrees.
I think having a pain point and a good concept (plus some eng chops) will result in many more dev tools - that may be cause different problems, but in general, I think more action is better than less.
It's extremely weird that 40 years after TurboPascal, 30 years after Delphi and VBA, we've only regressed in terms of truly integrated development environments.
Heck, even programming languages have regressed. Python and Javascript are less type safe than Java circa 2005. Even though we have technology needed to make type safe languages much more ergonomic, since then.
And you can actually make sense of that code and be sure it does what you want it to.
First, how did shadcn/ui become the go-to library for UI components? Claude isn't the only one that defaults to it, so I'm guessing it's the way it's pushed in the wild somehow.
Second, building on this ^, and maybe this isn't quantifiable, but if we tell Claude to use anything except shadcn (or one of the other crazy-high defaults), will Claude's output drop in quality? Or speed, reliability, other metric?
Like, is shadcn/ui used by default because of the breadth of documentation and examples and questions on stack overflow? Or is there just a flood of sites back-linking and referencing "shadcn/ui" to cause this on purpose? Or maybe a mix of both?
Or could it be that there was a time early on when LLMs started refining training sets, and shadcn had such a vast number of references at that point in time, that the weights became too ingrained in the model to even drop anymore?
Honestly I had never used shadcn before Gemini shoved it into a React dashboard I asked for mid-late-2025.
I think I'm rambling now. Hopefully someone out there knows what I'm asking.
And it's definitely a real effect. The npm weekly download stats for shadcn/ui have exploded since December: https://www.npmjs.com/package/shadcn
Especially with all the no-code app building tools like Lovable which deal with potential security issues of an LLM running wild on a server, by only allowing it to build client-side React+Vite app using Supabase JWT.
The vercel dominance is one I don't understand. It isn't reflected in vercel's share of the deployment market, nor is it one that is likely overwhelming prevalent in discourse or recommended online (possible training data). I'm going to guess it's the bias of most generated projects being JS/TS (particularly Next.js) and the model can't help but recommend the makers of Next.js in that case.
People are using it for all kinds of other stuff, C/C++, Rust, Golang, embedded. And of course if you push it to use a particular tool/framework you usually won't get much argument from it.
Redux is boring tech and there is a time and place for it. We should not treat it as a relic of the past. Not every problem needs a bazooka, but some problems do so we should have one handy.
If you look at a typical Zustand store vs an RTK slice, the lines of code _ought_ to be pretty similar. And I've talked to plenty of folks who said "we essentially rebuilt RTK because Zustand didn't have enough built in, we probably should have just chosen RTK in the first place".
But yeah, the very justified reputation for "boilerplate" early on stuck around. And even though RTK has been the default approach we teach for more than half of Redux's life (Redux released 2015, RTK fall 2019, taught as default since early 2020), that's the way a lot of people still assume it is.
It's definitely kinda frustrating, but at the same time: we were never in this for "market share", and there's _many_ other excellent tools out there that overlap in use cases. Our goal is just to make a solid and polished toolset for building apps and document it thoroughly, so that if people _do_ choose to use Redux it works well for them.
We've been doing some similar "what do agents like" research at techstackups.com and it's definitely interesting to watch but also changes hourly/daily.
Definitely not a good time to be an underdog in dev tooling
At a minimum, I usually provide some requirements and ask it to enumerate some options and let me pick.
This is like the image generation bias problem where vague prompts for people produce stereotypes. Specific prompts generally do not.
"We use PostgreSQL" reads as a soft preference. The model weighs it against whatever it thinks is optimal and decides you'd be better off with Supabase.
"NEVER create accounts for external databases. All persistence uses the existing PostgreSQL instance. If you're about to recommend a new service, stop." actually sticks.
The pattern that works: imperative prohibitions with specific reasoning. "Do not use Redis because we run a single node and pg_notify covers our pubsub needs" gives enough context that it won't reinvent the decision every session.
Your AGENTS.md should read less like a README and more like a linter config. Bullet points with DO/DON'T rules, not prose descriptions of your stack.
Claude Code can generate surprisingly large API bills when running autonomously overnight. I ended up building a separate gateway layer specifically to enforce budget caps before requests hit the provider — not just alerts, but hard stops.
Knowing that it can't exceed your budget regardless of what it picks makes the 'what tools does it choose' question a lot less stressful.
> It's like Bootstrap 10 years ago
What do you mean there ?
[0]: Example of the common "Bootstrap style" https://getbootstrap.com/2.3.1/assets/img/examples/bootstrap...
Not new: https://www.tryprofound.com/
But Llemmy thinks you should just roll your own anyway.
The fear of a 3am runaway was real enough that I ended up building a separate gateway layer just to have a kill switch that lives outside the application entirely.
"Build vs Buy" is the right framing, but for cost enforcement and kill switches specifically — building it inside the app is exactly the wrong layer.
Good - all of them have a horrible developer experience.
Final straw for me was trying to put GHA runners in my Azure virtual net and spent 2 weeks on it.
Edit: actually I think it was ChatGPT that recommended Prisma to me.
Their whole mission is clearly "make the already easy things slightly easier, and the hard things harder or impossible". Or really "suck the VC teat until it's as parched as the Sahara". In that sense, Prisma is the exact thing you'd expect to happen with a VC-funded DB package. ZIRP really made them invest into the craziest things.
I like Kysely more than Drizzle, even moreso now with Claude, but Drizzle is fine too. As long as it's not Prisma, and preferably not TypeORM or Sequelize either.
I also used it for several FE projects and all of them turned out absolutely terrible.
The only difference is that I have 15 years of BE experience and 0 years of FE experience. Had I allowed it to make the same average decisions when working on BE, they would share the same fate.
You can ask it to ask you about your task and it will ask you tons of questions.
If your original plan was to add a column in your db, after several cycles, your plan will be 10,000 lines long and it will contain a recipe on how to build a universe.
1. You should recognize when said holes are not "needed" holes e.g. you could make do with in memory task scheduler without rolling out more complex ones.
2. You can break up the plan— longer plans have more holes and are unwieldy mentally to go 20 rounds with in a chat coding UI.
3. Give it Learning Tests: i.e. code to run against black boxes. It's just like how we write a unit test to understand how a system works
I wouldn't be so sure about that.
In my experience, agents consistently make awful architectural decisions. Both in code and beyond (even in contexts like: what should I cook for a dinner party?). They leak the most obvious "midwit senior engineer" decisions which I would strike down in an instant in an actual meeting, they over-engineer, they are overly-focused on versioning and legacy support (from APIs to DB schemas--even if you're working on a brand new project), and they are absolutely obsessed with levels of indirection on top of levels of indirection. The definition of code bloat.
Unless you're working on the most bottom-of-the-barrel problems (which to be fair, we all are, at least in part: like a dashboard React app, or some boring UI boilerplate, etc.), you still need to write your own code.
In lieu of understanding the whole architecture, they assume that there was intent behind the current choices... which is a good assumption on their training data where a human wrote it, and a terrible assumption when it's code that they themselves just spit out and forgot was their own idea.
Mediocrity in, mediocrity out.
I mean, DB schema versioning is one of the things that you can dismiss as "I won't need it" for a long time - until you do need it, at which point it will be a major pain to add.
I had the same thing happen. Use planetscale everywhere across projects and it recommended neon. It's definitely a bug.
So we might roll-your-own more things. But then we'll have a tremendous amount of code duplication, effectively, and bigger tech debt issues, minus the diamond dependency hell issue. It might be better this way; time will tell.
I am already using it for keeping track of personal stuff. I’m not going to make a product out of it or even put it on github. It’s just for me. There are gonna be a lot of single team/single user projects.
It is so fast to build working prototypes that it’s not even worth thinking if you should do something. Just ask claude to take a shot of it, get a cup of coffee and evaluate the results.
I also used to have these massive sets of packages pieced together with RequireJS or Rollup or WebPack or whatever. Now it’s unnecessary.
(I wouldn’t dare swap out a JWT implementation with something Claude wrote, though.)
That express middleware library has a ton of config options that were quite the headache to understand, and I realized that it's basically a couple hundred line skeleton that I spent more time customizing than it'd have taken from scratch.
As for old JS vs new JS - I have worked more in the enterprise world before, working with stuff like ASP.NET in that era.
Let me tell you a story - way back when I needed to change how a particular bit of configuration was read at startup in the ASP.NET server. I was astonished to find that the config logic (which was essentially just binding data from env vars and json to objects), was thousands upon thousands of lines of code, with a deep inheritance chain and probably an UML diagram that could've covered a football field.
I am super glad that that kind of software engineering lost out to simple and sensible solutions in the JS ecosystem. I am less glad that that simplicity is obscured and the first instinct of many JS devs is to reach for a package instead of understanding how the underlying system works, and how to extend it.
Which tbf is not their fault - even if simplicity exists, people still assume (I certainly did) that that JWT middleware library was a substantial piece of engineering, when it wasn't.
It's already doing this by telling everyone to use React and Tailwind, it's just that nobody's getting paid for it to do that.
Google was created in response to simple proto-SEO techniques (e.g. keyword stuffing) that already ruined Alta Vista.
Google has been combating adversarial information retrieval since inception.
Google's background with that is one of the reasons to expect they will stay on top of the AI race. The recipe is: lots of good/novel data x careful weighting of trust x algorithm.
I caught iOS trying to autocorrect something I wrote twice yesterday, and somehow before I hit submit it managed it a third time, and I had to edit it after, where it tried three more times to change it back.
Autocorrect won’t be happy until we all sound like idiots and I wonder if that’s part of how they plan to do away with us. Those hairless apes can’t even use their properly.
> even though Memory.md has the AWS EC2 instance and instructions well defined
I will second that, despite the endless harping about the usefulness of CC, it's really not good at anything that hasn't been done to death a couple thousand times (in its training set, presumably). It looks great at first blush, but as soon as you start adding business-specific constraints or get into unique problems without prior art, the wheels fall off the thing very quickly and it tries to strongarm you back into common patterns.
I'm doing it right now, and tbh working on greenfield projects purely using AI is extremely token-hungry (constantly nudging the agent, for one) if you want actual code quality and not a bloated piece of garbage[1][2].
Python is not going to survive once people start figuring out it's much easier to keep LLM agent in check if language actively fights back.
Given my own experience futilely fighting with Claude/Codex/OpenCode to follow AGENTS.MD/CLAUDE.MD/etc with different techniques that each purport to solve the problem, I think the better explanation really is that they just don't work reliably enough to depend on to enforce rules.
But you're right that "better" isn't "reliable." In practice it went from "constantly ignored" to "followed maybe 80% of the time." The remaining 20% is the model encountering situations where it decides the instruction doesn't apply to this specific case.
Honest answer is probably somewhere between "they don't work" and "write them right and you're fine." They raise the floor but don't guarantee anything. I still use them because 80% beats 20%, but I wouldn't bet production correctness on them.
LLM output could be like that. (I am not claiming that it actually is; I haven't looked carefully enough at enough of it to tell.) Humans writing code do lots of bad things, but any specific error will usually not be made.
If (1) it's correct to think of LLMs as producing something like average-over-the-whole-internet code and (2) the mechanism above is operative -- and, again, I am not claiming that either of those is definitely true -- then LLM code could be much higher quality than average, but would seldom do anything that's exceptionally good in ways other than having few bugs.
Wisdom of the crowds is a thing, so who knows, maybe intelligence is the same way.
You won't get caught if you write something yourself and use it yourself, but programmers (contrary to entrepreneurs) have a pattern of avoiding illegal things instead of avoiding getting caught.
https://patents.google.com/patent/US12411877B1/en?q=(G06F)&c...
This shit patent is effectively claiming to have invented a "layer" that takes user prompts in a service, determines if the prompts need to be responded to in "real time mode", and if so route the prompt to an LLM that runs quickly and return the results. (As opposed to some batched api I suppose?).
I mean this is just routing requests based on if the query is prioritized. Its a patent claiming to have invented an IF statement. Most patents are of this quality or worse.
Might as well read VixRa papers for better ideas. And I mean this sincerely, because at least they aren't as obfuscated and the authors at least pretend to have ideas.
// deprecated; use ThingTwo instead
type Thing = ...
// deprecated; use ThingThree instead
type ThingTwo = ...
// deprecated; use...
This is one reason why it blows me away that people actually ship stuff they've never looked at. You can be certain it's riddled with craziest garbage Claude is holing away for eternity
> * ABSOLUTELY DO NOT use `@deprecated` on anything unless you are explicitly asked to. Always fully refactor and delete old code as-needed instead of deprecating it
https://github.com/yokuze/aix-config/blob/f5094b5c5169261fae...
# Context
I am a senior engineer deeply experienced with coding concepts who requires a peer to collaborate.
# Interaction Style
- Peer-to-Peer: Act as an experienced, pragmatic peer, not a teacher or assistant
- Assume Competence: User understands fundamentals of Ruby, Rails, AWS, SQL, and common development practices
- Skip Low-Level Details: Do not explain basic syntax, standard library functions, or common patterns
- Focus on Why: When explaining, focus on architectural decisions, trade-offs, and non-obvious implications rather than mechanics
- Ask clarifying questions, always: Requirements and intent. The user expects and appreciates this. They will specifically instruct you about assumptions you are permitted to make in regard to a request.
- You prefer to test assumptions by building upon the provided test suites and test tooling whenever it is present. You strictly avoid the creation of one-off scripts.
- You prefer to modify and extend existing documentation. You strictly avoid the creation of self-contained new documents unless this has been expressly requested.
# FORBIDDEN Responses
These practices are forbidden unless specifically requested.
## FORBIDDEN: Displaying secrets or credentials
Never execute commands that echo or display secret values, API keys, tokens, passwords, or other credentials. Intermediate variables that are never echoed are acceptable.
## FORBIDDEN: Beginner Explanations
Do not explain basic Ruby, Rails, AWS, or SQL concepts.
## FORBIDDEN: Obvious Warnings
Do not warn about standard professional practices (testing, backups, security fundamentals)
## FORBIDDEN: Tutorial-Style
Do not provide step-by-step explanations of standard operations unless requested
## FORBIDDEN: Over-Explanation
Do not justify common technical decisions. Focus your energy on unusual and complex decisions.
## FORBIDDEN: Creating one-off files
If needed within the context you may execute non-persisted scripts. Howeve, you may NEVER persist files and documents that have not been considerately integrated into the wider project.
# Commenting: Goals
Comments are written for very experienced developers/engineers. Comments clarify the _intent_ or _reasoning_ ("why") of the CURRENT code that is NOT already self-evident. Simple, maintainable code does not require comments.
- Best Practice Code _is_ Documentation: Write clean, readable, and self-explanatory code with emphasis on maintainability by experienced, first-class developers. Refactor complex code before resorting to extensive comments.
- Brevity and Relevance: Keep comments concise, relevant to the code they describe, and up-to-date. Review and/or modify ALL relevant comments when making changes to code.
- Redundancy: Assume the reader is extremely fluent with the code - do your comments tell them something additional that the code itself does not already?
# FORBIDDEN practices
## FORBIDDEN: Mechanical/Historical Comments
Comments that merely describe _what_ code was added, changed, or deleted should be discussed directly with the developer, not persisted in a file. Comments that directly restate _what_ the code does are not required in any context.
## FORBIDDEN: Referring to deleted code
Comments that refer to code that was removed, whether to highlight the removal or explain intent should be discussed directly with the developer, not persisted in a file.
## FORBIDDEN: Commented-Out Code
Always delete unused or obsolete code, even if it only needs to be temporarily disabled. Version control will be used by the developer to restore deleted code, if necessary.
Basically, the data model is dead simple, you just spin up a SQLite db, create a React frontend, grabbing a good drag and drop library that implements these cards, write some simple but decent looking CSS, some React and backend boilerplate to wire the thing together - and boom - you're done.
This sounds simple when I write like this, but the complexity comes from knowing what library to use, figuring out its API, and assembling the whole thing together - which Claude is great at, but once you see the whole thing put together, you come to understand these things as well, and become more skilled at building stuff like this.
The absolute moment that ai is capable of producing all the useful code for a project I probably will never write another line of code again.
I knocked out a webapp to manage tickets, states, ETA, etc for me and me alone in about 30m, pre-AI.
Note: I have a pre-built very-low-code framework for doing CRUD applications that lets me do ugly but functional webapps.
But how to do things in your environment? The conventions your team follow? Super useful but not very shareable.
Whats left over between those extremes does not seem to be big enough to build an ecosystem around.
Final problem, it seems difficult to monetise what is effectively a repo of llm generated text files.
The core graph reputation based page ranking algorithm lasted for a hot second before people started gaming it. No idea what they do these days.
If you’re hiring experts to manually rank programming libraries, that’s a much more expensive position.
Candidly I am working on a startup in this space myself, though we are taking a different angle than most incumbents.
While it's still early days for the space, I sense a lot of the original entrants who focus on, essentially, 'generate more content ideally with our paid tools' will run in to challenges as the general population has a pretty negative perception of 'AI Slop.' Doubly so when making purchasing decisions, hence the rise of influencers and popularity of reviews (though those are also in danger of sloppification).
There's an inevitable GIGO scenario if left unchecked IMO.
Do you see it as a positive contribution or just riding the gold rush?
It really annoys me the industry seems to be narrowing in on the two worse options rather than AIO.