DEV Community: Aditya Agarwal

Reviewing AI code from juniors is slower than writing it yourself

Aditya Agarwal — Wed, 02 Sep 2026 10:26:16 +0000

The junior's pull request appeared fantastic. They had made clean commits, maintained a tidy structure, and all the tests were passing. But after starting to read it, I couldn't put it down for three hours as I rewrote almost the entire thing in my mind.

The productivity lie

We keep saying AI made everyone faster. What it actually did was move the hard part somewhere else. Writing bad code used to be slow. The code now comes quickly, comes confidently, and is wrong more often than it is right. The slowness has not disappeared, it has just moved to my email inbox. As Porter, an expert quoted in a 2026 CIO.com report, noted: "If there's a bottleneck in the process, it becomes less about writing the code and more about checking the code that's been written."

The numbers are brutal

It's not just old people complaining. The data supports it. In July 2025, Faros AI monitored more than 10,000 developers on 1,255 teams. Individual output jumped hard: 98% more PRs, 154% larger PR sizes. It seems like a success. However, the time it takes to conduct reviews increased by 91%. Having to write more code, more complex code that requires double the time for testing, is not a productivity improvement. It simply shifts the cost with a nice image. Uplevel Data Labs actually analyzed nearly 800 engineers using Copilot in September 2024. Found no significant change in PR cycle time or throughput. But 41% more bugs were shipped into the repos. 😬

Why it's worse than junior code

A junior who writes something wrong typically writes it in a timid fashion. The uncertainty is palpable. AI produces inaccurate information with great confidence. A study conducted at Purdue University in August 2023 examined the responses provided by ChatGPT to 517 technical questions from Stack Overflow. 52% were factually incorrect. What's even more frightening is that 39.34% of the time, people chose AI answers because they were more confident, believing they were more likely to be correct, and didn't notice the errors unless they actually copied the code and tested it in an IDE. So now I have to test everything by myself. It's almost the same amount of work as writing the code. Lisle, a software engineering leader, also captured that dynamic well in the same CIO.com piece: AI is, he said, "like having a junior developer who can write a very large amount of code very quickly... it doesn't understand the code and the broader context. It often does the opposite of what you ask it to do."

The trust gap nobody wants to admit

A Sonar survey from January 2026 polled 1,100 IT professionals and found that 96% said they do not have complete trust in code produced by artificial intelligence. Almost 40% of the respondents indicated that it requires higher effort to review AI code compared to that of their human colleague. Think about it for a moment. The tool that was intended to save time for reviewers has actually resulted in increased costs in terms of reviewer time. Additionally, technical debt has been accumulating directly within the codebase. GitClear analyzed hundreds of millions of lines. Code churn more than doubled from a pre-AI baseline of 3.3% to a projected 7.1% in 2025. API evangelist Kin Lane put it in simpler terms saying "I don't think I have ever seen so much technical debt being created in such a short period of time during my 35-year career in technology."

What I actually think

The bickering between generations about who is more adaptable, veterans or juniors, is misguided. The underlying change is about determining who bears the cost of being overly confident and incorrect. Here's what I can't stop thinking about:

→ AI didn't make juniors productive. It made their output harder to verify. → Volume went up. Trust went down. Someone has to reconcile that, and it's the reviewer. → "Faster to write" and "faster to ship" are not the same sentence. I don't oppose AI. In our small group, it is very helpful for the mundane tasks. I used to act like a PR full of generated code was almost done. That's the easy part. The real productivity hack is that we simply shifted the workload to the one person who couldn't turn it down. So, let me ask you. When you are going through the code that is generated by AI and that has been written by a colleague of yours, are you reviewing the code or making silent modifications to it? If the latter is the case, then who can be considered as the real author of that code?

Standby pay at $3 an hour is a wage for owning your whole evening

Aditya Agarwal — Tue, 01 Sep 2026 19:13:00 +0000

Three dollars an hour to not drink.

That's the going rate for owning your entire evening. You can't have a beer. You can't drive two towns over. You can't take a nap so deep you'd miss the phone.

The thing nobody wants to price

Being on call is not work, but it's not vacation either. It's the perfect balance.

You are not under the influence of alcohol. You are close to your house. You can get to your worksite within thirty minutes.

I often come across the same argument sparking up on the internet. A person shares their $3-4/hr standby rate and questions if it's acceptable.

Some say taking a small stipend and 1.5x-3x when you are actually paged is fair. Others say you've essentially been convinced to rent your freedom for the cost of a cup of coffee. ☕

The law already decided you lose

Here's what is painful. A decision was made by the legal system on this issue many decades ago, and it was not in your favor.

According to 29 CFR §785.17 you can break on-call time into two categories. "Engaged to wait" means it's paid time. "Waiting to be engaged" doesn't have to be paid, unless you end up working.

The 1944 Supreme Court case Skidmore v. Swift & Co. established the test for how much control your employer has over your time to determine which bucket you land in.

That may seem reasonable. However, in reality, it is not.

For example, in a 1999 Seventh Circuit case, rural Wisconsin EMTs weren't entitled to be paid their entire regular salary for being on call when they had to stay completely sober and report to the hospital within seven minutes.

Please read that one more time. A combination of complete sobriety and being on a leash for seven minutes was considered not to be a severe enough limitation to be qualified as work.

The receipts

This isn't theoretical. The dollar figures are almost comically consistent across totally different jobs.

→ In January 2024, IBEW Local 1245 bumped standby pay from $2.28 to $3.00 an hour. That was the win.

→ During a November 2023 Stockton utility strike, Rex Benedict, a collections systems operator of 17 years, said workers were forced onto off-hour standby for $3 extra an hour.

