Tests and CI for agent-built code

What the signal means

A member reported asking an agent to rationalise a large, slow test suite. The result was a much smaller suite that the member felt covered the same ground. That opened a wider conversation about what testing should look like when agents write much of the code.

Suggestions were concrete: use deterministic clocks so time-based tests stop flaking; order test runs so cheap checks run first and expensive ones later; decide which checks belong in local git hooks and which belong in CI; and keep modules tidy so tests stay small. Several members treated these as basic hygiene that agents make more urgent, because agents generate tests quickly and a suite can bloat without anyone noticing.

A widely shared post arguing that UI end-to-end tests are rarely worth it drew disagreement. One member who builds software for clients to take over said that UI tests seldom pay off in that kind of handoff work. Others defended them for critical user flows. The thread also touched on a free security scanning offer from a code review vendor, and on how to share a repository with an outside party while using an AI coding assistant.

Practical implications

- Agents can help prune tests as well as write them. Pruning still needs a human to confirm what behaviour must stay covered. - Flaky tests waste agent time as well as human time. Deterministic clocks and isolated state are cheap fixes. - Split checks deliberately: fast local hooks for formatting and unit tests, CI for slower integration and security checks. - UI test strategy depends on who owns the software afterwards. Handoff projects and long-lived products justify different investments.

Content and community opportunities

- A short guide on test-suite hygiene for agentic projects, covering flakiness, ordering and suite size. - A hands-on lab where learners ask an agent to reduce a test suite, then check coverage and behaviour before accepting the change. - A decision table for when UI end-to-end tests are worth it.

Risks and open questions

- A smaller suite is only better if coverage of important behaviour is kept. Coverage numbers alone can hide gaps. - Agents may delete tests that look redundant but protect edge cases. - Free security scans are vendor offers. Their findings need review, and the vendor's claims are not community benchmarks. - Sharing repositories with outside parties while AI tools have access raises data-handling questions that each team must settle.

Watch next

- Tools that measure behavioural coverage rather than line coverage. - Patterns for agents that run, triage and fix CI failures on their own. - Whether the UI-test debate shifts as agents get better at operating browsers.