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!
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.
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.
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
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.
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.
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.
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.
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.
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.