→ In Hooksett, New Hampshire, a 2026-2029 DPW contract raised standby from $10 a day to $15 a day. For a 16-hour off-shift, that's under a dollar an hour.

→ In an August 2026 forum, a registered nurse described her on-call arrangement, noting she is paid $3/hour for standby time and 1.5x her normal pay if called in. Same story across multiple hospitals, multiple states.

→ A Michigan worker reported $3.40 an hour with a strict 30-minute response window.

Nurses, linemen, EMTs, public works crews - disparate professions, but they all have one thing in common.

Three bucks an hour is what a restricted evening costs when the buyer sets the price.

What we're actually arguing about

The idea of receiving a stipend plus 1.5 times that amount if you're paged may seem fair, but it undervalues one thing - your time on call waiting to be paged.

What they are paying for is that reassurance of having a human on call at 2 am who will be sober and ready to respond. This assurance is extremely valuable to them, but is not reflected much in your paycheck.

In the tech world, we essentially do the same thing, but we have more comfortable chairs. On-call rotations, getting alerts from PagerDuty, and being told to "just make sure you have your laptop nearby this weekend" is the same leash in a fancier case.

The counterargument carries weight: if you're not actually doing anything that causes things to break, why should you be paid the full amount? Fair enough. But then acknowledge that the employer is in fact asking the worker to work unpaid and patting itself on the back for its generosity when it throws the worker three bucks.

Time that is limited but unoccupied is work. You surrendered your night. Someone else invested it. The only question is whether you were compensated with a salary or a souvenir.

What is the lowest standby rate that you have uncomplainingly agreed to, and will you do it once more? 👀

Retries didn't make GitHub resilient. They DDoS'd it.

Aditya Agarwal — Sun, 30 Aug 2026 19:11:08 +0000

A capacity blip at GitHub resulted in an outage that lasted 7 hours and 47 minutes. The infrastructure recovered faster than the clients let it. 😬

What actually happened

GitHub experienced issues on August 17, 2026, from 13:28 to 21:15 UTC. Users were facing problems with Git operations, Actions, Issues, PRs, and Copilot. The error rate for Web and API traffic was around 20%, while for archive and raw-content downloads it was approximately 50%. The root cause of the issue was almost mundane, an Istio sidecar proxy reached its concurrency limit. Here's the nasty part. GitHub's autoscaling monitored the metrics of the host application, not the sidecar's proxy saturation. Therefore, the system detected everything as "normal" while the proxy was overloaded, and no new instances were deployed. Traffic overflowed, causing four HAProxy nodes to exceed their capacity limits, and subsequently degrading the gateway. It was a rough afternoon. However, it's fixable. What made a blip a saga was the following. ## Retries didn't help. They piled on. A hidden bug in the VS Code Copilot extension caused clients to excessively re-request auth tokens from the Copilot Token Service. Backend errors were returned, and the clients then did the "resilient" thing. They tried again. Right away. Over and over. The Token Service typically processes 7,000 to 9,000 requests per second. However, at the time of the incident, it received 70,000 to 100,000 RPS. This means 8 to 14 times the normal amount of traffic, specifically targeting infrastructure that was attempting to recover. In the blog post, GitHub CTO Vlad Fedorov provided a simple explanation: backend errors that "triggered a client-side retry loop that increased traffic during recovery."

They actually made the problem worse. This really frustrates me. It's as if we consider retries to be a measure of resilience. We just add a retry, release the product, and then we don't worry about it. However, an inexperienced retry loop will simply be a self-denial of service attack, albeit with good intentions. Each client that "helpfully" retries is one more member of the botnet that you, yourself, are funding. ## Why the default retry mindset is a trap

The mental model is incorrect here. What people generally perceive a retry to be is a "try again because this time it will most likely work" action. On a large scale, retrying an action on a system that is already overloaded is like adding more burden to it. Failure doesn't result from trying again, but from trying again with no limit and no pause in between. → No budget: clients retry unlimited times, so load has no cap. → No jitter: everyone retries on the same clock, so requests arrive in synchronized waves. → No backoff: retries fire instantly, so a struggling service never gets breathing room. Recovery processes require some slack to function. Simple retries consume all the slack as soon as any failures occur. ## The fix is unglamorous and it works

Firstly, implement budgets to retry the operation. Secondly, use backoff with jitter to delay repeating the operation. This is the pattern. A retry budget limits the number of retries as a percentage of your actual traffic. For example, "the retries should not be more than 10% of the requests." When you reach the limit, retries are no longer performed, and failure is immediately returned. That single rule would've capped GitHub's Token Service surge instead of letting it hit 14x. Backoff with jitter manages the timing. Backoff spreads retries out so a damaged service has a chance to recover. Jitter randomizes the wait time so that clients don't all retry at the same time.Even if jitter is not applied, exponential backoff can still cause thundering herds, since every client waits the same fixed interval and then retries at the exact same moment. All of this is pretty basic stuff that you can find in any good book on distributed systems. Let's face it, resilience is a joint effort between the client and server. A "resilient" client turning a blind eye to the server's suffering is simply a well-mannered adversary. ## The takeaway

Retries should not be seen as a safety net that costs nothing. Unplanned retries can actually put additional strain on your infrastructure when it's already struggling. If you can retry something immediately and for free, you have a bug, not a resilience pattern. Here's a question for you: take a look at your own client code right now. Is there a budget and jitter in your retry logic, or did you simply put the call in a loop and declare it to be "resilient"?

Meta reassigned engineers to data labeling and the good ones walked

Aditya Agarwal — Sun, 30 Aug 2026 10:33:39 +0000

