Does an AI Teammate Mean You Write Less Code?
We embarked on an experiment called Trio Programming: two engineers and an AI assistant building software together. Our goal was to discover effective workflows for this new dynamic. We started with a simple code kata, a clear set of rules for our AI, and a straightforward tech stack. Our assumption was that with a powerful AI coder, we’d move through the logic faster than ever.
Instead, we spent almost the entire session without writing a single line of business logic. The AI wrote plenty of code, but it was all in service of fixing a development environment that kept breaking. This led us to a counterintuitive conclusion: adding an AI to the team doesn’t accelerate feature development, it brutally exposes foundational weaknesses in your environment and workflow.
Our Setup: An Experiment in Trio Programming
Our team consisted of myself (Nik) acting as the “driver”—the one interacting directly with the AI—and my colleague Javier as the “navigator,” providing high-level direction and quality control. Our third programmer was GitHub Copilot, guided by a detailed set of custom instructions emphasizing a strict Test-Driven Development (TDD) cycle, small incremental changes, and explicit permissions before writing any code.
The plan was to tackle the “Hierarchy Kata” —a REST API for managing an employee hierarchy—using a pure stack: Core Java, JUnit 5, and Gradle. We wanted to keep things simple and avoid framework magic.
The Experiment That Failed: A Cascade of Configuration Errors
Our first mistake was idealism. We started with Core Java to avoid frameworks, but quickly realized the sheer amount of boilerplate needed for a simple REST endpoint was distracting us from the actual kata. We pivoted.
“Let’s delegate that work to Spring,” we decided, thinking it would get us back on track. This is where the real trouble began. Our session devolved into a frustrating, iterative battle with our own setup, guided by an AI that was helpful but lacked strategic oversight.
Missing Dependencies: We asked Copilot to generate a test for a Spring Boot controller. It correctly produced a test using
@WebMvcTestandMockMvc. But when we ran./gradlew build, the build failed spectacularly with dozens ofcannot find symbolandpackage does not existerrors . Ourbuild.gradlefile had JUnit, but none of the required Spring Boot test dependencies.Incorrect Dependency Configuration: We then asked Copilot to fix our Gradle file. It suggested adding the Spring dependencies, but the first attempt failed because we hadn’t defined a version number, leading to a
Could not find org.springframework.boot:spring-boot-starter-web:.error . The next fix involved adding the dependencies to thesubprojectsblock in our rootbuild.gradle, as they weren’t being inherited by the kata’s module. Each step was a tiny, painful discovery.Classpath and Package Structure Hell: After fixing the build file, the errors persisted. The problem? Our test file,
HelloWorldControllerTest.java, was insrc/main/javainstead ofsrc/test/java. The test dependencies weren’t on the main classpath. Once we moved it, we hit yet another wall:Unable to find a @SpringBootConfiguration. Our test in thecom.kata.hierarchypackage couldn’t find the main application class located incom.example.helloworldbecause of how Spring’s component scanning works.
The entire session was a cycle of: ask for code, watch the build fail, feed the error log back to the AI, and apply the suggested micro-fix. We weren’t programming; we were performing highly-structured, AI-assisted debugging on our own environment.
Principles That Actually Work
This frustrating experience revealed three principles that are critical for effective AI-augmented development.
The Environment is Non-Negotiable. An unstable or poorly understood development environment will completely derail any attempt at Trio Programming. The AI can suggest fixes, but it can’t reason about your setup holistically. Before you can ask an AI to write a feature, the entire team—humans and AI—must operate on a rock-solid foundation where builds, tests, and dependencies are flawless.
Human Navigation is Paramount. The session would have been a total failure without a human navigator. Javier’s role was crucial for steering the ship. He spotted issues in prompts, provided strategic direction (”let’s put it in a new package” ), and kept the focus on the larger goal while I was in the weeds prompting the AI. As I noted in my log, “Speak, not only think - it’s a very strong pattern”. The AI is a powerful tool, but it needs a human strategist to be effective.
Treat the AI as a System, Not Just a Coder. We started by giving the AI rules for writing code (TDD, small steps). But the real value came from using it as a diagnostic tool for a complex system that included our code, our build tool, and our framework. The prompts that worked best weren’t “implement this feature,” but rather “here is an error log, diagnose the problem and propose a minimal fix”.
The Unexpected Discovery: The AI Reshapes Human Roles
The most surprising insight was how the AI’s presence changed our own roles. My job as the “driver” became less about writing code and more about prompt engineering and AI flow control. I was focused on translating our navigator’s intent into precise instructions and context for the AI.
Javier’s “navigator” role expanded from guiding the code’s logic to managing the overall strategy and quality controlling both my prompts and the AI’s output. This division of labor was incredibly effective. Having one person focused on the high-level goal while the other managed the human-AI interface prevented us from getting stuck. The AI didn’t just add a third programmer; it created a new, more specialized dynamic between the two human programmers.
The Central Paradox of AI Collaboration
Herein lies the paradox: The goal of using an AI is to abstract away complexity, but its immediate effect is to surface hidden complexities you’ve been ignoring.
We thought we had a working Java setup. But the AI, by trying to follow our commands precisely and rapidly, immediately ran into every single flaw in our Gradle configuration and package structure. A human programmer might have found these issues slowly over time. The AI found them all at once, forcing a full stop.
Effective use of an AI programmer therefore requires:
An impeccably configured and automated development environment.
Deep human expertise in the underlying tools (Gradle, Spring), as the AI’s suggestions still need validation.
A workflow where humans provide strategic intent, not just tactical instructions.
Conclusion: Build Your Pipeline Before You Start the Assembly Line
Our first Trio Programming session felt slow and, at times, unproductive. We wanted to build an API, but we ended up building a robust, multi-module Spring Boot Gradle configuration. But as Javier aptly put it, this process is like building a good CI/CD pipeline: it “reduces the price of mistakes” and gives you the confidence “to move forward faster”.
The lesson is clear. You can’t just drop an AI into an existing workflow and expect a productivity boost. You must first use the AI to stress-test and harden your foundations. The initial time investment is not spent on writing features, but on creating an environment so solid that the AI can finally be unleashed on the work you actually want it to do. We ended the day in a much safer, more robust place, ready for the real work to begin.
 | A guest post by
|