DEV Community: Nikhil Sharma

How often do you review your AI code with another AI? I've noticed Copilot catching some really solid issues in code from GPT-5.6-Sol-High, so it seems like I should be running that "rinse" cycle a few more times to keep things clean.

Nikhil Sharma — Tue, 18 Aug 2026 02:57:17 +0000

How often do you review your AI code with another AI? I've noticed Copilot catching some really solid issues in code from GPT-5.6-Sol-High, so it seems like I should be running that "rinse" cycle a few more times to keep things clean. #ai

Nikhil Sharma — Tue, 18 Aug 2026 02:55:16 +0000

Fighting Fire with Fire: Using LLMs to Conduct In-House Security Audits

Nikhil Sharma — Sun, 16 Aug 2026 19:34:33 +0000

The Problem with Traditional Pentesting

Three weeks ago, I was tasked with performing a security audit on a product I am responsible for building and maintaining. Given the increasing reports of bad actors using AI to weaponize attacks against existing applications, I knew a standard "check-the-box" approach wouldn't suffice.

In my experience, relying on external penetration testers has the following drawbacks:

Cost: They are incredibly expensive.
Velocity: The process can take several weeks.
Depth vs. Compliance: Often, external audits feel like a "check-the-box" exercise. Even with legacy, poorly written code, these audits often fail to find critical logic flaws, instead flagging the same superficial vulnerabilities that a standard tool like OWASP ZAP would catch in minutes.

I wanted to avoid high costs and slow turnaround times. I wanted to: Use AI to defend against AI.

The "Guardrail" Problem

The experiment was not as simple as I expected. I quickly realized that the "safety" protocols built into modern LLMs actually make them difficult to use for security research.

I attempted to use standard coding agents like Claude and Codex, but they were too "polite"-they would identify general threats but failed to find deep, exploitable logic flaws. I then turned to specialized security tools like PentestGPT, only to hit a wall. Most frontier models have strict guardrails; if they sense you are performing cybersecurity testing, they trigger a refusal, often asking you to join a vetted list before they will assist with anything related to exploitation.

The Experiment

On the same day I saw that OpenAI launched the codex-security tool, I assumed that since the provider itself released a dedicated tool, it would work better.

I ran the scan directly against our codebase. After a few hours of whirring through the code and consuming my entire weekly token quota, the results came in.

The results were great! The AI identified several vulnerabilities that were not obvious through standard analysis. These weren't just "best practice" warnings, they were real, exploitable flaws that could have resulted in financial loss for the organization. Had we not run this scan, these flaws likely would have remained hidden until a malicious actor discovered them.

I spent the next several days in a "race to patch" to fix the vulnerabilities the AI surfaced.

The Great Trade-off: Security vs. Privacy

However, this success brings us to a profound, unresolved dilemma in the era of AI-driven development: The Privacy Paradox.

While I gained immense security assurance, I am still not entirely clear on the trade-off I made. By running a deep, exhaustive scan, did I effectively hand over the entire architectural blueprint of my source code to the AI provider?

In an era where AI agents are already integrated into our IDEs and daily workflows, some argue that the "secret sauce" is already out there. Another concern involves the risk of "asymmetric disclosure": If a model identifies a critical vulnerability in your code, is it programmed to tell you, or is it subtly designed to flag that same vulnerability for its provider?

Conclusion

I don't have a definitive answer to the privacy question, so I choose to operate under the assumption of "fair play" for now.

What I do know is that the ROI on AI-driven security scanning is undeniable. For any engineering leader concerned about the speed and cost of traditional audits, I suggest running an AI-driven scan on your code sooner rather than later. The ability to find complex, non-obvious vulnerabilities in a fraction of the time is a tool we can no longer afford to ignore.

Too lazy for Bash: My life with a local AI assistant

Nikhil Sharma — Mon, 10 Aug 2026 02:13:52 +0000

A few days ago I wanted to change something on my local media server.

Normally I'd SSH into it, remember where I'd configured everything, look up a couple of commands I'd forgotten, make the change and move on.

Instead I opened Pi(coding agent) and typed, more or less:

Find out why this isn't working and fix it.

Behind Pi was Qwen3.6-35B-A3B-Q4_K_M running on my own machine.
A few minutes later the job was done.

There is something about this that still feels absurd to me.
I grew up watching Dexter's Laboratory. Dexter would sit inside his secret lab, talk to computers and machines, and somehow the whole laboratory would respond to him.
Obviously my Linux box isn't Dexter's lab. But the interaction is becoming strangely familiar.
I tell my computer what I want rather than precisely how to do it.

