DEV Community: NITISH Sharma

I Built a Modern Blog Website Using Vibe Coding

NITISH Sharma — Fri, 24 Jul 2026 07:01:32 +0000

"Vibe coding" has been impossible to avoid the last few months — describe what you want in plain English, watch an AI generate the app, ship it. I'd used AI tools as a coding partner before, mostly for systems-level work in C++, where I'm reviewing generated code line by line anyway. What I hadn't done was hand something a full frontend from scratch and see how much of that same "describe it, review it, steer it" workflow actually held up outside my comfort zone.

So I picked a real project instead of a toy one: my personal blog. Small enough to fully understand end to end, substantial enough that routing, layout, and content structure would actually surface real friction if the tool couldn't handle them.

This is what that process actually looked like — including the parts that didn't just work on the first try.

What Vibe Coding Means to Me

I want to be upfront about the frame I went in with, because "vibe coding" gets talked about two very different ways.

One version treats it like a replacement for knowing how to build software — describe the vibe, get the app, never look at the code. That's not what this was.

The version I actually used treats AI as a fast, very literal collaborator: it can generate a huge amount of working structure from a description, but it doesn't know what "good" looks like for my project, and it doesn't catch its own mistakes. That part's still on me. So in practice:

I described intent, not implementation details — what the blog should do, not which components to use
I reviewed what came back before trusting it, the same way I'd review a pull request
I made the actual architectural calls — what pages exist, how content is structured, what stays out of scope
I stepped in to fix or rewrite anything that was subtly wrong rather than just "looked" right in the preview

The skill that mattered wasn't typing less code. It was asking clearer questions and knowing when to stop trusting the preview and go read the actual output.

The Idea Behind My Blog

I already write longer technical pieces on dev.to, but I wanted one place that was fully mine — for project write-ups (the kind of deep-dive I did on building a packet sniffer with libpcap) tied directly to how I want to be positioned professionally. The site's tagline sums up the intent pretty directly: Systems Programmer & Security Engineer.

The brief for the blog itself was deliberately narrow: fast, readable, no CMS overhead, nothing that gets in the way of the writing. A blog is exactly the kind of project where the content should be the interesting part, not the platform underneath it — which also made it a fair test case for vibe coding, since I wasn't trying to build something architecturally novel.

The Technologies Used

I built it using Google AI Studio's Build mode, which generates a full React application from a natural-language description. A few specifics about how it actually works, since "vibe coding" tools vary a lot underneath the same marketing term:

A two-pane interface: a chat panel for describing what you want, and a live code editor + preview pane showing the actual generated project
An annotation mode that lets you click directly on an element in the preview and describe a visual change, instead of describing "the button in the top right" in words
A Code tab that shows the real generated source — not a black box, an actual editable React project
One-click deploy, which is exactly how the site ended up live at a .ai.studio subdomain in the first place

No custom backend — a blog doesn't need one, and keeping that scope small mattered for how well the AI-generated result would actually hold up.

A rough shape of the kind of prompt that kicks off a build like this:

Build a minimal, modern personal blog in React.
Home page: list of posts with title, date, short excerpt.
Post page: full article content, clean typography, no sidebar clutter.
No backend — content should be easy to add as static entries.
Dark, minimal aesthetic. Fast load, no unnecessary animation.

My Development Workflow Using AI

The rhythm ended up being closer to iterative pair programming than "one prompt, done":

Start broad — one prompt describing the overall structure and pages, to get a working skeleton fast
Iterate conversationally — follow-up prompts to adjust layout, spacing, and typography, using the annotation tool for anything visual instead of describing it in words
Actually read the Code tab — periodically stopping to look at what got generated rather than just trusting that the live preview looked right
Fix by hand where needed — anything that was subtly off got corrected directly rather than re-prompted into a worse state

[Add here: one specific real example of a refinement loop you went through — e.g. a particular layout tweak, a piece of content structure you had to re-prompt several times to get right.]

Challenges I Faced (and How I Solved Them)

The biggest one wasn't a bug — it was scope. Tools like this are genuinely good at producing a working prototype fast, but the well-documented gap across this entire category (not just this one) is production-readiness: things like persistence, proper error handling, and security hardening aren't there by default. A generated blog looks finished in the preview long before it's actually finished.

Concretely, that meant:

Treating the first generated version as a draft to review, not a shippable result
Going through the actual source in the Code tab rather than assuming the preview told the whole story
Being the one to decide what "done" meant — the tool has no opinion on that, and won't tell you when it's cut a corner

[Add here: the specific challenge or bug you actually hit while building this — what broke, how you noticed, how you fixed it.]

What AI Did Well

To be fair to the tool, a few things about this workflow were genuinely impressive:

Scaffolding speed — skipping the "blank React project, routing, build config" setup tax entirely and starting from a working skeleton
Visual iteration — the annotation/click-to-edit flow made small design tweaks fast without hand-writing CSS for every adjustment
Context retention — it kept track of the whole project across a long back-and-forth conversation rather than losing the thread between prompts, which is where a lot of earlier AI coding tools used to fall apart

For a solo side project, that speed genuinely changed how much I was willing to attempt in a weekend.

Where AI Struggled — and Why Developer Judgment Still Mattered

The flip side of that speed: the tool has no sense of what "finished" means for my specific project. It'll happily generate something that looks complete in a live preview while quietly skipping things a shipped product actually needs — error states, edge cases, the boring-but-necessary parts.

That's not a knock on the tool so much as a description of what it's actually for: fast, high-quality scaffolding, not a substitute for someone who knows what a finished product should look like. Every decision about scope, priorities, and what "good" meant for this specific blog was still mine to make — the prompt doesn't make architectural decisions, it just executes on the ones you've already made, whether or not you've made them well.

Vibe coding compresses the blank-page problem, not the judgment problem. Getting from zero to something working got dramatically faster. Knowing what "something good" actually looks like didn't get any easier — that part's still entirely on the developer.
Reading the generated code isn't optional if you're shipping it. The preview can look finished while the code underneath is not.
Clear, specific prompts beat vague ones, exactly like clear, specific tickets beat vague ones on any team — "vibe" is doing a lot of work in "vibe coding," but specificity still wins.
The fastest path to a good result is still knowing roughly what good looks like before you start prompting — the tool amplifies direction, it doesn't supply it.

Final Thoughts: Would I Use Vibe Coding Again?

Yes — specifically for this category of project. Personal tools, prototypes, low-stakes frontends where I want to get from idea to something real fast, and where I'm going to review and finish the result myself rather than ship the first output verbatim. I wouldn't treat it as a blanket replacement for writing code by hand, especially anywhere production-readiness, security, or genuinely novel architecture actually matters — that's exactly where the gap between "impressive demo" and "finished product" shows up.

What it did change is how much I was willing to attempt for something like a personal blog, where the writing was always supposed to be the point, not the frontend plumbing underneath it.

If you've tried vibe coding yourself — whether it was AI Studio, or something else entirely — I'd genuinely like to hear how it went for you. What worked, where you had to step in and take over, and whether it changed how you think about your own workflow. Drop it in the comments; I'm curious how consistent this experience actually is across different tools and project types.

Building a Packet Sniffer in C++ with libpcap (And the Segfault That Taught Me a Lesson)

NITISH Sharma — Wed, 22 Jul 2026 14:24:07 +0000

I'm a CS student working toward a portfolio in AI/ML, DevOps, and cybersecurity, and one of the bigger projects on that list is NetSentinel — an ML-based intrusion detection system. You can't detect anomalies in network traffic if you can't first read network traffic, so before touching any machine learning, I went back to basics: write a packet sniffer in C++ using libpcap.

This post is the story of that sniffer — what it does, the bugs it taught me the hard way, and the refactor that mattered more than any single feature I added.

Why libpcap, and what even is a `pcap_t`?

libpcap is the C library behind tools like tcpdump and Wireshark's capture engine. It gives you raw access to packets flowing across a network interface, before any of your OS's normal socket machinery gets involved.

The first thing that trips people up is pcap_t — the handle you get back when you open a capture session:

pcap_t *descr = pcap_open_live(device_name, MAXBYTES2CAPTURE, 1, 512, errbuf);

pcap_t is what's called an opaque struct — you get a pointer to it, but you never see or touch its internal fields. Every single thing you do with it goes through a function call: pcap_loop() to start capturing, pcap_setfilter() to configure it, pcap_close() to tear it down. You never write descr->something.

If that pattern feels familiar, it should — it's the exact same shape as a FILE* from <cstdio>, or a sqlite3* from SQLite's C API. Open, operate through functions, close. Once that clicked for me, a bunch of other C libraries suddenly felt less mysterious.

