Over the past few weeks, I’ve been on a rewarding journey. As a Managing Director who is no longer a full-time software developer, finding the time to code and keep up with the relentless pace of new technologies is a real challenge. While my colleagues are experimenting with the latest frameworks and tools daily, I know I’m not alone in feeling that the tech landscape evolves faster than the hours in a day allow — or faster than what client projects typically permit you to explore.

That’s why I cherish internal projects. Earlier this year I posted about Posting our blog feed to social networks using Slack. And recently I set out to build a couple of internal tools for our Google Workspace environments, but I decided to try something different than what maybe most developers would do.

Instead of relying solely on traditional documentation or enabling an autopilot AI assistant directly inside my IDE or terminal (like a Claude Code subscription), I used the standard Google Gemini web client. It comes included with our company’s Google Workspace account — proving that you don’t need expensive premium subscriptions or complex local LLMs to get value.

learning by steering desk

My goal wasn’t just to generate code quickly. I wanted to dump codebases into the chat, ask the AI why it made specific choices, challenge those choices, and effectively use it as an interactive sparring partner. I wanted to stay in the driver’s seat.

This conscious, deliberate approach surprisingly taught me a lot about technologies I hadn’t used extensively before. Here is what I learned along the way.

Two projects, one learning curve

To give you some context, I built two distinct Spring Boot applications using Java 25 and a Hexagonal Architecture (Ports and Adapters):

  1. Google Workspace Multi-Directory Hub: A web application that synchronizes user directories across four independent Google Workspaces. It ensures that everyone in our company has a complete, up-to-date address book on their phone and in Gmail, utilizing the legacy Google Shared Contacts XML API.

  2. Drive Audit CLI: A lightweight console application that scans Shared Drives across our workspaces to detect explicit permission overrides (e.g., external @gmail.com accounts accessing internal documents) and exports the findings to Google Sheets.

I actually only planned to build the first one. But because the learning process with the AI was so effective and enjoyable (just one more prompt), I wanted to experience that "learning high" again. That’s why I started the CLI tool when the opportunity came along.

Steering the AI: the architect’s dilemma

One of my biggest takeaways was that while AI is incredibly powerful at writing boilerplate or explaining complex APIs, it doesn’t naturally care about your architecture.

I specifically wanted to use Hexagonal Architecture to isolate my domain logic from the Google API infrastructure. Time and time again, the AI would suggest quick-and-dirty fixes that violated this principle. It would try to leak API-specific DTOs into the domain layer or suggest tightly coupled solutions that ignored the DRY (Don’t Repeat Yourself) or YAGNI (You Ain’t Gonna Need It) principles.

Because I was using a web client and not an auto-commit agent, I was forced to read the code, recognize the architectural violations, and push back. "Why are you doing it this way? That breaks the port interface," I would type.

Instead of reducing my role to a mere "code reviewer" — a common fear in today’s AI discourse — this friction sparked a powerful synergy. I brought my software engineering experience and architectural vision (knowing what works in the long run), while the AI provided a vast wealth of technical details and API knowledge I hadn’t yet acquired (the how). This active dialogue forced me to deeply internalize the rules of Hexagonal Architecture in ways I wouldn’t have achieved in such a high pace on my own.

The AGENTS.md experiment

During the first project, I noticed I was constantly repeating myself to get the AI back on track architecturally. And my colleagues were actively picking and setting up system prompts or agent instructions (ref: Agents.md in our Spring 2026 TechRadar edition).

For the second project (the Drive Audit CLI), I decided to formalize this. I created an AGENTS.md file in the root of my repository containing strict rules: "Use Hexagonal Architecture", "No framework dependencies in the domain", "Fail gracefully", and "All code and comments MUST be in English" (as I wrote my prompts in Dutch).

I fed this file to the AI alongside my code dumps. It definitely helped to align the AI’s initial output with my architectural goals, drastically reducing the required corrections. However, it wasn’t foolproof. I still caught the AI occasionally slipping — for instance, generating comments in Dutch despite the explicit instruction to use English. It proved that while you can guide the AI, you can never blindly trust it. You always remain the lead developer.

Accelerated learning: tackling the unknown

The biggest win of this pair-programming approach was how it lowered the barrier to entry for technologies I wasn’t fully familiar with. Because I could ask the AI how to configure things and why it worked, I grasped the concepts much faster than by reading standard tutorials.

  • HTMX: I had heard of HTMX at The Conflux fullstackathon 2026 but hadn’t used it. I wanted a reactive UI for the Directory Hub without the overhead of a full SPA framework like React. The AI showed me how to combine Thymeleaf fragments with HTMX attributes to create a smooth, single-page experience. By asking questions, I learned exactly how the server-side rendering and client-side swapping interacted.

  • Testcontainers and WireMock: I was originally looking for a Google equivalent to AWS’s local cloud simulators (like LocalStack) to test my integrations offline. When I realized that didn’t really exist for these specific Workspace APIs, the AI and I worked out a custom solution using WireMock. We set it up so that I could use a single set of mock JSON files for two purposes: running my automated integration tests via Testcontainers, and spinning up a standalone WireMock Docker container to manually test the application UI locally.

  • Spring Retry: The Google Drive API is notorious for its strict rate limits. When my audit CLI started failing with 403 User Rate Limit Exceeded errors, I discussed the problem with the AI. It introduced me to Spring Retry, helping me configure an @Retryable annotation with an exponential backoff strategy that elegantly solved the issue without cluttering my business logic.

  • Modern Java & CLI UX: For the Directory Hub, the AI suggested utilizing Java’s Virtual Threads (finalized in Java 21) (Executors.newVirtualThreadPerTaskExecutor()) to fetch hundreds of profile pictures concurrently. For the Drive Audit tool, it helped me implement a clean command-line interface using Spring’s CommandLineRunner, complete with a progress bar and clean console logging instead of verbose stack traces.

Conclusion

Using an AI web client rather than an integrated, autonomous coding agent completely changed my relationship with the generated code.

Yes, the AI navigated the obscure legacy Google Shared Contacts XML API, generated complex boilerplate, and helped me set up testing environments. But because I had to copy the code, read it, place it in my project, and consciously ask questions when it made questionable choices, I understood every moving part.

I didn’t just get two working applications out of this experiment. I gained a deep, practical understanding of new libraries, modern Java features, and the nuances of Hexagonal Architecture. I own the code because I steered the process, and that makes all the difference.

For developers — and managing directors — who feel that technology is moving faster than they can keep up with, I highly recommend this approach. A low-barrier hobby project paired with a standard AI account is a fantastic way to bridge the gap. It turns a daunting learning curve into an engaging, interactive conversation.

learning by steering desk developer
shadow-left