I've been experimenting with local models for quite a while now, but only recently they have become useful on the kind of hardware I have. I'm not handing one my serious codebases and telling it to autonomously build features. The models aren't reliable enough for me to trust them that way.

But I've found another category where they're becoming extremely useful:

things I know I could do myself, but don't particularly want to do.

A Bash command. A configuration change. Investigating some service on my media server. A small script. Understanding some obscure error. All this while keeping things private.

The model doesn't need to be a genius for these jobs. It needs to be competent enough that supervising it is easier than doing everything myself.

Another use case is for language learning - the spoken ones - I keep a window to Local LLM open, so that I can ask it meaning of certain words, give me translations, help me refine my language etc, without ever sending my text across the fibre.

And I think that's the part I'm finding more interesting than the models themselves.
For most of my life, operating a computer meant learning its language. Commands. Menus. Configuration files. APIs. We're slowly adding another layer where the computer learns enough of our language that we can meet somewhere in the middle.

Today I have a reasonably capable model running locally, operating my own computer under my supervision. And most of the time I use this little piece of science fiction because I'm too lazy to remember a Bash command.

Fast, local, and offline dictation

Nikhil Sharma — Sat, 01 Aug 2026 01:55:26 +0000

Finally found the local speech-to-text model I have been looking for!

In the latest release of VS Code, I noticed they included a local model (Nemotron) for giving voice commands to your AI agent. After researching it a bit, I discovered the backend uses a very small model that runs entirely locally without heavy lifting.

I learned that Sherpa-ONNX can run these models, so I asked my AI agent to build a simple tool I can trigger with a keyboard shortcut to dictate text directly into my computer. Right now, I am amazed by the results-it is fast and accurate.

After some polish, I plan to release this as a standalone tool. I know everyone "could" build this themselves, but that's still labor you have to put in. Hopefully, releasing it will save a few hours of your time.

Check out the quick demo below to see its speed and accuracy in action.

Demo uses the parakeet-tdt-0.6b-v3-onnx model but nemotron works well too.

I Used to Deride AI Assistants. Then I Met a Stack of Business Cards.

Nikhil Sharma — Sun, 19 Jul 2026 00:18:39 +0000

I used to deride the idea of an AI assistant from the moment they entered the picture (after seeing all the different *Claw variants).

Why would regular people like me need an assistant? The best use case I had heard was: "Oh! It helps us decide whether I or my partner should drive the kids today!" Solving that sounded like a silly problem for an AI assistant to handle. Again, I didn't know any better because I didn't have that problem. I thought I could handle one-off tasks with just an AI subscription. What else was there?

I only found the answer once I had a specific use case for it. I attended a business event, talked to a dozen people, and collected several business cards. I wanted to send each person a personalized email thanking them and continuing our conversation.

If I were to do this manually, the process would look like this: open the email client, manually type in each email address from the business cards, ensure I typed everything correctly, compose my message, and again, make sure I didn't press "send" prematurely. Just thinking about it felt tedious.

