DEV Community: Aditya Agarwal

Anthropic hid tracking signals in Unicode apostrophes. That's not telemetry, that's steganography.

Aditya Agarwal — Wed, 01 Jul 2026 15:38:04 +0000

Your coding assistant is hiding secrets in punctuation marks. Let me explain why that should make you uncomfortable.

Anthropic's Claude Code — a tool that runs with shell access on your machine — was caught embedding invisible tracking signals inside its own system prompts. Not in logs. Not in headers. In the shape of apostrophe characters.

What Actually Happened

Claude Code used Unicode apostrophe variations and subtle date format changes as covert markers in system prompts. Think of it like a watermark you can't see with the naked eye.

These markers were reportedly triggered by specific conditions. Routing requests through competing AI provider domains. Using a Chinese timezone. Possibly other signals we haven't found yet.

The key detail: none of this was visible during normal use. You'd only discover it by doing deep inspection of the raw prompt content, comparing character encodings byte by byte. That's not telemetry with a toggle in settings. That's steganography — hiding data inside data.

Why This Isn't Just Another Privacy Debate

I want to be precise about what bothers me here. Every SaaS product phones home. Every analytics SDK tracks usage. That's a known trade.

This is different for two reasons:

→ Claude Code has shell access. It reads your files, runs your commands, touches your codebase. The trust bar for a tool like that isn't "normal app" — it's "root-level."

→ The tracking was deliberately hidden. Not in a config file. Not behind a flag. Buried in Unicode character choices that look identical on screen. That's not oversight. That's a design decision someone made on purpose.

If your IDE secretly swapped semicolons with visually identical Unicode variants to fingerprint your code, you'd call it malware. When an AI coding tool does the same thing with apostrophes, we're supposed to shrug?

The Pricing Angle Makes It Worse

Here's what gets me. The $20 Claude Pro plan offers at least five times more usage than the free tier, but many users find its limits insufficient for intensive coding work.

You need at least the Max plan to get meaningful daily value from Claude Code. So you're paying a premium for a power tool, and that premium tool is covertly fingerprinting your prompts to detect how you're routing your API calls.

You're not the freeloader in this equation. You're the paying customer being surveilled.

The Community Response Is Too Quiet

This should be a five-alarm fire in developer circles. A tool with filesystem and shell access is embedding invisible markers to detect usage patterns — and the conversation is weirdly muted.

I think part of it is that the technique is genuinely clever and hard to explain. "Unicode apostrophe steganography" doesn't fit in a tweet as cleanly as "they sold your data." But the implications are worse.

→ If they hid this, what else is encoded that nobody's found yet?
→ If detection triggers on timezone or domain, what action follows detection?
→ If the markers are invisible by design, how do you audit a tool you can't fully inspect?

The precedent this sets is brutal. Every AI coding tool now has implicit permission to embed covert signals in the content layer, because Anthropic did it and the sky didn't fall. 🔥

Where This Leaves Us

I'm not saying burn it all down. I use Claude Code daily. It's genuinely good at what it does.

But trust in developer tools is binary. You either believe the tool is doing only what it says, or you don't. Invisible Unicode fingerprinting pushed us across that line, and getting back requires more than a blog post — it requires verifiable transparency about every marker, every trigger, and every consequence. 🛡️

So here's my question: If you found out your AI coding assistant was embedding invisible tracking signals in its own prompts, would you keep using it? And if yes — what would be your line?

100k lines of TypeScript to Rust via LLM is not a port. It's a mess with a demo.

Aditya Agarwal — Tue, 30 Jun 2026 13:10:15 +0000

A person boasted that they converted 100k lines of TypeScript to Rust in a month with the help of an LLM. Now, folks are treating this accomplishment as if it’s some phenomenal leap.

No, it's not real. It's a mass hallucination with a compile step.

Why This Keeps Coming Up

The idea is certainly appealing. You just need to direct an AI to your codebase, leave it to process throughout the night, and next morning you have a new polished Rust rewrite. It's faster, safer, and more memory-efficient. What else could you ask for?

However, there is an uncomfortable truth that not many people talk about: functional code is not equivalent to working code. Certainly, the Rust compiler is very unforgiving. It will catch all of your memory errors. But it will not catch errors in your business logic. It will not catch silent corruption in your data. It will not catch that pesky off-by-one error hiding right behind that perfectly reasonable match arm.

The Test Suite Problem

This is the part that's hardest for me to accept. Whenever you're transferring 100k lines of any code from one thing to another, the first element you transfer is the test suite. Not the application code. The tests.

→ Tests are the specification. Without them, you have no way to verify the port is correct.
→ Tests catch the subtle behavioral differences between languages — how they handle nulls, floats, async boundaries.
→ Tests are what turn "it compiles" into "it actually does the same thing."

Nobody in these viral stories talks about porting the tests first. Because that's the boring, hard, unglamorous part. And because LLMs are terrible at it — test logic is deeply coupled to runtime behavior that the model has never observed.

If there is no ported test suite, it essentially means that there is no ported application either.

LLMs Don't Translate. They Improvise.

