AI-First Software Development

As an Infosec Engineer, my relationship with code has historically been pragmatic. I write code to solve specific security problems, but my tools are typically narrower in scope than the sprawling architectures built by full-time software engineers.

Recently, however, after exploring new paradigms in AI-assisted programming, I decided to test these concepts in the wild. I applied this methodology to build the Antlion project, and the experience fundamentally shifted my perspective on software development. By integrating Claude Code and modern AI-assisted workflows, I realized that the way we interact with code has irrevocably changed.

This post is a deep dive into my personal evolution: from traditional scripting, to awkwardly forcing AI into old habits, to fully embracing the new paradigm of agentic development.

Motivation: The Need for a New Modus Operandi

For a long time, my workflow was functional, albeit traditional. I would write scripts or small programs, test them empirically, document them, and push them to production. But watching the rapid evolution of AI coding tools, I realized that simply bolting a chatbot onto my existing workflow wasn’t enough. I needed to rethink my entire process from the ground up to actually leverage these tools as autonomous agents rather than glorified search engines.

The Pre-LLM Era: Scripts, Ad-Hoc Fixes, and Stack Overflow

Before the rise of LLMs, my development process looked exactly like this:

1. Create a folder, bootstrap Git, and initialize the programming language environment.
2. Dive straight into the code, creating subfolders and importing libraries.
3. Once the base structure (CLI, directory tree) was complete, start hacking away at specific components (a top-down approach).
4. Perform ad-hoc testing until reaching a working “v0.5”.
5. Polish the code, write documentation, and ship.

In security and IT operations, we rarely require the rigid bureaucracy of enterprise software development (Agile, heavy CI/CD, exhaustive system design). We optimize for speed and utility, building parsers, automation scripts, or Proof-of-Concepts (PoCs) to put out the immediate fire in front of us.

However, looking back with a critical eye, my process was fundamentally flawed. It severely lacked automated testing, which inevitably led to technical debt. Without unit tests, my scripts were brittle. A minor refactor or an unhandled edge case in a log file could quietly break the entire tool. Upgrading netbox-scanner to v2, for instance, was painful for exactly this reason.

I came to realize that adopting core engineering best practices, like test coverage, would make my deliverables significantly safer and more reliable. Under my old manual process, achieving this meant heavy reliance on Google, Stack Overflow, and official documentation to unblock myself. It worked, but it was incredibly tedious.

Method + LLM: The Friction and Fatigue of Early Adoption

I started riding the LLM wave early, diving into AI-assisted development around mid-2025 while learning Rust programming language and building Cordyceps, an educational Proof-of-Concept (PoC) ransomware.

At that stage, the AI tooling landscape was evolving at breakneck speed, but my workflow remained stagnant. Instead of taking the time to learn how to orchestrate agentic features, I simply took my flawed pre-LLM workflow and slapped AI on top of it.

Even after progressing from copying code out of a browser tab to using an in-IDE AI agent that automatically updated files, the fundamental problem persisted. Lacking a structured method for providing context, I found myself repeatedly explaining the project’s rules with every new chat session. This constant repetition, combined with the AI’s natural context degradation in longer threads, made me seriously question the tool’s long-term utility.

While the AI provided direct, tailored answers, this ad-hoc approach introduced massive friction:

• Context decay: Chats were painfully short-lived. I noticed that after a certain point, the AI’s answers would degrade, becoming biased or completely ignoring foundational instructions. In ML literature, this is a documented phenomenon known as “attention decay” or “context window saturation.” As a conversation grows, the LLM physically struggles to weigh your original system instructions against the noisy tokens of the ongoing chat.
• Psychological fatigue and “prompt rage”: Using AI in an unstructured manner took a surprisingly heavy psychological toll. Having to endlessly rebuild context left me genuinely frustrated with the AI for “forgetting” constraints; at times, it felt like arguing with a toddler. I had essentially shifted my stress from debugging broken code to debugging a stubborn LLM.
• Workflow silos: Initially, manually moving files back and forth from a browser was exhausting. But even after adopting a local agent plugin, the struggle remained because my process was still siloed.

I was still the developer doing all the heavy lifting; the AI was just a smarter, occasionally frustrating textbook. It was like copy-pasting from Stack Overflow, just generated on the fly. The solution wasn’t to “prompt harder.” The solution was to step back, review my entire workflow, and integrate AI much earlier in the software lifecycle, using its capabilities in a structured, deterministic way.

The New Way with LLM: Designing Antlion to Learn the Paradigm

Entering 2026, I realized the only way out of this frustrating cycle was to stop forcing the AI into my old habits. I decided to actually study the new way of working. I researched agentic workflows, structured AI tooling, and LLM orchestration.

Only after internalizing this new paradigm did I design the Antlion project. Antlion wasn’t just another script; it was deliberately conceived as a sandbox to practice an AI-native methodology.

This was a profound mindset shift. I finally understood that modern AI tools are no longer intuitive “chatbots”: they are complex orchestrators. Studying a tool’s architecture and best practices before deploying it is exactly how a senior engineer approaches any new technology. The tool and the paradigm must dictate the workflow, not the other way around.

I installed Claude Code directly on my machine, integrated the necessary editor plugins, and completely overhauled my approach:

1. Setting the Stage (Context Engineering)

Instead of jumping into the code, I started with documentation. I outlined goals, premises, constraints, and the tech stack in README.md. Then, using the Claude plugin, I executed /init to parse the greenfield project and build CLAUDE.md.

This file acts as the AI’s system prompt and rulebook. I tailored it to dictate exactly how Claude should behave, applying best practices like enforcing Test-Driven Development (TDD) and functional programming, inspired by Paul Hammond’s approach. I kept it highly concise: CLAUDE.md contained all my architectural guardrails in exactly 99 lines.

2. The AI Interview

Once the environment was set, my first prompt wasn’t a request to write code. Instead, I asked the AI to interview me:

Ask me clarifying questions about edge cases, UI/UX, and technical tradeoffs before we start building.

Adapted from Anthropic’s documentation, this technique was surprisingly effective. Like a chess opponent, Claude found gaps in my initial plan and predicted dependencies I hadn’t yet defined. Putting myself in the “interviewee” seat gave me greater control over the architectural decisions. Claude generated 13 targeted questions initially and raised further edge cases as we progressed.

We iterated until we reached a consensus. It felt like collaborating with a highly skilled peer to finalize system design before writing a single line of code. Only then did the AI update CLAUDE.md and generate a formal DESIGN.md specification.

3. Planning and Commitment

I switched Claude Code to plan mode (shift-tab) and requested an implementation plan. I reviewed it meticulously, added my constraints, and instructed the agent to proceed only when we were perfectly aligned.

Crucially, I forced the AI to commit the plan and TODO list to documentation before touching the codebase. Given my past struggles with contaminated chat contexts, I needed these specs committed as an immutable source of truth. It generated both files under the docs/ folder, and development began.

4. Test-Driven Development (TDD) in Action

With my coffee in hand, I instructed Claude to initiate Phase 0. What followed was mesmerizing. I watched the AI execute a flawless TDD loop:

1. Write: It wrote a test in tests for the data models (e.g., validating supported file formats).
2. Fail (Red): It executed the test using uv (as strictly instructed). The test failed.
3. Implement: It wrote the actual declaration code to resolve the failure.
4. Pass (Green): It re-ran the test suite. It passed. Task complete, onto the next.

I used this loop to finally familiarize myself with TDD. I was learning to implement it simply by observing an autonomous agent execute the framework perfectly.

5. Shifting from Coder to Product Manager

To ensure I was monitoring the model closely and actually learning the codebase, I reviewed and approved every new command and file edit. It was tedious, but necessary to remain in the driver’s seat.

At the end of Phase 2, Claude autonomously ran a comprehensive test suite before proceeding. I found myself acting as a Technical Product Manager: Are all tests green? Yes. Mark tasks as done in the TODO. Commit. Move on.

6. Enforcing Strict Boundaries (Pylance/Pyright)

During Phase 4, I configured my Python type-checking to “strict” mode. By Phase 7, Pylance warnings were accumulating. I initiated a strategic halt: I instructed Claude to resolve all warnings and added a new strict-typing enforcement rule to CLAUDE.md. Claude surgically fixed the warnings and re-ran the tests successfully. From that point forward, the codebase looked as though it were written by a senior Python engineer, complete with modern, rigorous type annotations.

7. Bottom-Up Architecture and Debugging

Unlike my traditional top-down scripting approach, Claude naturally adopted a bottom-up architecture. It built and tested specific, isolated components before wiring them into the main dispatcher.

When things inevitably broke (such as a proxy issue with LiteLLM or a bug where the program bypassed the --dry-run flag to create a folder) Claude troubleshot, reasoned about the execution flow, and deployed rapid fixes immediately after I fed it the terminal output.

8. The Final Polish

The code under antlion/src eventually felt a bit cluttered, so I prompted Claude to refactor it applying enterprise Python best practices. It modularized the project instantly. The resulting architecture was clean, professional, and highly maintainable.

Takeaways: The Paradigm Shift

Looking back, my 2025 endeavor was basically my legacy workflow with an AI bot duct-taped to it. The 2026 approach is a true AI-first workflow.

1. Change the process, not just the tool. You cannot simply bolt AI onto your existing stack. You have to step back, study agentic methodologies, and fundamentally restructure how you build software.
2. From code to specifications. Development is now less about writing syntax and more about defining rigid prerequisites and system specifications. However, foundational engineering skills are still what separate production-grade tools from hobbyist scripts. You have to know what to ask for, and you must know how to review the output.
3. Unprecedented velocity. Historically, a project like Antlion would have taken me two to three weeks working 4 hours a day. Using this agentic workflow, the project was delivered in about 15 commits, taking less than 6 hours total. The efficiency gains are staggering.
4. Clarity is king. Defining clear goals and mandating TDD was the ultimate differentiator. Had I blindly accepted the code Claude initially offered without strict constraints, the project would have collapsed into an unmaintainable mess.

I am incredibly excited for what comes next. By taking the time to learn the available tools and paradigms, I stopped fighting the AI and started orchestrating it. Other capabilities, like Claude Skills, are ready to be explored, and I will absolutely be integrating them into my future engineering workflows. 🤖 🚀