DEV Community: Aditya Agarwal

The 72-hour dependency cooldown is security theater that breaks your builds

Aditya Agarwal — Wed, 12 Aug 2026 19:35:21 +0000

Last week, the continuous integration pipeline I set up failed because a package that I had locked three weeks ago was no longer resolving in the same manner on my local machine. The solution? Just wait for 72 hours. Because that seems to be the approach to security these days. 🙄

The new gospel of waiting

Security teams think they have found the answer to supply-chain attacks: Time. Here's a simple suggestion: don't install a package as soon as it's released. Wait 72 hours so that someone else can discover the poison. The entire ecosystem quickly adopted it. In July 2026, GitHub implemented a default 72-hour cooldown for non-security Dependabot updates. Both pnpm and Yarn implemented minimum package age restrictions in September 2025. npm v11.10.0 added min-release-age in February 2026. Additionally, PyPI also took measures to protect against future typosquatting attacks. They decided to block the upload of new files to any release that was older than 14 days. Everything seems reasonable. It seems like adults are finally starting to consider the risk in the supply chain.

The math doesn't math

The unspoken truth is that... Most of the malware you are trying to avoid is eliminated even before your cooldown begins. Consider the major attacks in 2025/2026: Axios, s1ngularity, Shai-Hulud. All malicious packages were found and removed within a median of 14 hours. This window of 72 hours is sheltering you from a danger that would have perished already, by the 15th hour. You are essentially paying three days of opportunity cost to be protected from a fire that your sprinklers have already extinguished.

Attackers read the docs too

Delays do not merely inconvenience your opponents; they actually instruct them. Kennedy Toomey, an Application Security Researcher at Datadog, said it plainly in an April 16, 2026 report:

"Dependency cooldowns are not completely effective. If everyone starts using cooldowns, intelligent attackers can just wait with executing the malware and survive the cooldown. Code that doesn't execute on install takes longer to discover."

Read that twice. The countermeasure teaches attackers to just... wait longer. If you implemented a 72-hour gate, the adversary set a 96-hour fuse. Incumbent malware has now been engineered to hibernate throughout your entire safeguard timeframe and activate after you've patched. At the same time, the number of new open-source malware packages continues to increase. In fact, Sonatype discovered 394,877 new open-source malware packages in Q4 2025, which is 476% more than the previous three quarters combined. Taking a three-day break can't combat such a workload. It just gives you the illusion of being occupied.

What the cooldown actually costs

Allow me to share what's really happening, as I have firsthand experience. Our team is small. If we lose an hour to "why won't this install", that's an hour not spent on our product. And then, the codebase becomes inflexible. You end up pinning everything so hard, postponing any updates, and six months down the line you end up with a fossil dependency graph that nobody is willing to deal with. That's the deal. We lose a lot of speed. The consultancy Evil Martians summed up the feeling in their analysis from July 28, 2026. They urged not to "introduce tools just because it's safer," since this "makes processes slower and often gives a false sense of security without real risk reduction."

What I remember most is the expression "False sense of security". Because when a team feels safe they stop being vigilant and that's worse than speeding up and staying paranoid.

So what do you actually do

I'm not suggesting that you blindly install everything in the middle of the night. 🔒

What I mean is that we should select tools that detect harmful activities, and not tools that simply postpone an attack based on a pre-set time. Runtime scanning and behavioral analysis beat arbitrary time gates. Fast detection and revocation is where the 14-hour median comes from, so lean into that ecosystem. Pin for reproducibility, not for superstition, and keep a real update cadence. A cooldown could be used as one small indicator among a bunch of real defenses. As the headline policy, it's theater with good production values. The hackers have already changed their approach. The real question is, will your security staff? Or will you continue to pay them three days of agony to watch a magic act?

OpenAI buying Astral means uv now answers to a model company

Aditya Agarwal — Wed, 12 Aug 2026 10:31:57 +0000

Python packaging was finally solved, and the solution turned out to be a tool so powerful, user environment sanity isn't the only use case. It installs things. No more and no less than that.

OpenAI revealed its acquisition of Astral on March 19, 2026. The entire Astral team, with founder Charlie Marsh, joined the Codex org as a result.

The tool everyone already switched to

Allow me to provide some context for those who may have missed out on this information for some reason.

Former Khan Academy engineer, Charlie Marsh, founded Astral with the mission to reimplement Python's toolchain in Rust. Astral released uv, which is a drop-in alternative to pip, virtualenv, and pip-tools in February 2024.

The speed improvement was so significant that Astral commented that it wasn't just a "nice improvement", but it was in fact 10 to 100 times faster than the previous pip workflows.

The statistics support this. uv can resolve the Jupyter project dependencies in about 0.57 seconds when cold. Poetry takes around 7.59 seconds. When the cache is warm? Just about 20 milliseconds. ⚡

It caught people's attention. uv was already attracting over 126 million downloads monthly by early 2026, according to JetBrains.

When I use the term "conquered," I'm not exaggerating. uv didn't win a debate. It won over the most users.

Governance loses the race

This is the part that's meant to annoy you.

While uv was gobbling up the ecosystem, the community was otherwise engaged... trying to have a committee organize the ecosystem. PEP 772 proposed an elected Python Packaging Council, a real governance body for exactly these decisions.

The PEP remained under review for 14 months.

Compare those two situations as they unfolded in parallel. A product supported by corporate interests was released, improved, and became popular with 126 million monthly users before the city's elected officials even finished discussing its governance structure.

That sums it up. The town was writing a constitution. Astral was delivering binaries.

This is not meant as a criticism of the council people. Governance is intentionally slow and cautious. The problem is that slow and cautious will always lose to a fast product with actual distribution.

So who does uv answer to now?

This is what I keep wondering about.