Losing your best employees doesn't always happen through direct action. Simply de-soul the job. Meta learned this the hard way, and the receipts are ugly. ## What actually happened

From March to June 2026, Meta relocated approximately 6,500 engineers and product managers to a new data labeling unit, Applied AI, representing 30% to 50% of staff on some core product, infrastructure, and security teams. They were not junior employees, but rather the individuals responsible for constructing and operating Meta's infrastructure. Their new role? Creating coding puzzles, Evaluating AI-generated GitHub repos, and Doing RLHF grunt labor. Management's message was clear. "Transfers are not voluntary."

The context nobody says out loud

In 2025, Meta acquired a 49% share of data-labeling firm Scale AI for $14.3 billion, and its founder, Alexandr Wang, was appointed Chief AI Officer. There was a logic behind the reassignment. A decision was made that the high-cost senior engineers would be operating the low-cost labeling machine. Meta posted a net profit of $26.8 billion in the same quarter it laid off 8,000 people and drafted 6,500 more into labeling. It was not about surviving. It was about making a decision. 💸

Layoffs aren't what breaks morale

Everyone braces for layoffs. Instead, they bleed out slowly as the survivors look over their shoulders, lose focus, and underperform. The silent killer of a team is how you reward the ones who remain. Engineers who spoke to WIRED described the labeling work as "soul-crushing." One said the Applied AI unit had become a "gulag" where, thanks to the lack of meaningful work, "you have zero purpose in life all of a sudden."

They began to refer to themselves as "draftees". You've already lost your top talent if they describe their current role as "conscription", they just haven't put in their two weeks' notice. Leadership was also aware. CTO Andrew Bosworth mentioned during an internal "Tuesdays with Boz" meeting on June 2, 2026, that the AI reorg had been "atrocious" and that morale was "maybe not the worst it's ever been in 20 years here, but it's probably up there"

The quiet resignation wave

The headlines didn't capture what really happened after the forced reassignments. As documented by Gergely Orosz of The Pragmatic Engineer, top infrastructure and AI engineers who were reassigned started actively interviewing. They left for Anthropic, OpenAI, and Google. The good ones walked. Nobody fired them. After that, panic set in. Meta changed its longstanding policy of not engaging with departing staff. They began providing senior IC6+ engineers who were attempting to leave with one-time retainer equity grants, frequently $1M+ vesting over 3 to 4 years. Several engineers responded with a negative answer. Consider this. No amount of money could erase the experience of being conscripted into a job that you feel has no purpose. ## What I take from this

I am in charge of a small startup. We are fifteen people, with a limited budget, and surprisingly enough, there are no forced labor camps involved. I may not have the highest bid, but I can be the reason you don't have to waste your time and resent your effort. The lesson here could not be more simple:

→ People stay for the work, not just the paycheck. → Once you strip the purpose out, money becomes a bribe, not a reason. → The talent you most want to keep has the most options to leave. → How you treat survivors after a cut speaks louder than the cut itself. Meta could afford $14.3 billion for Scale AI and $1M retention grants. What it couldn't replace, of course, was the feeling that the job was a meaningful one. It is easy to retain morale with minimal costs, but very difficult to restore it once it is lost. My question to you is: Have you ever quit a job not because of the pay or a layoff, but rather because the work slowly lost its meaning for you?

GUIs should have been keyboard-first this whole time

Aditya Agarwal — Sat, 29 Aug 2026 10:12:18 +0000

A viral post set the internet ablaze last week with a straightforward proposition: GUIs ought to be entirely keyboard-driven. After that, everyone chose a side. Terminal loyalists against the point-and-click defenders, shouting over each other as if it were the end of August 2026 and nothing existed beyond that. 🔥

The war is the wrong war

Here's my take: the TUI vs GUI fight is a distraction. Whether your application presents itself in a terminal window or as an Electron type application that can run on a modern web browser, it doesn't really matter to anyone. What people are actually looking for is a tool that respects their skills. The true offense is not having graphical interfaces, but having graphical interfaces that make you suffer if you try to use the keyboard. You are familiar with those. You enter a search, locate what you need, and then you realize you must grab the mouse to click a button that could have easily been activated by pressing Enter.

The math nobody argues with

This is not about sending good wishes. There's a 46-year-old model that already settled it. The Keystroke-Level Model, built in 1980 by Card, Moran, and Newell at Xerox PARC, put actual numbers on interface friction. This model quantified the costs associated with interactions on an interface. For instance, a keystroke takes about 0.28 seconds. Using a mouse to point takes about 1.1 seconds. And moving your hand between the keyboard and mouse takes another 0.4 seconds. Add it up. Every GUI that takes your hand off the keyboard to make you reach for the mouse is a 1.5-second minimum tax. Homing plus pointing. It may sound insignificant, but when you actually have to do it repeatedly four hundred times in a day, it's not so small a task after all. According to Jakob Nielsen, power users can complete tasks in half the time when using keyboard shortcuts rather than navigating through menus. It's that simple.
→ Keyboard-first isn't nostalgia
→ It's the interface refusing to waste your time
→ The mouse is a great tool, just not for the thing you do 400 times

The best apps already figured this out

Do you notice anything? The tools that people truly enjoy using are designed with the keyboard as the primary focus, but surprisingly, they are not traditional terminals. In 2005, Apple sent out Spotlight with Cmd+Space. Then Slack popularized the in-app command palette after a developer built a quick-switcher by exploiting a Slack XSS vulnerability during a 2014 hack day and passed it around the company. The Cmd+K shortcut is used consistently across various tools and applications such as GitHub, Discord, Figma, Notion, and Spotify. These applications have a graphical user interface but are designed to be efficiently used with the keyboard. Exactly. They are GUIs that no longer punish your hands.

