DEV Community: Shekhar Bhardwaj

FONA: Fear of Not AI-sking

Shekhar Bhardwaj — Wed, 29 Jul 2026 00:25:19 +0000

A friend texted me at 11 PM on a Tuesday . He'd been thinking about a side project for two years. He'd just realized, with something like horror, that there was no excuse anymore. Claude could probably scaffold the thing in an evening. So why hadn't he? What was he doing with his time?

I told him I had no good answer , because I had the same question. I'd been staring at my own list of half-finished ideas all week . The newsletter I never started . The script that would save me an hour every Monday. The blog post sitting in a draft folder. Each one a one-prompt task. Each one untouched. The friction that used to protect me from my own unfinished business is gone .

That's the new guilt. Three words you'll catch yourself thinking , probably this week. Could've prompted it . The friend who pinged me at 11 PM was experiencing the same sentence in real time , just with two years of compound interest attached.

The shame from Chapter 1 makes the cost unspeakable. The could've-prompted-it makes it unbearable . Both at once is the texture of work now.

Here's how it lands, in three layers.

Personal . Before AI, not doing something hard was forgivable . The task was hard. You had a life. You had a job. Hard things take time, and you didn't have time. Now the task isn't hard. The task is two paragraphs of clear instruction and a wait of forty seconds. Not doing it stops looking like a constraint and starts looking like a character defect.

The excuse vanished with the friction. I'm not a writer. I'm not a designer . I don't know how to code . These used to be statements of fact . Now they're statements of choice. You can't hide behind incompetence anymore, because incompetence has a workaround.

So you start prompting things just to feel less guilty. A draft of an email you might not send. A summary of an article you'll probably skim anyway. Code for a script you aren't sure you need. Generation becomes anxiety management. It's the equivalent of opening twenty browser tabs you'll never read , except now the tabs write themselves.

And here's the trap. You aren't doing less work. You're doing different work. You're choosing what to prompt, evaluating whether the output is right, stitching it into something usable . The task moved from production to specification , verification , and integration. The hours didn't disappear. They got denser , and somehow more tiring. Many people , when they're honest about it , report feeling more exhausted than they did before they had the tool . The pitch was less work . The reality is shifted work .

Organizational. The pressure climbs the org chart fast.

Where's the first pass ? Where's the draft? Questions that used to be unreasonable now sound reasonable, because a first pass takes thirty seconds. Nobody arrives empty-handed anymore. Thinking time, the kind that used to happen quietly before you wrote a word, now has to be smuggled in . It doesn't count as output.

Reply times went the same way. Thirty seconds with Claude is the new implicit SLA. The considered email , the one that arrives the next morning after a night of thought, reads like stalling. Slowness is now a luxury good.

And vacation stopped being free . You went to India or Florida. The team channel didn't go quiet. People kept shipping , because your bandwidth was no longer the bottleneck. You come back and find your absence had a measurable cost. It used to be invisible. That was the point of vacation .

Cultural. Outside work, the same machinery runs in your personal life.

Every dormant idea is now accusatory . The novel I wanted to outline. The course I said I'd build. The startup I sketched on a napkin five years ago. Every one of them is two prompts and a Saturday away from at least existing in draft form. My hobbies turn into obligations. Rest starts to feel like a productivity gap.

Even leisure gets prompted. Vacations researched by AI. Hobbies optimized. Books recommended. The unprompted moment , the dumb hour spent staring at a wall, becomes rare and faintly suspect. Are you actually resting, or are you wasting a chance to ask the model something useful?

The comparison floor rose accordingly. What counts as " effort " got recalibrated to post-tool output. Your relative grind doesn't matter . The absolute artifact does . The person sitting next to you with three working side projects didn't necessarily work harder than you. They prompted more. The visible work in your industry is now everyone's post-AI ceiling , and it's the ceiling you're being measured against.

That's the deeper move , and it's the one that does the real damage.

The AI sets a floor of always energetic, always available , always articulate. It doesn't have a bad week. It doesn't get sick. It doesn't have a kid with strep throat and a deadline on Friday. It just answers, well, every time. And once the floor is set, your bad day becomes the failure point . Not because you did less than you used to. Because the comparison shifted underneath you.

The burnout from this isn't the burnout of working too much. It's the burnout of being measured against something that doesn't burn.

That's the line worth carrying out of this chapter. The

thing about the floor is that you can't see it . You only feel it pressing up against you, every time you finish a perfectly reasonable day's work and somehow feel like you fell short.

You did the work. You just didn't do it the way the model would have.

That's the new guilt. Three words you'll catch yourself thinking, probably this week. Could've prompted it . There's a name for the feeling. It's the AI-era cousin of FOMO, and it deserves its own acronym: FONA, the fear of not AI-sking.

Agentic Ledger: an open source flight recorder for AI agents (looking for testers and contributors)

Shekhar Bhardwaj — Mon, 27 Jul 2026 21:35:09 +0000

I have been building an open source tool called Agentic Ledger and it just reached the point where I need more eyes on it than my own. This post is an introduction and an ask.

The problem

