DEV Community: Shekhar Bhardwaj

Nobody Hacked the Reactor

Shekhar Bhardwaj — Thu, 16 Jul 2026 15:41:29 +0000

If you read one headline about the Kudankulam breach this month, you probably came away thinking someone kicked in the door of a nuclear reactor. They did not. That version is scarier and less true than what actually happened, which is worth understanding, because the real version is coming to a company near you.

Here is the short version. A ransomware crew called World Leaks dumped about 19,000 files, roughly 14 GB, onto the dark web. The files relate to Units 3 and 4 at the Kudankulam Nuclear Power Plant in Tamil Nadu, both still under construction. Blueprints of ventilation and cooling systems. Floor plans of a shared control room. Supplier lists. Inspection records. Insurance paperwork. Some of it dates back to 2016.

Now the part that got buried. None of it came from the reactor.

The air-gap held. The filing cabinet didn't.

Think of a nuclear plant like a bank. The vault is the reactor core and its control systems. In this case those designs belong to Russia's Rosatom, they sit on networks physically cut off from the internet, and they were not part of the leak. The vault held. It did its job.

What leaked was the equivalent of the bank's facilities binder. The HVAC drawings. The floor plan. The list of who supplied the locks and who inspected them last. Not the money, but a detailed map of the building around the money.

And that binder was not even inside the bank. It was a copy, sitting at a contractor. Reliance Infrastructure won the 2018 contract to build out Units 3 and 4, so Reliance had legitimate copies of all these documents. Reliance stored them on a server hosted by a third-party data center company called Yotta. Yotta noticed something wrong on May 29. By then the files were already gone, and they went public on June 11.

So trace the path of a single blueprint. It starts at the plant. It gets copied to a contractor who needs it to do the work. The contractor parks it at a data center vendor. An attacker walks into the data center vendor. Four organizations, three handoffs, and the document is on the open internet. The plant did everything right and still lost.

That is the whole lesson, and it has nothing to do with reactors.

How they actually got in (spoiler: it was boring)

Everyone wants a breach at a nuclear facility to involve some genius zero-day and a hooded figure in a basement. World Leaks does not work that way, and they almost never have to.

World Leaks is a rebrand of Hunters International, which was itself built on the bones of the old Hive gang. Sometime in early 2025 they made a business decision: stop encrypting files, just steal them and threaten to publish. Encryption is loud and law enforcement was catching up. Pure theft is quiet, leaves less evidence, and the long-term pain of leaked secrets is often worse for the victim than a few locked servers they can restore from backup.

Their signature move is embarrassingly simple. They find a VPN or a remote-access login with no multi-factor authentication, they get a valid username and password (bought, phished, or reused from some other breach), and they log in. Not break in. Log in. Once inside, they use tools that already live on the network so nothing looks out of place, they find the good stuff, and they quietly copy it out.

Same crew, same playbook, hit Tata Electronics just last month and walked off with iPhone and Tesla supply-chain data. They asked for 1.5 million dollars, got ignored, and published. This is a business, and it runs on your worst password hygiene.

"But was it AI?"

This is the question everyone asks now, so let me be straight with you, because pretending otherwise is exactly the kind of thing I write about.

There is no evidence AI was used to pull off the Kudankulam breach. None. This was stolen credentials and a missing MFA prompt. If anything, the honest headline is "nuclear plant contractor breached by a weak login," which does not exactly trend.

But do not exhale yet, because the AI story here is real. It is just one layer up. Across the ransomware economy, crews are wiring AI into the parts around the break-in. Writing cleaner phishing lures at scale. Sorting through stolen data to find the valuable 19,000 files inside a haystack of 858,000. Running the extortion negotiation. Security researchers have been tracking this shift all year.

So the accurate way to think about it is this. AI did not make this attack possible. AI is making this exact kind of attack cheaper, faster, and doable by people who could not have done it before. The breach was boring. The trend behind it is not. When the boring attack gets automated, you get a lot more of it.

What actually stops this

None of the fixes are exotic. They are just unglamorous, which is why they get skipped.

Turn on MFA everywhere, especially the boring stuff. The single most common way this specific crew gets in is a remote login with no second factor. A VPN without MFA in 2026 is an unlocked door with a "please rob me" sign on it. This is the highest-leverage item on the list and it is basically free.

Own your vendors' security, in writing. The plant did not leak. Its contractor's data center did. If your sensitive data lives at a third party, their weakest control is now your weakest control. That means real security requirements in the contract, proof they are met, and the right to check. "We assumed they had it handled" is not a strategy.

Stop hoarding. Some of these files were nine years old. Ask why a 2016 blueprint was still sitting on a live, reachable server in 2026. Data you deleted cannot leak. Retention limits and moving old records offline shrink the blast radius before anything goes wrong.

