DEV Community: Nimesh Kulkarni

AI Is Not Just Replacing Work, It Is Challenging How We Think

Nimesh Kulkarni — Sat, 27 Jun 2026 13:25:58 +0000

For a long time, we treated AI like a tool.

Something that could autocomplete code, summarize long documents, generate images, or answer simple questions. It felt useful, but still limited. The human was always the thinker, and AI was just the assistant.

That line is slowly becoming blurry.

Today, AI can reason through problems, debug code, write product strategies, explain complex systems, generate architecture diagrams, and even challenge our assumptions. It does not just give answers anymore. It can break down problems in a way that looks very close to thinking.

For developers, this is both exciting and uncomfortable.

We used to believe that writing syntax was the main skill. Then AI made syntax cheap. Now we say problem solving matters more. But AI is also getting better at problem solving. It can compare approaches, suggest tradeoffs, identify bugs, and explain why one solution is better than another.

So the real question is not whether AI will overtake human thinking completely.

The better question is: what kind of thinking will still matter?

Blind execution will lose value. Copying tutorials will lose value. Writing basic CRUD apps will lose value. But taste, judgment, creativity, clarity, and understanding real human problems will become more important.

AI can generate ten solutions in seconds, but someone still has to decide which one is actually useful. AI can write code fast, but someone still has to understand the product, the users, the constraints, and the long term impact.

The future developer will not be the person who simply writes code.

The future developer will be the person who knows what to build, why it matters, how to guide AI properly, and how to judge the output with real understanding.

AI may overtake many thinking tasks, but it will also expose who was truly thinking in the first place.

The people who only memorized steps will struggle.

The people who understand systems, ask better questions, and keep learning will become more powerful than ever.

I made my portfolio

Nimesh Kulkarni — Sun, 21 Jun 2026 08:42:23 +0000

This is my portfolio website, My most minimal design yet..!

check it out : https://www.n1m35h.in/

rate it /10

Why I chose a brutalist, ticket-inspired design for Evento's waitlist page

Nimesh Kulkarni — Thu, 11 Jun 2026 18:10:53 +0000

My first post was about the idea behind Evento. This one is about the first thing people actually see before they even understand what it does: the waitlist page.

Most SaaS waitlist pages look the same. Clean sans-serif font, a gradient hero, a centered email input, maybe a subtle animation. Nothing wrong with that. But Evento is not a project management tool or a CRM. It is about real events, real energy, and real people showing up somewhere together. The design had to reflect that.

The direction: ticket-inspired brutalism

I wanted the page to feel like an actual event ticket. Bold contrast, raw typography, barcode details, floating event cards. The kind of visual that makes you feel something before you read a single word.

Brutalism felt right because it is honest. No softness to hide behind. Either it works or it does not.

Sound cues

Tbh this was the most experimental decision. I added subtle sound interactions to the page because events are inherently sensory experiences. A silent waitlist page for an event discovery app felt like a missed opportunity.

What I learned

First impressions on a waitlist page matter more than most founders think. You are not just collecting emails. You are telling people what kind of product they are about to trust.

If you have not seen it yet: https://evento.n1m35h.in/waitlist

Would love feedback from the DEV community, especially on the interaction design choices.

How AI Is Quietly Automating 70% of Customer Support

Nimesh Kulkarni — Wed, 10 Jun 2026 13:57:05 +0000

Customer support automation used to mean rigid chatbots, scripted menus, and irrelevant help centre links.

That is changing fast.

Platforms like Zendesk, Intercom, and Freshworks now use large language models to understand customer questions, search company knowledge, complete basic actions, and escalate complex issues to human agents.

In some deployments, these platforms report automation or resolution rates near 70%.

That does not mean 70% of support jobs have disappeared. It means a large share of repetitive customer conversations can now be resolved without an agent manually handling every step.

What AI Support Agents Can Do

Modern AI agents can:

Understand natural language
Identify customer intent
Search approved documentation
Generate contextual answers
Check order or account information
Process simple requests
Summarize conversations
Transfer difficult cases to humans

Unlike traditional chatbots, they do not depend entirely on fixed decision trees.

A customer can write:

«I paid for the upgrade, but my account is still on the free plan.»

