DEV Community: Aditya Agarwal

Bun rewrote itself from Zig to Rust using an LLM in 9 days. That should terrify you.

Aditya Agarwal — Sun, 14 Jun 2026 13:10:13 +0000

A major runtime just got machine-translated to a completely different language and merged in under two weeks. Let me say that again slowly.

Bun, the JavaScript runtime that the community keeps considering for a serious relationship, finished a rewrite of itself, from Zig to Rust. The rewrite was composed in its majority by the LLM model. The process lasted around 9 days. The Pull Request contained over 1M LoC of Rust.

I don't think everyone realizes how amazing that is.

This Isn't a Rewrite. It's a Translation.

Rewriting software and translating software are worlds apart. The former involves humans re-thinking the architecture, fixing old mistakes, and inevitably making some new and different mistakes in the new language. A translation means you shove code through a machine and hope the output is equivalent.

Who besides the maintainers themselves possibly has a shot at understanding most of the new codebase, given that they didn’t write it by hand? This isn’t a rhetorical question. It’s the only question that counts.

A Million Lines Nobody Wrote

Imagine the scenario of conducting a code review for a million lines of LLM-generated Rust. You're not reviewing logic someone reasoned through. You're reviewing output that looks reasonable — which is the exact failure mode LLMs are famous for.

What worries me the most about this is:

→ LLMs are confident pattern matchers, not reasoning engines. They'll translate idioms from Zig into Rust that compile but subtly violate Rust's ownership model in ways that only surface under pressure.

→ Edge cases are where translations break. The happy path translates fine. The weird concurrency bug that took six months to find in Zig? The LLM doesn't know it exists.

→ Roughly 9 days means roughly 9 days of testing. For a runtime that wants to run your production JavaScript. 😬

Tech Debt Laundering

Here's the phrase I keep coming back to: tech debt laundering.

You had a Zig codebase with known quirks, known debt, known ownership among contributors. Now you have a Rust codebase with unknown quirks, hidden debt, and near-zero institutional knowledge. The debt didn't disappear. It just got dressed up in a new language and a clean git history.

The old codebase was battle-tested. The new one is battle-translated. Those are not the same thing.

Why This Should Worry the Whole Ecosystem

Bun is not just another fun project some people happen to use. Some folks actually depend on it for their business. Some companies have staked their entire technological infrastructure on it. And the heart of said infrastructure is now a pile of almost-generated, not-quite-engineered code.

I don't mind AI in codebases. I use LLMs every day. However, there's a distinction between employing an LLM to generate a utility function that I meticulously check and using one to translate a complete runtime that I distribute to thousands of developers.

The real issue here is the speed. Nine days are just not enough to have the kind of thorough, adversarial reviews that a million-line systems codebase requires. It’s enough to let you know if “it” compiles and the tests pass. It’s not enough to let you know if “we” understand what we’re shipping. 🔥

The Real Question

This creates a dangerous situation that other projects facing a similar "wrong language" issue might try to replicate what Bun has done here, and undoubtedly most of them will lack the same resources and engineering know-how to offset the risks.

I think we're going to look back on this moment as either a breakthrough or a cautionary tale. I still can't say which. But I do know the trust we've placed in open source assumed maintainers knew their own code. That just became a lot more difficult.

So here's what I want to know: Would you run LLM-translated code in production — and if so, what would it take for you to trust it?

Most agentic workflows are just while loops with vibes

Aditya Agarwal — Sat, 13 Jun 2026 16:09:56 +0000

Each week I see a new “autonomous agent” demo in my feed, and each week it seems to be the same thing: a loop that calls an LLM, does not check anything important, and runs until the API key screams.

We need to talk about this. Because most of what people are calling "agentic workflows" are just while loops with vibes.

The Pattern Is Everywhere

You've seen the code. Maybe you've written it. I know I have.

It appears as shown in the image below:

while not done:
    result = call_llm(context)
    context = update_context(result)
    done = result.is_acceptable()  # narrator: most of the time, it's not

That seems_good_enough function is doing a lot of heavy lifting. In most repos I've poked through, it's either a hardcoded iteration cap or another LLM call asking "are we done yet?" Sometimes it's literally just max_retries -= 1.

That doesn't sound like an agent. It's more like a billing reminder with a ticking clock. 🔥

Why This Matters Right Now

The hype around agentic coding is intense. People are building "autonomous" systems that refactor code, write tests, and deploy features without human input. The promise is amazing.

The truth is more mundane. Token spend is on the rise everywhere and most of it is from agent loops with no clear, “done” condition. They spin. They retry. They rephrase the same prompt in hopes that the new answer will be the one that satisfies the prompt.

The Exit Condition Is the Whole Point

Here's the thing nobody wants to hear: the hard part of building an agent isn't the loop. What's difficult is to determine when the loop needs to stop.

→ A code-writing agent needs to know what "correct" means — tests pass, types check, linter is clean
→ A research agent needs to know what "sufficient" means — not "keep Googling forever"
→ A planning agent needs to know what "done" means — an actionable plan, not an infinite refinement spiral