AI agents run unattended. They call LLMs in loops, use tools, spawn sub-agents, and spend real money, and most of that happens where you cannot see it. When an overnight coding loop burns $40 getting stuck on the same failing test, or a multi-agent crew quietly retries itself into a huge bill, you usually find out from the invoice.

The observability tools that exist mostly want you to instrument your code with an SDK, and each one speaks one framework. I wanted the opposite: something that watches everything, requires changing nothing, and keeps the data on my machine.

What it is

Agentic Ledger is a transparent proxy that sits between your agent and the LLM provider. You point your agent's base_url at it, and it records every request and response, assigns each call an action id, works out what it cost, and passes the response through untouched. Your agent never knows it is there.

Your Agent  ->  Agentic Ledger Proxy  ->  OpenAI / Anthropic / any gateway
                       |
                SQLite or Postgres
                       |
                Live dashboard + API

No SDK, no decorators, no monkey patching. It works with any framework and any provider because it operates at the only layer they all share: the HTTP call.

Everything is local-first. Your prompts stay in a SQLite file on your machine (or your own Postgres). MIT licensed.

Try it in two minutes

pip install -U agentic-ledger
AGENTICLEDGER_UPSTREAM_URL=https://api.openai.com python -m agenticledger.proxy

Or with Docker (multi-arch, non-root, Sigstore-signed):

docker run -p 8000:8000 \
  -e AGENTICLEDGER_UPSTREAM_URL=https://api.openai.com \
  -v $(pwd)/data:/data \
  ghcr.io/shekharbhardwaj/agentic-ledger:latest

Then point your agent at it:

client = OpenAI(
    base_url="http://localhost:8000/v1",
    default_headers={"x-agenticledger-session-id": "run-1"},
)

For coding agents like Claude Code it is even less work, one env var and zero headers:

export ANTHROPIC_BASE_URL=http://localhost:8000
claude

The dashboard is at http://localhost:8000.

What you get

Real cost accounting. Per call, per session, per agent, per day, including prompt cache reads and writes priced with each provider's own convention. Cache traffic is where most of a coding agent's real spend lives, and most tools ignore it. My rule for this project: the numbers are meant to match your provider bill, and if they do not, that is a bug I want reported.

Loop awareness. This is the part I have not seen anywhere else. The proxy infers agent loops from raw traffic: it stitches ReAct-style threads together, groups fresh-context iterations (Ralph-style overnight loops) into runs, and flags the pathologies that waste money, like the same tool called with the same arguments over and over, or a step budget blowing past its limit. In block mode it acts as a circuit breaker and returns HTTP 429 to a stuck loop instead of letting it burn.

A loop runner. agenticledger run --max-iterations 50 --budget 25 -- <your agent command> re-executes your agent in a loop, attributes every call to the run, and stops on a completion promise, a budget ceiling, or the iteration cap, whichever comes first.

Budgets and rate limits. Hard USD caps per session, per agent, per day, enforced in the request path before the call reaches the provider.

An MCP server. Your agent (or Claude Desktop, or Cursor) can query the ledger about itself: list sessions, explain any call, check whether a run is over budget.

OTLP ingest. Frameworks that already emit OpenTelemetry GenAI spans can send them straight in.

There are step-by-step guides for Claude Code, Codex CLI, opencode, OpenClaw, BMAD-METHOD, LangGraph, CrewAI, OpenAI Agents SDK, Gemini CLI, AutoGen, Pydantic AI, Vercel AI SDK, LiteLLM, and OpenRouter in docs/integrations.

Where the project stands

Honest status: this is a solo project, currently at 0.4.0. The core is solid and tested (100+ tests, CI on three Python versions, signed multi-arch images with SBOMs), and I dogfood it daily against my own coding agents. What it lacks is mileage on other people's stacks. That is exactly the gap you can help close.

The ask

If you run agents, be a tester. Point your stack at the proxy for a day and tell me what broke, what confused you, and whether the cost numbers match your provider console. Ten minutes of your traffic teaches me more than a week of my own.

If you want to contribute, there is real surface area:

Framework guides. If your framework is not in the integrations list, or the guide for it misses something, a PR there is small and immediately useful.
Pricing coverage. The cost table needs to keep up with new models and providers. Adding a model is a one-line change plus a test.
Loop detection heuristics. If you have transcripts of an agent getting stuck in a way the flags miss, I want to see them. This is the most interesting open problem in the project.
Frontend. The dashboard is a small React + Vite app. If you enjoy data-dense UI work, there is plenty to improve.
Postgres at scale. The Postgres backend works, but has not been hammered. If you run heavier traffic, your findings are valuable.

There is a CONTRIBUTING guide in the repo, and I am seeding the issue tracker with starter tasks labeled good first issue. And if none of the above fits but you have opinions on what an agent observability tool should do, open an issue and say so. At this stage, direction feedback matters as much as code.

Repo: https://github.com/ShekharBhardwaj/AgenticLedger
Site: https://agentic-ledger.dev
Install: pip install -U agentic-ledger

Thanks for reading. Come break it.

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