The AI can understand that this is not just a general billing question. It may need to verify the payment, check the subscription status, and escalate the case if the account was not updated correctly.

Why Support Is Easy to Automate

A large percentage of support volume comes from repetitive questions:

How do I reset my password?
Where is my order?
How do I download an invoice?
Can I cancel my plan?
How do I add a team member?

These questions are important, but they usually follow predictable patterns.

AI is good at understanding the request, retrieving the correct information, and presenting it clearly. When connected to business systems, it can also complete the task instead of simply explaining it.

The Human Role Is Changing

AI will not remove the need for human support.

It will change what human agents handle.

AI can manage simple and repetitive requests. Humans can focus on:

Complex technical issues
Sensitive complaints
Security incidents
High-value customers
Unusual exceptions
Retention conversations

AI can also assist human agents by drafting replies, summarizing long conversations, translating messages, and retrieving relevant documentation.

The 70% Figure Needs Context

Not every company will automate 70% of its support volume.

The result depends on:

The quality of the knowledge base
The types of customer questions
Access to business systems
Escalation rules
Workflow design
How resolution is measured

A company with clear documentation and thousands of repetitive questions may achieve a high automation rate.

A company handling legal, medical, financial, or highly technical cases may require more human involvement.

The Biggest Challenge Is Knowledge

AI support agents are only as reliable as the information available to them.

Outdated articles, conflicting policies, and missing documentation can lead to incorrect answers.

This is why AI support projects often become knowledge management projects.

Companies must clean their documentation, remove duplicate information, define clear policies, and continuously review failed conversations.

Final Thoughts

AI is not quietly replacing customer support.

It is quietly automating the predictable parts of it.

Platforms like Zendesk, Intercom, and Freshworks are turning support bots into agents that can understand questions, retrieve information, complete actions, and escalate when necessary.

The goal should not be maximum automation.

The goal should be reliable resolution.

AI should handle repetitive work quickly, while humans remain responsible for the situations that require judgment, empathy, and accountability.

I kept skipping events alone. So I built Evento to fix that.

Nimesh Kulkarni — Sun, 07 Jun 2026 17:32:12 +0000

For a long time I had a habit of finding events I was genuinely excited about and then not going.
Not because I did not want to. Because my friends were busy. Or not interested. Or I just could not bring myself to walk into a room full of strangers alone.
Concerts. Hackathons. Local treks. Community meetups. I would find them, get excited, and then talk myself out of going because I had no one to go with.
At some point I asked myself a simple question. What if I could find someone else who is already going to that same event?
That is Evento.
It matches you with verified people going to the same events as you. Real profiles, verified users, no randomness. Whether you are introverted, shy, or just have a friend group that is always somehow busy on the exact weekend you want to do something, Evento is built for exactly that feeling.
I am not building this for some abstract user persona. I built it because I was tired of skipping things I actually wanted to do.
Launching in few days. If this sounds like something you have needed, the waitlist is open right now.
https://evento.n1m35h.in/waitlist

AI Companies Are Paying Millions for Your Old Reddit Posts. Here's Why That Should Concern You.

Nimesh Kulkarni — Sat, 06 Jun 2026 10:06:04 +0000

I am so tired of opening my code editor and seeing the same AI-generated dashboard. Same layout. Same gradient. Same components. It all looks like it came out of the same broken photocopier.

Here is what is actually going on.

Models trained on AI output degrade over time. Researchers call it model collapse. Every generation trained on synthetic data gets slightly worse than the last. Diversity drops. The weird, specific, human stuff disappears. Everything drifts toward a boring average.

By April 2025, over 74% of newly created webpages had AI-generated text in them. Stack Overflow drowned in AI answers overnight. Content farms switched to pure synthetic output the moment it became cheap enough.

The web is now mostly a mirror reflecting a mirror.

So what are OpenAI, Google, and Anthropic doing about it? They are going back to the old internet. Pre-2022. Before the flood. Google signed a $60 million per year deal with Reddit just to access your old posts. OpenAI did the same. Anthropic got sued for taking it without asking.

Your decade-old forum arguments and niche shitposts are now formally worth more than anything being written today. That is not an exaggeration. That is a business decision backed by hundreds of millions of dollars.