If your exit strategy relies on the LLM declaring that it has finished, then well done, you've left the design of your system up to a token predictor with no understanding of what it means to be finished.

The Bar Should Be Higher

I'm not saying agents are fake. Real agentic systems exist and they're genuinely useful.

But they share one trait: crisp, verifiable exit conditions that don't depend on the model's self-assessment. Think tool-use results you can programmatically validate. You want external state changes that you can measure. You want explicit claims, not feelings.

What sets an agent apart from a while loop is accountability. An agent is aware of its success, while a while loop is only aware of running out of retries.

A Quick Gut Check

Before sending out your next agent, question yourself on three fronts:

→ Can I write a unit test for my exit condition without mocking the LLM?
→ If I removed the iteration cap, would this loop ever stop on its own?
→ Can I explain to a non-technical person what "done" means for this workflow?

If you answered no to any of those questions, then you don't have an agent. You have an expensive loop! Which is fine, loops are useful, just don't put "autonomous" in the paper. 😅

The Uncomfortable Truth

We are currently at a stage where the sample itself is the final product. It's simple to launch and raise funds based on a looping LLM call that creates impressive output in a screen recording.

Production is a whole other beast. Production means your agent is running at 3 AM and there is no one there to see if it got a little stuck and ate up your entire monthly token budget because it just kept trying to work on iteration two.

If you can't define your exit condition, you didn't build an agent. You built a billing event.

The most effective agent code I have seen consists mostly of mundane constructs like conditionals, validators, and state machines, with an LLM hidden somewhere inside them, and not the other way around. The smarts are not in the loop, but in the ability to get out of it. 🧠

So here's my question: What's the most creative exit condition you've built into an agent workflow — one that doesn't just ask the model "are we done?"

You have great ideas that I'd love to use.

Bun rewrote itself from Zig to Rust in 9 days with an LLM. That's terrifying.

Aditya Agarwal — Sat, 13 Jun 2026 10:23:42 +0000

It took nine days to rewrite all of Bun from Zig to Rust using an LLM and get the new code to the point where I could merge it. I saw that and my reaction was not “cool.” It was “oh no.”

Let me be clear. The speed isn't what scares me. The confidence is.

Why This Hits Different

Bun's lead developer had publicly downplayed the idea of a Rust rewrite just days before it happened. Then an LLM-assisted rewrite landed and got merged in nine days flat.

This is not just refactoring some part of the codebase. It's not porting a utility library. It's literally re-implementing an entire JavaScript runtime system - which is known to be one of the most complicated pieces of software.

The Real Gamble Isn't the Language

The debate between Zig and Rust is not the real issue. That's the wrong argument.

The fundamental issue we should be discussing here is whether or not the team has a solid comprehension of the code that has been recently delivered? If a Large Language Model is used to translate hundreds of thousands of lines of code from one language to another, the output could be compilable. It could even pass all the tests. However, the conceptual understanding, meaning the knowledge regarding "what was the purpose of writing this line" is not simply transmitted alongside it.

→ LLM-generated code can be correct without being understood.
→ Code you don't understand is code you can't debug under pressure.
→ A runtime is the worst possible place for "it works, don't touch it" code.

I have worked on codes where some person wrote a critical module and then left the company. Thats already terrifying. Now, imagine the "some person" is a language model who cant expound on its design decisions.

Speed as a Liability

Nine days is impressive engineering velocity. It's also a red flag for review depth.

Imagine the level of detail in a thorough code review of a runtime. You would be reviewing memory safety, edge cases related to the event loop, how syscalls behave consistently across all supported operating systems, and subtle concurrency bugs. These kinds of checks already take weeks when the code is authored by a human who can provide insight into the logic behind their implementation.

Fast merges feel great until the first mystery bug in production. The kind where the stack trace makes no sense because the code was mechanically translated and nobody on the team wrote it by hand.

I don't believe that the Bun team works carelessly. They possess evident skills. But talent doesn't give you a shortcut past the "deeply knowing your own codebase" requirement. Especially when it comes to a critical system like this.