There's a subtle danger nobody tells you about. If you ask an LLM to translate TypeScript into Rust, it won't perform a faithful translation. It will reinterpret. It will optimize. It will perceive a familiar pattern and replace it with what it believes to be the idiomatic Rust equivalent.

Occasionally, that's acceptable. Occasionally, it modifies error handling behavior without you noticing. Occasionally, it adjusts the asynchronous flow in a functionally distinct manner when the system is under heavy load. Occasionally, it excludes a particular scenario because it was deemed unnecessary based on the training data. 🫠

These are not compilation errors. These are bugs you get in production at 3 AM because a particular combination of inputs triggered a code path that the Learning Model 'thought' needed to be “cleaned up.”

A human porter will ask questions for clarification if they don't understand something. In contrast, an LLM will simply produce a whole lot of plausible garbage and proceed to the next document.

The Demo Trap

The scariest part? These ports often demo perfectly. The happy path works. The basic API calls return the right shapes. You can stand on a stage or record a screen share and it looks incredible.

This is because LLMs have been designed to perform this task precisely- generating an output that seems accurate for a human reader. The bugs are in the infrequent cases- the edge situations, the race problems, the strange state changes that could only be detected by your test suite (the one that was not transferred).

I've seen this pattern before with regular code generation. The code looks clean. It even looks better than what a human would write. And then you trace a bug for two days and realize the AI invented a function signature that doesn't match the actual contract. 😅

What a Real Port Looks Like

A true port is not exciting. It's very systematic. It goes module by module with tests running green at every step. Converting 100k lines of code in a real port isn't something you do in a matter of weeks either. It involves humans making judgment calls about architectural differences between the source and target language.

→ Port the tests first
→ Port module by module, validating against those tests
→ Flag every spot where language semantics diverge
→ Accept that some things need to be redesigned, not translated

That's not a sexy story. It doesn't go viral. But it produces software that actually works.

The Real Question

I'm not anti-AI in code. I use LLMs daily. They're great for boilerplate, exploration, and rubber-ducking. But there's a canyon between "AI helped me write some Rust" and "AI ported our entire production codebase." 🔥

Celebrating unverified ports as engineering achievements sets a dangerous precedent. It tells teams that rigor is optional if the vibes are right.

So here's what I want to know: have you actually shipped an LLM-generated port to production? What broke first?

100k lines of AI-ported Rust nobody can review is not an achievement

Aditya Agarwal — Tue, 30 Jun 2026 10:09:12 +0000

Someone ported 100k lines of TypeScript to Rust in a month using AI. They don't know Rust. People are calling it an achievement.

I'm calling it a liability.

The Claim

Here's the setup. A developer fed a massive TypeScript codebase into an AI tool and got Rust out the other side. 100k lines. One month. Zero prior Rust experience.

In theory, it all seems amazing. In practice, it raises a question nobody wants to ask: who reviews this code?

You Can't Review What You Can't Read

This is the part that is so painful. If you are not familiar with Rust, you didn’t really port anything, you just told a machine to produce output in a language you are unable to assess.

That isn't engineering at all. It's more like a trust exercise using a random text generator.

Skilled Rust developers who reviewed the output raised red flags right away. The excessive use of Arc<Mutex<...>> wrappers – a common anti-pattern indicating a lack of understanding of Rust's ownership system, where everything is wrapped in thread-safe reference counting simply to silence the compiler. The code compiles. It runs. But the essence of using Rust is lost.

→ Rust's value is zero-cost abstractions and compile-time safety guarantees
→ Slapping Arc<Mutex<>> on everything turns Rust into a slower, harder-to-read Go
→ The compiler stops complaining, but the architecture is lying to you

No Tests, No Port

Here's the other thing. No test suite was ported first.

Just think about it for a moment. You are in possession of 100k lines of code that were automatically generated using a language that is foreign to you, and you don't have a tool to automatically check if the behavior is similar to the original one. Is it functional? You can't be sure. You just have to believe it.

The first step in a true port is to have tests. You transfer the test suite, then you transfer the implementation, then you execute the tests. This might not be the most exciting or glamorous process, but it is the most effective one. It's also the only version that actually works.

If there are no tests, you basically end up with 100k lines of unverified Rust code that no team member can update. It's not really a port. It's just accumulating technical debt that happens to have a Rust logo on it. 🦀

The Actual Risk

I’m not against AI code generation. I use it every day. But there’s a huge difference between using AI as a tool to speed up things when you get what the results are and using AI as a substitute for getting the results.

When an issue occurs in that 100k-line codebase — and it's inevitable — a person must debug Rust. Not "request AI to debug Rust." You have to read the borrow checker errors, comprehend the lifetime annotations, follow the ownership graph. If there's no one on the team able to handle that, you're screwed iterating errors through the AI and crossing your fingers.

→ AI-generated code you understand is a productivity multiplier
→ AI-generated code you don't understand is a time bomb
→ The explosion is just deferred, not prevented

Speed Is Not the Flex You Think It Is