Every boilerplate component you copy from an AI, every SEO article generated in bulk, every "here is a step by step guide" that reads like nothing, is feeding a loop that makes the whole thing worse.

I do not have a clean solution to pitch at the end of this. I am just a developer who is bored and annoyed that genuine human output has become the scarce resource in a world drowning in content.

Write something real. Even if it is ugly.

Vite Just Got a Bigger Engine: Why VoidZero Joining Cloudflare Matters

Nimesh Kulkarni — Fri, 05 Jun 2026 12:33:31 +0000

If you build frontend apps in 2026, there is a good chance Vite is somewhere in your workflow. Maybe directly. Maybe through your framework. Maybe through a test runner, plugin, or starter kit you barely think about anymore.

That is why VoidZero joining Cloudflare is worth paying attention to.

VoidZero is the team behind Vite, Vitest, Rolldown, Oxc, and Vite+. Cloudflare says those projects will stay open source, vendor-agnostic, and community-driven. The interesting part is not “company acquires tooling team.” The interesting part is what this signals for the next phase of JavaScript tooling: faster, more integrated, and closer to production runtimes.

The JS toolchain is finally consolidating

For years, frontend tooling felt like a group project where everyone submitted a different build system at 11:59 PM.

Bundler here. Transpiler there. Test runner somewhere else. Dev server doing its own thing. Then your production runtime casually has different behavior because, of course, why not.

Vite changed the default expectation: local dev should feel instant, framework authors should get a solid foundation, and teams should not need a PhD in build configs just to ship a button.

VoidZero pushes that further with projects like:

Vitest for fast testing that feels native to Vite projects
Rolldown as a Rust-powered bundler direction for the ecosystem
Oxc for fast parsing, transforming, linting, and formatting foundations
Vite+ as a commercial layer around the open tooling

The vibe is clear: less glue code, fewer duplicated pipelines, faster feedback loops.

Why Cloudflare is an interesting home

Cloudflare has been leaning hard into developer infrastructure: Workers, Pages, D1, KV, R2, Durable Objects, Workflows, AI tooling, and local development around workerd.

The key developer pain here is simple: local dev should match production more closely.

Cloudflare’s Vite plugin already runs server code inside workerd, the same open-source runtime model behind Workers. That means you can test platform features locally without pretending everything is just Node.js.

That is a big deal. Ngl, “works locally, breaks in production” is one of the least funny recurring jokes in web dev.

What developers should actually do now

Do not rewrite your stack because of one announcement. That is how we summon yak-shaving demons.

Instead, make a small practical check:

npm create vite@latest
npm install -D vitest

If you are already on Vite, review whether your project still has old build/test glue that Vite-native tooling can replace. If you deploy to edge or serverless runtimes, check whether your framework has a runtime-aware Vite integration instead of relying on generic Node-only assumptions.

Also, keep an eye on Rolldown and Oxc. Not because you need to migrate today, but because the performance work happening there will likely show up through frameworks and tools before most app teams touch it directly.

The takeaway

VoidZero joining Cloudflare is not just frontend ecosystem gossip. It is another sign that the JavaScript toolchain is moving from “many separate tools wired together” toward “one faster pipeline from dev to deploy.”

For developers, the win is simple: fewer weird config layers, faster feedback, and local environments that behave more like production.

That is the kind of boring infrastructure improvement that quietly makes everyone ship better software. Lowkey, those are the best ones.

Kubernetes Dashboard Is Passing the Baton — Headlamp Is the Upgrade Path

Nimesh Kulkarni — Thu, 04 Jun 2026 12:34:18 +0000

Kubernetes Dashboard has been that classic “first window into the cluster” for a lot of devs. You install it, click around pods and services, and suddenly Kubernetes feels less like dark magic.

But the Kubernetes project is now clearly pointing users toward Headlamp as the modern replacement path. And honestly? That makes sense.

This is not just a UI swap. It is a small signal about where Kubernetes tooling is going: less “one built-in dashboard for everyone” and more extensible, safer, workflow-friendly interfaces around real cluster operations.

Why this shift matters

The old Dashboard solved a real onboarding problem: “What is running in my cluster?”

But production Kubernetes teams need more than that:

clearer visibility across namespaces and workloads
safer access patterns for different users
plugin-friendly workflows
better alignment with modern cluster operations
a UI that can grow without becoming a giant one-size-fits-all panel