For a couple of years, the response was "an independent startup that quite enjoys Rust." Okay, so startups have motives, but these were packaging-shaped motives.

The correct response would be the Codex team from OpenAI.

Just to clarify, uv is still going to be open source, and in the announcement Marsh said: "As part of Codex, we'll continue evolving our open source tools to push the frontier of software development." So I guess we'll have to take him at his word.

However, intentions and structure are different things. A large portion of Python's daily package installs is now being funneled through a technology owned by a monopoly corp. That is a dependency the community never approved.

OpenAI is an organization that adheres to a set of incentives in a world inexorably stratified by power and money.

→ The community built a democratic process. Astral built a product.
→ Only one of those decided who controls Python packaging.
→ Distribution beats deliberation, every time.
→ By the time governance catches up, the winner already has an owner.

The takeaway

We like to think that open ecosystems are self-governing and based on consensus. Here's a perfect example that this is not always the case.

It was the tool that won, not the governance body. Uv was a seriously good tool that outgrew the process and outcompeted the governance meant to steer it. Ecosystem governance doesn't lose to bad actors, it loses to good tools that iterate faster than committees can convene.

Here's what I'd like to know: if technology advances and how resources are distributed will always be ahead of the decisions made by elected officials, is there a form of local governance that can meet the pace? Or should we simply accept that the quickest and best-financed solution will prevail, and work from there?

Go error handling won and the if err != nil crowd deserves the win

Aditya Agarwal — Tue, 11 Aug 2026 19:26:47 +0000

The competition for the most used code snippet has a clear winner: if err != nil. Whoever wrote this ten thousand times should get the award.

A Medium post was published on August 9, 2026, which was a retrospective comparing a Go vs a Rust production backend rewrite. It re-ignited the oldest flamewar on the internet: is Go's error handling a wart or a feature?

The complaint everyone repeats

You've probably heard that Go is too wordy, if err != nil is just clutter, proper languages use Result and ?.

The complaint is further substantiated by the Go Developer Survey from April 9, 2024. 13% of the respondents indicated that "verbosity of error handling" was a challenge.

However, if you take another look at the survey, you'll see that Go has a satisfaction rate of 93%. 🤔

So 13% grumble about the typing while nine out of ten devs are happy. This is not a language "falling apart"; it is a tradeoff that people made on purpose and keep making.

The try() near-miss

Here's the part that slips people's minds. Go almost gave up.

One of the Go co-designers, Robert Griesemer, submitted Proposal #32437 on June 4, 2019, to include a built-in try(). With this, you would simply write f := try(os.Open(filename)) and all the boilerplate would disappear.

Sounds nice, right? The community disagreed hard.

On July 16, 2019, the proposal was closed and rejected. The feedback was overwhelmingly negative, and the people who work on Go every day took one look at the shortcut and said, "No, thanks."

That is unusual. The majority of languages rush to embrace sugar. The Go language users made a choice to retain the "annoying" thing because the "annoying" thing is effective.

Verbosity is the point

Let's go back to January 12, 2015 when Rob Pike said this in "Errors are values": "Errors are values. Values can be programmed, and since errors are values, errors can be programmed.."

That is the basic philosophy. An error should not be a magical control-flow escape mechanism. It is simply a value that needs to be managed at the point where it occurs.

Hiding an error behind a ? is saying "not my problem, bubble it up". Typing if err != nil makes you stop and decide. Wrap it. Log it. Retry it. Bail.

That verbosity is the point: I want to see every failure, not sweep it under a syntactic rug. The mantra in the Go community is "errors are values" and it's not uncommon to see functions in Go returning an error as their last return value. This makes error handling more visible and helps developers remember to handle it.

→ You read top to bottom, no jumping to find where a ? unwound the stack
→ Every failure path is visible in the diff during review
→ The code you wrote at 3am five years ago still reads the same at 3am today

Old Go code doesn't become unnecessarily complicated over time.

The breadcrumb trail

On September 3, 2019, Go 1.13 was released. It introduced the %w verb for fmt.Errorf, along with the errors.Is and errors.As functions.

This eliminated the excuse of "manual wrapping" and gave you a straight line through your stack.

if err != nil {
return fmt.Errorf("could not fetch user %d: %w", id, err)
}

Uber, Cloudflare, and Monzo use this exact pattern to run their backend microservices. If and when a request dies in production, the wrapped error will read like a breadcrumb trail from the crash back to the cause.

You don't need a decoder ring or to dig through stack traces. You simply get a string that indicates where the error occurred and what the code was trying to do.

What I actually think

I run a small startup. We ship fast and we're on call for our own mistakes.

The most enjoyable aspect of writing explicit errors is not the writing part. It is reading it six months later when I've forgotten absolutely everything and something's on fire.

Code that contains an excessive amount of unnecessary or repeated information is uninteresting and not engaging to read. However, when you're in a high-pressure situation trying to troubleshoot and fix a problem in a production environment, you need that kind of boring code that is clear, simple, and gets the job done efficiently!

Those who used if err != nil didn't really fail. They tolerated the redundancy in order for themselves and others to easily understand the code even when tired. This is not a flaw. It's like having good coding habits integrated into the language.

Here's my question to you: Has a ? operator ever saved you more time debugging than an explicit error trail has cost you? I'm genuinely interested if there are examples.

Agile fatigue isn't about Agile. It's about who holds the stopwatch.

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

Your stand-up routine lasts 45 minutes. No one in that room thinks it's a stand-up routine. You're basically giving a status update with unnecessary details. Also, the individual inquiring about what is blocking you is not actually helping to resolve the issue.

The framework isn't the problem