Encrypt data at rest and segment your networks. The reactor survived because it was walled off. Apply the same instinct to everything else. If an attacker gets one login, they should land in a small room, not the whole building. And stolen files that are properly encrypted are a lot less useful on a dark web forum.

Assume you will be breached and rehearse it. Yotta spotted the intrusion, which is good, but the files were already gone. Speed is everything. The gap between "something is wrong" and "we contained it" is measured in hours, and you do not want to be writing the plan while the clock runs.

Where this is heading
Three things are true at once, and they point the same direction.

The extortion-only model is winning. Stealing and threatening to publish is quieter and often more profitable than locking files, so more crews are copying it. That means the threat you are defending against is data leaving, not systems freezing, and a lot of tools are still tuned for the wrong one.

AI is lowering the floor. The skill you needed to run a competent data-theft-and-extortion operation is dropping, because the tedious parts are getting automated. Expect more attacks, run by less capable people, at higher speed.

And critical infrastructure is squarely in scope. Power, water, transport, anything with contractors and construction and decades of accumulated documents. The reactor cores may be air-gapped. The sprawling human and paperwork perimeter around them is not, and that perimeter is where this fight is actually being fought.

The uncomfortable takeaway from Kudankulam is not that a nuclear plant is fragile. It is that the plant was strong, and it lost anyway, because your security is only as good as the least careful company holding a copy of your secrets. Most organizations have no real idea how many copies of their secrets are out there, or who is holding them.

That is the question worth sitting with. Not "could someone hack our reactor." The reactor is probably fine. The question is: where are all the copies, and who is watching the ones we forgot about?

Burn After Reading

Shekhar Bhardwaj — Fri, 10 Jul 2026 14:48:57 +0000

My manager ruined a perfectly good beer at an open air brewery in Richmond by telling me the truth about my career. The advice aged better than the beer. Here's the T-shaped engineer pitch nobody gave you, and six prompts worth burning tokens on at the end.

The T-shaped engineer idea was first called out for me at an office happy hour, over beers at an open air brewery in Richmond. Careers came up, the way they do when engineers drink near their manager, and mine made a point I couldn't shake: depth alone doesn't carry you. The engineers who go furthest are deep in one thing, conversant in everything around it, and able to explain their work to anyone in the building.

I nodded, went home, and kept doing exactly what I was doing. Going deeper and calling it growth. It took me embarrassingly long to admit he was right.

The machine took the easy half

For years the deal was simple. Be great at the craft and the craft carries you.

That deal is being renegotiated by a machine that writes code faster than you, never sleeps, and costs less than your coffee habit. The vertical part of your skill set, the part we spent a decade sharpening, is now shared with anything that has an API key.

Here's what the machine can't do. It can't notice the VP checked out two slides ago. It can't tell a product manager no in a way that makes them feel heard. It can't repair a relationship after a tense meeting or read the silence after a bad demo.

That's the half you were told was optional. It's now the half that's left.

The T, minus the LinkedIn version

The vertical bar is one area where you are genuinely deep. Not "familiar with." Deep. You're the person people ping when that thing is on fire.

The horizontal bar is working knowledge of everything around it. Product. Design. Data. Infra. Security. The business itself. Enough to be dangerous in any meeting.

Soft skills aren't a third thing bolted on. They're what the whole letter is made of. Communication is what lets your depth travel outside your own head. Depth that can't travel is a diary.

"My code speaks for itself"

Say "I'm bad with databases" in an interview and you'd fix it by Friday. Say "I'm bad with people" and somehow it's a personality.

Your code has never spoken for itself. Code doesn't attend calibration meetings. Your promotion case is written in English and decided by tired people reading it on their phones.

The engineer who quietly fixes the outage at 2am gets a thank you emoji. The one who fixes it and writes a postmortem people understand gets a reputation. Same fix. Different career.

Nobody gets promoted for elegant recursion. People get promoted because someone in a room they weren't in could explain their impact. Your job is to arm that person.

How to build the T

Pick your vertical and commit. You can't be T-shaped without the stem. Take your strongest area and go embarrassingly deep. Depth earns you the right to be heard on everything else.
Steal the horizontal from meetings you don't need to attend. Sit in the product review. Ask the finance partner what moves their number. Ask the dumb question. Half the room was too proud to.
Write like your reader is busy. Answer first, context second. If your status update needs a scroll, it needs an edit.
Explain your work at three altitudes. To an intern, to a peer, and to a VP with thirty seconds. If you can only do one, you're deep. Not T-shaped.
Handle feedback like a production incident. Acknowledge fast, skip the defensiveness, fix the root cause. Arguing with the alert doesn't clear it.
Do the human maintenance. Follow up. Give credit by name. Disagree in private, defend people in public. It compounds slower than code, which is why impatient people skip it and plateau at senior.