That is where Headlamp is interesting. It is a CNCF project built as a Kubernetes UI that can be extended, embedded into workflows, and used across different cluster setups.

Lowkey, this is exactly what Kubernetes tooling needed. Not another shiny control panel. A better foundation.

The practical developer takeaway

If you are still using Kubernetes Dashboard for learning or lightweight inspection, you do not need to panic-migrate today.

But if you are building team workflows, internal platforms, or anything close to production, start treating Headlamp as the thing to evaluate next.

A simple migration mindset:

Learning cluster / quick inspection
  -> Dashboard is okay for now

Team platform / shared cluster UI
  -> Evaluate Headlamp

Production ops workflow
  -> Combine UI access with RBAC, audit logs, and CLI/GitOps flows

The important part is not “UI vs CLI.” Real teams use both. The UI helps people understand and inspect. The CLI and GitOps pipelines keep changes controlled and repeatable.

Do not skip the boring security bits

Any Kubernetes UI is only as safe as the permissions behind it.

Before rolling one out, check:

Does every user have the minimum RBAC they need?
Are admin actions limited to the right people?
Is access behind SSO or your normal identity layer?
Can you audit who viewed or changed what?
Are destructive actions restricted?

Because a beautiful cluster UI with overpowered permissions is just a very polished footgun. Fr.

My take

The Dashboard-to-Headlamp transition is a healthy move. Kubernetes is mature enough now that the default UX should not just be “show me objects.” It should support real operational workflows.

For developers, the move is simple: keep using visual tools to learn faster, but design production access like an engineering system, not a convenience shortcut.

Actionable takeaway: if your team exposes a Kubernetes UI, review the RBAC model this week and test Headlamp in a non-prod cluster before the migration becomes urgent.

Agent-Native Desktops Are Coming: Code Review Is the First Workflow to Fix

Nimesh Kulkarni — Wed, 03 Jun 2026 12:32:46 +0000

AI coding tools are moving from “chat box next to your editor” to something much more serious: agent-native developer environments.

GitHub just pushed this direction hard with the Copilot app and desktop-style agent workflow announcements. OpenAI is also framing Codex as a broader productivity layer, not just a coding prompt. The signal is pretty clear: agents are becoming part of the work surface, not a side quest.

That sounds futuristic, but for most teams the first real place to care is boring and practical: code review.

The problem is not generation anymore

Generating code is no longer the impressive part. Most teams already know an AI assistant can draft a component, write tests, explain a stack trace, or refactor a file.

The messy part is everything after generation:

Which agent changed what?
Did it understand the existing architecture?
Are the tests meaningful or just green-looking?
Is the diff safe enough to merge?
Who owns the final decision?

Ngl, this is where “AI boosted my productivity” can quietly become “AI created a review queue I do not trust.”

Agent-native means workflow-native

An agent-native desktop should not just be a nicer chat UI. The useful version gives agents a real workflow:

Task context: issue, branch, constraints, and acceptance criteria
Workspace access: repo, terminal, tests, docs, and dependency graph
Change tracking: clean diffs, summaries, and decisions made
Review gates: lint, tests, security checks, human approval
Memory boundaries: what the agent can reuse, forget, or escalate

That is the difference between “vibe coding with a powerful autocomplete” and “delegating a small engineering task with guardrails.”

Start with the review loop

If your team wants to adopt agentic coding without chaos, do not begin by letting agents ship bigger features. Begin by making reviews easier to trust.

A practical setup can be simple:

agent_review:
required:
- summarize_diff
- list_risk_areas
- run_tests
- flag_security_sensitive_files
- explain_remaining_uncertainty
human_decision: required

The magic is not the YAML. The magic is forcing the agent to show its work before a human approves the merge.

What developers should watch next

The next wave of dev tools will compete on orchestration, not just model quality. The best tools will help us manage multiple small agents, compare their changes, rerun checks, and keep review context visible.

That is a big deal because developers do not need more random AI output. We need tighter loops, cleaner diffs, and less context switching.

Takeaway

Agent-native desktops are worth watching, but do not wait for the perfect tool. Start designing your workflow like agents are junior teammates: give them scoped tasks, require evidence, and keep humans in charge of merge decisions.