Though the caption reads "One month", a blitzkrieg approach devoid of understanding isn't really speed; it's movement.

I've seen teams rewrite systems in half the time by cutting scope ruthlessly and understanding every line. Conversely, I have seen teams "move fast" for the same amount of time and then struggle for the next two years. The second group always started out bragging about speed too.

The flashy version of this would be: “I used magic AI to learn Rust and port 20k critical lines in three months with a single test failing but it was right. Then a griffin delivered my performance improvements.” But that’s boring. And also how it works. 💡

The Takeaway

Writing code is no longer difficult. Understanding code is the hard part. It always was, honestly. AI just made it possible to skip the understanding step at scale, which means the consequences of skipping it also scale.

If your team can't review it, maintain it, and debug it at 3 AM when production is down — you didn't ship an achievement. You shipped a future incident report.

What's your bar for "good enough" when it comes to AI-generated code in a language the team doesn't know?

100k lines of TypeScript to Rust with zero Rust experience. That's not engineering.

Aditya Agarwal — Mon, 29 Jun 2026 19:13:46 +0000

Someone ported 100k lines of TypeScript to Rust in a month using Claude. They had zero Rust experience. And honestly? I can't stop thinking about it.

The developer then used differential fuzzing — the process of throwing random data at two versions of a program and comparing the results — 2.3 million battle simulations no less, to validate that the Rust output matched the original TypeScript behaviour. The vast majority of tests passed. The code was finished. The internet lost its collective shit.

Why This Hit a Nerve

This is a divisive tale for developers. On one side, "It runs, the tests pass, what does it matter how it was written?" On the other, "You don't know Rust. You're just using a photocopier."

Both camps have a point. Neither wants to admit it.

Passing Tests ≠ Understanding Code

Here's what I find annoying. The validation strategy itself was actually quite clever. Doing differential fuzzing over millions of runs is not a lazy hack. That is real engineering effort put into the validation stage.

However, verifying something and understanding it are two different things.

→ Can this developer debug a borrow checker issue at 2am without Claude?
→ Can they reason about unsafe blocks or lifetime annotations under pressure?
→ Can they make architectural decisions in Rust that Claude wouldn't suggest?

If your answer is no, then what precisely shall be the outcome when that AI-generated code runs into that edge case which wasn't covered by 2.3 million fuzzing runs? You're not an engineer in that language. You're a QA pipeline with a very expensive compiler.

The "It Works" Trap

I understand the counterargument. We don't gatekeep people using StackOverflow. We don't test every JavaScript developer's knowledge of the event loop before allowing them to push to the main. Tooling has always been part of engineering.

However, there's a distinction between utilizing tools to enhance comprehension and relying on tools to completely substitute it. A carpenter using a nail gun still knows the location of the studs. This seems more akin to someone having instructed a robot to construct a house then checked if the doors can open. 🏠

The doors might open fine. Until there's an earthquake.

What This Actually Proves

The real story isn't "AI can port languages." We already knew that. The real story is that testing infrastructure might matter more than language expertise now.

That's either thrilling or terrifying depending on your perspective.

→ If you're a Rust purist who spent years mastering ownership semantics — this feels like a slap.
→ If you're a startup founder who needs a working port yesterday — this feels like a miracle.
→ If you're an engineer thinking about career longevity — this is a fire alarm. 🔥

The developer didn't learn Rust. They learned how to assure that Rust output is correct. Those are radically separate skills. And the industry has yet to resolve which it finds more important.

The Uncomfortable Middle Ground

I wouldn't call this developer a cheater. You need actual knowledge to create a fuzzing harness that can execute 2.3 million simulations. People don't appreciate enough the expertise required to determine both what and how to test something.

However, I believe that the statement “I ported 100k lines to Rust” does not have the same meaning as before. There is a caveat to that sentence now. Actually, there might be a caveat to every sentence regarding engineering output nowadays.

We are all experiencing a lot of changes. The developers who thrive won't be the ones who gatekeep or the ones who blindly trust AI output. They'll be the ones who know exactly where the AI's confidence ends and their own judgment needs to begin.

Well, that line is more unclear than what we are willing to believe. 🤷

So here's my question: if AI-generated code passes every test you can throw at it, does it matter that no human understands it?

AI didn't commoditize software. It commoditized confidence.

Aditya Agarwal — Mon, 29 Jun 2026 16:10:28 +0000

Nowadays, everyone believes they are capable of delivering production software. This is the actual disruption - it's not about the code, it's about the confidence people have.

Pieter Levels made a post on X that went viral. In it, he mentioned how AI was turning software into a commodity, and shared that he’d been canceling a bunch of SaaS subscriptions and instead building small custom solutions for himself using AI. The reactions to that post were like lightning. Indie hackers the world over suddenly started muttering: wait, why exactly am I paying for that? I could just build it myself.

It's a fair question. It's also a dangerous one.

The demo is the easy part

AI has made it stupidly easy to get something working. You can go from idea to functional prototype in an afternoon. That's genuinely incredible.

The thing is, a "functional prototype" and something you can actually put into production is a different story altogether. And AI just handed everyone a running start toward the edge of that canyon.