When the app dares you to touch the mouse

Superhuman pushed the boundaries even more, I gotta give them credit for that. The founder, Rahul Vohra, purposely designed the app "to be deliberately a bit annoying to use with the mouse." The mouse friction of the app is a feature and not a bug. It pushes you towards keyboard shortcuts whether you were planning on learning them or not. The May 2026 internal data also shows that users actually respond to 72% more emails within an hour and save over four hours a week. That's an entire movie and a nap! Linear has been doing this since the very beginning. Every action you can take has a keyboard shortcut. Karri Saarinen, Jori Lallo, and Tuomas Artman designed it that way, and they were able to turn a profit in 2021 by creating a tool that developers open almost involuntarily. None of these are TUIs. That's the part the entire debate has been overlooking.

What this actually means for the stuff we build

I develop software with a small group, and this made me reconsider how I perceive our product. We no longer inquired if this should be something terminal. That was irrelevant. The real question became, could a user perform a frequent action without the need to exit the keyboard. In most cases, the answer was no, and it was painful. That's why we first optimized the common paths, introduced a command palette, and kept the uncommon things to the mouse as it should be. Because that's the fair split. Rare actions can hide behind a click. Common actions that have you reaching for your mouse/trackpad every time? That's just a slow tax you're imposing on your power users. 💀

It's not a religious issue whether or not power users should be respected. It's about ensuring that the users who engage the most with your product don't have to pay a 1.5-second toll repeatedly. The reflexive hostility to the GUI that a lot of them have - sentiment that's often justified, but sometimes it goes too far - comes from repeatedly feeling a hand on their shoulder. Here's something to think about: which app do you use daily, and do you feel like it could be twice as fast if it just allowed you to hit the Enter key?

Tying bonuses to badge swipes is how you teach people to game you

Aditya Agarwal — Thu, 27 Aug 2026 10:13:03 +0000

The interns discovered the cheat code earlier than the bosses realized that there was a whole game to be played.

Someone shared that there would be a bonus multiplier based on badge swipes. The intern's optimal move was clear within roughly four seconds: swipe, purchase coffee, swipe out. 💸

You didn't measure presence, you measured a door

Let's be honest about something no one in that room ever seems to acknowledge. Swiping a badge isn't "an engineer doing focused work close to their peers."

Yes, a badge swipe simply opens a door.

When you add a bonus to opening the door, you're making it the goal. Not collaborating. Not shipping. Opening the door.

Once a metric becomes a target, it ceases to be a good metric.

The receipts are ugly

This is not just a concept. The monitoring systems have been integrated into evaluating performance and pay.

In June 2023, an internal Google memo from Chief People Officer Fiona Cicconi declared that badge swipes would be used to ensure three days in the office, with bosses told to "co-locate high-performing, low-performing, and average-performing employees" and managers "encouraged to incorporate badging, tool and resource logins" into reviews. By the end of 2025 and early 2026, Amazon was deploying dashboards that automatically highlight those clocking up the fewest hours as "low-time badgers" or "zero badgers" off a rolling eight-week swipe average.

Next, the money came into play. A survey conducted by ResumeTemplates in October 2024 asked 713 business leaders:

→ 18% of companies use badge data to dock bonuses
→ 12% let it hit base salary
→ 21% treat it as grounds for termination

According to the same survey, 60% of companies monitor employee attendance, and the most common method used is the employee badge. Hence, for the most part, companies are essentially evaluating employees based on their ability to walk through a door.

And the door is lying

We will most likely see a predictable outcome. In Owl Labs' 2025 report, 43% of hybrid workers were actively "coffee badging," and another 12% were waiting their turn.

That's true. The intern experienced coffee badging. You arrive, show your face, then vanish.

The data has been manipulated to a point where it cannot be considered true anymore. Occuspace provided numbers from late 2025 indicating that badge data on building occupancy is exaggerated by 15% to 20% due to hit-and-run swipes.

I'll repeat that in other words. Leadership decided on salaries based on an inaccurate amount. About a fifth lower. Then, they turned attendance into a game and can't believe employees are exploiting it to get compensated.

The surveillance war nobody wins

So the metric got gamed. Naturally, the response isn't "maybe the metric was dumb." The response is more surveillance.

For example, you can use tools such as CurrentWare, which costs $12/user/month, advertises the capability to "detect coffee badging" by monitoring your IP and MAC addresses; the exact hours your machine is latched onto the office network.

Think about that for a moment. You're essentially hiring a vendor to care for the emotional well-being of your engineer's laptop and its relationship with the WiFi.

This is the arms race that the thesis anticipates. If you use money as a proxy, you will not achieve the desired result. You will experience fraudulent activities, followed by MAC-address forensics, and then more sophisticated fraud.

The part everyone skips

No one leaves a job they love without a backward glance. John Frehse, head of global labor strategy at Ankura, is very clear on this. 'Coffee badging is a clear indicator of dysfunction in a workplace.' ☕

The coffee badge is a symptom of the underlying problem: The office isn't a good enough place to be, so rather than work out how to make it better, people optimize for looking "most of the office" rather than actually being in the office.

Instead of investing in tracking down MAC addresses at $12 a head, why not examine why people don't show up and reward that.

The metric was always a proxy for something tangible: individuals working on projects collectively. If you reward the proxy, the tangible asset no longer matters, and everyone concentrates on optimizing the proxy.

Takeaway

Adding a monetary value to anything changes it from a measurement of reality to a measurement of motivation. The interns simply happened to read the spec more quickly than you could put it down.