Now, about the title

Burn After Reading is an instruction.

The same AI that commoditized your vertical bar is the cheapest soft-skills coach ever built. No ego, no calendar, and it'll run the awkward rep a hundred times for pennies. You've read. Go burn some tokens:

Paste your last design doc: "Rewrite the summary so a VP with thirty seconds gets why this matters. Then tell me what I buried."
"Interview me about [your specialty] like a curious product manager. Interrupt me every time I use jargon."
"Play a director who wants to cut my project. Push back hard. Afterward, grade how I defended it."
Paste the spicy Slack message before sending: "Tell me how this reads to someone having a terrible day. Then fix it without losing the point."
"Ask me five questions a security engineer, a designer, and a finance partner would each ask about my current project. Score my answers."
Paste your self-review draft: "Find every sentence describing activity instead of impact. Rewrite one so I see the difference."

An hour of your life, a few cents of compute. Cheaper than the beer that started this.

The point from that brewery still holds. Depth gets you into the room. The crossbar keeps you there.

Burn accordingly.

I Spent $200 Solving a $2 Problem. That Is Why AI Site Reliability Will Matter.

Shekhar Bhardwaj — Mon, 29 Jun 2026 00:16:26 +0000

So this weekend I spent $200 solving a $2 problem.

Not because I was careless. Not because the system was broken in the old way. It happened because the tool was powerful, fast, confident, and wrong for just long enough.

That is the strange thing about AI systems. They do not always fail loudly. A cloud server goes down, an alert fires, a dashboard turns red, someone opens an incident bridge, and the team knows what kind of movie they are in. AI failure is softer. The answer looks useful. The workflow keeps moving. The agent tries another path. The model explains itself beautifully. The bill keeps climbing.

With cloud reliability, we learned how to survive machines failing. We built retries, failover, backups, autoscaling, health checks, runbooks, and incident reviews. The cloud taught us that infrastructure is never perfect, so systems must be designed to bend without breaking.

AI is teaching us something different. The machine may be running perfectly and still produce the wrong result. The API may be healthy, the latency may be fine, the token stream may complete, and the business outcome may still be bad.

That is why AI Site Reliability is going to become its own serious discipline.

It will not be enough to ask, “Is the model available?” We will have to ask, “Is the model still useful?” “Is it drifting?” “Is it spending too much?” “Is it using the right tools?” “Is it looping?” “Is it making the same mistake with more confidence?” “Is a human needed before this continues?”

In the cloud world, uptime was the king metric. In the AI world, usefulness will matter just as much. A model that is always available but often wrong is not reliable. An agent that finishes every task but spends 100 times more than needed is not reliable. A chatbot that gives answers with perfect grammar but poor judgment is not reliable.

The next generation of reliability engineering will care about cost, correctness, context, and control.

Cost matters because AI turns thinking into metered usage. Every retry has a price. Every long context has a price. Every tool call has a price. A bad loop is no longer just wasted time. It is a live meter running in the background.

Correctness matters because AI can fail while looking successful. Traditional systems usually return errors when something breaks. AI can return a confident paragraph. That means we need new checks. Not just status codes, but reasonableness checks. Not just logs, but decision trails. Not just observability, but explainability at the workflow level.

Context matters because AI systems depend heavily on what they are given. A great model with bad context becomes a fancy guessing machine. Missing policy, stale data, poor prompts, broken retrieval, or unclear instructions can quietly damage the final answer. In AI systems, reliability starts before the model is even called.

Control matters because autonomy without guardrails becomes expensive chaos. Agents need budgets. They need stop signs. They need permission levels. They need escalation points. They need to know when to ask a human instead of burning another 200,000 tokens trying to be clever.

This is where AI reliability will feel different from cloud reliability. Cloud systems fail because components break. AI systems fail because judgment breaks. The server may be healthy, but the reasoning path may be sick.

That changes the work.

Future AI runbooks will not only say, “Restart service.” They will say, “Check prompt version.” “Compare answer against source.” “Review tool call chain.” “Inspect token spend.” “Validate retrieval freshness.” “Freeze autonomous retries.” “Route to human approval.” “Roll back model behavior.” “Switch to smaller model.” “Stop the agent.”

The best teams will not be the ones using the biggest models everywhere. They will be the ones that know when not to use AI. They will know when a $4 rule, a database query, a simple form, or a human approval is better than a $400 reasoning adventure.

That is the real lesson.

AI is not magic infrastructure. It is probabilistic labor inside software. It can work beautifully. It can also overthink, overspend, hallucinate, retry, and explain its way into trouble.

So the future of AI reliability is not about distrusting AI. It is about respecting it enough to build around its failure modes.