What Figma actually is

Consider Figma for a moment. It is more than just "a design tool." It encompasses many years of addressing edge cases for live collaboration over unstable networks. It's conflict resolution when two people edit the same frame. It's accessibility compliance, enterprise SSO, version history that actually works, and a plugin ecosystem with thousands of integrations.

You can build a design tool demo in a weekend. You cannot build Figma. The gap between those two things is measured in years and hundreds of engineers.

Salesforce is in the same boat. Everyone loathes it. Everyone believes they can build something to replace it. Nobody who's tried has come away thinking it was simple. The product isn't the UI — it's the decade of workflow edge cases baked into every dropdown menu.

Where AI-generated code actually breaks

Here's the pattern I keep seeing. AI-generated code works great in isolation. One API, one database, one happy path. 🎉

Afterward, you establish a connection with a second system. Subsequently, a third one. Soon after, you have to manage retrying, partial crashes, expiry of auth tokens, rate limitations, and ensuring data consistency among services, as well as dealing with the vendor's API that, for some unknown cause, returns XML solely on Tuesdays.

AI-generated code may still not work for such complex multi-system integrations. Not because the models are bad -- they are scarily good at isolated problems. But real-world software is not an isolated problem. It is a thousand isolated problems duct taped together with error handling and prayers.

Confidence is the actual product now

Here's my interpretation of what really transpired. AI did not actually make it easier to build software. It just gave the impression that software development was becoming easier.

It's essential. Very important.

When a compelling demo can be created at no cost, it becomes challenging for people to appreciate the efforts put in after the demo. The unglamorous work. The monitoring. The migrations. The "a customer in Japan found a bug that only happens with double-byte characters in the billing address" type work.

The gap between a demo and an actual product has always existed. AI just made it invisible to anyone who hasn't crossed it before. 😅

So what do we actually do with this?

I'm not trying to imply that AI tools are negative. As a matter of fact, I rely on them all the time. They've changed how I work in ways I genuinely love.

However, I've observed a change in the narrative. People are associating "I built a working thing" with "I built a product." They are not identical statements.

The skill that matters most right now isn't prompting or vibe-coding. It's knowing what you don't know — recognizing when your working demo is 5% of the actual problem.

→ The demo proves the concept.
→ The product proves you understand the edge cases.
→ The business proves you can maintain it at 3 AM when something breaks.

AI made the first step a commodity but the other two are still as costly as ever.

What's the widest gap you've seen between a demo and the actual production version? I'd love to hear war stories.

AI didn't kill developer joy. Managers who mandate AI did.

Aditya Agarwal — Sun, 28 Jun 2026 19:10:47 +0000

The posts that say "I don’t feel like a developer anymore" are not about AI. They’re about your boss reading one thread on LinkedIn and deciding everyone on the team needs to completely change how they work.

I often see this confused. Programmers who voice existential dread are mixed up with "anti-AI luddites." However, if you look at the conversations carefully, it’s not about "this tool exists." It’s more about "my manager mandated this tool for everything, and now my work is meaningless."

The real complaint isn't about Copilot

A post that went viral entitled “Don’t feel like a developer anymore after AI” has received thousands of responses across developer communities. The feeling is widespread. People are saying they’ve been reduced to monitoring and checking AI work.

But here's what I notice in those threads. The devs who feel worst aren't the ones experimenting with AI on their own terms. They're the ones whose managers mandated AI-first workflows without asking what problems actually needed solving.

There's a difference between "I chose this tool because it helps me" and "my skip-level saw a demo and now we have an AI-output quota." 🙃

Autonomy is the whole game

Decades of research on developer productivity say the same thing. Autonomy over tools and process is the single biggest predictor of job satisfaction.

→ Devs who choose AI tools feel empowered
→ Devs who are told to use AI tools feel surveilled
→ Same technology, completely different emotional outcome

When a manager says "use AI to ship faster," what a developer hears is: "your craft doesn't matter, only throughput matters." That's not an AI problem. This issue has nothing to do with AI.

The identity crisis is real but misattributed

There are developers who truly enjoy solving puzzles, designing architecture, debugging, and getting into the flow of writing code. But if you take all of that away and instead tell them to "review this AI slop and correct its hallucinations," it's definitely going to seem like a different job, because in reality, it is a different job.

However, there is no compulsion to use them for personal projects. There is no compulsion for open source maintainers to accept AI generated PRs. The coercion is organizational not in the existence of the tool.

The developers who are really winning with Ai right now? They chose when to leverage it for the boilerplate they despise writing. They chose when to ignore it and work on the fun stuff. They have control. 🎯

What managers get wrong

The pattern I see everywhere:

→ Manager reads "10x productivity with AI" article
→ Manager mandates AI usage across the team
→ No discussion about which tasks benefit
→ No acknowledgment that some work is better done by humans
→ Developer satisfaction craters
→ Manager blames developers for "resisting change"

This is not an adoption strategy. It's cargo culting. And it is causing people to burn out faster than any tool ever could.