If you cannot quantify "great work happening in the room," should you even be paying for the room, or for the work?

What's the most obviously-gamed metric you've watched a company defend with a straight face?

The 2 a.m. AI interview is how companies stopped interviewing back

Aditya Agarwal — Wed, 26 Aug 2026 10:25:13 +0000

Last month I had a job interview at 2 a.m. The interviewer didn't blink, didn't nod, and didn't let me ask a single question back. Well, the room was empty. Except for an AI avatar and a countdown timer. ⏱️

The "convenience" pitch is doing a lot of work

Here's the pitch. In August 2026, CodeSignal CEO Tigran Sloyan described the AI interviewer to Forbes as "a massive time advantage to candidates who are currently employed, in a different time zone or have family commitments."

That sounds good. Maybe flexible. Humane perhaps. According to CodeSignal, one out of every three candidates completes their AI interview outside of regular business hours. According to Ribbon AI, 25% of interviews it books are scheduled between 10 p.m. and 2 a.m. local time. When looking at its manufacturing clients specifically, that number jumps to 35%. People are expected to complete this task at midnight when they are exhausted and after their kids are asleep. And we consider that a win for them.

Read the marketing they don't show candidates

Convenience is the version that is for you. There is a version for employers as well. The 2026 marketing materials for Eightfold AI's "AI Interviewer" product said the loud part loud: "Candidates can start an interview the moment they apply. Even at 2 AM. You talk to talent before your competitors do."

Identify who "you" refers to. It's not the candidate but the organization trying to secure you before your competition does. That's the real issue here. Being assigned the 2 a.m. time slot is not something they do to accommodate your busy life. It's a strategic move to give them a clear upper hand in their sales funnel.

The one-way mirror

This is the real issue I have with it. An interview was never meant to be a one-sided test. It's like a dialogue where you evaluate the other person as they do the same to you. You can inquire specifically about the on-call rotation details. You get to observe the hiring manager's response when you really press them on how they're handling their technical debt. You get to see if they sidestep the "why did the last person leave this role" question. That's an advantage. That's the criterion you use to determine if they are worthy of you. An AI-generated character destroys all of it:

→ You can't ask the company anything real
→ You can't read a human's face for the truth behind the answer
→ You can't build rapport that tips a close decision your way
→ You get scored, not met

When a human isn't there, it doesn't mean that hiring is then fair; it just means that it's imbalanced. They have every mechanism to measure you, and they sneakily strip you of the only mechanism you have to measure them.

Candidates already smell it

I am not the only one giving up on the interview process. A report surveyed almost 3,000 job seekers to learn it was not just me. More than a third (38%) of U.S. job seekers have pulled out of an application because they learned AI would be used at some point in the process. A further 12% said they would automatically reject an interview if AI was involved. The most common reason people jumped off was "Pre-recorded video interviews scored by AI with no human present" at 33%. They were closely followed by no clear disclosure about how the AI is used at 27%. 70% reported that they had never been explicitly informed in advance that their evaluation would be done by an AI. 21% only found out after they logged in. Just picture yourself sitting down, expecting a person, and getting a countdown and a camera instead. 🙄

This isn't anti-AI. It's anti-ambush.

I spend all day with AI. I'm not here to tell you that the tech is malevolent. The issue lies in the intention behind the first round. Previously, it used to mark the beginning of mutual assessment. If a company is not willing to have an actual human interaction with me before I even get in the door and start putting in the time, why would I want to work for them? Because that is likely indicative of how they'll treat me once I'm an employee. I see it as an indication that the company may not be a good fit. The AI-driven initial interview isn't the problem, it's a symptom. Recruitment is meant to be a dialogue. But as soon as you turn it into a one-way process where the candidate cannot see through the mirror, you don't make it convenient for the candidates - you only show them who holds the power. Obviously a format that requires a 2 a.m. interview would be one you should walk away from - that's not showing the candidate any respect.

So where do you draw the line: would you sit through an AI interview, or walk away the moment there's no human on the other side?

Go 1.27 banning generic methods from interfaces is the honest move

Aditya Agarwal — Tue, 25 Aug 2026 19:14:02 +0000

This August, Go finally shipped with generic methods. However, right after they were released, Go slapped your hand and told you all the places you couldn't use them. Everyone is angry. I don't believe they're right. ## What actually happened

Version 1.27 of Go was released on August 19, 2026. This release includes the foundation necessary to support defining methods and functions within concrete types (specifically structs) using their own type parameters. However, there is a caveat that confused people. An interface cannot implement a generic method. In fact, interfaces cannot declare any generic methods at all. To make clear why that is painful to hear, you need some context. For roughly a decade the official Go FAQ flatly said: "We do not anticipate that Go will ever add generic methods."

Later in January 2026, Proposal #77273 was filed by Go co-designer Robert Griesemer. It was accepted by May and shipped by August. A decade of "never" turned into "yes, but."

The orthogonality complaint

This is the argument posited by the angry crowd. "In Go, methods and interfaces are intended to be two sides of the same coin."

When you write a method, some interface somewhere should be able to leverage it. That is the basic social contract of this language. But if you break it for generic methods, you end up with a feature that is isolated. 😤

And the people making that complaint are not wrong. It's a real thing. At first glance, it may seem like a betrayal, a partial feature, an added element that was restricted in order not to showcase the insufficiency of the entire type system. ## Why the ban is the honest move

Now, let's take a look at the actual statement Griesemer made in the proposal. "Maybe we should reconsider this: Concrete methods are a language feature that we want for its own sake, for reasons having nothing to do with interfaces."