We need systems that treat AI as powerful but not sacred. Helpful but not always right. Fast but not free. Available but not automatically reliable.

Because in the old world, downtime was expensive.

In the AI world, uptime can be expensive too.

And sometimes the system will not crash at all. It will just calmly spend $1000 solving a $10 problem.

Orignal Post

FONA: Fear of Not AI-sking

Shekhar Bhardwaj — Sat, 27 Jun 2026 18:28:09 +0000

FONA — short for "Fear of Not AI-sking" is a term I coined for the anxiety that you should be using AI for a task, and that reaching for it last, or not at all, means you're falling behind.

There is a new kind of guilt in the AI era. It is not the fear that AI will replace you. It is the fear that AI was available, ready, waiting in the prompt box and you still did not ask. That quiet feeling has a name: FONA Fear of Not AI-sking. It is the anxiety that the task you avoided, the idea you parked, or the project you kept calling “someday” may no longer be blocked by time, skill, or tools. It may just be waiting for one honest prompt.

A friend texted me at 11 PM on a Tuesday. Not the usual kind of late-night text like, “Are you awake?” This was more of a quiet existential audit. He had been thinking about a side project for two years. Two full years of “I should build this someday.” Two years of casually mentioning it, mentally polishing it, occasionally getting excited about it, and then putting it back on the shelf like a decorative ambition.

Then it hit him. Claude could probably scaffold the whole thing in an evening. Not finish it. Not make it beautiful. Not turn him into a founder with a podcast mic, a black turtleneck, and strong opinions about cold plunge therapy. But enough to make the thing real. Enough to remove the comfort of “someday.”

And that was the horrifying part. Because once the excuse is gone, what are you left with? Yourself. The final boss.

I told him I had no good answer, because I was currently losing the same boss fight. I had my own graveyard of half-finished ideas. The newsletter I never started. The script that would save me an hour every Monday. The blog post sitting in a draft folder, quietly judging me. The little product idea I kept calling “interesting” so I would not have to call it “abandoned.”

And now each one had a new label attached: could’ve prompted it.

That is the new guilt. Not “I didn’t have time.” Not “I didn’t know how.” Not “I need to learn React first,” which, historically, has been the adult version of “my dog ate my homework.” No. Now the brain says: you could have asked.

You could have opened ChatGPT, Claude, Cursor, or whatever flavor of robot intern you prefer, and typed: “Make me a starting point.” “Turn this into a plan.” “Write the first ugly version.” “Explain the hard part.” “Generate the annoying boilerplate.” “Help me stop pretending this is blocked.”

That feeling needs a name. So here it is: FONA — Fear of Not AI-sking.

FONA is the creeping anxiety that you are underusing the most powerful assistant you have ever had access to. It is not the fear that AI will take your job. It is the fear that AI is sitting there, fully charged, emotionally unavailable, ready to help, and you are still raw-dogging your to-do list like it is 2016.

FONA is looking at a task and realizing the hardest part is no longer, “Can this be done?” It is, “Why haven’t I even asked?”

It shows up in small moments. You spend 45 minutes formatting an email and then remember AI could have made it sound less like a hostage note. You manually rename 80 files and then feel a spiritual slap from the automation gods. You sit on a blog idea for three weeks and then watch someone else publish a worse version with more confidence. You open an empty document, stare at it, close it, and somehow call that “thinking.”

Before AI, procrastination had dignity. You could say things like, “I need a weekend,” “I need a designer,” “I need to research the market,” or “I need to wait until things calm down.” Beautiful lies. Respectable lies. Lies with a blazer on.

Now the lie has to survive a prompt box. That is much harder.

Because AI has made starting embarrassingly cheap. Not succeeding. Not mastering. Not shipping something great. Just starting. And starting used to be where we hid.

That is what my friend was really texting me about at 11 PM. Not the side project. Not Claude. Not code. He was grieving the death of a very comfortable excuse. The idea had not been blocked for two years. It had been waiting for him to ask.

And honestly, same.

So maybe the point is not to become the kind of person who prompts everything. That sounds exhausting and slightly cursed. Maybe the point is to notice the moment when you are avoiding the ask. When the task is small enough to start, but vague enough to dodge. When the idea is not impossible, just inconvenient. When the first version would take one decent prompt and 20 minutes of honesty.

That is where FONA lives.

And maybe the cure is simple: do not build the whole thing. Just ask the first question. “Can you help me make this real enough that I can’t keep pretending it is only an idea?”

That might be the most dangerous prompt now. Because once AI gives you the first draft, the skeleton, the outline, the script, the landing page, or the messy prototype, the excuse is officially dead. And then it is just you and the thing you said you wanted to do.

Terrifying. Useful. A little funny. Very Tuesday night.

Originally published at shekharbhardwaj.com