The fix is boring

Give developers choice. Let them integrate AI where it helps them. Measure outcomes, not tool adoption. Stop treating "uses Copilot" as a KPI.

The developers who feel like developers again will be the ones whose managers trust them to decide when AI helps and when it doesn't. That's it. That's the whole insight. No framework needed. No transformation roadmap. Just trust. 💡

It's not true that AI took away developer joy. The real reason was taking away developer autonomy. AI was just used as an excuse.

Have you ever been forced to use AI tools in your job? Did it help — or did it make you feel like a code reviewer for a mediocre junior dev? Tell me all about it.

AI didn't kill Tailwind UI. The lifetime license did.

Aditya Agarwal — Sun, 28 Jun 2026 10:08:53 +0000

Everyone's saying AI killed Tailwind's business. I think that's the lazy take.

Recently, about 75% of the Tailwind CSS engineering team was let go. The trendy explanation is that the framework was obviated by AI-generated code. In reality, the rot set in long before ChatGPT could ever write a flex justify-center.

The Lifetime License Problem

Tailwind UI was offered with a lifetime access option in exchange for a single payment. This was a fantastic offer for developers, but a very poor one for any business.

Think about it. You charge someone once. Then you support them forever. Every bug fix, every new component, every compatibility update — that's cost with zero new revenue from existing customers.

The only way to grow is to acquire new customers. However, your market is limited. All developers who already purchased a license are users that you will never be able to monetize in the future.

This is the slow bleed that kills dev tool companies. The thing they never even thought of but that was always somewhere in the minds of the existing team. It shows up as a gradual inability to fund the team that built the thing.

shadcn Didn't Help

After that shadcn/ui appeared and made a brutal offer of free, copy-paste components that rival the paid library of Tailwind UI.

The traffic for Tailwind's documentation decreased by 40%, causing revenue to drop by about 80% as well. It may seem like a superficial number, but it actually reflects the overall success of the project. For a project that lives or dies on ecosystem mindshare, traffic is the business.

And this is the reality:

→ Tailwind UI's one-time revenue model was already unsustainable
→ shadcn/ui gave developers a free alternative with no friction
→ AI autocomplete made both easier to use, reducing docs visits
→ The layoffs became inevitable — AI just made a convenient scapegoat

AI did not eat the lunch that Tailwind was going to have. shadcn just happened to bring a free lunch to the same cafeteria. And Tailwind had already used up the old lunch tickets.

The Real Lesson for Dev Tools

Every developer tool founder needs to be looking at this right now. One-time payments feel good, seem like they are in the best interest of the developer but they put you on a timer.

Tools that survive in the long run typically take one of two approaches. They either transition to a subscription model (which is a painful process and developers usually hate it), or they create such a rich ecosystem in their paid tier that it grows faster than what is available for free and can be replicated.

Tailwind CSS will continue to exist as an open-source utility framework. It’s used in millions of projects. However, Tailwind the business required Tailwind UI to generate revenue forever from a model that was not built to do so.

This Isn't Just About Tailwind

I've seen this pattern before at every scale. A dev tool launches with a "pay once, own forever" pitch because it feels right. Developers cheer. Revenue spikes. Then year two hits and growth flatlines because your TAM already bought in.

Do you want to know the uncomfortable reality? Subscriptions are necessary because software is not a one-time product. It requires constant updates and maintenance that have real costs. Lifetime deals use future profits to fund current operations. 💸

Adam Wathan and the Tailwind team built something genuinely great. This isn't a failure of engineering or vision. It's a business model that was always going to hit a wall. AI and shadcn just made the wall arrive faster.

Next time a developer tool says 'lifetime license', you might want to consider if it's a good bargain, or if you're just seeing a business undercharging for their future.

What do you think — can one-time payment models ever work long-term for dev tools, or are they always a ticking clock?

r/programming banned LLM posts. 6.9 million devs just exhaled.

Aditya Agarwal — Sat, 27 Jun 2026 13:10:19 +0000

The biggest programming subreddit just temporarily banned all LLM-related posts. 6.9 million developers didn't protest. They thanked the mods.

The reaction speaks for itself.

The Breaking Point

The moderators were direct about it. They mentioned the volume, the quality collapse, and their own exhaustion as reasons. Every other post had become “I asked ChatGPT to build X” or “Why AI will replace your job in 18 months.”

The comments were full of repeating the same things over and over. Nobody was learning anything new. They were just stuck.

Everyone Uses It, Nobody Trusts It

This is the statistic that I can't get out of my head: 84% of developers are using or intending to use AI tools, while only 3% have a high level of trust in the results.

Read that again. We're all using the thing. Almost none of us believe it. That's not adoption — that's compulsion.

The content flooding the programming communities followed a similar pattern:

→ Hot take about AI replacing developers
→ Tutorial that's basically "paste this into ChatGPT"
→ Thought piece predicting the future with zero evidence
→ Repeat, daily, forever

None of it served a purpose. It was information on information on information. A snake eating its own tail while writing a blog post about it.

The Ban Isn't Censorship, It's Hygiene