Letting the user pick a device

The very first version of this sniffer just auto-picked whatever device pcap_lookupdev() handed back (deprecated now, but fine for a first pass). The obvious next step was letting the user choose — laptop Wi-Fi, loopback, whatever.

pcap_findalldevs() gives you a linked list of every available interface:

pcap_if_t *alldevs;
pcap_findalldevs(&alldevs, errbuf);

for (pcap_if_t *d = alldevs; d != nullptr; d = d->next) {
    std::cout << d->name << '\n';
}

Interesting detail: unlike pcap_t, a pcap_if_t is not opaque. d->name, d->next, d->description are plain, directly-accessible fields — no accessor functions needed. The two types sit at opposite ends of "how much the library hides from you," and it's a nice example of a library only hiding what actually needs hiding.

I wrote a small helper to walk the list by index so a user could type a number instead of a device name:

pcap_if_t* selectNodeByIndex(pcap_if_t* head, int targetIndex)
{
    if (targetIndex < 0) return nullptr;

    pcap_if_t* current = head;
    int currentIndex = 0;

    while (current != nullptr) {
        if (currentIndex == targetIndex) return current;
        currentIndex++;
        current = current->next;
    }
    return nullptr;
}

Looked done. It was not done.

The segfault: a classic use-after-free

Here's what my main() looked like right after wiring device selection in:

std::cout << "Opening device: " << selectedDev;
pcap_freealldevs(alldevs);
descr = pcap_open_live(selectedDev->name, MAXBYTES2CAPTURE, 1, 512, errbuf);

Run it, print the device list, type a number... segfault. Instantly.

The bug: selectedDev isn't a separate copy of anything — it's a pointer into the same linked list alldevs owns. pcap_freealldevs(alldevs) walks the whole list and frees every node in it, including the exact node selectedDev points to. The very next line dereferences selectedDev->name — memory that had just been freed.

Two variables, two different names, pointing at overlapping memory. Freeing one silently invalidates the other, and nothing about the code looks wrong — that's what makes use-after-free bugs so nasty compared to, say, a syntax error.

The fix was just reordering — finish reading from the list before freeing it:

std::cout << "Opening device: " << selectedDev->name << '\n';

descr = pcap_open_live(selectedDev->name, MAXBYTES2CAPTURE, 1, 512, errbuf);
if (descr == nullptr) {
    std::cerr << "pcap_open_live failed: " << errbuf << '\n';
    pcap_freealldevs(alldevs);
    return 1;
}

pcap_loop(descr, -1, processPackets, reinterpret_cast<u_char*>(&count));
pcap_freealldevs(alldevs);   // only free once nothing still points into it

The lesson that stuck with me: before calling free/delete/pcap_freealldevs on anything, the real question isn't "am I done with this variable" — it's "does anything else still point into this memory."

The quiet failure: when nothing crashes, but nothing happens either

Bug #2 was sneakier because there was no crash at all. I'd pick loopback, see "Opening device: lo" print... and then the program would just exit. No error, no packets, nothing.

Turns out pcap_open_live() can succeed at opening the handle even without the right privileges — the actual failure happens later, on the first internal read inside pcap_loop(), and I wasn't checking its return value:

int result = pcap_loop(descr, -1, processPackets, reinterpret_cast<u_char*>(&count));
if (result == PCAP_ERROR) {
    std::cerr << "pcap_loop failed: " << pcap_geterr(descr) << '\n';
}

Once I added that check, the actual problem showed up immediately: permissions. Capturing raw packets needs CAP_NET_RAW/CAP_NET_ADMIN, which a normal user doesn't have by default:

sudo setcap cap_net_raw,cap_net_admin=eip ./simplesniffer

The real takeaway here: check return values from anything that can fail silently. A function returning early with an error code and a function succeeding can look identical if you never look at what it returned.

Actually parsing packets: peeling layers one at a time

With capture working, the fun part: turning raw bytes into something meaningful. A captured frame is layers stacked back to back in memory — Ethernet header, then IP header, then TCP/UDP/ICMP, then payload. You don't copy anything to get at each layer; you just reinterpret the same buffer at increasing offsets:

const struct ether_header* eth = reinterpret_cast<const struct ether_header*>(packet);
uint16_t etherType = ntohs(eth->ether_type);

