The Machines Are Arguing About Themselves
May 28, 2026
Are businesses really making decisions based on this noise?
For several months I've been running a weekly sweep of Hacker News, Reddit, and LinkedIn, collecting the most provocative claims about AI replacing software developers. I started doing it because I was frustrated by the extreme polarity of the hot takes and I wanted raw material to write about here.
What I didn't expect was to start wondering whether some of the takes themselves were generated by the very thing they're arguing about!
There's a version of this debate that sounds like this:
"I work in a big tech company. No one writes code anymore, we just review. The reviewing is getting less and less. AI does it all.
If your company isn't like this, then it's just that they are lagging behind."
-- Hutcho12, Reddit r/cscareerquestions
And there's a version that sounds like this:
"Vibe coding seems like a religion more than anything to me... There is especially no evidence that vibe coding is a skill:"
-- Sirens of Titan, Hacker News: Is vibe coding a new mandatory job requirement?
Both of those are real quotes, posted in the last few weeks, by real (I think?) people on real platforms. Both ends are equally confident, and neither is citing anything specific. They share the signature qualities of LLM-optimized engagement content: declarative, polarizing, free of the qualifications that would make them less shareable.
This is the Great AI Job Replacement Spectrum, and it runs from "I haven't written a line of code in three weeks" to "anyone saying AI replaces developers has never shipped production software" — with very few in the middle willing to sit still long enough to just say I don't know yet.
Here's the thing I keep coming back to: a meaningful percentage of the content driving this debate is probably generated by the same tools the debate is about.
I'm not promoting a conspiracy theory. I think it's the inevitable reality of LLMs today — they're cheap, fast, and extremely good at producing confident-sounding opinions in comment-box prose. They're especially good at producing the kind of content that gets engagement: declarative, polarizing, free of the qualifications and caveats that ground an opinion in the real world but make it far less shareable.
When I look for basic LLM-generation signals in the claims I've been collecting — vague social proof, big anecdotal assertions with little verifiable evidence — a number of the most-circulated hot takes score surprisingly high. Not all of them. But enough to notice.
The dismissive end of the spectrum isn't immune either. "The 10x hypebots fall into two categories: hobbyists who could barely code, and people using LLMs to launder licensed code" is a rhetorically complete argument that requires no real experience to generate. It just requires a prompt.
So we have a situation where: AI tools are producing takes about whether AI tools will replace developers, those takes are shaping the opinions of executives and founders making real hiring and build decisions, and the signal-to-noise ratio is collapsing in real time.
If you're a founder trying to figure out whether to hire a technical co-founder, bring on a software agency, or just hand a Claude subscription to your operations manager and see what happens — the discourse is not helping you.
The breathless replacement narrative ("one senior with AI is better than three fresh juniors") pushes toward under-investing in technical judgment at exactly the moment when architectural decisions are getting harder, not easier. More AI tooling in the stack means more surface area for decisions that compound — and those decisions don't get easier just because the code that implements them got cheaper to write.
The equally breathless dismissal ("making widgets do the right things well is still hard, it's been this way since COBOL") pushes toward ignoring genuine productivity shifts that are real, observable, and already repricing what a small technical team can deliver.
Neither extreme is a useful frame for making actual decisions. And if a meaningful fraction of both extremes is machine-generated content optimized for engagement rather than accuracy, we're not even arguing about the real question — we're arguing about the argument.
The useful version of this conversation isn't "will AI replace software engineers?" It's more like: which parts of the software development process are changing fastest, and what does that mean for how you think about technical capacity?
That question has real answers that vary by context. For a seed-stage SaaS founder, the calculus looks different than it does for a company running complex infrastructure built over a decade. For a Shopify store adding custom features, it looks different than for a team building something with significant state, compliance requirements, or genuine novel architecture.
What doesn't vary much by context: the things that have always been hard in software — understanding what you're actually trying to build, making decisions about trade-offs that won't bite you in eighteen months, knowing when something that works in a demo will fail under load — those are not getting easier. The bar for good judgment is going up, not down, because the cost of generating plausible-looking bad decisions just got a lot cheaper.
That's true whether the bad decision comes from an overconfident AI agent, an overconfident vibe coder, or an executive who read too many LinkedIn hot takes and decided they no longer need anyone on staff who can tell the difference.
Ignore the takes. Watch the patterns.
When experienced engineers — people with long post histories, specific technical context, something to lose by being wrong — start describing concrete changes in how they work, that's worth reading carefully. When founders describe what actually shipped, with specifics about what broke and what didn't, that's worth reading carefully.
The rest — the sweeping declarations, the engagement-optimized provocations, the takes that could have been written by anyone (or anything) with fifteen seconds and a text box — those are noise. Useful noise, maybe, if you're tracking the shape of the discourse. Harmful noise if you're using it as the basis for real decisions.
The machines are arguing about themselves. That's genuinely interesting. It's just not a reliable guide for what you should do about your engineering team.
Clint Miller is a Partner at Launch Supply, a boutique software agency that builds custom software for founders and operators who need technical partners, not just coders.