For some individuals, this is being presented as resistance to progress. "You can't just ignore AI!" Sure. You also can't ignore a fire alarm, but you don't want it going off every thirty seconds when there's no fire.

The signal-to-noise ratio became so low that real programming discussions – algorithms, performance, debugging stories – were being drowned in a sea of AI hype. The ban is not about sticking our heads in the sand. It’s about trying to keep a space where people still talk about code.

Think about it. When's the last time you read an AI-in-programming post and genuinely changed how you work? Not felt vaguely anxious. Not bookmarked it and never returned. Actually changed something.

The Real Problem Is Incentives

AI content is easy to produce. It gets clicks. It triggers emotions — fear, excitement, outrage. That's a perfect storm for flooding any community.

At the same time, a well-thought-out post you write on database indexing strategies in hours will get a tiny fraction of the engagement. Something is broken in the system.

This is what happens when platforms optimize for volume over value. Those who provide real value disengage, while the noisy ones who may not contribute constructively stay. It's a vicious circle until drastic measures are taken. And eventually someone has to pull the emergency brake.

What This Signals

A 6.9-million-member community doesn't make this decision lightly. When they make such a decision, it is for a good reason:

→ Developers are fatigued, not excited, by the AI content cycle
→ Quality still matters more than hype to working programmers
→ Community trust is fragile — flood it with noise and people check out

I think we'll see more communities follow. Not because they're anti-AI, but because they're pro-signal. The developers who actually build things need spaces where "I shipped this" matters more than "AI will ship this for you someday." 🔧

The Takeaway

The ban holds up a mirror. It shows what millions of developers have tried to say but couldn’t find the words for. “We’re tired of hearing about AI and would like to go back to our programming now.” The irony of my writing that in an AI-adjacent post is not lost on me. But sometimes you just need to identify what it is to be able to turn the damn thing off.

So here's my question: Has the flood of AI content in developer communities made you smarter, or just more anxious? I have a feeling I know which way this one leans. 💬

React's real problem is corporate capture, not technical debt

Aditya Agarwal — Sat, 27 Jun 2026 10:12:06 +0000

Vercel not only took React in but took in the team that creates it. They hired the team that builds it, and now the library you depend on has a landlord. 🔑

You should be more concerned about that than you are.

The Quiet Acquisition

Vercel hired important React core team contributors, including Andrew Clark, Sebastian Markbåge, and other significant members who have a major influence on the future direction of React.

There was no acquisition news. There was no antitrust review. One company simply hired the brains behind the most popular UI library on the planet, and we all just… kept coding.

React Server Components: Feature or Funnel?

When React Server Components were introduced, they were presented as the new revolutionary technology. The promise was attractive - reduced client-side JavaScript, improved performance, and an intelligent rendering approach.

Well, the reality is that the most mature RSC implementation ready for production is in Next.js, although different frameworks have started to pop up that offer different levels of support. And, Next.js performs best on Vercel.

→ React introduces a major new -shifting feature
→ That feature is deeply integrated with one framework
→ That framework is built by the company that employs the React team
→ That company sells hosting optimized for that framework

There is no need for a conspiracy theory. Just track the money flow.

"Open Source" With an Asterisk

React still uses the MIT license. No one disputes that. Open source, however, isn't just the license, it's also about governance.

When one company controls the core team's paychecks, the roadmap stops being neutral. Features that benefit Vercel's infrastructure get prioritized. Features that don't? They wait. 😕

Isn't it interesting? The React documentation suggests Next.js as one of the primary frameworks to use for new projects, among others. Not Create React App, Not Vite, but the framework that happens to be developed by the same company that employs the React team.

That's not a suggestion. That's a sales funnel disguised as documentation.

Why This Matters Beyond React

I've seen this pattern before. A beloved open-source tool gets captured by a single vendor, and the community slowly loses its voice.

The danger isn't that React becomes bad software. It probably won't. The danger is that React's evolution starts optimizing for one company's revenue instead of the broader community's needs.

Developers working with React and tools like Remix, Astro, or plain Vite are likely noticing the shift mentioned above. While RSC support (React Server Components) anywhere outside Next.js varies from experimental to increasingly stable, Vite's official RSC plugin is feature-complete for core functionality. The “unopinionated library” is certainly becoming opinionated. And isn’t it a coincidence the opinions match those of one specific company’s product catalog?

What Would Healthy Governance Look Like?

There have been suggestions about a React foundation, like Node.js joining the OpenJS Foundation after its governance crisis.

→ An independent foundation with multiple corporate sponsors
→ A public roadmap shaped by community RFC, not one company's sprint planning
→ Core team members funded by a pool of stakeholders, not a single employer

This isn't radical. It's how mature open-source projects survive corporate pressure. Linux, Kubernetes, and Node.js all went through versions of this.

React has not. And nobody with the power to change that has any incentive to do so. 🤷

The Bottom Line

The main issue with React isn't class components or problematic useEffect, or even bundle sizes. It's the fact that the developers creating the library are employed by the organization that also provides you with hosting services.