That is how AI coding becomes useful in real teams: not louder, just safer and smoother.

Stop Shipping Blob Tokens: OIDC Is the Cleaner Deploy Secret

Nimesh Kulkarni — Tue, 02 Jun 2026 12:34:29 +0000

Ngl, one of the easiest ways to make a deployment pipeline sketchy is to give it a long-lived storage token and hope nobody ever leaks it.

That pattern is still everywhere: CI uploads static assets, build artifacts, screenshots, or user-facing files to some blob bucket, and the workflow stores a token in secrets.BLOB_TOKEN forever.

It works.

It also quietly creates a key that can outlive the job, the branch, the intern who created it, and sometimes the entire project. Big yikes.

The better pattern that keeps showing up across modern platforms is OIDC-based deploy auth: your CI job proves who it is, asks the provider for short-lived access, does the upload, and disappears.

The old flow

Most teams start here:

- name: Upload assets
  env:
    BLOB_TOKEN: ${{ secrets.BLOB_TOKEN }}
  run: npm run upload-assets

Simple, but the risk is obvious:

the token sits in your repo/org secrets forever
rotation becomes another chore nobody owns
leaked logs, compromised runners, or copied workflows can turn into real access
every workflow tends to get more permission than it actually needs

For a side project, maybe that feels acceptable. For production pipelines, it becomes tech debt with security vibes.

The OIDC flow

With OIDC, GitHub Actions or another CI provider can request an identity token for the current job. The cloud/storage platform verifies claims like repo, branch, environment, and workflow, then issues temporary credentials.

The workflow shape becomes closer to this:

permissions:
  id-token: write
  contents: read

jobs:
  upload:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Upload assets with short-lived auth
        run: npm run upload-assets

The actual provider setup differs, but the idea is the same: trust the workload identity, not a copied secret string.

This is why recent platform updates around OIDC for blob/storage workflows are worth paying attention to. They are not just “nice auth features.” They are a signal that deployment secrets are moving from static keys to verified, short-lived identity.

Why developers should care

This is not only a security-team thing.

OIDC makes day-to-day engineering cleaner:

fewer secrets to create, share, rotate, and audit
safer preview deployments from protected branches or environments
tighter permissions per repo/workflow instead of one mega-token
less panic when someone accidentally prints an env var in CI

Tbh, the best security improvements are the ones that remove a thing you had to remember. OIDC does exactly that.

A quick migration checklist

If your build uploads anything to blob storage, artifact storage, package registries, or cloud buckets, check this:

Is the workflow using a long-lived token?
Does the provider support OIDC or workload identity federation?
Can access be scoped by repo, branch, workflow, or environment?
Can the token be removed after the OIDC path works?

Do not migrate everything in one heroic PR. Pick one low-risk upload job, move it to OIDC, and document the pattern for the next workflow.

The takeaway

Long-lived deploy tokens were convenient when CI/CD was simpler.

But now that pipelines publish assets, trigger releases, talk to AI services, and touch production infra, “just store a token” is starting to look outdated.

If a platform gives you OIDC for deploy-time storage access, use it. Your future self will have one less secret to babysit — and that is a clean W.

Multi-Agent Code Reviews Need Pipelines, Not Vibes

Nimesh Kulkarni — Mon, 01 Jun 2026 12:36:23 +0000

Most teams are about to hit the same AI coding problem: one agent can write a lot of code, but it cannot be the only judge of its own work.

That is where multi-agent review starts to matter.

The next useful dev workflow is not “ask the model to be careful.” It is a pipeline where different agents own different checks, and boring deterministic tools still do the boring deterministic work.

The single-agent trap

A coding agent can implement a feature, update tests, and explain the diff. That is already powerful.

But if the same agent writes the code, reviews the architecture, checks security, decides whether tests are enough, and summarizes the risk, you are basically asking one intern to approve their own pull request.

That is not a workflow. That is optimism with a CLI.

A better pattern

Think of AI agents like specialized reviewers in your engineering loop:

Implementation agent: writes the first version of the change.
Test agent: looks for missing cases, edge conditions, and regression gaps.
Security agent: checks auth paths, secrets, injection risks, unsafe dependencies, and data exposure.
Architecture agent: watches for coupling, weird abstractions, and changes that fight the existing system.
Summary agent: turns the mess into one clean PR comment humans can actually use.