That statement puts everything in a new light. He isn't sorry for the limitation. He's saying the feature stands on its own without the interface plumbing. The issue is not being too lazy to write generic interface methods. It's that generic interface methods would break the runtime in ways you'd feel later. If the language allows it, people will write explicitly generic methods, even if it breaks type inference. Go doesn't allow it because "it cannot be known at compile time which of the infinite possible instantiations of concrete methods will be needed at run time". Software engineer Corentin Giauque Saubert explained the implications in simple terms. Generic interface methods "cause type erasure to fail, lead to dynamic dispatch issues, and are incompatible with reflection."

The consequences of this design decision are already apparent in the current implementation. For example, in Go 1.27, generic methods will be invisible to the reflect package, as this information is not available at runtime. Consider this for a moment. If interfaces had the ability to contain generic methods, many of the reflection-based tools that you currently use would become obsolete, or would become much more complex to implement. ## Saying no is a design decision

This is the hot take that upsets everybody. A language saying no to a feature request the community is begging for, can sometimes be a sign of strong leadership and discipline, not a failure. It could have involved interfaces with generic methods, dynamic dispatch, and everything else. This would have appeared to work perfectly in a demo but caused issues in real-life usage over time. Instead, they delivered what keeps the language easy. Concrete generic methods that compile predictably and don't poison reflection. The complaints that orthogonality is broken are true. However, orthogonality is a method, not an end. The end is a type system that a regular person can keep in their mind. Every language eventually has to make this trade-off. Do you ship the nice-looking feature that leaks abstractions throughout your entire system or do you ship the slightly uglier, but more honest feature and then just take the downsides of that? Go took the downsides. ## The takeaway

I prefer a language that says "no, that costs too much" rather than one that says "yes" and hands me the bill three releases later. The generic methods ban isn't a crippled feature. It's a boundary someone was brave enough to draw. 🙂

So here's a question: Do you perceive a programming language that includes a feature with a built-in hard limit as a weak language, or as a language that is looking out for you?

Swift 6 turned working code into a compile error and iOS devs are furious

Aditya Agarwal — Mon, 24 Aug 2026 10:31:31 +0000

Everything was working perfectly fine in your application for multiple years. Then one day a simple configuration change of a flag resulted in over 20,000 warnings for you to handle. Welcome to Swift 6, where your working code yesterday is a compiler error today. ## The change nobody asked to be default

WWDC 2024 introduced Swift 6, which was then reinforced and solidified in 2025 and 2026. The main highlight of Swift 6 was default data-race safety, achieved by strict concurrency checks during compilation (and strict concurrency checking is now on by default). The pitch is actually good. The compiler now mathematically proves your code has no data races before it even runs. This is important because data races were a serious issue. According to Apple's WWDC 2024 sessions, they caused almost 30% of crashes in production iOS apps. This means that an entire category of Heisenbugs disappears. Theoretically, this is a significant advantage. Sendable closures and actor isolation don't play nice with code written before they existed.

Writing for Level Up Coding in December 2025, iOS developer Alok Upadhyay flipped the Strict Concurrency Checking flag on his team's largest legacy module and got 20,000 warnings, describing his screen as "a sea of red and orange warnings." Another common issue is referred to as "whack-a-mole". For example, on the Swift.org forums in April 2025, a developer mentioned that they added @MainActor to all classes to fix the errors and 50 more appeared. That loop ate half a week before the thing finally built. Three and a half days were spent verifying that code which had already been sent for production was correct. Also, you don't have control over everything. For instance, a developer porting Ditto Edge Studio in June 2026 observed that a single dependency "can hold your entire module hostage" if it's not ready for Swift 6 (even if your code is perfect). This was not an unusual edge case in the early days. In the June 2024 beta, roughly 42% of packages were reported as ready (1,500 of 3,400), but that number included a lot of packages that weren't using any concurrency code. ## But the payoff is real, and that's the annoying part

I want to dislike this rationally. I am unable to. An iOS developer, nicknamed "BB", ported three production apps to the new library, roughly 180,000 source lines of code in total. As of September 2025, he experienced a 41% decrease in crash rates and determined that actors contribute to only a 5 to 8% performance overhead under high contention. That is not a minor adjustment. It means less 3am notifications and fewer negative reviews for you. Mrugesh Tank, co-founder of idiotswithios.com, decided to switch on Swift 6 for a two-year-old-project in August 2026. The second he did that, he got bombarded with 60+ errors. At least a dozen were real bugs. Actual data races and actor isolation violations hiding in shipped code. The compiler wasn't nitpicking. It was actually detecting issues. ## So where does that leave us

Here's the stress I continue to experience:

→ The safety guarantee is legit and the bug it kills is expensive. → The migration cost is also legit and lands entirely on teams who already shipped fine. → Making it the default forced that bill on everyone at once, ready or not. That final point is what it's all about. 🔥

It's not necessarily a bad thing to invest three sprints to implement a safety feature. It's more of a compromise, where the cost is being covered by the teams whose applications were not failing due to data races anyway. Strict concurrency should have remained optional for a while longer, and the ecosystem should have been further along before forcing it as a build cost. Because "mathematically correct" and "worth it this quarter" are different questions. Are you going to flip the flag on a working legacy app today, or are you going to wait until Apple forces your hand?

Seven interview rounds is a confession that your bar is broken

Aditya Agarwal — Sun, 23 Aug 2026 19:12:29 +0000

If you have to go through seven interview rounds, it's not thorough process - it's a hostage situation. A company that needs seven conversations to decide on you is telling you it can't read a signal. So they're going to wear you down until you're the only one left.

What long loops actually measure