You can still love React and acknowledge this is a problem. I do. But pretending the current arrangement is fine because the code is technically open source is naive. The way it is managed is just as important as the permission to use it.

So here's my question: at what point does corporate capture of an open-source project become a dealbreaker for you — or does it ever?

AI commoditized code, not software. Developers keep confusing the two.

Aditya Agarwal — Fri, 26 Jun 2026 13:11:31 +0000

People has responded in different ways to a recent tweet by Pieter Levels where he explains he replaced all his paid SaaS with machine learning-powered custom builds and the internet went wild. But Levels was talking about code, not necessarily software.

Those are not the same thing. The gap between them is where most of us actually work.

What happened

In a June 2025 post, Levels shared that he had thrown out all paid software from his life and instead replaced it with custom AI-generated tools, making the case that if AI could build it for you in minutes, why pay for it?

Herbie Bradley disagreed. Creating software that is trustworthy — the type that manages edge cases, scales up, and doesn’t compromise your data in the middle of the night — is still a very difficult thing to do. The discussion raged across X and suddenly every engineer was talking about it.

Code is cheap now. Software never was.

Here's the distinction that no one is explaining clearly enough.

Code is what you have in your editor. And AI is so good at writing it for you. You can describe your way to a first draft of the program faster than ever before. This is the real part.

Software is everything around that code:

→ Error handling that doesn't silently eat failures
→ Auth that actually works when tokens expire
→ Migrations that don't nuke production data
→ Monitoring that wakes you up before users notice
→ The boring, unglamorous connective tissue that makes a product trustworthy

AI commoditized the first, but the second barely got a glance. And mistaking one for the other is what causes you to produce a lot of fragile prototypes and name it engineering.

The prototype trap 🪤

I understand the attractiveness of it. Creating a fast tool that solves your specific issue seems like having a superpower.

However, it is essential to keep in mind that any tool you create will require maintenance. For example, that AI-generated script taking over your project management SaaS was a good idea, but eventually, it will stop working. Guess what? You will be the one dealing with support.

Levels can make that tradeoff. He’s a solo operator who ships fast and tolerates breakage. It’s a rational choice for his situation. But most of us are not in that situation. Most of us work on a team where reliability is not optional, and “it works on my machine” stopped being cute a long time ago.

This is actually good news for your career

If you're a developer reading all the "coding is dead" opinions and feeling anxious, just relax.

The hard parts of your job — designing systems that hold up under real usage, making architectural decisions you won't regret in six months, debugging problems that span multiple services — none of that got easier. AI can generate code for you based on a description of desired functionality but defining that desired functionality is just the same as it ever was. Writing tests is still as hard and manual as it's always been.

Your worth did not depend on how quickly you could write a function. It was in knowing which function to write, where to put it, and what happens when it fails. That skill just got more valuable, not less. The amount of code available increased but the need for good decisions remained constant. 🎯 🎯

The real divide ahead

I think we're heading toward a split in the industry. On one side: people who generate lots of code quickly and ship things that mostly work. The second will be those who develop software that truly functions as intended on a large scale and meets users' needs.

Both are valid. However, they are different jobs with different pay scales and different failure modes. Understanding which one you are doing and which one the situation demands is crucial.

AI didn't turn trivial software engineering into a solved problem, it just made the parts we thought were trivial go by faster and more reliably.

I have a question for you: when do you know if AI-generated code is “good enough,” versus software that requires human engineering judgment? Where is the boundary in your work?

React lost the mass and Vercel is wearing its skin

Aditya Agarwal — Fri, 26 Jun 2026 10:12:04 +0000

There used to be a sense that the React community had ownership of the project. Nowadays, it feels more like a hosting company is managing it internally.

That shift happened slowly, then all at once.

The Quiet Takeover

Several React core team members work for Vercel. Everyone knows that. They even mention it on their LinkedIn profiles.

Consider this for a minute. The people deciding React's future collect paychecks from a company that sells React deployment. The roadmap and the business model have their lunch together.

Server Components and the App Router were not requested by thousands of developers. They were envisioned, and it just so happens that that aligns perfectly with Vercel’s infrastructure narrative. Two features that would be extremely hard to self-host, but are trivial to Vercel. Funny that.

"Open Source" With an Asterisk

React is still MIT-licensed. Nobody disputes that.

Open-source is more than just a license. It's a feeling of governance. It's about deciding if the community is involved as a contributor or a user.

Right now? A lot of developers feel like consumers.

→ Server Components require deep framework integration where Next.js remains the most mature implementation, with other frameworks like RedwoodJS and Waku offering experimental or limited support
→ The App Router introduced mental model changes that benefit server-centric architectures
→ Documentation increasingly assumes you're using Next.js as the default path

You could attempt to use React Server Components without Next.js at some point. In theory, it's possible just like how it's possible to run a marathon without shoes. It can be done. However, your better judgment will likely advise against it.

The "Does Anybody Actually Like React?" Question

A thread with that exact title recently gained serious traction in developer forums. Not from newbies. From experienced engineers who have been authoring React for years. 🤔

