Are AI coding tools fundamentally changing Agile/team software development?

5 hours ago 1

I'm an engineering lead wrestling with some fundamental questions about how AI coding assistants (Claude, Cursor, etc.) should change... or not change... how we build software as a team, and I'd love the community's perspective.

The Core Tension:

We're facing pressure to adopt a more "startup-like" approach: bigger PRs, fewer tickets, individual engineers taking on massive chunks of work solo with AI assistance. The argument is that AI tools let one engineer build in 5-6 days what used to require parallelizing across a team.

But this seems to violate core software engineering principles:

- Knowledge silos: One person becomes "the GraphQL guy" with 8,000-line PRs that are impossible to meaningfully review

- No knowledge sharing: Junior engineers don't learn from participating in the work

- Bus factor: What happens when that person leaves?

- Code quality: Can you really review an 8,000-line PR, or does it become "ship it and fix bugs later"?

The Counter-Argument:

- Startups move fast this way and win

- AI tools ARE changing everything.. maybe we're the ones using "punch cards" by sticking to old practices

- The customer doesn't care about our internal code quality, only that features ship

- Does tech debt even matter anymore if AI can navigate messy codebases?

My Current Thinking:

AI tools absolutely make us faster, but they're a multiplier on existing skill. A senior engineer with Claude can maintain good architecture and patterns while moving 10x faster. A junior engineer might just produce 10x more mediocre code faster.

I believe AI should enhance our existing workflow... better ticket planning, faster implementation of small chunks, AI-assisted code review.. not replace the workflow entirely with "hero engineering."

But I'm genuinely uncertain:

- Are traditional Agile practices (small tickets, parallelized work, thorough code review, documented backlogs) becoming obsolete?

- Is this a genuine paradigm shift, or are we just rediscovering why those practices existed in the first place?

- How do you balance "move fast" with "build maintainable software" in the AI era?

- Does code quality matter if you can ship features quickly and customers are happy?

Context:

- Team of ~20 engineers across 3 teams

- Using Claude Code, Cursor, etc.

- Pressure from leadership who built solo/small-team projects quickly to adopt that approach at scale

- Some engineers still not using AI tools effectively (or at all)

Has anyone successfully navigated this transition? What does "good" software engineering look like in 2025 with these tools? Am I clinging to outdated practices, or are there real risks to the "move fast, big PRs, worry about quality later" approach?

Read Entire Article