I heard about a person who completed seven interview rounds and then suddenly stopped hearing from them. Not declined. Ignored. Seven rounds of someone's life, and the reward was silence. 🫠

Hiring managers often try to justify long interview processes with the latest explanation being that it filters out candidates who rely too much on AI. Adorable anecdote. Unfortunately, that's not the type of thing a seven-round loop is filtering for. It screens out those who cannot or do not want to dedicate hours of their time to the process. The people you needed the most? They're gone too.

The people you actually want are already hired

An analysis conducted by Deloxe HR in August 2026 revealed that high-performing talent is hardly ever available on the market for more than two weeks. And an agile competitor can hire an exceptional candidate in nine days. In the meantime, your loop is still being scheduled for the third round. The situation becomes even more challenging when you consider that Deloxe HR's 2026 data models indicate that a seven-round loop, with there being five internal stakeholders and eight finalists, is burning $14,000 in billable internal hours for your role before they even jump into onboarding. These inefficient processes increased the Time-to-Fill from 30 to 75 days. As a result, you ended up paying more while also moving slower and attracting less qualified candidates. What you're describing is definitely a leak, not a filter.

Google already ran this experiment

Here is the section that debunks the argument that more rounds lead to more rigor. Google's People Analytics Team conducted research on five years of internal interview data. When four structured interviews are conducted, Google can predict whether a candidate will be hired with 86% confidence. Actually, any interview after the fourth is statistically redundant. Limiting the interviews to four reduced the time it took for Google to hire someone by two weeks. Google had fewer interviews but didn't give up any signal about the candidate, and got to a final decision faster. When a firm says that rounds 5, 6, and 7 are about "validating the decision," they're talking about kabuki. The information indicates the decision was made at 4.

Every extra round leaks candidates

The Loop doesn't simply fall short when it comes to measurement. It actually pushes people away. → The iCIMS 2025 State of Frontline Hiring Report found the interview stage now accounts for 32% of all candidate drop-off. More than application abandonment, scheduling, and onboarding friction combined. → The Cronofy 2024 Candidate Expectations Report surveyed 12,000 candidates. 42% abandon the process entirely because scheduling takes too long. → The 2023 UX Content Survey found 43% of respondents say "too many steps and too much free work and time" is the most broken part of recruiting for UX content work specifically. Read in tandem. Your longest, most "thorough" stage is where you lose the most people. It looks like you constructed a funnel that destroys itself when it reaches its widest point.

What this really signals

Every round you add to the hiring process piles on more cost for a small startup like mine, and by then the candidates have already walked away. I don't think long loops are romantic, a company that needs seven of them isn't being careful, it's outsourcing its indecision to the candidate. A truthful seven-round loop would be labeled: we don't trust our judgment, so we'll just wear you down instead.

Length isn't rigor. Length is doubt wearing a suit. If you achieve 86% accuracy after four structured rounds, rounds five to seven do not measure skill. They measure who is willing to be measured seven times. That sends a completely different message, and a negative one at that.

The takeaway

The longer the interview, the more likely it is you have no idea what you're doing. Fix the screen, not an endurance test. I have a question for you - what's the most rounds you've ever stayed for? And, did you learn anything new from the additional rounds that you didn't see in the first two rounds?

Postgres as your message queue is a SPOF you'll regret at 3am

Aditya Agarwal — Sun, 23 Aug 2026 02:17:03 +0000

At 3 am the pager is activated. Your queue is backed up, your database is on fire, and those two facts are the same fact. This is the trap nobody warns you about when they advise you to simply utilize Postgres for all your needs.

The hype has a new victim

The simple advice, "Just use Postgres" was very effective in the beginning. You didn't need a complex architecture involving six different services. It was enough to deploy the common monolith and you could rest at night. After that, the hype got out of control. Nowadays, individuals place their message queue directly into the database used by their customers. I see why people find it attractive. SELECT ... FOR UPDATE SKIP LOCKED allows you to reserve jobs with zero new infrastructure. No brokers, no ops, just one line of code. You just hid it inside your most critical, least replaceable component.

MVCC was not built for this

The downside you may encounter later on is that Postgres creates a new row for every update, but that's the nature of MVCC.

A queue can be likened to a table that you keep modifying. You claim a job, then modify the table.

Complete a job, again, modify the table. Retrying the job, once more, update the table.

Brandur Leach who used to be a Staff Engineer with Stripe, recently detailed this in his article "Transactionally Staged Job Drains in Postgres" . The result: table bloat, index fragmentation, autovacuum starved for air.

Gunnar Morling argued the same in his analysis from November 3, 2025, "'You Don't Need Kafka, Just Use Postgres' Considered Harmful": long-running consumer transactions will at some point inevitably lead to MVCC bloat and WAL pile-up, and vacuum just loses the race against the change rate.

Your queue is slowly damaging the database where it is stored.

The numbers are not close

I want to bring up throughput because this is the bottleneck in our fantasy.

On May 15, 2023, a benchmark indicated that Postgres-as-a-queue maxed out at approximately 660 messages per second using a 1KB payload, with a 38ms P95 publish latency.

RabbitMQ processed 25,000 messages per second in the same test environment. It was not twice as much, not three times as much, but nearly 40 times as much.

The managed options available are excessive. Regular Amazon SQS will provide high throughput almost without limit.

And if you need something more, FIFO SQS will achieve exactly-once processing with a ceiling of 3k messages per second or 30k in a batch.

You are opting for a tool that maxes out at 660 to steer clear of "complexity." Meanwhile, the dull cloud queue is scaling above and beyond you.

The SPOF nobody planned for

Now the 3am part. Everything is fine until your delivery process stalls.

