Ten mindset changes for development teams
This article is part of my series on development using AI. Earlier articles explore making estimates more useful and moving from requirements to a shared design.
AI-assisted development can create an illusion of speed. Code appears quickly, but incorrect assumptions, missing requirements, and operational concerns may surface later during review, testing, and deployment.
Spec-driven development brings these decisions forward. The team establishes the intended behaviour, scope, constraints, and acceptance criteria before asking AI to implement the change.
This involves a trade-off. Spending more time upfront may delay the first visible implementation, but it can reduce rework and support longer-term stability and quality.
That requires a mindset change across developers, product teams, reviewers, and engineering leaders. Clarification, design, and verification need to be recognized as part of delivery. The speed at which code is generated is only one part of the outcome.
The specification as a shared agreement
A specification gives the team and AI a common reference for implementation and review. It captures what the change should achieve, the boundaries it must respect, and the evidence needed to confirm that it works.
It does not have to describe the entire system or settle every future decision. Define enough detail for the next increment, make unresolved questions visible, and update the specification as the team learns.
10 mindset changes for development teams
1. Start with intent, not code
Clarify the problem, intended outcome, and scope before discussing implementation. Check that the proposed change addresses the actual need and fits the existing system.
2. Make ambiguity visible
Separate confirmed requirements, assumptions, and open questions. Ask AI to identify gaps rather than silently make decisions. Resolve questions that could materially affect the design or scope.
3. Treat the specification as a living agreement
Update the specification when investigation or implementation changes the team’s understanding. Record important decisions and their rationale so the specification, code, and tests remain aligned.
4. Specify the next safe increment
Define a manageable change with clear boundaries, relevant dependencies, and acceptance criteria. Avoid overengineering or designing features that are not yet needed.
5. Define correctness beyond functionality
Consider security, privacy, performance, reliability, and observability alongside functional behaviour. Include the constraints relevant to the change, including what should happen when something fails.
6. Set measurable expectations
Replace vague requirements such as “fast” or “scalable” with agreed targets and operating conditions. Define how those targets will be verified. AI can suggest questions, but the team must confirm the expectations.
7. Define evidence before implementation
Map important requirements to acceptance criteria and verification methods. These may include automated tests, performance measurements, configuration checks, or specialist reviews.
Check that the evidence will demonstrate the intended behaviour, rather than simply confirm how the code was written.
8. Review intent before reviewing code
Review the specification for missing requirements, conflicting constraints, unsupported assumptions, and unnecessary scope. Correcting these early can prevent the same misunderstanding from spreading across code and tests.
9. Delegate execution, not accountability
AI can assist with planning, coding, testing, and review. The team remains responsible for validating the evidence, weighing trade-offs, and approving the result.
A passing test run or a confident AI explanation is an input to that judgment.
10. Treat context as shared infrastructure
Maintain domain rules, architecture decisions, engineering standards, and operational constraints as reusable project context. Give important sources an owner and keep them current.
Each specification can reference this context and add the details specific to the change.
Make room for the upfront work
This approach needs support across the team. Product teams help clarify outcomes. Engineers identify dependencies and constraints. Reviewers examine the proposed behaviour before implementation. Leaders allow time for these decisions.
The first implementation may take longer to appear. The aim is to carry fewer unresolved assumptions into development and spend less time correcting them later.
AI can accelerate execution. A shared specification helps the team direct that execution and assess whether the result is ready.
Top comments (0)