if (etherType == ETHERTYPE_IP) {
    parseIPv4(packet + sizeof(struct ether_header),
              caplen - sizeof(struct ether_header));
}

Two details bit me here that are worth knowing up front:

Byte order. Multi-byte fields like ether_type and port numbers arrive in network byte order (big-endian), and my CPU is little-endian. Skipping ntohs()/ntohl() means comparing the right bytes in the wrong order — the classic "why is this never matching" bug.
Variable header length. struct ip's ip_hl field is a word count, not a byte count, because IP headers can carry optional fields. Forgetting to multiply by 4 means computing the wrong offset for everything after it.

The full pipeline ended up as: parseEthernet → check EtherType → parseIPv4 → check protocol number → parseTCP/parseUDP/parseICMP. Each function only ever needs to know about its own header — no function reaches backward or forward across layers it doesn't own.

The refactor that mattered more than any feature

Here's the part I actually want other people building similar tools to take away.

My first working parser looked like this — each function found something, and immediately printf'd it:

void parseIPv4(const u_char* packet, int caplen)
{
    // ...parse the header...
    std::printf("[ip] %s -> %s | protocol %d\n", srcIp, dstIp, iph->ip_p);
}

It worked. It was also a dead end. If I ever wanted to save packets to a file, group them into flows, or hand features to an ML model — all actual requirements for NetSentinel — I'd have had to re-parse the same raw bytes all over again, because the only "output" of parsing was text on a terminal.

The fix: stop printing inside the parser. Parse into a plain data struct instead, and let something else decide what to do with it:

struct PacketInfo
{
    uint8_t  srcMac[6] = {0};
    uint8_t  dstMac[6] = {0};
    uint16_t etherType = 0;

    bool        hasIPv4 = false;
    std::string srcIp;
    std::string dstIp;
    uint8_t     protocol = 0;
    uint8_t     ttl = 0;

    bool     hasTransport = false;
    uint16_t srcPort = 0;
    uint16_t dstPort = 0;
};

Every parse* function now takes a PacketInfo& and fills it in instead of printing:

void parseIPv4(const u_char* packet, int caplen, PacketInfo& info)
{
    // ...same parsing logic as before...
    info.hasIPv4  = true;
    info.srcIp    = srcIp;
    info.dstIp    = dstIp;
    info.protocol = iph->ip_p;
    info.ttl      = iph->ip_ttl;
}

Printing becomes one function, called once, after parsing is completely done:

PacketInfo info;
parseEthernet(packet, caplen, info);
printPacketInfo(info);   // the ONLY function that touches stdout now

The satisfying confirmation that this actually worked: my parser's .cpp file no longer needed to #include <cstdio> at all. Zero output dependency, anywhere in the parsing code. Anything that wants packet data now — a flow tracker, a CSV writer, a feature extractor for a model — just becomes another reader of PacketInfo. None of them will ever need to touch a raw byte buffer.

One small design detail worth calling out: notice the bool hasIPv4 flag sitting next to the IP fields. Not every frame is IPv4 — some are ARP, some IPv6 — and without that flag, an unparsed packet's srcIp/ttl would just sit at their zero-initialized defaults with no way to tell "genuinely empty" apart from "never reached this layer." Every optional layer in the struct follows that same has-flag pattern.

What's next

The plan from here is to build outward from PacketInfo rather than back into raw bytes:

Group packets into flows (keyed by source/destination IP + port + protocol) and track stats per flow — packet counts, byte counts, duration
Export flow records so a Python pipeline can train a baseline anomaly-detection model on them
Eventually feed live traffic through that trained model for real-time flagging — the actual "intrusion detection" part of NetSentinel

None of that would be possible in a sane way if every consumer still had to re-parse raw Ethernet frames from scratch. That's the whole reason this refactor came before any of it.

Try it yourself

If you want to see this working without needing real suspicious traffic: capture on loopback and generate traffic yourself.

sudo ./simplesniffer     # pick the loopback interface

In a second terminal:

ping -c 3 127.0.0.1

You'll see the layered output for each ICMP echo request/reply. Swap ping for nc -l 127.0.0.1 9999 and echo "hello" | nc 127.0.0.1 9999 in two more terminals if you want to see the TCP path instead.

Lessons that generalize past this one project