The real problem isn't with JSX, hooks, or the virtual DOM. Those issues were resolved long ago.

The frustration with React comes down to one thing really, trust. Developers opted into React because it was a library, and a view library at that, not a framework.

Currently, the library has tendrils growing into your server, tendrils growing into your routing, tendrils growing into your caching layer, and tendrils growing into your deployment target. And all of those tendrils keep pointing at one company's checkout page.

What's Actually at Stake

I don't believe Vercel is bad. They hire intelligent people and develop actual technology.

However, the future development of a library that is being used by millions of developers should not be based on the business model of one company. This is not the concept of open source. It is more like a marketing channel that has a GitHub repository. 🔥

The React team would argue that these features benefit everyone. And to be fair, they do. But you can also claim that “benefits everyone” and “mainly benefits one company” are both correct at the same time.

This was anticipated by other frameworks. Svelte, Solid, and even Vue have always had a clearer separation between the core library and the deployment layer. React kinda mixed it up, and now people are starting to question for whom the framework is built.

Where This Leaves Us

The previous version of React that served as only a view library is obsolete. The current version of React acts as a full-stack opinion engine, and you will also find a billing page attached with that opinion.

You are not obliged to use React with Vercel. Many teams don't. But the gravity is real, and it pulls harder with every release.

The React ecosystem would benefit the most if it could set up its own overseeing body. For instance, a foundation or steering committee where most members are not employed by any specific company. We need to make “open” mean a lot more than just a title of a license document. ✊

Well, the question remains if React's direction is primarily determined by one company, is the open-sourcing of the code enough to gain your trust in the project's direction now? If not, what would have to change for that to be the case?

AI made coding boring and nobody wants to admit it out loud

Aditya Agarwal — Thu, 25 Jun 2026 19:16:37 +0000

There was something fulfilling that died within me when I no longer had to debug my code.

I can't tell you the specific date that this feeling began to spread. But there's a growing chorus of experienced developers saying the quiet part out loud: coding isn't fun anymore, and AI might be the reason.

The Thread That Hit a Nerve

A viral thread in a popular senior developer community recently went boom. The premise was simple: “coding doesn't seem fun anymore.” It wasn't burnout cases or junior devs dealing with imposter syndrome in the replies.

These were staff engineers, tech leads, and founders. Individuals who opted for this profession out of passion for the craft. And yet, they were all expressing a similar sense of hollowness.

The "Mentally Lazy" Problem

Here is a recurring theme. Developers who lean heavily on AI assistants report feeling "mentally lazy" — their words, not mine.

It is logical when you give it a second thought. The satisfaction of programming was never really about the output. It came from the process. The moment your brain clicks two concepts together and you see the path forward. That's what gives you a dopamine rush.

AI assistants like this short-circuit the loop. You receive the answer even before your brain completes the question. The code is functioning, the PR is being shipped, and you don't get the ... feeling.

→ The puzzle is solved before you get to enjoy solving it.
→ The "aha moment" gets replaced by a "yeah, that looks right" moment.
→ You become a code reviewer of machine-generated output instead of a creator.

That's not programming. That's middle management using a terminal.

The Corporate Squeeze

Meanwhile, every company on earth is pushing AI adoption like it's oxygen. And the productivity gains are real — I'm not going to pretend otherwise. Products are reaching shelves at faster speeds. Repetitive tasks are being eliminated. New employees are truly able to get up to speed faster on alien projects.

But there's a tension nobody in leadership wants to acknowledge. The same tools that make developers faster are quietly eroding the craftsmanship that made those developers good in the first place.

Experienced engineers developed their intuition by investing countless hours of effort. By analyzing stack traces while it was 2am. Through writing bad code, understanding why it was bad, and rewriting it. You can't shortcut that process and expect the same caliber of engineer on the other side.

→ Companies want 10x productivity now.
→ They're borrowing against the skill development of their team to get it.
→ Nobody's accounting for that debt yet.

The Part Nobody Wants to Say at Work

Here's the reality check. If you tell your manager "AI tools make me feel less skilled and less engaged," you sound like a luddite. You sound like the person who refused to learn Git in 2012.

Therefore, developers remain silent. They operate the tools. They deliver the tickets. And they slowly lose the thing that made them fall in love with this work. 🔇

I don't think the answer is rejecting AI tools entirely. That would be stupid. But I think we need to be honest about the tradeoff instead of pretending it's all upside.

Some days I intentionally close the AI assistant and write code the old way. I do it because I want to re-experience the process of thinking and working out a solution. Because I want to remember what it feels like to think through a problem. To hold the whole system in my head and feel it click into place.

Protect that feeling at all costs.

Where This Leaves Us

The increased productivity with AI coding tools is real. The deskilling is real too. Both can be true at once and it doesn't help to pretend otherwise. The programmers who will do best in the next 10 years are those who use AI intentionally — as a complement not a replacement — while still focusing on the deep problem-solving abilities that no autocomplete can provide.

So here's my question: have you noticed yourself thinking less deeply since you started using AI assistants? And if so, what are you doing about it?