Co-Authoring with LLMs: AI and TDD
Last updated on 2026-07-16 | Edit this page
Estimated time: 20 minutes
The AI Copilot in Modern Development
Large Language Models (LLMs) have fundamentally changed how we write code. It is tempting to view traditional software methodologies like Test-Driven Development as legacy burdens from a pre-AI era.
However, co-authoring with an LLM is completely consistent with the core principles of TDD. In fact, using an LLM to help write tests is one of the most effective ways to leverage AI safely in scientific computing.
Where LLMs Excel: Writing Boilerplate and Generating Strategies
Writing tests by hand can sometimes feel repetitive. This is where an LLM can act as a powerful accelerator.
1. Generating Parametric Cases
LLMs are exceptionally good at brainstorming edge cases. You can
describe your function’s interface and ask: > “What are 10
edge-case coordinate inputs for a 2D rectangle overlap function? Output
them as a Python list of tuples compatible with
@pytest.mark.parametrize.”
2. Drafting Hypothesis Properties
Setting up property-based tests requires wrapping your head around Hypothesis strategies. You can ask an LLM to draft the boilerplate: > “Draft a Hypothesis strategy that generates two valid, non-overlapping rectangles where one is always strictly to the left of the other.”
The LLM does the heavy lifting of writing the syntax, while you focus on the high-level design of the mathematical properties.
The Danger: Outsourcing Trust
While co-authoring is highly encouraged, there is a dangerous anti-pattern: blind delegation.
[ Danger Zone ]
Human Drafts Code ---> LLM Writes 100 Tests ---> Blind Merge (No Trust)The fundamental goal of testing scientific software is to build trust. You cannot outsource trust to a statistical model.
1. You are the Responsible Party
If your simulation code produces a corrupt dataset or a physically impossible thermodynamic state, you cannot blame the LLM in your peer-reviewed retraction letter. You, the human researcher, remain entirely responsible for the scientific validity of your outputs. Every line of test code generated by an AI must be vetted, understood, and run by you.
2. The Post-Hoc Testing Trap
If you write a big block of complex code, dump it into an LLM, and ask, “Write some unit tests for this,” you have completely defeated the design benefits of TDD.
- No Design Feedback: You miss the warning signs of a highly coupled design. The LLM will happily write highly complex, unreadable, brittle mocks to test your messy code, rather than prompting you to refactor it into clean, isolated units.
- Confirmational Bias: The LLM-generated tests will often simply confirm whatever bugs are already present in your implementation, validating incorrect behavior because it was asked to “test the existing code” post-hoc.
The Ideal AI-TDD Workflow
To keep your design clean and your trust intact, use this collaborative loop when working with AI:
- You design the test interface: Write the first test outline or parameterized structure yourself. This forces you to think about the modular design of your function.
- The LLM populates the matrix: Ask the LLM to generate the exhaustive list of coordinates, edge cases, or boundary conditions to fill out your test suite.
- You verify and run: Execute the test suite locally. Ensure you understand exactly why each test passes or fails.
- The LLM drafts the draft implementation: Feed the failing tests to the LLM and ask it to write the minimal code to make them turn green.
- You refactor: Clean up the code structure yourself, running the tests at every step to keep the loop tight and safe.