My Programming Adventures with Google Gemini and Code Assist

My initial foray into building a personal bug bounty toolkit started, as many programming adventures do, in the terminal. I envisioned a CLI akin to Metasploit, leveraging Python scripts with mitmproxy to manage traffic. While functional for basic tasks, it quickly became apparent that a command-line interface, no matter how well-structured with menus, has its inherent limitations. There’s only so much you can effectively visualize and interact with in a text-only environment before the need for a richer, more intuitive user interface becomes undeniable.

It was around this time, after grappling with the constraints of a purely terminal-based approach, that I began exploring the burgeoning world of AI coding assistants. I experimented with ChatGPT, then GitHub Copilot, before finally landing on Google Gemini. What became clear to me, quite quickly, was that Gemini, in particular, aligned remarkably well with my working style and specific needs. It just clicked. It felt like the easiest of the three to communicate with, making it a natural choice for a project as ambitious as the Bug Hunter Toolkit.

Architectural Choices and Resource Constraints

And ambitious it was. I decided to pivot from a CLI to a full-fledged web application, and with Gemini by my side, I set a challenging goal: a Go backend with a vanilla JavaScript frontend. This architectural choice was entirely my own, stemming from years of full-stack web development in on-premise environments (before the age of AI). I’d often run into frustrating “freemium” models with open-source JavaScript packages for things like interactive data tables, where the essential advanced features I needed were locked behind a paywall. Sticking with vanilla JS for this initial iteration allowed me to maintain complete control and avoid such licensing hurdles.

Crucially, this choice, along with Go and SQLite3, was also driven by practical constraints: I was developing on a VM with very low resources. I simply couldn’t afford the overhead of more resource-intensive solutions like PostgreSQL or full-blown React/Angular frameworks. I needed a minimal resource usage system, and this combination perfectly fit that requirement, allowing me to learn core Go concepts without external complexities. The sheer scope of building a comprehensive toolkit across different languages and paradigms, however, still made the prospect of an AI co-pilot not just appealing, but seemingly essential.

Navigating the Hurdles of AI Collaboration

It’s interesting to note that much later in the development process, after I’d built out a significant portion of the Bug Hunter Toolkit and started hitting some of those expected hurdles with vanilla JavaScript, a Gemini AI chat actually suggested I consider moving to a proper frontend framework for greater scalability and maintainability. That suggestion, coming as I was already contemplating the next, more robust version of the toolkit, definitely lingered, hinting at the evolving complexity I’d eventually want to tackle.

However, the journey was far from a seamless, magical experience. My “programming adventures” with Gemini were indeed an adventure, filled with unexpected turns. One of the most significant hurdles I encountered was Gemini’s tendency to lose context during longer chat sessions. It felt like, after a certain number of turns or once the conversation became sufficiently complex, the model would start to “forget” earlier details or requirements, leading to irrelevant or even contradictory suggestions. This meant I couldn’t just keep asking follow-up questions indefinitely; I had to find ways to periodically “reset” the context or condense prior information.

Compounding this was the behavior of Google Code Assist. While powerful for boilerplate and quick suggestions, it sometimes seemed to misunderstand my intent entirely, leading to code snippets that were syntactically correct but logically flawed, or simply didn’t fit the existing codebase. There were moments where it felt like Code Assist was actively “messing things up,” and I’d spend time debugging its suggestions rather than leveraging them for speed.

These challenges weren’t roadblocks, though; they were learning opportunities. I quickly realized that working with an AI like Gemini wasn’t about simply dictating tasks. It was about developing a new kind of “prompt engineering” intuition – a dance between clarity, conciseness, and strategic re-contextualization. I had to learn the best approaches to break down complex problems into smaller, digestible prompts, provide explicit examples, and actively verify every piece of code it generated. This iterative process, this constant “trust but verify” mindset, became fundamental to my workflow.

The Bug Hunter Toolkit: Three Weeks to a Comprehensive Solution

Despite these challenges, or perhaps even because of the unique way they forced me to adapt my development approach, the results have been nothing short of remarkable. In just three weeks, with Google Gemini as my primary development partner, I’ve brought the Bug Hunter Toolkit (bhtoolkit) to life. This isn’t just a prototype; it’s a fully functional web application that is already proving its worth in managing the complexities of bug bounty hunting and penetration testing.

You can explore the source code yourself on GitHub: https://github.com/J0n-H4rr150n/bhtoolkit

The bhtoolkit is designed to be a comprehensive hub, addressing many of the pain points I experienced with my earlier CLI attempt. It currently provides:

• Centralized Management: A robust system for platforms, targets, and domains, allowing for clear organization of research efforts.

• Dynamic Scope Definition: The ability to precisely define in-scope and out-of-scope rules per target, a crucial feature for ethical and effective testing.
• Streamlined Workflow: Integration of target-specific checklists and notes (with Markdown support!) to keep all relevant information at my fingertips.

• Advanced HTTP Analysis: A powerful HTTP Proxy Log Viewer and Analysis tool, complete with features like JavaScript link extraction, comment finding, and parameterized URL analysis to dig deep into web traffic.

• Interactive Request Modification: A Request Modifier to easily craft and resend custom HTTP requests, a staple for any serious tester.
• Visual Reconnaissance: Capabilities for Sitemap Generation from proxy logs and manual additions, plus a Page Sitemap for mapping user journeys and understanding application flow visually.

• Automated Subdomain Discovery: Integration with Subfinder and httpx for efficient and automated subdomain tracking and live host checks, significantly speeding up the reconnaissance phase.
• Findings Management: A dedicated section to log and manage security findings.

• Visualizations: Graph Visualizations for sitemaps, providing intuitive insights into the application structure.
• Robust Backend & Frontend: Built with a Go backend for performance and concurrency, leveraging a Chi-based router, and a responsive Vanilla JavaScript frontend for complete control and a lightweight user experience.

The bhtoolkit as it stands is exactly what I envisioned: a highly customizable and robust system that genuinely helps me with my bug bounty hunting. While it’s already a powerful tool, my mind is constantly buzzing with ideas for further enhancements and a deeper level of customization. In fact, the journey to refine and expand this toolkit, diving into even more complex ideas and pushing the boundaries of what’s possible with AI assistance, is the subject of my next blog post and a continuing adventure I’m currently on.