People enjoy criticizing Agile methods, such as the lengthy 45-minute daily stand-up meetings. The 45-minute standups, the story points that somehow became a performance review, the sprint that never ends. However, blaming Agile would be similar to blaming the hammer for the hole in your wall. Despite everything, statistics show that people are still using it. Digital.ai's 17th Annual State of Agile Report from January 2024 surveyed 788 software pros and found 71% of organizations use Agile. The most painful aspect is that only 11% of practitioners in the same report were "very satisfied" and 33% more were "somewhat satisfied". Therefore, fewer than half of the individuals who use it feel satisfied with it. This is not due to a failure of the framework but rather a failure of trust.

Ceremonies become cameras when trust runs out

An event is what you make of it. The same standup can feel like a quick check-in or a daily interrogation. It's not about the ritual. It's about the person with the stopwatch and their intentions. In June 2023, Bradley Momberger of Bitovi hit the nail on the head with this, describing what we might call "faux Agile," where a product owner or manager becomes, in his words, "the single chokepoint for all communication."

An even clearer indication of the issue at hand is: the tools "are designed for the micro-managers on the team and not trustful enough of developers to do the right things."

If the board is there to monitor you and not support you, then it's not Agile you are talking about, but rather surveillance using a Jira license. 🎥

The report also identifies "developer burnout", "unrelenting demand", and a "disconnect between Agile practitioners and the business" as primary barriers. None of those are process issues. They are symptoms of the experience of low trust.

"You're doing Agile wrong" is a smell

They will come around kicking and screaming if they have to. Tell them they are going about it all wrong and you may as well have suggested sacrificing a chicken at the next stand-up. It's actually a confession. A perfect explanation came from an article in InfoWorld in 2016: "the issue with most agile implementations, isn't with agile, it's with Agile, the Capitalized Methodology". Little-a agile is a set of values. Big-A Agile is what your Vice President purchased a consulting package for. The defense mechanism of "you're doing it wrong" never asks who made a weapon out of the ritual. It simply shields the trademark.

Metrics are the honest tell

Observe how your velocity chart behaves. It will tell you what your organization truly desires. The governance advice from DevSamurai is clear: "Agile metrics should not be used for surveillance. It is for awareness."

Axify.io echoed it in June 2025, warning that "metrics can feel like surveillance if you're not careful" and to treat them "as a team support tool, not a punishment tool."

A September 2025 Medium analysis added its own warning, advising "Transparency Over Surveillance" because "when metrics become weapons, teams hide problems instead of fixing them."

If you use the numbers as a weapon, people will find ways to manipulate the numbers. Here's how I read it now:

→ Metrics used for awareness build trust
→ Metrics used for judgment kill it
→ Once trust dies, every ceremony curdles into a checkpoint

What we actually do about it

In my startup, we have asynchronous standup meetings almost every day. We communicate when something is blocking us. We don't fake busyness for the sake of looking busy. We use story points as a way to estimate the effort and complexity of a task, in order to help with planning and to measure our own velocity and progress. This did not call for a new structure. It called for the faith that adults will bring issues to light if you don't penalize them for it. Fatigue caused by Agile is a real thing. However, it's not the actual mechanics of Agile causing the fatigue, it's the constant oversight and pressure. If you were to switch from Scrum to Kanban, a manager without trust will start measuring the time you were spending on each task, But it wasn't really the framework that did that. Here is a question for you to ponder: which ceremony within your team lost its function as a tool and instead started acting as a camera, reflecting what is truly going on?

The AI-native junior can't debug and we're pretending that's fine

Aditya Agarwal — Sun, 09 Aug 2026 19:27:08 +0000

One of the recent graduates who is a part of our team was able to author a PR with 400 lines of code in just one afternoon. The changes were clean, all tests were passing and the PR was ready to be shipped. Then all of a sudden production had a memory leak. No dialog box, no autocompletion, just a graph going up and a very stressed junior.

The thing nobody wants to say out loud

A viral post on r/ExperiencedDevs about a coworker being fired for using AI instead of learning the code spawned massive arguments. It hit 1000+ comments discussing if AI is silently destroying the way juniors are meant to learn. Both sides are half right. And both sides are dodging the real problem. We didn't recruit engineers that are AI users. We recruited operators for a prompt and are surprised they can't think through a system without it.

The data caught up to the vibes

