HCode Day 3: First Mid Done, First Testing Round Closed

Done with my first day of mids.

I still have another one tomorrow, but honestly that one is cybersecurity and blockchain, so it feels like a cakewalk compared to the amount of time my brain wants to spend on HCode anyway.

So after finishing today, I went right back to testing HCode.

This is Day 3 of building it, and today was less about adding flashy new stuff and more about forcing myself to sit down and actually test what is already there.

What I Tested Today

Today was mostly a testing day:

UI and UX flow across the HCode surfaces
Basic extension loading and behavior
Service additions and whether they feel connected or random
Tool detection and execution
Playbook structure and tool coverage

That sounds simple when written as a bullet list. It is not simple when the product is a VS Code fork with multiple built-in extensions, a security workflow surface, MCP plumbing, ACE additions, and a growing list of external tools that all behave differently.

flowchart LR A["Open HCode"] --> B["Check UI and UX flow"] B --> C["Load extensions"] C --> D["Validate services"] D --> E["Run tools"] E --> F["Check playbooks"] F --> G["Note gaps before shipping"]

UI/UX Testing

I spent a good amount of time just clicking through the product like a user instead of like the person who built it.

That always exposes different problems.

When you are building, everything feels obvious because you already know what each panel is supposed to do. When you test properly, you start seeing the awkward transitions, the places where the UI feels heavier than it should, and the parts where the workflow still feels stitched together instead of native.

That was the big theme today: HCode works better than before, but it still needs smoother product behavior.

Some surfaces are starting to feel clean. Some still feel like engineering scaffolds wearing product clothes.

Testing the Extensions

I was also testing the extensions more seriously today.

Not just whether they exist in the sidebar, but whether the basic additions of services and behaviors make sense together.

That matters a lot now because HCode is no longer just a renamed Code - OSS tree with side experiments. At this point, every extension either has to strengthen the main workflow or get rethought.

The test I keep using is simple:

Does this make HCode feel more like one product, or more like six unrelated ideas?

That question kills a lot of weak additions fast.

The Best Part of HCode Right Now

One of my favorite parts of HCode right now is the tool layer.

The goal is not just to list generic pentesting tools and make the user install everything manually like a normal checklist app.

The better direction is this:

If a tool is missing, HCode should help install it.
If the default tool is mediocre, HCode should help discover better options.
If a workflow needs multiple tools, HCode should connect them through playbooks instead of treating each tool like an isolated button.

So the best part of HCode, at least in my head and increasingly in the product, is that it is supposed to do more than just launch nmap.

It should help you build the right stack.

That means checking core tools like nmap, validating whether they are present, handling missing installs better, and even searching GitHub for stronger tool options when the generic answers are not good enough.

That is way more interesting to me than shipping yet another static tool list.

flowchart TD A["Need a capability"] --> B{Tool already installed?} B -->|Yes| C["Run tool in HCode"] B -->|No| D["Install missing tool"] C --> E["Feed result into workflow"] D --> E E --> F{Good enough tool?} F -->|Yes| G["Keep using it"] F -->|No| H["Search GitHub for stronger options"] H --> I["Upgrade tool stack"]

Testing Tools and Playbooks

Today I was checking the basics around tools like nmap, service wiring, and whether the product flow still makes sense once real tools come into the picture.

Then I went back to the playbook side.

This part matters to me a lot. I do not want HCode playbooks to be generic filler. I want them to reflect real workflows built from tools and methods used by top security practitioners around the world.

So I have been trying to gather strong tools, strong workflows, and strong playbook ideas from people whose work actually matters in the field — researchers and builders like Jason Haddix, NahamSec, and others whose approaches have shaped how people do recon, bug bounty work, and practical security testing.

The goal is not to imitate personalities. The goal is to learn from proven workflows and encode that into usable playbooks.

If HCode gets this right, the playbook layer could end up being one of the strongest parts of the whole product.

Where It Stands Tonight

So I am closing my first proper testing round for HCode.

The result is basically this:

good progress
useful foundations
better structure than before
still a lot of improvement needed

Most importantly, it still needs stronger agentic capabilities before I would feel comfortable calling it ready to ship.

That is the real gap now.

The tools are forming. The extensions are forming. The workflows are forming.

But the product still needs smarter runtime behavior and stronger agent coordination if it is going to feel like HCode instead of just a powerful shell.

Signing Off

Day 3 of HCode, signing off.

First day of mids is done. Tomorrow’s exam should be a cakewalk too.

I do still need to study, even if I keep telling myself it is easy.

But for today, I got what I wanted: a real testing pass, clearer gaps, and a better sense of what HCode still needs before it can ship.

Still building.

— Vasanth