AWS engineers actually sounded the alarm on this in a December 17, 2021 Architecture Blog post; an inoperable delivery process places backpressure on the database, which creates a feedback loop that results in even more failed work.

I'm sorry, could you please read that again? The queue failure and the database failure merge into a single event.

→ Your queue is down, so your app is down. → Your database is thrashing, so your queue can't recover. → Every worker retry makes both worse.

There is also a silent killer. For each connection, Postgres creates a new OS process.

Many worker nodes are constantly polling, claiming, and updating jobs. This results in continuous connection churn, which can deplete your pool, causing your user-facing queries to compete with the job runners for a spot.

A single point of failure was created by you, which was responsible for handling two tasks.

When it's actually fine

I'm not ruling it out completely. For minor internal tasks within the system or a sporadic background job, I guess it's okay. I think Postgres queues are amazing if you're not doing a ton of jobs per minute and you don't mind not having a broker. SKIP LOCKED is a beautiful thing. The issue arises when you assume that something that "works at low volume" will also "work at scale with production traffic." These are two separate assumptions, and the pager exists in the space between them. Here's a simple reality check. Would your database go down if your queue did? Then, you didn't create a shortcut; you built a SPOF. Well, if you have boring stuff, it might be the right time to offload it, right? What's your rule of thumb, when does "just use Postgres" cease to be common sense and become a problem you'll struggle to solve?

Polyglot persistence was the mistake. Postgres was always enough.

Aditya Agarwal — Fri, 21 Aug 2026 19:16:42 +0000

Four databases in one would be great if you had a reason for needing them.

That used to be our technology combination some time ago. It still causes me emotional pain when I remember. We had Mongo for handling documents, Redis for caching, Elasticsearch for searching, and then some obscure vector database for the new fancy AI features that every developer needed immediately.

We removed everything. Only Postgres is being used now.

How we got sold four databases

The justification was always based on using the most suitable solution for a particular problem. It may seem like a good engineering approach, but in reality, it just means that you will have to monitor and maintain four control planes.

It was Martin Fowler who coined the term back in November 2011, stating that "any decent sized enterprise will have a variety of different data storage technologies for different kinds of data".

That was reasonable in 2011. Back in 2011, Postgres lacked many of the features we required.

However, this motto remained relevant for longer than it should have. We continued to open new stores simply because some blog post recommended it, not because the data required us to do so.

The bill nobody warns you about

What was even more challenging than dealing with the costs on the cloud was that each store had its own backups, its peculiar way of scaling, and something different would fail at each of them at 3 am.

Once we migrated onto Postgres and consolidated our systems, not only did our bill decrease, but the operational overhead decreased significantly. This meant fewer issues to be alerted for. Fewer systems to constantly monitor. 🎯

But actually, it was a more subtle cost that convinced me to finally take the plunge. Tacnode's Alex Kimball coined the term back in March 2026: the "Retrieval Gap."

If one decision is reading from multiple stores, each read is reflecting a different point in time. You're assessing a composite state that has never really existed.

Consider this: Your cache stores some information, your search index stores different information, and your source of truth stores yet more information. Your code then accesses this information based on a specific moment's snapshot, which may not have ever been an accurate reflection of actuality.

Having a single database in place will also ensure that all processes are in sync and there are no discrepancies in time tracking. The effort put into migration will be worth it for this reason alone.

Postgres quietly ate everything

While we were off trying to weld four systems into one, Postgres went away and became an adult. A proper one.

In 2024, Feng Ruohang, creator of the Pigsty distribution of Postgres, penned "Postgres is Eating the Database World," in which he positioned Pigsty as "a data management abstraction framework with the potential to encompass everything and devour the entire database world."

That seems like an exaggeration, but when you see the reality of what was delivered, it starts to look like a fair description.

→ Vector search: In 2024, Timescale benchmarked Postgres with pgvector plus its pgvectorscale extension as faster than Pinecone and cheaper.

→ Queues: Tools like pg-boss (Node) and River (Go) run entirely on SELECT ... FOR UPDATE SKIP LOCKED. Postgres becomes a transactional message broker, no Kafka cluster required.

→ Workflows: In mid-2026, durable execution moved into the database. DBOS and Microsoft's pg_durable use Postgres transactions and advisory locks to run crash-safe workflows without a separate orchestration cluster.

The vector DB is gone. The queue system is gone. The search cluster is gone.

Stephan Schmidt, a CTO coach for over a decade now, wrote the original manifesto on this topic: "Just Use Postgres for Everything" (updated December 2025). His assertion is that with the right indexing strategies, Postgres will scale as far as you could ever want for Kafka, RabbitMQ, Mongo, and Redis use cases, and then some. Up to millions of users even.

Millions of users, that's not a toy ceiling, that's most of us, to be honest.

The part where I hedge (a little)

I'm not suggesting that specialized stores are bad in every case. For instance, if you're Google, you have problems that Postgres is not interested in.

Choosing a single-purpose tool in that situation was not the mistake, we really did need it. The mistake was going with four by default, funnelling everything through YAGNI and "the right tool for the job" because that felt like the more grown-up thing to do. The mistake was not being able to see that "just use the database" would have been the right choice.

Fragmentation comes at a daily cost. It's cheaper to use a slightly suboptimal index for one database than to have an optimal one that you can't analyze for four databases running separately.

The takeaway

Begin by using Postgres. Introduce a second store into your system only when Postgres has fallen over, and allow it to prove that it is. In many cases, it never will, and you've just saved yourself from the burden of a stack that you would've been developing, operating, and tending for the rest of your life. 🐘

Which store in your architecture are you secretly confident that Postgres could have managed from the start?