A study by Anthropic in January 2026 titled "How AI assistance impacts coding skills" found that AI users averaged 50% on comprehension quizzes. The hand-coding group averaged 67% (Cohen's d=0.738, p=0.01). The most significant difference was not about syntax or style, but rather related to debugging questions.🧠

The situation deteriorates for the heavy users. Those in the "AI delegation" group who consistently depended on AI scored less than 40 percent. They were the quickest in completing the tasks yet demonstrated "less independent thinking and more cognitive offloading."

Simply put by Anthropic's researchers: "If junior engineers' skill development has been stunted by using AI in the first place, the productivity benefits may come at the cost of skills necessary to validate AI-written code."

Twice the reading is required. The individuals supposed to evaluate the AI are those who lacked the strength to evaluate anything in the first place.

The codebase is rotting quietly too

GitClear analyzed 211 million lines of code created from January 2020 to December 2024. Refactorings decreased from 25% of commits in 2021 to fewer than 10% in 2024. In 2024, the percentage of duplicate code blocks increased by 800% unexpectedly! It was also the year when the amount of copy-pasted code surpassed that of refactored code. This is not an issue of skills. It's about a system that is getting clogged up over time because there is no one person overseeing the entire operation.

Why debugging is the wall

Generating code and understanding a system are different sports.
→ Writing code is local. You need one file and a clear goal.
→ Debugging is global. You need hundreds of files living in your head at once.
→ AI is great at the first. It falls off a cliff on the second.
Have you seen SWE-bench, the benchmark full of bugs from real GitHub repos? Generalist models such as GPT-4 and Claude 2 didn't even get over 5%. They don't solve anything for the same reason our junior hesitated. Actual glitches require an entire mental image of hundreds of interconnected documents, and there is no instruction manual that gives you that.

So whose fault is it?

We didn't fall into the trap. We set it up and led them into it. We rewarded speed over understanding. We praised the fast PR and never asked anyone to explain the logic behind it. In April 2025, Om Moolchandani, CISO/CPO at Tuskira, stated: "Junior resources have less problem-solving acumen, lack deep system-level understanding (e.g. the ability to dissect and resolve issues in language compilers/ interpreters, operating systems), and the concepts are ultimately formed based on the level they enter the industry. Many can generate functional code snippets but struggle to explain the logic behind them or secure them against real-world attack scenarios."

That is the essence of it. Create, perhaps. Justify, no. We outsourced the learning curve, then acted surprised the learning didn't happen.

What I'm actually doing about it

I no longer judge junior team members based on their pull request speed. In our tiny team, fast code integration is insignificant if you cannot take the time to explain and discuss the implementation with me. The solution is not to prohibit AI but to ensure that people deserve the quick workaround.
→ Explain the diff out loud before it merges. No "the AI wrote it."
→ Debug one gnarly thing a week with the autocomplete off.
→ Read old code that isn't yours until the system stops feeling like magic.
AI can speed up things amazingly well provided you already have a framework to speed up. But it's not at all a substitute for creating that framework in the first place. The junior developer who panicked and froze is not defective. They're just the one who was never before asked to do the hard thing, and then the hard thing showed up in their real work. My question is, if your top junior had no tools due to AI for a week, would they still be your top junior?

The Hutter Prize measures intelligence better than any OpenAI benchmark

Aditya Agarwal — Sun, 09 Aug 2026 10:27:59 +0000

Winning a leaderboard doesn't hold any value for me now. Every week, a new model surpasses an existing benchmark, but at the same time, I become less confident in those numbers.

The contest nobody's gaming

There is a contest that is 20 years old now, and it measures intelligence more honestly than any OpenAI eval

The Hutter Prize is at stake. It has offered cash rewards for compressing a Wikipedia XML dump without loss of information since 2006. As of February 2020, competitors have instead been challenged to compress the 1-gigabyte file enwik9 (although the file was previously the 100MB enwik8). No "reasoning" it can fake by pattern-matching training data. Just a file, and a hard number for how small you made it. 📦

Why compression is a lie detector

Most benchmarks fail to account for one important thing. If you want to achieve good text compression, you need to be able to predict that text effectively. Predicting and compressing can essentially be the same thing. If you can predict the next word, you don't have to remember the word, you remember the prediction. The prominent goal of AI (strong AI) research is to develop systems that perform better, are easier to use, learn faster, and generalize from few data, that is, can do more with less. The capacity for good compression is closely connected to intelligence... Intelligence, however, is a controversial term while file sizes are not. A file size is something that cannot be distorted.

The rule that kills benchmark theater

This is my favorite section. Your score is the size of the compressed file plus the size of your decompression program, combined. This one rule eliminates the cheat every AI leaderboard has to suffer. You can't shove Wikipedia into a massive neural net and declare it compression because the net is part of your score. There are additional constraints:

→ Single CPU core, not a GPU farm
→ Under 10GB of RAM
→ Finish in under 100 hours

Therefore, it recognizes and encourages real algorithm intelligence rather than the one who has rented the most powerful computing cluster. While intelligence is a slippery concept, file sizes are hard numbers.

That last line is the whole point.

The numbers are brutal and beautiful

The standing record was achieved by Kaido Orav and Byron Knoll on September 3, 2024. The fx2-cmix algorithm managed to compress 1,000,000,000 bytes into precisely 110,793,128 bytes. About 11.1% as a fraction of the original size. It was a 1.585% improvement over the previous record of 112,578,322 bytes that Orav set himself back in February 2024. They were awarded €7,950 for those optimizations. Prize founder Marcus Hutter personally finances the prize which pays €5,000 for every 1% the world record is exceeded by the total pool of €500,000. Consider the gap. It took months to achieve a 1.585% improvement. No company announcement can replace the simple truth that progress in research and development is incremental.

The big labs already agree

Here's a new perspective that could put an end to the debate. The Google DeepMind, Meta AI, and Inria team demonstrated in their ICLR 2024 paper "Language Modeling Is Compression" that models such as Chinchilla 70B are the best compressors out there. This applies to text, images, and audio. Marcus Hutter contributed to the paper. Hence, the identical concept that is behind the €500,000 competition is the process that is behind every model that people compare. The CoRecursive podcast put it perfectly when they said that "compression is the ultimate prediction test". We've just been cheering for the noisy proxy instead of the direct, clean signal. A benchmark score provides information on the performance of a model based on a set of pre-defined questions. In contrast, a compression ratio indicates how effectively the model represents the actual data distribution.

What this changed for me

I used to take benchmark tables at face value. Now I see them as a form of advertising. When a lab says "state of the art," I want to know the one thing they never publish: how small can it make the file, program included. That number is indisputable. You were either able to predict the following byte or you were not. The Hutter Prize may not be flashy, but rather a steady effort to compress a file size, with competitors who are in pursuit of that 1% improvement with each attempt. However, it is truthful. And in an industry saturated with leaderboard drama, being truthful is the most uncommon standard there is. My question to you is this: if compression is the cleanest measure of intelligence we have, why are all labs still racing on benchmarks that no one can reproduce?

Codeberg banning AI code is not a cult. It's a boundary.

Aditya Agarwal — Sat, 08 Aug 2026 19:30:20 +0000

YouTuber Theo, founder of T3, gave thousands to Codeberg. He saw them vote in AI restrictions and called it "spite-driven" and a "cult."

He is mistaken. It wasn't about purity, it was about setting a boundary.

What actually happened

Codeberg e.V. is a non-profit Git forge located in Berlin. You can see it as a European version of GitHub, however, it is operated based on a democratic membership structure.

That is an important point. Members do not receive policies in a top-down manner. They actually have the opportunity to vote on them.

Therefore, a 14-day asynchronous vote was held on the proposal in the period from July 9 to July 22, 2026. The vote was closed by the admins Bastian Greshake Tzovaras, Otto Richter, and William Zijl and the results were announced on the following day.

The proposal was approved by 358 votes in favor to 144 against, with 14 abstentions, for a total of 516 votes cast. That's 516 votes cast, roughly 71% approval, with about half of active members turning out.

The new Terms of Use state it directly: "Do not upload creations that are primarily composed of code written by 'generative AI'-tools (or services like Claude, OpenAI Codex)."

Why "cult" is the wrong word

A cult doesn't conduct an open vote and then lose 144 of them. A cult doesn't accept dissent this openly.

Codeberg did the most sensible thing here. They requested, they quantified, and they released the numbers of the losers as well as the winners.

Critics often overlook the fact that Codeberg explicitly stated that they would never resort to using automated content analysis to delete large numbers of repositories. Enforcement is done on a case-by-case basis, following the common sense of the community.

Small projects, experiments, and repositories that were created before LLMs are not affected. That's not zealotry. That's a maintainer team trying to protect their review bandwidth without becoming code police. 🤷

This is about review cost, not vibes

The real argument isn't "AI bad." It's who pays for the flood.

A paper published on arXiv on July 31, 2026 discussed open-source governance, and in the paper, a Matplotlib maintainer was quoted saying that AI "changes the cost balance between generating and reviewing code."

One more time. It became inexpensive to create. But it remained expensive to review.

Every PR that can't be automatically reviewed goes to a human volunteer. When you can spray a hundred plausible-looking commits in an afternoon, the bottleneck moves entirely onto the people saying yes or no.

Codeberg also feels the pinch in the real world. For instance, a storage drive they previously paid €700 for now costs about €3,700, and they attribute this to AI datacenter expansions distorting the prices of hardware.

It means that the same machines causing a data flood are also driving up the cost of the disks used to store that data. Isn't that a wild loop?

Boundaries attract, not repel

If these were considered behaviors of a cult, people would run away as fast as they could. But instead, it was quite the opposite.

The Zig programming language community moved its infrastructure over to Codeberg. Why? Well, GitHub was basically forcing AI-assisted entry points onto contributors, and Zig hoped to encounter fewer violations of its strict no-AI policy over on Codeberg.

Communities have the autonomy to reject contributions that are beyond their capacity to evaluate. This is what governance is all about. It's similar to a linting rule, CLA, or a code of conduct.

You may have a different opinion about where exactly Codeberg decided to draw the line. I myself am not entirely certain I would have drawn the line there.

However, having a different boundary in mind does not justify claiming that the one that was drawn is illegitimate.

The takeaway

Theo provided funding to an organization based on democracy, but became upset when the democratic decision was not in his favor.

Establishing a contribution limit is not being overly selective. It's a team of maintainers determining what they can responsibly handle. And they ask for feedback from everyone beforehand. ✅

I'd like to know what you think about this: How can we differentiate between a healthy community boundary and real gatekeeping, and what decision would you have made on July 22?

Platform teams became the new gatekeepers we said we hated

Aditya Agarwal — Sat, 08 Aug 2026 10:12:54 +0000

We killed the ops silo. Then we gave it a golden path and a nicer logo. The platform team was meant to solve our problems. Somehow it became the same disease with a Backstage portal on top. ## The pitch we all bought

Team Topologies sold platform teams as a way to reduce cognitive load. According to Gartner, 80% of large engineering organizations will have platform teams by 2026. This is an increase from 45% in 2022. But here's the tension nobody wants to name. "You build it, you run it" and "let the platform team handle it" are pulling in opposite directions. You can't advocate ownership and then have all deploys funnel through a dedicated team of specialists. Gotta choose one. ## The bottleneck came back wearing a hoodie

We disliked the ops team because of the never-ending ticket queue. If you needed a database, you had to submit a request and then wait for someone from another department to approve and create it for you. Platform engineering was supposed to bring self-service. But the State of Platform Engineering Report (Volume 4) reports that 45.3% of platform teams highlight developer adoption as the biggest challenge. Why? Well, 36.6% depend on top-down mandates to coerce developers to use their platform and not because they actually want to. 😬

Well, it's more like the compliance coach with a big stick. Rachel Sweeney got it right, as quoted by Brian Bensky in his Fairwinds article from July 2025:

You will always be forced to react to their needs if you impose the use of your abstractions on the team. The ops silo is reactionary. It's the same email but a different sender. ## The portal is not the platform

According to Kellton Tech, Spotify's IDP solution - known as Backstage - holds an approximate 89% market share amongst IDP adopters. We can assume that every organization is currently engineering a stunning developer portal. Here's the trap. You create a fancy UI, but the functionalities behind it, are still dependent on manual platform team approval. Simply press the button, a human will arrive shortly. Well done! You successfully redesigned the ticket queue, using improved CSS. Charity Majors, CTO of Honeycomb, advocates for "guardrails over gatekeepers." She cautions that strict abstractions lead to "more abstraction pain" and prevent developers from being able to debug their code. Because the platform obscures everything, your engineers are unable to remedy their own incidents. They open a ticket. Rinse and repeat. ## Why the shiny platform still fails

The failure rate is extremely high when looking at the numbers. The report revealed that 78% of platforms that attempt to address all developer issues and challenges right from the start eventually collapse. It appears that the new big-bang platform is essentially the new big-bang rewrite in a different guise. And it gets even worse than that. 29.6% of platform teams don't measure success at all. If you're not keeping track of developer friction, you won't notice the line that's starting to form. Instead, you'll mistakenly think you're brilliant, all while your users find ways to bypass you. ## What actually separates a road from a wall

I have seen this happening within my team. The day you start needing permission from a so-called "platform", you've already been defeated. Here's the line I keep coming back to:

→ A platform you can bypass is a road. A platform you must use is a wall. → If adoption needs a mandate, your product is bad. Fix the product, not the policy. → Guardrails let people move fast and warn them at the edge. Gatekeepers make them stop and knock. → If devs can't debug through your abstraction, you didn't reduce cognitive load. You hid it. Effective platform teams I have encountered function as an in-house product organization. They strive to be chosen. They lose prospects due to being sluggish, which is painful, but it motivates them to improve. The ones who are not good will always bring up organizational policy to justify their actions. That's how you can tell they are not to be trusted. ## The uncomfortable takeaway

The issue is not platform engineering. The issue is renaming centralized control to "reducing cognitive load". Responsibility was reallocated to a dedicated team and we were still shocked when the blockage reappeared. 🎯

Changing the name and creating a portal isn't enough to break down a silo. You have to create such a smooth and efficient process that nobody has a reason to work in isolation. Here's a question for you: Do developers opt-in to using your platform team, or are they instructed to use it? If it's the latter, what would happen if you made it optional tomorrow?

The slot machine workflow is the real vibe coding problem

Aditya Agarwal — Fri, 07 Aug 2026 19:28:21 +0000

There's a lot of debate going on right now about whether Artificial Intelligence can write good code.

The actual issue is not with the code but the lever you are using to retrieve it.

The re-roll is the tell

Yes, it's the loop we all know too well. You ask for something, take a look, say "it's not what I had in mind", then ask again, take another look.

At a certain moment in time, you've stopped reading the differences. You're simply waiting for the result that seems correct, so you can stop making changes.

Iteration is not trying the same solution multiple times and failing.

Rerolling is like trying again because you don't like the outcome, with the hope that this time the result will be more favorable. Engineering is about problem-solving, taking into account what you learned from the previous attempt. They are not the same thing. 🔧✨

Why this specific loop rots your brain

"Vibe coding" was a term first used by Karpathy in February 2025. According to him, it's when you fully surrender to the vibes and forget the code completely.

Nice presentation. However, it didn't highlight enough how difficult it is to break the habit.

The numbers that made me quit. In his March 2026 essay "One More Prompt: The Dopamine Trap of Agentic Coding," former Instacart site reliability engineer Quentin Rousseau noted that on average, Vegas slot machines "win," i.e. pay out, about 5% of the time.

AI programming tools are giving back 80% or more. The marginal cost of one more attempt falls to almost zero.

Exactly, that's the trick. A regular slot machine makes you lose enough to quit, but this one makes you win often enough that you never do.

Steve Yegge was right when he wrote "The AI Vampire" in February 2026: AI coding "dispenses dopamine and adrenaline shots like they're a fire sale.

Tyler O. captured the scary part in words in his May 2026 article "The Terminal Star": "Source code flutters past and my hunger to read it diminishes."

That's the whole disease in one sentence. The dopamine trains you to stop reading.

The receipts are ugly

If this was just a feeling, that's okay. But the numbers are appearing in the repositories.

The 2025 report from GitClear conducted an analysis of 211 million lines of code across 3,400 repositories. Refactored or "moved" code, which constituted 25% of all changes in 2021, fell to below 10% in 2024.

Code is no longer being refactored, it is only expanded.

Same report: commits with duplicate code blocks spiked 800% in 2024. Roughly 6.66% of commits now carry substantial duplication, up from 1.8% in 2023.

Yes, they do. If re-rolling is free, then why bother looking for the existing function? Just pull the lever, paste the fresh block and move on.

Another study that is applicable to this context is the DORA report from Google in 2024 which showed that for each 25% increase in AI adoption, delivery stability decreased by 7.2%.

The more you gamble, the more unsteady your financial situation becomes.

The part nobody wants to admit

A March 2026 Multitudes study tracked over 500 developers. Engineers using AI tools showed a 19.6% jump in out-of-hour commits, nights and weekends.

Read that one more time. The tool that was meant to free up your evenings is, in fact, tying you to the desk until late at night.

That is not being productive. It is a casino where you cannot see outside and there are no clocks.

I admit I've done it to our own product. It's 11pm, I've reprompted the same function six times, and I couldn't actually explain what the current version does.

I did not have a vision.

ThePrimeagen referred to much of this as "demo porn," but that term stuck because it was a fitting description.

How I try to break the loop

Not flawlessly. However, these are useful:

→ Read the diff before you decide it's wrong. If you can't say why it failed, you haven't earned a re-roll.

→ Cap your pulls. Three tries, then you stop and think instead of spin.

→ If you're re-prompting the same thing four times, the prompt isn't the problem. Your understanding is.

→ Refactor on purpose. That "moved code" number falling off a cliff is a choice, not a law of physics.

It's not about the tool, it's about the loop. Using a hammer doesn't prevent you from focusing on the nail, but this contraption actually does that.

The solution is not to abandon AI. It is simply to keep our eyes open while pulling the lever.

Come on, tell the truth, when was the last time you reposted something without reading it?

The Staff engineer with 4 years of experience is a hiring problem we made

Aditya Agarwal — Fri, 07 Aug 2026 10:17:54 +0000

A hiring manager sparked outrage when they revealed that they automatically reject candidates with Staff or Principal titles who only have 3-4 years of experience. It became a hot topic of discussion on the internet.

Half the replies called them a gatekeeper. The other half called it common sense.

They're both missing the point.

The candidate didn't inflate anything

A junior engineer doesn't just wake up one day and decide to call themselves a Staff Engineer. It's a title someone else has to give to them.

It's often handed out by startup founders in lieu of a competitive salary.

Datapeople analyzed millions of tech job postings from 2022. A quarter of roles that were "junior" in 2019, needing under 4 years of experience, got rebranded with "senior" titles by 2022.

Ravio's numbers are even stronger. From 2019 to 2023, there were three times as many "Lead" early in career positions, and half as many "Junior".

The role stayed the same despite the title change.

Titles became a currency

Here's the mechanism, said plainly.

More than 400 organizations were surveyed by Pearl Meyer. 54% were actively using titles to attract talent, a 35% jump from 2018.

Their managing director Susan Sandlund was frank in saying that "without big pay raises they have to give something to their key employees."

That's the whole scam in one sentence.

And employees are well aware of it. A MyPerfectResume survey revealed that 92% feel that businesses resort to exaggerated titles in order to pretend like "there is room for career advancement," all the while withholding potential pay increases.

The most surprising statistic is that 15% of people actually confessed to accepting a reduced salary in return for a fancier title.

We exchanged currency for a term.

The word stopped meaning anything

That's the reason an auto-reject seems unfair yet justifiable at the same time.

A title once used to indicate the size of the scope you worked on. Now it signifies the size of the company you worked for.

KORE1's market report hit the nail on the head when it said: "a staff engineer at a forty-person startup and a staff engineer at Google are not the same job, the same scope, or the same price." A staff title at a company that gives them away "tells you almost nothing about the person's actual scope."

Therefore, the manager isn't rejecting the individual. They're rejecting a flawed message.

However, dismissing the signal by discarding the candidate? That is not a diligent approach. The candidate is the one who suffers from the inflation, not the one causing it.

What Staff was supposed to mean

Will Larson is the one who wrote a book about this and his definition is quite strict and straightforward.

A Staff engineer is not a superior Senior engineer; it is a Senior engineer who has segued into one of the Staff roles.

Scope. Influence. Not tenure, not a raise dodge.

According to that standard, many "Staff" engineers working for a 40-person startup aren't really at the Staff level. Similarly, some engineers with only 3 years of experience are performing work at the Staff level because small teams require it.

Having many years of experience is also not a valid measure. According to data from early 2026 provided by Levels.fyi, Staff and Principal level engineers with 5-7 years of experience were making between $700K-$900K. In contrast, some Seniors with 15 years of experience were making less than that.

The market has changed and today seems to value experience above the "youthful energy" that many managers claim to seek.

The part nobody wants to say

Startups deliberately chose this approach, as it is more cost-effective to provide a printed title than to offer a salary at the experienced professional level.

Index Ventures discovered that 30% of execs who were brought on board during the "first 10" phase of a startup were early power-mongers who had inflated their job titles and only had five years or less of work experience.

But it only continues to work if the individual decides to switch jobs and that fancy title then turns into a downside.

We gave people a paper crown and then feigned shock when their next employer refused to take it as payment.

The takeaway

Please do not interpret titles as scope. Instead, consider them to be context.

One should inquire about what the individual in question actually owned. Ask about what they inspired. Ask about what fell apart in their absence. That's a 10 minute conversation, not an auto-reject filter.

→ Title tells you the company's comp philosophy, not the candidate's skill
→ YoE tells you almost nothing on its own
→ Scope is the only thing worth screening for, and it takes real questions

It's not the candidates who are at fault here. It's us - the entire industry - for transforming an actual job into a retention incentive.

So my question to you is, if you were hiring tomorrow, would you screen out a 4-year Staff engineer on sight, or would you make them prove the scope? And do you know which one your ATS actually does?

Compliance-grade pentesting is a scan wearing a suit

Aditya Agarwal — Thu, 06 Aug 2026 19:15:06 +0000

You paid for a PDF document that was passed off as a penetration test.

You spent money on a penetration test. All you received was an export from a scanning tool that had the consultant's logo on the report. 🎭

The suit doesn't fit

Essendis hit the nail on the head in their 2026 pricing guide. They state the market is flooded with "cheap engagements that are a vulnerability scan wearing a suit."

That line is stuck in my head. Because that's the one thing founders can actually purchase.

Netragard raised a red flag on this: automated scans in pentest clothing. You push a button on the tool, push print on the report, and push the box on your checklist.

Nobody actually tried to break in.

Why the cheap thing keeps winning

Here comes the part no one likes to talk about. They aren't the ones to blame for this.

According to an analysis in January 2026 from Analogue Computer, the pentesting market is a "market for lemons," and "the market clears not at the price of risk reduction, but at the price of plausible deniability."

Read that twice. Customers are not buying security, they are buying a checkmark on an audit document.

In a more polished way, Lorikeet Security expressed the same idea in the beginning of 2026: "Compliance frameworks reward control presence over control effectiveness." An auditor inquires do you perform penetration testing?, receives a report, and ticks the box.

The vendor offering a scanner and PDF printer at a low price wins over the human chaining exploits.

What SOC 2 actually says (spoiler: not much)

People often assume that SOC 2 requires a pentest but in reality, it doesn't.

The AICPA's SOC 2 framework does not have the words "penetration test" in it. So, auditors have to rely on the coverage of Trust Services Criteria like CC7.1 in the case of detection and monitoring and CC4.1 in the case of monitoring activities and control evaluation.

Theater sneaks in through that gap - if your architecture never requires adversary emulation, why would you pay for it?

PCI DSS version 4.0 is the mature version to follow. Becoming fully mandatory in March 2025, it clearly separates vulnerability scanning (Requirement 11.3) from penetration testing (Requirement 11.4). Additionally, according to 11.4.4 of PCI DSS v4.0, any exploitable vulnerabilities must be corrected and then the testing must be repeated.

The last word is crucial here. Retested implies that the change that fixed the problem had to be confirmed by someone to actually work. A scanner cannot do that.

How to spot the scan in a suit

Essendis provided potential purchasers with the clearest information I have ever come across:

→ "A firm quoting sight-unseen is planning to run a scanner."
→ If the report looks like a raw export with a logo slapped on, you overpaid for a scan.
→ Real testing means manual business-logic probing, privilege escalation, chained exploits.

The price itself can be a pretty good indicator. For example, a legitimate web app pentest in 2026 will cost you somewhere between $5,000 and $30,000. If the quote is well below that range and it shows up before anyone has even seen your application, then you probably have your answer.

In February 2026, Linford & Co put out a manifesto, which they referred to as, "The Penetration Testing Mirage." In it, the firm stated, "running a commercial scanner and printing a PDF is not a penetration test... That is a commodity service that could be performed by an intern on their first day."

Tough, but true.

The takeaway

The problem isn't with the scanner. Scanners do their job well.

The real villain here is deception. The real deception happens when machine-generated content is passed off as the work of a human adversary, and the client is willing to buy into the charade because the box only sees the costume.

I understand the temptation. As a small team, when you're trying to finalize an enterprise deal, the cheapest option that satisfies the requirement seems like a victory. But one day, someone who doesn't just scan passes through your business logic and finds the door that you never tested. 😬

Here's something to think about. If the market recognizes only plausible deniability, the solution is not more intelligent auditors. It's the buyers who should change their question from "did we pass?" to "did anyone really try to break in?"

When you last bought a "pentest," did you check whether a human touched it, or did you just file the PDF and move on?

An AI chatbot invented a refund policy and a court made the company pay

Aditya Agarwal — Thu, 06 Aug 2026 10:34:00 +0000

When a chatbot promises you a discount that doesn't actually exist, who's responsible: the company or the bot? A court made the company pay it anyway.

This is what should cause sleepless nights for your legal team. Not that an agent deleted a database, but that it made an unapproved promise. 😳

The story

In November 2022, Jake Moffatt hastily reserved a flight from Vancouver to Toronto. His grandmother had recently passed away.

He asked the chatbot about bereavement fares, and it told him he could book a full-price ticket immediately and then apply for a reduced bereavement rate refund within 90 days of the date the ticket was issued.

No, that was not true. The airline's actual bereavement policy was different.

Believing in the accuracy of the information provided by the chatbot, Moffatt went ahead and booked the flights, paying $1,630.36 CAD. He submitted the refund request with his grandmother's death certificate on November 17 but Air Canada rejected the claim.

The ruling that changes things

Moffatt lodged a claim with the British Columbia Civil Resolution Tribunal. His claim was successful.

On February 14, 2024, Tribunal Member Christopher C. Rivers ruled entirely in his favor and found Air Canada guilty of negligent misrepresentation. The case is Moffatt v. Air Canada (2024 BCCRT 149).

Air Canada went even further by claiming that because a chatbot is not a legal person, it cannot be held responsible for a contract.

Rivers described it as "a remarkable submission" and stated that "the chatbot is still just a part of Air Canada's website." Voilà!

Air Canada was required by the tribunal to compensate Moffatt in the amount of $812.02 CAD, which consisted of $650.88 for the difference in the fares, $36.14 in interest before the judgement, and $125 tribunal fees.

The fine was insignificant, but it set a huge precedent.

Why this is the scary agent story

All our fear reserve is dedicated to agents that perform actions. Agents that deploy code, delete data, or mistakenly send an email to 40,000 recipients.

But that's not the point here. The point is the person who actually vocalizes things.

Destroying something is like a noisy action. You notice the mistake, undo it, and then log an incident.

A promise made under a hallucination is legally unenforceable. It seems like run-of-the-mill, good-natured assistance until a client drags you into court over it.

Let's break down what was really going wrong with the Air Canada case. At its core, it was a context drift failure of Retrieval-Augmented Generation.

→ The bot retrieved the correct policy document.
→ It distorted the synthesis on the way out.
→ The output sounded confident and specific.
→ Nobody caught it because it wasn't an error, it was a sentence.

Exactly, that summarizes the issue. Your guardrails are there to look out for anomalies, not to catch a well-written incorrect paragraph.

What I'd actually change

If you are deploying a chatbot, do not think of it as a search bar. Treat it as a new employee that can sign contracts.

That's because, according to the law, it is what was previously determined by a tribunal.

Let me give you my perspective on this:

→ Any statement about money, refunds, or entitlements needs a hard-coded template, not a generated one.
→ Log every promise the bot makes, not just the errors it throws. The promises are the liability.
→ Put a verification step between "retrieved the policy" and "told the customer." Context drift lives in that gap.
→ Assume a customer will quote your bot back to you in a legal filing. Write your prompts like they will.

I'm aware of the friction explanation. Canned responses are more noticeable and less natural than fluid replies.

However, "fluent" is what ultimately cost Air Canada the lawsuit. The chatbot did not hesitate, it did not stutter, it spoke clearly and confidently about a policy that was not there.

The takeaway

Credit for bringing this pattern to light belongs in part to Suresh Kumar Ariya Gowder, whose Medium post described the hallucinated bereavement discount as a promise problem not a bug problem.

The most risky capability of your agent is not that it can take action. It is actually that it can give its word in a way that was never approved by your lawyers.

This is a question for you: Would you be aware, before the customers, if your support bot assured them that they would receive something the next day that your policy clearly states they would not receive?