The point is not to add AI everywhere. The point is to stop pretending one model pass is enough.

CI is the control plane

The cleanest place to run this is still CI.

A practical pull request flow can look like this:

Run lint, type checks, unit tests, and build checks.
Trigger focused AI reviewers only after the deterministic checks finish.
Give each reviewer a narrow prompt and a narrow permission scope.
Collect findings into one review summary.
Escalate only the risky or uncertain parts to a human.

This keeps the workflow grounded. Traditional tools catch facts. Agents catch judgment-heavy issues.

MCP makes this easier, but also riskier

With MCP and similar tool layers, agents can access GitHub, CI logs, docs, issue trackers, observability tools, and internal systems through a standard interface.

That is exactly why the pattern is useful.

It is also exactly why permissions matter.

Start read-only. Log every tool call. Scope access to specific repos and workflows. Do not give an AI reviewer write access just because the demo looked clean. If it can comment on a PR, that is already useful. If it can merge, deploy, or mutate infrastructure, that needs a much higher bar.

The real upgrade

The future of AI coding is not one giant prompt that does everything.

It is smaller agents, clearer jobs, shared context, deterministic checks, and human attention saved for the decisions that actually need taste.

Multi-agent code review is not about replacing review culture.

It is about making review culture scale when AI starts generating more code than humans can comfortably inspect line by line.

Markdown Is Becoming the AI App Interface

Nimesh Kulkarni — Sun, 31 May 2026 12:35:12 +0000

A quiet developer pattern is getting louder: Markdown is becoming the interface layer for AI apps.

Microsoft's markitdown project has been trending because it solves a boring problem that keeps showing up in real products: how do you turn PDFs, Word files, slide decks, spreadsheets, and HTML pages into something an AI system can actually use?

The answer is not glamorous. Convert the mess into Markdown.

That sounds too simple, but it works because AI apps do not fail only at the model layer. They fail when the input is messy, hidden, lossy, or impossible to inspect.

Why Markdown keeps winning

Markdown has a boring superpower: everyone can read it.

A developer can open it in a terminal. Git can diff it. Static sites can render it. LLMs can follow headings, lists, code blocks, and links without needing a custom parser for every file type.

That makes Markdown a solid handoff format between real-world documents and AI workflows.

PDF / DOCX / PPTX / HTML
        ↓
Markdown
        ↓
cleanup + validation
        ↓
search, RAG, summaries, agents, docs

The important part is not "Markdown is cool." The important part is that Markdown gives your pipeline a visible middle layer.

If the output is bad, you can inspect the Markdown and see where the context broke.

The use case that matters

Imagine an internal AI assistant for a support or engineering team.

The source material is never clean. There are old onboarding docs, customer PDFs, policy pages, architecture notes, product specs, and random exports from tools nobody wants to maintain.

Without a common format, every file type becomes a separate problem.

With Markdown, the flow is simpler:

markitdown product-spec.pdf > product-spec.md

Then the app can clean it, split it by headings, index it, summarize it, or pass selected sections into an agent.

That is the real win. Markdown becomes the boring contract between messy documents and useful AI behavior.

Where this helps right now

This pattern is useful when teams want to:

turn support docs into searchable knowledge
feed architecture notes into coding agents
migrate old documents into a docs site
build lightweight internal knowledge bases
keep AI context auditable instead of hiding it inside a black-box parser

The last point matters. When an AI answer is wrong, the team needs to debug the context, not just blame the model.

If the context is Markdown, you can read it. You can diff it. You can fix it.

The trap

Conversion is not magic.

Tables can break. Scanned PDFs may need OCR. Images can disappear. Slide decks can lose structure. Footnotes can land in weird places.

So the pipeline should not be:

convert -> trust blindly -> ship

It should be:

convert -> validate -> normalize -> use

A small validation step saves a lot of weird AI behavior later.

Takeaway

Markdown is becoming more than a writing format. It is becoming a practical interface for AI apps.

Before adding another vector database, agent framework, or prompt trick, check the boring thing first: is the input clean, readable, and inspectable?

Most AI products get better when the context gets better. Markdown is one of the simplest ways to make that happen.