This Is the New Normal (And That's the Terrifying Part) 🔥

Here's what keeps me up at night. If Bun can do this, every team is going to try it.

Startups will leverage LLMs to rephrase decades-old services in a few days. CTOs will approve language shifts that previously required months to complete. And some of those rewrites will work beautifully. But some will ship half-understood code into production systems that handle money, health data, or infrastructure.

→ The barrier to "just rewrite it" just dropped to near zero.
→ The barrier to "actually understand what you shipped" hasn't moved at all.

We are about to step into a time where writing code can be done incredibly fast and the real challenge will be in understanding the code. This disparity will likely result in some epic failures. 💀

What I Actually Think

I don't think LLM-assisted rewrites are inherently bad. They are like power tools. Power tools are fantastic until someone ignores the safety rules.

The Bun rewrite could be successful in the end. The team might spend the next few months internalizing every line. Rust's compiler catches entire categories of bugs that Zig doesn't. So, there are advantages in this approach.

What concerns me most is not the particular case but the precedent this sets. A decision-making timeframe of 9 days from “we’re not doing that” to “it’s merged” does not leave room for the slow, boring work of actually understanding what you built.

The best engineers I know aren't the fastest coders. They are the ones who are able to articulate every obscure line of code in the codebase when there is an outage at 3 AM. LLMs can not do that. Not at the moment.

My question is, would you mass-merge LLM-translated code into a critical system your team ships to millions of users? And if so, what's your plan for when something breaks in a part of the code that nobody actually wrote?

AI doesn't make you a generalist. It makes you a nobody.

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

Everyone is cheering that AI turns you into a "full-stack everything." But no one is questioning what it means when all of us are full-stack everythings.

Here's the uncomfortable math: if AI hands every developer the same superpowers, those powers aren't superpowers anymore. They will become basic requirements.

The Essay That Hit a Nerve

A post titled "LLMs are eroding my software engineering career and I don't know what to do" went viral in developer communities, garnering hundreds of passionate responses. Its core message was direct: AI is diminishing the value of specialization, turning everyone into a generalist.

It wasn't the essay that surprised me. It was the reaction to it. Senior developers, with 10-15 years of experience, publicly sharing their career anxiety that their skills might be commoditized instantly.

The "Everyone Is 10x" Lie

The common story is like this: AI can make each developer ten times more productive. You can now work on backend, frontend, infra, data — everything. You are a generalist superhero. 🦸

But economics doesn't care about your productivity fantasy. The reality is:

→ AI gives every developer the ability to do generalist work
→ The supply of "generalists" explodes
→ Oversupplied skills get paid less, not more
→ Companies need fewer people to ship the same output

This is not a theory. It's about how much is available and how many people need it. The exact same principle that renders AI-generated stock images completely valueless is beginning to affect commoditized development work.

When everyone can build a CRUD app with a prompt, building CRUD apps pays CRUD wages.

Specialization Was Your Moat

Consider the reasons why senior engineers were paid more. It wasn't because they were capable of "doing a little of everything.” It was because they possessed depth — whether in distributed systems, performance engineering, security, or domain knowledge that required years to acquire.

That depth was a moat. It was hard to replicate, hard to hire for, and therefore valuable.

The pitch now is: "You don't need to worry about depth. AI will fill in the gaps." However, if everyone's gaps are equally filled by AI, your moat has been destroyed. You have gone from being "the person who truly understands X" to "one more dev with a ChatGPT subscription."

That's not a promotion. That's a demotion with better tooling.

What Actually Holds Value

I believe the solution is not to refuse AI. That's just denial with extra steps. However, I am convinced that considering "AI turns everyone into a generalist" is a harmful idea that only advantages employers over engineers.

What still holds value in a world of commoditized code generation:

→ Taste — knowing what to build, not just how to build it
→ Domain expertise — understanding the problem space deeply enough to ask questions AI can't
→ Systems thinking — seeing second-order effects, failure modes, and tradeoffs that don't show up in a prompt response
→ Judgment under ambiguity — making the call when there's no clear right answer

None of these are things you develop by becoming a "generalist who vibes with LLMs." They come from going deep on hard problems over time. 🔍

The Real Risk Nobody Talks About

The scariest part isn't that AI replaces developers. It's that AI makes developers interchangeable.

If what you are offering as your value proposition is “I can ship features fast with AI assistance.” Well, congratulations! So can the next hundred applicants. You’ve essentially optimized yourself right into a commodity.

Companies love commodities. Commodities are cheap and replaceable. That's great for hiring managers. It's terrible for your salary negotiation.

The developers who will thrive aren't the ones who become the best users of AI. They're the ones who remain the hardest to replace even with AI. That means going deeper, not wider. It means building expertise that can't be prompted into existence. 💡

The generalist hype is a sugar rush. Specialization is still the long game.

So here's my question: are you building skills that survive commoditization, or are you just getting faster at work that's about to get cheaper?

AI makes experienced devs 19% slower. They just don't feel it.

Aditya Agarwal — Wed, 10 Jun 2026 19:11:28 +0000

Senior devs used AI coding tools and got 19% slower. But they felt 20% faster. Read that again.

No, you read that correctly. A 39-percentage-point difference between what people think about something and what the truth is. And it might be the most important finding about AI-assisted development this year.

The Study

Experienced open-source developers who worked on real tasks were measured by researchers with and without AI coding assistants. They weren't juniors going through tutorials. These were seasoned contributors familiar with their codebases.

The outcome? These AI tools actually made them 19% slower. Those same developers self-reported feeling roughly 20% faster.

The Productivity Placebo

I believe I understand the situation here. And if you've used Copilot or Cursor for more than a week, you probably recognize it too.

The typing feels faster. Autocomplete fills in boilerplate. Tab-tab-tab and you've got a function skeleton. That dopamine hit of "wow, I didn't have to type that" is real. Your fingers are doing less work. Your brain registers that as speed. 🧠

But here's what your brain doesn't track well:

→ The 4 minutes you spent reading generated code to check if it actually does what you wanted
→ The 12 minutes debugging a subtle hallucination buried in otherwise-correct output
→ The context switches when AI suggestions pull you down a different path than you intended
→ The false confidence that lets a bug slip into code review

While you save time on generation, you end up spending that time on verifying and debugging the code. So, in the end, there is no real advantage. But it doesn't feel negative because the slow parts are spread out and invisible.

Why This Should Worry Us

This does not oppose the use of AI tools. It's an argument against blind trust in them.

If you feel faster but you're actually slower, you won't course-correct. You'll keep doing the thing that feels productive. This is what we call a productivity placebo.

The situation is even more alarming at the organizational level where managers observe that developers are creating more code, more commits, more PRs, and all the vibes-based metrics are trending positively, yet if actual throughput is down 19% nobody realizes it until deadlines start slipping and the bug count keeps growing. 😬

What I Think This Actually Means

I don't think AI coding tools are useless. I think we're using them wrong.

The experienced developers involved in this research were working on codebases that they were already familiar with - i.e., they already had the mental models and knew what to type; for them, AI assistance was an overhead, not a leverage.

I think the calculus changes in the unknown unknowns. Trying out a new API. Writing in a language you touch once per year. Filling in a project structure you've never made before. That's where generation speed might actually outweigh verification cost.

The lesson isn't "stop using AI tools." The lesson is stop assuming they're helping just because they feel good.

The Uncomfortable Takeaway

Track your time and effort spent on debugging. Time yourself while debugging code before and after testing. Not "do I feel productive" but "did this task take less time." Use a timer if you have to. Be honest with yourself about the debugging tax.

The top developers in my circle consider AI assistants as junior pair programmers. They are good for helping with ideas and providing boilerplate code, but you still need to carefully check and review every line of code they produce as if the assistant is a new hire. The bottom developers treat them like magical oracles. 🎯

If the feeling of speed and the reality of speed are pointing in opposite directions, the feeling is lying to you.

What's your experience — have you ever actually timed yourself with and without AI tools on the same kind of task?

Senior devs are 19% slower with AI tools but think they're 20% faster

Aditya Agarwal — Wed, 10 Jun 2026 16:12:47 +0000

Senior devs are getting slower with AI tools and don't even realize it. That's not my hot take. That's what a recent study found.

Experienced developers were 19% slower when using AI coding assistants. The kicker? Those same devs self-reported feeling about 20% faster. That's nearly a 40-percentage-point gap between perception and reality.

Take a moment to process that.

The Productivity Placebo

This is crazy because it completely changes the perspective on AI-tools. We were led to believe that these tools benefit experienced developers the most. Senior developers are aware of what quality code is, so they can better direct the AI. That was the idea.

But the data tells a different story. The developers who should benefit most are actually losing time. And they're so confident they're winning that they don't notice.

Why Seniors Might Be Losing Time

I have a hypothesis. Senior developers come equipped with solid mental models. They are able to maintain a complex system in their mind and write down solutions nearly at the same speed as their thoughts.

Now imagine adding an AI assistant to this mix. Suddenly you're reading suggestions, evaluating generated code, fixing subtle bugs the AI introduced, and context-switching between your plan and the AI's plan. That’s not speeding up. That’s slowing down in the guise of assistance.

→ Reading AI output takes time — time you wouldn't spend if you just wrote it yourself.
→ Reviewing generated code is harder than writing it — you have to verify someone else's logic against your mental model.
→ Subtle AI errors are the worst kind — they pass the vibe check but fail in production.
→ The "accept and fix" loop is deceptive — it feels fast but adds up.

Junior developers may actually find value in it as they are exposed to new patterns they might not know. For seniors, the AI is repeating what they already understand, and doing so at a pace that costs them time.

The Perception Gap Is the Real Problem

Not only is the 19% slowdown alarming, but also their level of confidence is even more frightening.

If you perceive 20% faster, you'll never doubt the tool. You'll never conduct the experiment. You'll advocate for AI assistants in every team meeting because your intuition tells you they are effective. That is a classic perception trap 🧠

This is important for teams to consider when making tooling decisions. If your most experienced engineers are unknowingly losing productivity and still championing a tool based on ‘vibes’ - that’s a problem.

Where AI Tools Actually Shine

I don't feel threatened by AI tools. In fact, I use them every day. But I've started being honest about where they help versus where they just make me feel productive.

→ Boilerplate and scaffolding — great. I don't need to type another Express route handler from memory.
→ Unfamiliar languages or APIs — solid. It's like having docs that talk back.
→ Complex logic in a codebase I know well — questionable. I'm usually faster on my own.
→ Debugging subtle issues — actively harmful sometimes. The AI confidently suggests wrong fixes and I waste time proving it wrong.

The problem is, the real benefits of it are not spread equally among all kinds of work. Where many teams get it wrong is treating it like an "always on" productivity tool.

The Takeaway

Measure, don't assume. If you're a senior dev who swears by Copilot or similar tools, try a week without them on a real task. Time it. Compare honestly. You might surprise yourself.

The best tools are the ones that make you faster and you can prove it. Otherwise, they simply provide a false sense of security.

**Have you ever measured your actual productivity with vs. without AI. For me, it doesn’t matter much, as I’m just having fun and learning new things.

Experienced devs are 19% slower with AI tools. Nobody wants to believe it.

Aditya Agarwal — Wed, 10 Jun 2026 13:17:00 +0000

Every AI coding tool on the market promises you'll ship faster. A recent study says experienced developers actually got 19% slower when using them.

Read my lips: NOT beginners. NOT interns. We need EXPERIENCED developers.

Why This Hurts

This isn't some edge case buried in a footnote. The slowdown was attributed in part to time spent reviewing and debugging AI-generated output, though the study also found a significant perception-vs-reality gap where developers believed AI was helping even when it wasn't.

Senior developers didn't simply take what the computer gave them. They read it, doubted it, experimented with it, found the little errors, and corrected them. That process consumed a lot more time than it would have taken to write the software in the first place.

And let's be honest about something that nobody talks about. This directly contradicts the core marketing pitch of every single AI coding assistant on the market.

The Productivity "Feeling"

I believe that’s relatable for many of us. You prompt Copilot, it spits out 40 lines, and you think wow, that was fast. It feels productive. It’s a dopamine rush. The code is right there. Just ship it.

But feeling fast and being fast are two very different things. The study suggests that for experienced devs, the gap between those two is not just real — it's negative.

→ AI generates code quickly, so you feel like you're moving
→ You spend the next 20 minutes verifying and fixing what it wrote
→ Net result: slower than if you'd just typed it yourself

The junior dev might accept the output and move on. The senior dev knows better. And that knowing better is exactly what costs them time. 🎯

The Uncomfortable Implication

If senior engineers — the ones companies pay the most — get slower with these tools, what does that mean for the "AI will 10x your team" narrative?

This indicates that the story is not fully accurate. At worst, it's a convenient story told by companies selling seats.

I'm not saying AI coding tools are completely of no use. I actually use them myself. They are helpful for boilerplate codes, trying out new libraries, or even explaining your code when you're alone. However, saying that they save time for everyone? That's just a marketing gimmick with no real evidence to back it up.

What Senior Devs Actually Do

Here's what I think people overlook. Skilled developers do more than just put words on a screen. They choose a direction.

They are the final safeguard against incorrect requirements. They catch architectural mistakes before they become expensive. They hold context about the system that no AI has access to.

When you give that to someone and then add an AI that generates with confidence code that looks right but often is subtly wrong, which means that have a new job – an AI babysitter 😄– not a productivity gain, a tax.

→ The value of a senior dev is judgment, not typing speed
→ AI tools optimize for typing speed
→ The mismatch is predictable

So What Do We Do With This?

I don't think the answer is "throw away Copilot." The answer is to stop pretending the productivity gain is universal and automatic.

Let’s be realistic about where AI is useful and where it’s not. Judge by outcomes, not by what seems cool. And maybe stop using "we gave everyone Copilot" as a substitute for actually investing in developer experience.

The 19% number is a gut check. It's not the final word on AI-assisted development. But it's a data point that deserves more attention than it's getting, especially when billions of dollars are being spent on the opposite assumption.

If you're a senior dev, has AI tooling actually made you faster — or does it just feel that way? I'd genuinely love to know. 🤔

HTMX getting hired by GitHub doesn't validate your hatred of React

Aditya Agarwal — Wed, 03 Jun 2026 10:13:10 +0000

Carson Gross got hired by GitHub. Your timeline is now unbearable.

When the HTMX creator joined GitHub's Next R&D team, two camps immediately claimed total ideological victory within hours. HTMX fans announced React's imminent death, while React fans dismissed the move as a simple acqui-hire. They’re both wrong.

What Actually Happened

GitHub brought Carson Gross onto their research and development team. That's the update. That's the news.

HTMX is a hypermedia-focused library that extends HTML with AJAX attributes. It lets you do dynamic UI stuff without writing JavaScript. It's genuinely clever and useful for a specific set of problems.

GitHub already uses React heavily across its frontend. They didn't rip it out. They didn't announce plans to rip it out. They hired one person to explore ideas.

The HTMX Victory Lap Is Premature

I understand you. When you've been yelling "we don't need 200KB of JavaScript to update a div" for three years, it's like you've been proven right. Your hero was noticed by a big company. 🎉

But a research hire is not an endorsement of your architecture choices. Companies like GitHub have R&D teams specifically to hedge bets and explore alternatives. That is the purpose of R&D. They do not intend to rewrite github.com in HTMX in the next quarter.

→ One hire does not equal a technology shift.
→ R&D teams explore dozens of directions, most of which go nowhere.
→ GitHub investing in HTMX research says "interesting" not "winner."

It's quite embarrassing to see you using this to respond to React developers mentioning you. Please stop.

The React Dismissal Is Equally Delusional

On the other side, I've seen React devs acting like this is meaningless. “It’s just corporate charity.” “They’re only paying him to maintain the project, nothing else.”

That's nonsense. GitHub wouldn't pay for R&D teams if they didn't think there was value there. They clearly see something worth investigating in the hypermedia approach. Maybe they're only interested in certain aspects. Maybe it's for specific parts of their product where a lighter touch makes sense. Either way, they're taking it seriously enough to pay for it.

→ Dismissing HTMX as a toy ignores real problems it solves.
→ Not every UI needs a virtual DOM and a state management library.
→ Server-rendered HTML with sprinkles of interactivity is a legitimate pattern.

If your response to this news is "lol who cares," you're telling on yourself. You have not considered the tool. You've only chosen a side.

This Is Just Corporate R&D Hedging

Based on what I see, GitHub is a large platform with various components, and different parts have different requirements. While some features may require a complex client-side framework, others could function well with a more simplistic approach like HTMX that reduces the overall complexity.

Smart companies don't marry one approach forever. They explore. They experiment. They keep options open. That's boring and reasonable, which is exactly why nobody wants to hear it. 😅

The real lesson here isn't "HTMX good, React bad" or the reverse. It's that the industry is slowly accepting what senior devs have known forever: pick the right tool for the specific problem. Sometimes that's React. Sometimes that's HTMX. Sometimes it's a plain HTML form with zero JavaScript.

The Actual Takeaway

Let's not associate frontend tool choices with political affiliations. The news that Carson Gross was hired by GitHub is intriguing. It indicates that the hypermedia approach is valid enough to demand serious consideration at the enterprise level. It doesn't mean React is obsolete, your SPA is legacy code, or you should rewrite stuff. Just relax. 🧊

What's your honest take — have you actually tried HTMX on a real project, or are you just vibing with the discourse?

AI didn't devalue senior engineers. It exposed the ones who were never senior.

Aditya Agarwal — Tue, 02 Jun 2026 13:09:27 +0000

The panic about AI replacing senior devs isn't exposing a technology problem. It's exposing a title problem.

Every few weeks, there's a post where someone is very excited about how AI coding assistants can now scaffold entire microservices, write a sorting algorithm, and produce boilerplate faster than any human. And it always concludes with: Senior engineers are toast.

I believe it's actually the opposite.

The title inflation reckoning

Lately, more and more engineers have been discussing the issue of title inflation. When you spend five years writing CRUD endpoints, you get that "Senior" title simply because you managed to stay at the company long enough. Not because you actually advanced.

That's not seniority. That's tenure.

And when an LLM can do the exact same CRUD work in 30 seconds, the gap between "senior by title" and "senior by capability" becomes impossible to ignore. The beginner has 30 seconds to learn something new, after all. It just made it visible.

What AI can actually replace

Let me be honest about what AI coding assistants are genuinely good at right now.

→ Scaffolding services from well-known patterns
→ Writing algorithms that exist in training data
→ Generating tests for straightforward functions
→ Translating between languages and frameworks

That's right. That's amazing. And if that was your entire job, then yes, you should be nervous.

However, the point is that it was never intended to be the only thing a senior engineer did. If this ended up being the case in your situation, the title was actually performing better than you were.

What AI still can't touch

The engineers I respect most spend their time on stuff that doesn't fit in a prompt.

→ Deciding what to build, not just how to build it
→ Making architectural tradeoffs that won't blow up in 18 months
→ Mentoring junior devs through their first production outage
→ Saying "no" to a feature that looks easy but creates hidden coupling
→ Navigating ambiguity when the requirements are a mess

Such decisions cannot be made based on abstract, impersonal and context-free factors. They require context about your system, your team, your business, and the failures you've already lived through.

No other model possesses that background. No other model has the same scars as you.

The real senior engineer job description

I believe AI is actually making it clear what seniority was meant to be about from the start. It should never have been about how fast you type or how well you memorize API signatures.

Being a senior means you can hold the entire system in your head. You remember which corners were cut and for what reasons. You can look at a suggested design and feel the future production incident hiding in that design.

That skill comes from years of making mistakes and learning from them. It's not something you get from a title bump during a performance cycle.

This is good news, actually

If you are a senior engineer who has been performing truly senior roles such as architecture, mentorship, system design, and cross-team alignment, artificial intelligence has just made you even more valuable. Because now you have a tool that can take care of the mundane aspects while you concentrate on the challenging responsibilities.

If you're a senior engineer who's been coasting on the title while doing junior-level work, AI didn't devalue you. It just stopped overpaying for you.

That's uncomfortable. But it's not unfair.

The engineers who'll thrive aren't the ones who can out-code a model. They're the ones who know what to build, when to say no, and how to bring a team along with them. That's the real deal. It has never changed.

So here's my question: has AI changed what you actually do day-to-day as a senior engineer, or did it just change what you're expected to do? I'd love to hear how your role has shifted — or hasn't. Have you found yourself handling more of the "soft" or human-centric work as algorithms take on some of your previous responsibilities?

Copilot doesn't make juniors dumber. It makes seniors lazier.

Aditya Agarwal — Mon, 01 Jun 2026 16:09:42 +0000

Everyone blames AI coding tools for ruining junior developers. Nobody talks about what it's doing to the seniors.

I've been thinking about this for a while. The dominant narrative is that Copilot is creating a generation of developers who can't code without autocomplete. But I think we're looking at the wrong level of the org chart.

The real problem isn't generation

As of November 2023, GitHub Copilot counted with more than 1.8 million paid subscribers. There are immense amounts of developers relying on AI code every day.

Research indicates that AI assistants can increase a team’s written output but not necessarily its quality. Let’s assume that sinks in now. The additional volume of code that is less optimal must be identified and fixed somewhere. And that somewhere has always been assumed to be in the code review.

Seniors are rubber-stamping AI slop

This is what I continue to notice. A junior opens a PR with Copilot-generated code that mostly works. The senior reviewer skims it, sees it passes CI, and hits approve.

Prior to Copilot, that identical senior would have detected the strange abstraction. They would have identified the function that does three things. They would have highlighted a comment outlining why the solution was incorrect, rather than just that it was wrong. That comment served as the complete mentoring system. 🔥

Now? They too are feeling the pressure to ship sooner. They're glossing over the details because the AI handed them an implementation that was "close enough". They're also skipping the deep thinking because the AI gave them something "good enough." The review becomes a formality.

Speed is the wrong metric

The conversation around AI coding tools has shifted from "will it replace us" to "is it degrading our skills." But even that framing is too broad.

Junior developers who are utilizing Copilot are not yet an expert. They're reading the suggestions, accepting some, rejecting others. They're building intuition, even if it's a different kind of intuition than we built.

Seniors using Copilot are unlearning. They already had the deep knowledge. They already understood the tradeoffs. Now they're outsourcing exactly the kind of thinking that made them senior in the first place.

→ A junior who accepts bad AI code doesn't know better yet. That's expected.
→ A senior who approves bad AI code does know better. That's erosion.
→ The junior loses a learning moment. The senior loses a muscle they spent years building.

The mentorship gap is the real cost

The most experienced senior colleagues I've had the opportunity to work with approached the code review as if they were teaching something. For them, each Pull Request was an opportunity to pass on knowledge. Every remark was a small masterclass on design, naming, edge cases, or system thinking.

When seniors stop doing that work, juniors don't just miss one lesson. They miss the entire feedback loop that turns them into future seniors. That pipeline breaks silently. You don't notice it until two years later when nobody on the team can debug a production issue without asking ChatGPT. 😅

This isn't an anti-Copilot take

I rely on AI coding tools. They're really helpful for boilerplate code, experimentation, or when you're stuck. I'm not saying we should do away with them.

I am here to say that being a senior developer is not a job that will be automated away, because the hard parts of being senior were never the parts a computer could do. It was not about typing speed. It was about judgment, and mentorship, and staying "no, this isn't good enough" when the CI is green.

Copilot doesn't make juniors dumber. It just becomes dangerously easy for seniors to refrain from the work that made them seniors in the first place. And that's the quiet part out loud. 🎯

So here's my question: has AI tooling changed the depth of code reviews on your team? Are seniors still teaching through PRs, or has review become a rubber stamp?

AI coding assistants make junior devs faster and worse at the same time

Aditya Agarwal — Sun, 31 May 2026 13:09:59 +0000

Copilot gives juniors the speed of a mid-level dev with the judgment of an intern. That's not a compliment to anyone involved.

I have been assessing PRs submitted by junior developers for some time now, and I noticed a change in the last year. The code appears to be more neat. It is delivered more quickly. But when something breaks, the person who wrote it often can't explain what it does.

The Speed Trap

AI programming helpers such as GitHub Copilot are truly amazing. A junior developer can set up the structure of a new feature in a few hours whereas it would have required them a week to implement it two years ago.

But speed without understanding is just technical debt with a bow on it. The code gets merged, the ticket gets closed, and nobody notices the problem until production does.

Here's the recurring pattern that I've noticed:

→ Copilot generates subtly incorrect code that passes superficial review
→ The junior dev can't spot the issue because they didn't write the logic themselves
→ The senior reviewer skims it because it looks clean and idiomatic
→ A bug ships that nobody on the team fully understands

This isn't hypothetical. It's Tuesday.

The Fundamentals Gap

Research has indicated that AI-suggested code is more likely to contain security errors. That tracks with what I'd expect when the person accepting the suggestion doesn't fully understand what it's doing.

The concerning aspect is not the existence of bad code, but the potential of having juniors who've never bothered to learn the fundamentals because the AI just writes seemingly working code for them on the first instance. Why learn how async error handling actually works when Copilot provides you with something that passes the tests? 🤷

Well, the simple answer is that tests cannot cover every single use case and potential issue. And when the thing Copilot wrote fails at 2 AM, you need someone who can actually read the code, not just someone who can prompt for a fix.

I worry we're creating a generation of developers who can ship fast but can't debug what they shipped.

This Isn't an Anti-AI Take

I rely on Copilot. I enjoy using Copilot. It saves me real time on boilerplate and helps me think through approaches faster.

But I already know what good code looks like. I can somehow tell when a recommendation is not quite right. That instinct comes from years of writing bad code myself and learning from it the hard way.

Juniors haven't built that instinct yet. And if AI removes the struggle that creates that instinct, we have a real problem. It's akin to handing out a calculator before you understand the concept of multiplication. They will receive responses. They just won't know when the answers are wrong. 🎯

What Actually Helps

I'm not suggesting AI tools should be off-limits for junior devs. It wouldn't work and might even have the opposite effect.

I believe that teams should plan for this to happen.

→ Require juniors to explain AI-generated code line by line in PR reviews
→ Pair program on the debugging, not just the building
→ Create space for juniors to write ugly, slow, manual code sometimes — that's where learning lives
→ Treat Copilot suggestions like Stack Overflow answers: useful starting points, not gospel

The goal isn't slower development. It's making sure the person behind the keyboard is actually growing, not just the codebase.

The Real Question

AI assistants aren't going away. They're going to get better. The developers who thrive will be the ones who used AI as a tool to accelerate learning, not a shortcut to skip it.

Those students who simply coasted through their initial couple of years by copy-pasting code and not really comprehending what they were doing? They are going to face a formidable obstacle. And they won't have the skills to debug why they're stuck. 😬

How is your team handling AI assistants with junior developers? Are you seeing the same patterns, or am I overthinking this?

Senior developer" after 3 years is title laundering

Aditya Agarwal — Sat, 30 May 2026 19:16:30 +0000

Startups hand out senior titles like candy. The industry pays the price.

I have been doing interviews for about a year now, and I cannot escape this pattern. Someone denotes themselves as a “Senior Engineer,” they have some number of years of experience—perhaps three—and they cannot provide an intelligent explanation of how a basic concept works, e.g. database indexes. This is not a fluke. It’s an epidemic.

The Numbers Don't Lie

Based on data from levels.fyi, on average, it takes between four to seven years to be promoted to a senior engineering position at a FAANG company. For startups, the average is three years, and in some cases, two years.

That discrepancy is not due to rounding numbers. That's a completely different definition of the same word.

Startups resort to this approach for obvious reasons. Since they cannot offer competitive salaries, they use titles as a competitive advantage. For instance, a 25-year-old engineer who would be hired at Google as L4 gets the title of “Senior Engineer” in a 15-person startup. This is a win-win situation as it doesn’t cost anything to the startup and the employee feels like getting a promotion. The real problem surfaces once this engineer decides to leave the startup and look for a new job.

What "Senior" Actually Means

The title isn't about writing code faster. It never was.

A senior engineer mentors juniors without being asked. A senior engineer pushes back on product when the proposed timeline is fantasy. A senior engineer makes architectural decisions they'll have to live with for years and accepts that responsibility.

Here's what I see instead from many three-year "seniors":

→ They can build features but can't design systems
→ They defer to product on every technical decision
→ They've never mentored anyone because the startup had no juniors
→ They've never navigated a codebase they didn't build from scratch

It's not their fault they haven't had enough practice, but the title implies that they have.

The Hiring Problem Is Real

Hiring managers complain about this all the time. The disconnect between title and skills is one of the largest offenders of time when it comes to technical recruiting.

You advertise a senior role and receive an overwhelming response with so many applicants. A substantial portion of those applicants is using the term "Senior" with less than four years of experience. Since you cannot automatically rule out candidates based on their years of experience as some tend to progress quickly, you end up wasting a lot of time interviewing them all only to realize that they are, in fact, mid-level engineers with a senior title on their resume.

The candidates are also at a disadvantage. They attend a senior interview, are questioned about system design and leadership, and have a negative impression. They are not to blame. They were put in a losing position because the title implied they would be offered a role based on their experience. 😕

This Is Title Laundering

It's called title laundering because that's essentially what's happening. A startup creates a title with no industry-standard justification. The engineer brings that title to their next job. The new company either grants the title as is or has to verify it which costs them resources. The startup that created the title faces no repercussions.

It's equivalent to creating currency without a central bank. But, in the end, inflation renders the money useless.

The impact is evident. "Senior" means so little now that some companies have started ignoring titles entirely and testing everyone from scratch. That's arguably fairer, but it's also exhausting for candidates who genuinely earned their level. 🎯

What Would Actually Help

I don't have a silver bullet. But a few things would move the needle:

→ Startups should use titles like "Engineer II" instead of borrowing prestige from "Senior"
→ Engineers should be honest with themselves about where they actually are — title ≠ skill
→ Hiring managers should normalize asking "what did senior mean at your company?" without it feeling like an attack

The best engineers I know don't care about the word on their LinkedIn. They care about the work. The title is supposed to be a shorthand for capability, and right now that shorthand is broken.

So Here's My Question

If you got a senior title early in your career, did it help you or did it set expectations you weren't ready for? I'm genuinely curious — drop your experience below. Tell us!