Network engineer / automation builder
I started vibe coding these projects because real network work kept exposing slow, repetitive gaps. Codex, Claude, and Grok helped me move from ideas to working code; I own the workflow design, testing, logging, and safety decisions that make the tools useful.
How I actually build
I am a network engineer, not someone who began with a traditional software-development path. These tools started with problems I knew firsthand: vague device tickets, more than 100 switches to search, access points that needed consistent setup, UPS cards that had to be visited one at a time, and short device logs that made patterns hard to see.
My process is iterative. I plan the workflow, build a narrow version with AI as a coding partner, run it against ugly edge cases, study the logs, and change the design when the evidence proves my first idea wrong. The custom MAC-tracing algorithm alone took repeated tuning because the real switching environment did not behave like a clean diagram.
Start with the ticket, CLI sequence, decision points, and failure states.
Use Codex, Claude, and Grok to explore implementations quickly.
Keep detailed logs and test the awkward cases, not only the demo path.
Deny by default, re-read state, constrain commands, verify, audit, and preserve rollback.
Selected systems
Each case study starts with the manual problem, then shows the architecture, safeguards, testing approach, and tradeoffs behind the implementation.
Trace, diagnose, and safely remediate a network edge from one evidence-driven workspace. Shared policy, scheduling, rollback, authorization, and reporting also power Comply-FI and LogNinja.
Read the suite case study
Discovers UPS network cards, normalizes health and event data, schedules fleet scans, and turns device CLI output into an operational history.
Read the case study
Provisions NMC2 and NMC3 cards over serial, SSH, or a simulator—then reads every setting back before declaring the workflow successful.
Read the case study
Gives an AV support team narrowly scoped device lookup and port recovery without exposing unrestricted access to the switching environment.
Read the case study
Discovers access points, classifies port-policy drift, previews exact remediation, and verifies or rolls back operator-approved changes.
Read the module case study
Searches and classifies switch logs across inventory scope using a fixed read-only command set—without turning the web UI into a free-form CLI.
Read the module case studyEngineering principles
A polished interface is useful; a workflow that fails safely under stale evidence, concurrent work, unreachable devices, and partial success is the harder problem.
Re-read device state close to apply time instead of trusting an old search result.
Validate targets, interfaces, roles, and commands on the server—not only in the UI.
Capture pre-change configuration and make restoration a verified workflow.
Record who acted, what ran, what failed, and what the live read-back confirmed.
Product evolution
The original toolkit established inventory-driven lookup, device discovery, diagnostics, and guarded operator actions from a CLI-first workflow.
The same practical foundation evolved into a shared web platform with policy, scheduling, evidence history, authorization, rollback, reporting, and modules.