That is when the idea of an assistant started making sense. I fire up my coding agent(not a *Claw still), I take a single photo of all the business cards together. I ask the it to extract the names and email addresses. Then, I ask it to loop through the list and ask me what I want to send to each person. It creates drafts(which I still manually review - can't trust them enough), I say send, and then it sends them all automatically.

It feels exactly like talking to a real assistant: you tell them what you want done, and it gets done without you having to press buttons or navigate a UI. That is exactly what I did; I simply gave it instructions using my voice.

This makes me feel that having an AI assistant is indeed helpful. It might have also been useful to jump on this a little sooner, as I could have bought that Mac Mini at the older, lower price.

Stop hiding behind Code (Comfort Zone)

Nikhil Sharma — Fri, 17 Jul 2026 03:06:05 +0000

I missed a chance to take center stage at a networking event yesterday.

Why? Because I chose my comfort zone over actual preparation.

I was heading to a local business meeting and realized I didn't have any physical business cards. As a developer, my immediate instinct was to solve this with technology. I spent my limited prep time building a custom web page and a scannable QR code.

It felt like a smart, modern solution. It wasn't.

When I got to the event, I realized two things very quickly:

The "Tech" is clunky: Asking someone to pull out their phone, unlock it, open the camera, scan a code, and wait for a page to load is a massive amount of friction.

The "Pitch" was missing: Because I spent my time coding, I hadn’t refined my 30-second introduction. When an opportunity arose to take center stage and speak, I didn't take it because I wasn't ready.

The Takeaway: Prioritize the Human Connection

This experience was a harsh reminder that in business, friction is the enemy of connection. By focusing on the "how" (the technology), I completely neglected the "who" (the people) and the "why" (the value I provide).

As developers, we love to optimize processes, but sometimes we optimize for the wrong things. I built a digital handshake, but I forgot that the most effective networking tool isn't a QR code or a business card-it's the clarity of your message and the confidence to deliver it.

Next time, I'm putting the laptop down. I'll be showing up with a clear pitch, a firm handshake, and the courage to take the stage - no code required.

For everyone trying to build something: You are planting seeds. You don't yell at a sprout for growing too slowly. You nurture it and you accept that some plants might not make it. The focus is on the care (fun), not just the harvest (result).

Nikhil Sharma — Tue, 28 Apr 2026 12:09:30 +0000

Software Developers: Redundant or Resilient?

Nikhil Sharma — Sat, 25 Apr 2026 23:23:14 +0000

In the era before AI-assisted coding, my workflow for any feature followed this pattern:

I would analyze the business problem. Even if the Product Manager spent time on it, I would read the documentation and ask clarifying questions. This established a foundational understanding of the problem.
After some back-and-forth discussion, I would begin planning the implementation. This deepened my understanding of the problem.
I would review the existing codebase to identify established patterns and determine what I could reuse. This strengthened my familiarity with the codebase.
If no existing pattern applied, I would research similar scenarios and evaluate design patterns to find the best fit for the problem. This reinforced my coding practices and potentially uncovered new solutions.
Finally, I would start implementing. As I coded, I would continuously consider improvements and alternative approaches. This increased my familiarity with both the problem and the solution.

After completing this process, I could often recall the implementation details and logic from memory during team discussions. If a bug arose, I could usually deduce its cause without immediately inspecting the code, often because I recognized an edge case I had overlooked during implementation.

Overall, this process helped me learn more, retain more knowledge, and perform more of the work myself. These were actually the most fun parts of the process. Today, I spend much of my time reviewing code. However, reviewing is not the same as writing it. As the saying goes in mathematics, you cannot learn simply by reading a textbook; you must engage with the material and put pen to paper.

Maybe times have changed, and I do not even need to know all those details. But then it makes me wonder: am I redundant in this process?

Some people might point out that you bring in taste and judgment. However, what stops a non-developer from showing these skills? They just have to ask AI for alternatives and pick the best solution based on their understanding.

There are still a few places where AI is not as good, especially where there is any integration, whether it involves hardware devices or multiple systems stitched together. However, this mostly covers missing bridges (i.e., AI cannot click buttons on a hardware device or check multiple systems at once). These tasks are limited. Software Engineers working in novel fields might also not feel redundant, but those people are few and far between.

This makes me lean toward "Redundant" as the answer for most dev jobs today. The only way forward seems to be moving to the next level, i.e., truly being an engineer (working with systems that do not exist yet) instead of being a mechanic or developer (working with known systems).

Claude and I aren't vibing at all

Nikhil Sharma — Thu, 23 Apr 2026 02:48:08 +0000

I really enjoyed working with Opus 4.6 in Copilot, especially for tasks that required a bit of creativity (e.g. it was much better at building a landing page compared to GPT-5.3-Codex), but I never got a Claude subscription. I finally did, at last.

After spending 24 hours with Claude Code in VS Code, I've come to the conclusion that it is focused entirely on "vibe coding". It will absolutely do anything to get you to a working solution, even if it isn't best practice.

The code is pretty sloppy. It hardcodes things it should have created configs or constants for. When I asked it to update some sidebar design, along with a change that impacted a common element used globally, I expected it to respect my structure. I have things neatly organized in __sidebar.scss and __global.css, but instead of using each for its own purpose, it stuffed everything into the sidebar file.

It readily fills in the blanks for API calls. For example, while working with the Calendly API, it invented a couple of concepts that looked legit only until I tested them manually and they failed.

Also, the rate limits are insane; you can't just work off a Pro account. Compare this to the fact that I never hit my rate limits on Codex (not even close) or on Copilot, which I was using exclusively just a couple of months ago. People coding entirely on vibes would ask for even the tiniest of things using AI, so it makes sense to extract as much value from them.

Since the code is sloppy, I can imagine the state of the code in a few months. Even if you wanted to maintain it, you would need to ask AI to handle the smallest of tasks because it would be too tiring to comprehend such code.

I also understand now why people need so many prompt files (skills) and whatnot with Claude. It needs a lot of prodding and prompting and has difficulty working off clear instructions at once.

I will still continue giving a piece of my time to it for the next few days, but it seems to have not gotten off to a good start.