Opaque handles (pcap_t, FILE*, sqlite3*) all follow the same shape: operate through functions only, never touch fields directly.
Use-after-free doesn't always look wrong. Two differently-named pointers can point into the same memory — freeing one silently breaks the other.
Check return values from anything that can fail without crashing. A silent early return and a full success can look identical from the outside.
Decouple "compute the answer" from "do something with the answer." The moment your parsing/logic function starts calling printf (or writing to a file, or hitting a network socket) directly, you've locked yourself into re-doing that computation for every new consumer that shows up later.

Still very much a work in progress — next post will probably be about turning PacketInfo into flow-level statistics.

Finally wrapped up my Terminal Chat (TUI) project.

NITISH Sharma — Sun, 22 Mar 2026 18:18:20 +0000

Built a real-time multi-user chat system in C++ using TCP sockets and ncurses. Multiple rooms, mentions, online users — all inside the terminal. No buttons, no mouse, just pure keyboard and questionable life choices.
I’ll be honest — I did use ChatGPT along the way. But not as a shortcut. More like a debugging partner that doesn’t get tired of my mistakes. The actual building, breaking, fixing, and understanding… that part was on me.
Also, I’ve realized something:
I genuinely enjoy building TUIs.
There’s something weirdly satisfying about making complex systems work inside a terminal. It’s not flashy, it’s not “modern UI”, and most people won’t care… but for those who live in the terminal — this is home.
This project is basically for people who:
open terminal first, browser later
think keyboard > mouse
and don’t mind staring at text all day
Click for github repo
Next step: make it more scalable and less “it works on my machine”.

I Built a Tool That Turns TODO Comments Into Actual Documentation

NITISH Sharma — Fri, 20 Mar 2026 19:50:27 +0000

Most developers already “document” their code — just not in a structured way.

We write things like:

// TODO: optimize this
// BUG: fix crash here
// NOTE: handle edge case

Over time, these comments pile up across files, and eventually… they become invisible.

I ran into this problem while working on multiple small projects. I knew I had pending work scattered across the codebase, but there was no simple way to track it without introducing another tool or workflow.

So I built DocTrack.

💡 The Idea

Instead of forcing developers to adopt a new system, I wanted to reuse what already exists inside the code.

DocTrack scans a project and extracts structured information from inline comments:

What needs to be done (TODO, BUG, etc.)
Where it exists (file + line)
What context it belongs to (code block)

The goal is simple:

Turn implicit developer notes into explicit, usable documentation.

⚙️ How It Works

At a high level, the tool:

Recursively scans a directory using C++17 filesystem APIs
Reads files line-by-line
Uses regex to detect tagged comments:

TODO
BUG
NOTE
FIXME
CODENOTE
1. Extracts:
file name
line number
message
1. Captures surrounding code context using a brace-tracking approach
2. Generates output inside a docs/ folder:
doc.md
report.html (via Pandoc)

🧠 The Interesting Part: Context Extraction

Extracting a single line is easy. Extracting meaningful context is not.

I initially tried using regex to capture entire functions, but that quickly breaks due to:

nested {} blocks
different coding styles
multi-line structures

Instead, I implemented a brace counting strategy:

When a relevant tag (like BUG or FIXME) is detected:
- Start capturing lines immediately
- Increment counter on {
- Decrement on }
Stop when braces balance

This provides a reasonable approximation of the surrounding code block without needing a full AST parser.

It’s not perfect, but it works reliably for most real-world cases.

📄 Example Output

# FILE: calculator.cpp

### Line 12 [BUG] → fix division logic

int divide(int a, int b) {
    // BUG: division by zero
    return a / b;
}

⚖️ Trade-offs

This approach intentionally avoids:

AST parsing (too complex for a first version)
language-specific parsing logic

Instead, it favors:

speed
simplicity
language-agnostic behavior

The downside:

context detection is heuristic-based
edge cases can break block extraction

🚀 Why This Approach

There are already tools for task tracking, but most require:

manual input
separate interfaces
extra discipline

DocTrack works differently:

no new workflow
no extra effort
just leverage what developers already write

🔗 Project

If you're curious or want to try it:

https://github.com/monkonthehill/doctrack

🤔 Open Questions

I’m still exploring a few directions:

Should this move toward AST-based parsing for accuracy?
Would a VS Code extension be more useful than CLI?
How to handle large codebases efficiently?

Would love to hear thoughts from others building developer tools.

📌 Final Thought

Developers already leave a trail of intent inside their code.

The real opportunity is not adding more tools —
but extracting value from what’s already there.