# Test-driven development Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later. Programmers also apply the concept to improving and debugging legacy code developed with older techniques. Process Add a test Run all tests. The new test should fail for expected reasons Write the simplest code that passes the new test All tests should now pass Refactor as needed, using tests after each refactor to ensure that functionality is preserved Repeat. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Agentic Engineering in Python: From Vibes to Evidence DevFeed: [Agentic Engineering in Python: From Vibes to Evidence]() Original publisher: [Read original article]() Author: Ben Batman Published: 2026-09-14T14:00:00Z Content type: tutorial Language: en Sources: [Real Python]() Topics: [Loop Engineering](), [AI Agent](), [Python](), [Transformers](), [Code review](), [Test-driven development]() Tags: [agentic](), [agentic-engineering](), [ai-coding-agents](), [cheat-sheet](), [code-review](), [learning](), [python](), [tests]() ### AI overview This tutorial presents agentic engineering in Python as a disciplined workflow for delegating bounded tasks to AI coding agents while retaining human control over intent, constraints, review, and release decisions. It explains execution and acceptance loops, the Engineering Evidence Ladder, and the RECAP review method for evaluating agent-generated changes with tests, type hints, refactoring, and code review. ### Source excerpt Move from vibe coding to agentic engineering in Python, using tests, types, and code review to prove an AI agent's changes are safe to keep. ## Python Practice Problems: Parsing CSV Files DevFeed: [Python Practice Problems: Parsing CSV Files]() Original publisher: [Read original article]() Author: Jim Anderson Published: 2026-09-13T14:00:00Z Content type: tutorial Language: en Sources: [Real Python]() Topics: [CSV](), [Python](), [Test-driven development](), [Command-line interface](), [pass]() Tags: [code](), [coding](), [command-line](), [data](), [python](), [testing](), [tutorial](), [tutorials](), [writing-code]() ### AI overview An intermediate-level tutorial that helps Python developers practice parsing CSV files through interview-style problems. It covers writing solutions, test-driven development with pytest, solution improvements, and the trade-offs between Python's built-in csv module and pandas. ### Source excerpt In this tutorial, you'll prepare for future interviews by working through a set of Python practice problems that involve CSV files. You'll work through the problems yourself and then compare your results with solutions developed by the Real Python team. ## Introducing Consort: Test-driven development on a branching database DevFeed: [Introducing Consort: Test-driven development on a branching database]() Original publisher: [Read original article]() Author: Kevin Hartman Published: 2026-09-09T13:41:25Z Content type: article Language: en Sources: [Databricks]() Topics: [Test-driven development](), [Database](), [Integration testing](), [Software Engineering](), [Refactoring](), [Continuous Delivery (CD)](), [Pull Request](), [Reverse Engineering]() Tags: [code](), [continuous-delivery](), [database](), [development](), [integration](), [partners](), [platform](), [postgres](), [pull-request](), [refactoring](), [reverse-engineering](), [software](), [software-development](), [testing]() ### AI overview The article introduces Consort, a workflow for applying test-driven development to a branching database. It argues that copy-on-write branches of a real database can replace mocks, bring integration testing into the inner development loop, and let engineers run destructive tests in isolation. Versioned schema migrations can move with the dependent code, enabling what the article calls Data CD and helping catch production database problems during pull requests and merges. ### Source excerpt For 25 years I built software on the practices I grew up with: Kent Beck's TDD, Martin... ## Extreme Programming remains relevant for building software teams in 2026 DevFeed: [Extreme Programming remains relevant for building software teams in 2026]() Original publisher: [Read original article]() Author: Anton Zaides Published: 2026-08-18T06:01:00Z Content type: opinion Language: en Sources: [Manager.dev]() Topics: [Programming](), [Development](), [Refactoring](), [Test-driven development](), [pair\_programming](), [Code review]() Tags: [code](), [code-quality](), [development](), [pair-programming](), [programming](), [redesign](), [tdd]() ### AI overview The author revisits Kent Beck's Extreme Programming after experiencing frustration with Scrum and the pressures facing modern engineering teams. The article argues that XP remains relevant because it combines five values, 14 principles, and numerous practices aimed at improving both software and team life, rather than reducing the methodology to TDD and pair programming alone. ### Source excerpt A method created 30 years ago is still your best guide for building software ## TDD inside the agent loop - theater or actual value? DevFeed: [TDD inside the agent loop - theater or actual value?]() Original publisher: [Read original article]() Author: Martin Fowler (martin@martinfowler.com) Published: 2026-08-11T11:39:00Z Content type: article Language: en Sources: [Martin Fowler]() Topics: [Test-driven development](), [Large Language Model](), [Artificial Intelligence](), [mutation-testing](), [test-coverage]() Tags: [agents](), [ai](), [claude](), [development](), [llm](), [testing]() ### AI overview This exploratory evaluation examines whether having an AI coding agent follow a test-driven development workflow produces better results than a non-TDD workflow. Across small, medium, and larger greenfield business-logic tasks, the reported results showed no clearly discernible difference in outcome quality or mutation scores; in some cases, the non-TDD solutions were judged slightly better in design and test quality. ### Source excerpt My colleagues at Thoughtworks tend to be big fans of Test-Driven Development, and many people in the industry advocate telling LLM agents to use TDD when building software. Birgitta Böckeler was curious if this really makes a difference, so conducted a few experiments. more... ## How a Tech Lead Encouraged Testing in Legacy Code DevFeed: [How a Tech Lead Encouraged Testing in Legacy Code]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-08-04T06:02:15Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [Test-driven development](), [legacy](), [clean-code](), [Template](), [Software Engineering]() Tags: [clean-code](), [legacy-code](), [tdd](), [tech-lead](), [training](), [unit-tests]() ### AI overview This opinion article recounts how an engineering leader struggled to introduce testing and clean-code practices across multiple companies. As a Tech Lead, the author created a testable Clean Architecture template, recruited developers who valued quality, built an initial module, and trained the team to use the approach. ### Source excerpt "We don't have time to write the code twice." ## AI Coding Tip 029 - Stop Using One Model for Everything DevFeed: [AI Coding Tip 029 - Stop Using One Model for Everything]() Original publisher: [Read original article]() Author: Maxi Contieri Published: 2026-07-26T15:08:02Z Content type: opinion Language: en Sources: [Maximiliano Contieri - Software Design]() Topics: [coding](), [ai-coding](), [Testing](), [Test-driven development]() Tags: [ai-coding](), [coding](), [cost](), [review](), [scope](), [tdd](), [testing]() ### AI overview The article argues that AI coding pipelines should assign different models to planning, coding, reviewing, and testing. It recommends using fresh context, automated test harnesses, independent reviewers, model rotation, and separate models for TDD stages to reduce shared blind spots, vendor dependence, and missed edge cases. ### Source excerpt TL;DR: Assign a different model to each pipeline stage since none excels at planning, coding, reviewing, and testing alike. Common Mistake ❌ You open one chat with your favorite model and ask it to p ## Teaching the Agent Our Craft: Structured Agentic Development on a Real Codebase DevFeed: [Teaching the Agent Our Craft: Structured Agentic Development on a Real Codebase]() Original publisher: [Read original article]() Author: Alex Haldeman Published: 2026-07-06T16:00:00Z Content type: article Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Agentic development](), [Claude Code](), [Development](), [AI-assisted coding](), [Test-driven development]() Tags: [agentic](), [agentic-development](), [ai-and-emerging-tech](), [claude-code](), [clean-architecture](), [structured](), [test]() ### AI overview 8th Light describes a structured agentic development workflow built around Claude Code. The approach adapts Research-Plan-Implement by separating research, planning, and implementation, adding review cycles and involving product managers and designers at each transition. It also applies test-driven development, clean architecture, and explicit project conventions to address common agent failure modes. ### Source excerpt The Mission We recently partnered with a startup that had developed a clinically proven approach to alleviating neuroplastic chronic pain. Their program worked: a coach-led model that helped patients ease chronic pain at a lower cost than conventional treatment. The problem was reach. The in-person model could not scale to the demand they were seeing, and there were not enough coaches to close the gap. We were brought in to build a digital platform that could deliver the program to every patient who needed it. Our Development Philosophy and Inspiration At 8th Light, we approach agentic development the same way we approach any software engagement: with discipline around test-driven development, clean architecture, and code that is built to embrace change. But agentic development comes with its own failure modes. An agent produces code that covers the happy path and misses critical behaviors. A context window fills with stale reasoning from earlier attempts, and the agent starts working against itself. Without explicit conventions, the output works but looks like nobody on the team wrote it. Tyler Burleigh's Research-Plan-Implement gave us a useful frame for thinking about this. His core observation: the bottleneck is not code generation, it is ensuring the model understands what to build before it starts building. RPI addresses that by separating research, planning, and implementation into distinct phases, each with a review cycle before the next begins. We adapted that structure into our Claude Code workflow, with the additional goal of keeping product managers and designers genuinely in the loop at each transition, not just developers. What follows is a description of the harness we built from a Claude Code-specific perspective. The HarnessStructure Before walking through the pieces, it helps to see how they fit together. Everything that teaches the agent our craft lives in a handful of files at the project root and inside a single .claude/ directory. None of it is ## TDD in Legacy Code - Maintainable Component Tests - Backend DevFeed: [TDD in Legacy Code - Maintainable Component Tests - Backend]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-07-02T06:02:41Z Content type: tutorial Language: en Sources: [Optivem Journal]() Topics: [Back end](), [Test-driven development](), [legacy]() Tags: [api](), [backend](), [component](), [erp](), [legacy](), [legacy-code](), [refactor](), [tdd](), [tests]() ### AI overview A tutorial on refactoring brittle backend component tests that are coupled to a backend API and ERP system, with the goal of making them more maintainable. ### Source excerpt Many Backend Teams write unmaintainable Backend Component Tests - coupled to the Backend API and ERP. I'll show you how to refactor these brittle tests. ## Why Legacy Code Turns Small Changes Into Multi-Day Firefighting DevFeed: [Why Legacy Code Turns Small Changes Into Multi-Day Firefighting]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-06-30T06:02:36Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [legacy](), [Test-driven development](), [Development](), [Software]() Tags: [dev](), [engineering](), [legacy-code](), [tdd]() ### AI overview This commentary examines how legacy code can turn a small change into days of investigation and risk. It argues that tangled dependencies, missing tests, and outdated code prevent senior developers from improving architecture and make routine maintenance frustrating. ### Source excerpt The field took twenty minutes. Everything around it took three days. ## The AI-Assisted Engineering Workflow I Use Day to Day DevFeed: [The AI-Assisted Engineering Workflow I Use Day to Day]() Original publisher: [Read original article]() Author: Alex Razvant Published: 2026-06-28T13:01:33Z Content type: tutorial Language: en Sources: [Neural Bits]() Topics: [AI-assisted coding](), [Loop Engineering](), [Test-driven development](), [Claude Code](), [codex](), [Production Engineering](), [coding]() Tags: [ai](), [claude](), [claude-code](), [codex](), [coding-agents](), [engineering](), [production](), [tdd](), [validation](), [workflow]() ### AI overview The article presents a controlled workflow for AI-assisted engineering with Claude, Codex, and other coding agents. It describes intake, task decomposition, test-driven development, bounded implementation, review gates, system validation, and sign-off while keeping the engineer involved throughout. ### Source excerpt How I structure intake, slicing, TDD, implementation, review gates, system validation, and signoff when working with Claude, Codex, and coding agents in production engineering work. ## How we migrated a live routing system using AI-assisted refactoring DevFeed: [How we migrated a live routing system using AI-assisted refactoring]() Original publisher: [Read original article]() Author: Arnold Wakim Published: 2026-06-23T00:00:00Z Content type: article Language: en Sources: [Datadog | The Monitor blog]() Topics: [AI-assisted coding](), [migration](), [Test-driven development](), [cursor](), [Kafka]() Tags: [ai](), [claude](), [cursor](), [duckdb](), [kafka](), [migration](), [postgresql](), [production](), [refactoring](), [routing](), [storage]() ### AI overview An engineering account of migrating Stream Router's storage architecture with AI-assisted, test-driven refactoring while preserving live production traffic. ### Source excerpt Using AI-assisted refactoring, we migrated our live routing brain to a relational model, safely validating changes against live production traffic. ## Engineering Den: Claude Code skills and hooks for frontend teams DevFeed: [Engineering Den: Claude Code skills and hooks for frontend teams]() Original publisher: [Read original article]() Author: Beniamin Malinski Published: 2026-05-07T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [Claude Code](), [Front end](), [Development](), [Test-driven development](), [Testing](), [GitHub](), [TypeScript](), [Docker Container](), [Accessibility](), [codex]() Tags: [accessibility](), [claude-code](), [codex](), [container](), [engineering](), [frontend](), [github](), [go](), [javascript](), [skills](), [testing](), [typescript]() ### AI overview Redpanda describes a shared repository of more than 40 Claude Code skills and 90 hooks for frontend teams. The tools automate quality checks for type safety, linting, formatting, tests, builds, accessibility, and browser regressions, while a lifecycle skill guides work from planning and test writing through verification, pull requests, and reporting. The article also mentions SandCastle, which runs Claude Code instances in separate Docker containers, and compatibility with Codex. ### Source excerpt Ship cleaner frontend code faster with new shared Claude skills (40+) and hooks (90+). Includes powerful workflows like /work, /go, /tdd, and built-in quality gate checks. ## Agentic code workflows with Nick Tune DevFeed: [Agentic code workflows with Nick Tune]() Original publisher: [Read original article]() Author: Dr Milan Milanović Published: 2026-03-26T16:01:37Z Content type: article Language: en Sources: [Tech World With Milan Newsletter]() Topics: [agentic-coding](), [ai-coding](), [Claude Code](), [Code quality](), [code reviews](), [Test-driven development](), [Testing](), [Command-line interface](), [Domain-driven design (DDD)](), [migration](), [Requirements](), [Continuous Delivery (CD)]() Tags: [agentic](), [agentic-coding](), [agents](), [ai-coding](), [ai-tools](), [best-practices](), [claude-code](), [cli](), [code-quality](), [code-reviews](), [continuous-delivery](), [domain-driven-design](), [migration](), [requirements]() ### AI overview An interview with Nick Tune about advanced agentic coding workflows. It covers planning requirements, modeling development as a tested state machine, implementing features with Claude Code and guardrails, enforcing architecture rules deterministically, reviewing pull requests, applying TDD, and using custom tooling. ### Source excerpt Most engineers who talk about AI productivity talk in abstractions. ## The Way of TDD DevFeed: [The Way of TDD]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2026-03-10T12:24:00Z Content type: article Language: en Sources: [Google Testing Blog]() Topics: [Test-driven development](), [Test coverage](), [Development](), [Algorithm](), [Code]() Tags: [algorithm](), [article](), [bartosz-papis](), [bugs](), [code](), [development](), [quality](), [refactor](), [tdd](), [test](), [test-coverage](), [tests](), [tott]() ### AI overview This article explains Test-Driven Development as a red-green-refactor cycle: write a failing test, make it pass with minimal production code, and then refactor. It describes reported benefits and limitations, and demonstrates the process by modifying a voting algorithm to support abstentions. ### Source excerpt This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Bartosz Papis Test-Driven Development (TDD) is the practice of working in a structured cycle where writing tests comes before writing production code. The process involves three steps, sometimes called the red-green-refactor cycle: Write a failing test Make the test pass by writing just enough production code Refactor the production code to meet your quality standards Research shows TDD has several benefits: it improves test coverage, reduces the number of bugs, increases confidence, and facilitates code reuse. This practice also helps reduce distractions and keep you in the flow. TDD also has its limitations and is not a silver bullet! See the Wikipedia article about TDD for a detailed explanation and references. Here is a short practical example. Assume you need to modify the following voting algorithm to support the option for voters to abstain: def outcome(ballots): if ballots.count(Vote.FOR) > len(ballots) / 2: return "Approved" return "Rejected" 1. We start by writing a failing test - as expected, the test doesn't even compile: def test_abstain_doesnt_count(self): self.assertEqual(outcome([Vote.FOR, Vote.FOR, Vote.AGAINST, Vote.ABSTAIN]), "Approved") 2. We fix the compilation error by including the missing enum option: class Vote(Enum): FOR = 1 AGAINST = 2 ABSTAIN = 3 Now that the test compiles, we fix the production code to get all tests passing: def outcome(ballots): if ballots.count(Vote.FOR) > (len(ballots) - ballots.count(Vote.ABSTAIN)) / 2: return "Approved" return "Rejected" 3. We now refactor the code to improve clarity, and complete an iteration of the TDD cycle: def outcome(ballots): counts = collections.Counter(ballots) return "Approved" if counts[Vote.FOR] > counts[Vote.AGAINST] else "Rejected" Learn more about TDD in the book Test Driven Development: By Example, by Kent Beck. ## Why the Author Is Skeptical of Test-Driven Development DevFeed: [Why the Author Is Skeptical of Test-Driven Development]() Original publisher: [Read original article]() Author: January Published: 2026-01-29T00:00:00Z Content type: opinion Language: en Sources: [Drew DeVault]() Topics: [Test-driven development](), [Testing](), [test-coverage]() Tags: [software-testing](), [tdd](), [test-coverage](), [testing](), [tests](), [unit-test]() ### AI overview The author argues that test-driven development can provide useful rapid feedback and test coverage, but warns that it may shape code around testability and cannot ensure that tested behavior matches actual software requirements. ### Source excerpt I've gotten a lot of flack throughout my career over my disdain towards test-driven development (TDD). I have met a lot of people who swear by it! And, I have also met a lot of people who insisted that I adopt it, too, often with the implied threat of appealing to my boss if appealing to me didn't work. The basic premise of TDD, for those unaware, is that one first writes a unit test that verifies the expected behavior for some code they want to write, observes the new test fail, and then one writes the implementation, iterating on it until the test passes. The advantage of this approach is, first, to ensure that your codebase is adequately covered by testing, and, second, to provide you a rapid feedback loop to assist in your work. I have often found elements of TDD to be quite useful. Using a unit test or something similar to provide an efficient rapid feedback loop is a technique which I have employed many times. However, I am and have always been skeptical of the cult which arises around automated software testing and in particular TDD. A lot of people adopt an unquestioning loyalty to TDD, building tools and practices and vibes around the idea. It's often too much. The flaw with TDD is that, while it ensures that you have a test for every function you write, it also exerts an influence on the tested codebase, shaping the code to be as "testable" as possible, which only sometimes leads to better code. Moreover, TDD has no means of ensuring that the behavior that your tests verify is the right behavior for your software to have. Software with a thousand passing tests and 100% test coverage could be doing whatever the user or the business or whatever needs it to, but it could just as easily not meet the requirements in spite of those comprehensive tests - and in any case it gives you confidence in your work, which may or may not be misplaced. The cult of TDD exploits the fact that TDD is very good at making you feel like a good, diligent programmer. That rapid fee ## TDD & Commit: Is unit testing harmful? What about Rework/Refactoring? DevFeed: [TDD & Commit: Is unit testing harmful? What about Rework/Refactoring?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-26T06:54:19Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Refactoring](), [Unit testing]() Tags: [refactoring](), [tdd](), [testing](), [unit-testing](), [video]() ### AI overview A video talk examines how test-driven development relates to unit testing, refactoring, rework, and commit practices. It argues that testing problems usually stem from unclear intent, churn, poor test design, or misplaced tests rather than TDD itself. ### Source excerpt A recording from Denis Čahuk's live video ## TDD, TBD, Dynamic Teaming: What would a great CTO do? DevFeed: [TDD, TBD, Dynamic Teaming: What would a great CTO do?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-25T10:42:13Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Development](), [Agile]() Tags: [agile](), [leadership](), [legacy](), [metrics](), [mocking](), [tdd](), [team](), [testing]() ### AI overview This webinar connects test-driven development with dynamic team structures, trunk-based development, onboarding, and technical leadership. It argues that TDD and clear design seams can reduce onboarding friction, while measurement choices such as story points and pull-request counts influence team behavior and may obscure change friction. ### Source excerpt You're a CTO overwhelmed with improvement initiatives and pressure from your product team to stop with the Agile nonsense and just ship things. How do you balance your focus and execution? ## Should TDD be Mandatory? Why are so few teams using it? DevFeed: [Should TDD be Mandatory? Why are so few teams using it?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-24T13:33:16Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [engineering-culture](), [Testing]() Tags: [culture](), [engineering](), [experimentation](), [tdd](), [testing]() ### AI overview This article argues that TDD should neither be mandatory nor banned. Successful adoption depends more on psychological safety, cultural buy-in, team autonomy, and room for experimentation than on enforcement. It also presents TDD as a way to support earlier feedback and safer delivery under change. ### Source excerpt Popularity is not a good measure for quality. The best litmus test for engineering culture is an ongoing effort to learn and experiment with a small part of your bets. ## TDD: Getting out of the never-tester mindset DevFeed: [TDD: Getting out of the never-tester mindset]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-23T07:10:16Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Mocking]() Tags: [coaching](), [gatekeeping](), [tdd](), [team](), [testing]() ### AI overview This session examines why developers and teams struggle to adopt test-driven development. It argues that testing resistance often comes from systemic blockers such as gatekeeping, fragile delivery processes, limited psychological safety, and unclear testing goals. It presents coaching questions and emphasizes that TDD cannot overcome a dysfunctional working context on its own. ### Source excerpt Teams often lose the testing battle before it has begun due to their in-grained identity as not-testers or being in a certain camp: TDD, anti-TDD, old-school, new-age, vibe coder, etc. ## Understanding Mocks, Stubs, Fakes, and Shunts in Test-Driven Development DevFeed: [Understanding Mocks, Stubs, Fakes, and Shunts in Test-Driven Development]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-21T08:05:36Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Test-driven development](), [Testing]() Tags: [mocking](), [tdd](), [testing](), [tests](), [video]() ### AI overview A recording from Denis Čahuk's live video explains the differences between mocks, stubs, fakes, and shunts, and examines how overusing or misunderstanding test doubles can create tangled tests. It discusses testing outgoing commands with mocks and how difficult mocking setups may indicate design problems. ### Source excerpt A recording from Denis Čahuk's live video ## How Mocking Affects Software Design and Testability DevFeed: [How Mocking Affects Software Design and Testability]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-19T07:45:14Z Content type: tutorial Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Testing](), [Test-driven development](), [Refactoring](), [test-coverage]() Tags: [coverage](), [mocking](), [mongodb](), [refactoring](), [tdd](), [testing]() ### AI overview A recorded talk examines when mocks are useful, common misconceptions about mocking and TDD, and how excessive or poorly chosen mocks can constrain software design and testability. It discusses multi-mock tests, database mocking, and designing narrow seams around dependencies. ### Source excerpt If you've ever felt like your tests get in the way of refactoring, or like mocks make everything harder rather than simpler this stream is for you. ## ☀ While I'm out: A 6-part deep dive on TDD, engineering culture and leadership DevFeed: [☀ While I'm out: A 6-part deep dive on TDD, engineering culture and leadership]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-17T14:03:59Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [engineering-culture]() Tags: [engineering-culture](), [leadership](), [mocking](), [tdd](), [testing](), [unit-testing]() ### AI overview The author announces a six-part Substack series based on earlier coaching streams and webinars. The series covers testing, mocking, TDD, engineering culture, team dynamics, and leadership, with posts scheduled from July 19 through July 26. ### Source excerpt A Summer Deep-Dive on Testing, Design, and Teams from our previous webinars and coaching streams. ## TDD: The Missing Protocol for Effective AI Assisted Software Development DevFeed: [TDD: The Missing Protocol for Effective AI Assisted Software Development]() Original publisher: [Read original article]() Author: John Riccardi Published: 2025-05-28T18:14:00Z Content type: tutorial Language: en Sources: [8th Light Insights]() Topics: [Test-driven development](), [Large Language Model](), [AI Development](), [Software Engineering](), [Prompt Engineering]() Tags: [ai](), [coding](), [core](), [engineering-and-devops](), [llm](), [prompting](), [quality](), [software-development](), [tdd]() ### AI overview This article argues that test-driven development provides a structured communication protocol for collaborating with AI coding tools. It explains that large language models often struggle with broad, ambiguous software tasks because developers provide insufficient context, constraints, and edge cases, and recommends writing tests first before using AI to implement solutions. ### Source excerpt Bottom Line Up Front The goal isn't to replace human developers but to offload repetitive tasks so we can focus on creativity and architecture--where human expertise is irreplaceable. Start your next feature by writing tests first, then let AI help implement the solution. You'll deliver higher quality code faster, with greater confidence. Large Language Models Aren't as Simple as They Seem Large language models (LLMs) have a fundamental flaw: they appear deceptively easy to use. That blinking cursor invites you to interact with an LLM as if it were another human being--one that understands your intent, the context of your questions, and the logic behind your requests. You type a prompt, hit send, and then disappointment sets in. While it's exciting to watch it generate multiple files of code for your new project, the moment you try to run that code, it often fails to work as intended or doesn't run at all. As you continue prompting it to iterate on previous outputs, the LLM may go in circles, change direction entirely, or simply stall. The core issue is that we ask LLMs to do too much while providing too little direction and context--effectively setting them up for failure. It's like the classic PB&J experiment, where a father follows his children's sandwich-making instructions literally. We believe we're being clear, but we drastically underestimate how much implicit context AI lacks about the problems we're trying to solve. What we need is a better communication protocol--one that structures our requests in a way AI tools can reliably understand and execute. Why AI Struggles With Large, Ambiguous Problems Despite their impressive capabilities, current LLMs consistently struggle with large, vague problems. The issue is not primarily token limitations or technical constraints; it's a deeper problem in how we frame our requests. When developers ask AI to "build a complete authentication system" or "create an e-commerce checkout flow," they inadvertently set the AI up to [Next page]()