The AMS Moment: Why Stopping to Ask 'Are We Missing Something?' Could Save Your Next Project

The year is 2025, every company, mainly the tech ones are on the rush to implement AI and gain efficiency with that. Software teams often leap from problem identification to solution architecture in record time. We’ve all been there: whiteboarding sessions filled with excitement, architecture diagrams multiplying, and the team rallying around an elegant technical solution. But here’s the uncomfortable truth—sometimes we’re solving the wrong problem entirely, or worse, solving it in a way that creates more issues than it resolves.

This is where the AMS Moment comes in: a deliberate pause before execution begins, where the team asks collectively, “Are we Missing Something?”

The Cost of Charging Forward

In Thinking, Fast and Slow, Daniel Kahneman describes how our brains default to System 1 thinking—fast, intuitive, and emotional. In software development, this manifests as pattern matching: we recognize what appears to be a familiar problem and immediately reach for familiar solutions. We’ve built recommendation engines before, so when asked to implement AI-powered code suggestions, we instinctively start designing microservices, selecting ML frameworks, and debating between vector databases.

But System 1 thinking has blind spots. It doesn’t naturally question assumptions. It doesn’t pause to ask whether the problem framing itself is correct.

Consider the recent explosion of AI coding agents. Teams everywhere are racing to integrate tools like GitHub Copilot, cursor, or building their own code generation systems. The technical challenge is intoxicating: fine-tuning models, designing context windows, creating effective prompts. But the AMS Moment forces harder questions:

• Are we solving developer productivity, or are we masking deeper issues in our development process?
• Will generating code faster actually accelerate delivery, or will it create a new bottleneck in code review and technical debt?
• Have we validated that developers actually want to write code this way, or are we building based on executive enthusiasm?
• What happens to junior developer learning curves when code generation becomes ubiquitous?

These aren’t questions you ask while you’re excited about architecting a solution. They’re questions you ask when you deliberately stop and create space for skepticism.

What Big Tech Knows About Stopping

Amazon’s famous “six-page memo” practice, detailed in Working Backwards by Colin Bryar and Bill Carr, embodies this philosophy. Before any major project begins, teams must write a detailed narrative document starting with a press release for the customer. The exercise forces teams to articulate the problem, the customer, and the benefit before any solution is proposed. It’s an institutionalized AMS Moment.

The memo format works because narrative writing is hard. You can’t hide fuzzy thinking in prose the way you can in bullet points. As you write “customers struggle with X because of Y,” you’re forced to confront whether you actually understand X and Y, or whether you’re making assumptions.

In The Lean Startup, Eric Ries advocates for validated learning before scaling solutions. His concept of the Minimum Viable Product (MVP) is essentially a continuous AMS Moment—constantly questioning whether you’re building something people actually need. The innovation isn’t in the building; it’s in the disciplined pause to validate assumptions before committing resources.

Google’s post-mortem culture, described in Site Reliability Engineering, applies this same thinking to failures. But the deeper lesson is about making space for questioning before failures occur. The best teams don’t just ask “what went wrong?” after an outage—they build rituals that ask “what could go wrong?” before pressing deploy.

How the AMS Moment Works

The AMS Moment is not a meeting. It’s a ceremony with specific structure:

1. The Trigger: Before any significant technical decision or project kickoff, the team schedules a dedicated AMS session. This isn’t optional. It’s part of the process.

2. The Constraints: The session has a time box—typically 30-60 minutes depending on project scope. This prevents analysis paralysis while forcing prioritization of concerns.

3. The Rules:

• No solutions allowed yet. Only questions and observations.
• Every team member must contribute at least one concern or gap.
• Seniority doesn’t matter. A junior engineer’s “stupid question” might reveal the critical oversight.
• Someone captures everything without judgment or immediate rebuttal.

4. The Categories: Structure the questioning around key dimensions:

• Problem framing: Are we solving the right problem? For the right users?
• Assumptions: What are we taking for granted? What if those assumptions are wrong?
• Constraints: What aren’t we considering? Technical debt? Team capacity? Regulatory issues?
• Alternative approaches: What if we didn’t build anything? What if we bought instead of built?
• Success definition: How will we know if this works? What does “done” mean?

5. The Decision: After the time box, the team makes one of three choices:

• Proceed: The questions raised were addressed, or represent acceptable risks.
• Pivot: A significant gap was identified that changes the approach.
• Investigate: Critical unknowns emerged that need research before proceeding.

The AI Coding Agent Example

Let’s apply this to a real scenario. Your VP of Engineering announces that the company is building an internal AI coding agent to boost developer productivity by 40%. The solution seems clear: fine-tune an LLM on your codebase, integrate it into IDEs, track code generation metrics.

A team energized by the technical challenge might immediately start:

• Evaluating which LLM to use
• Designing the embedding strategy for code context
• Building telemetry to measure adoption
• Creating prompts for different coding scenarios

But the AMS Moment forces a different conversation:

“Are we missing something about the problem?”

• Has anyone actually measured what slows down our developers? Is it code writing, or is it build times, unclear requirements, and excessive meetings?
• What does “40% more productive” even mean? More code? Faster features? Better quality?

“Are we missing something about our constraints?”

• Do we have the ML expertise to maintain this? Or will this become another “innovative prototype” that never reaches production?
• What’s the latency budget? Developers won’t use a tool that interrupts their flow.
• How do we handle security? Feeding proprietary code to an LLM has implications.

“Are we missing something about alternatives?”

• Have we tried simply adopting GitHub Copilot Business first? Why reinvent this?
• What if the real productivity win is reducing our 12-step deployment process, not generating code faster?

“Are we missing something about success?”

• If developers write 40% more code but bugs increase by 60%, did we succeed?
• What if developers hate it and refuse to adopt it? Do we mandate usage?

These questions aren’t pessimism. They’re due diligence. And sometimes, they’ll reveal that the original problem framing was off entirely. Maybe developers aren’t slow because they type too slowly—they’re slow because they spend days waiting for architectural decisions, or because technical debt makes every change risky.

Why This Is Harder Than It Sounds

The AMS Moment challenges several deeply embedded organizational behaviors:

Action bias: We reward teams that ship. “Analysis paralysis” is an insult. Stopping to question feels like not doing.

Sunk cost fallacy: Once a leader champions an idea, questioning it feels like questioning their judgment. The more senior the sponsor, the harder it becomes to ask “Are we sure about this?”

Expertise trap: Senior engineers have pattern recognition. They’ve solved similar problems. This experience is valuable but can become a blindfold. Sometimes the junior engineer who says “I don’t understand why we’re doing it this way” is seeing something everyone else missed.

FOMO (Fear of Missing Out): When everyone is building AI coding agents, not building one feels like falling behind. The AMS Moment might reveal you don’t actually need one, but that’s an uncomfortable position when competitors are announcing their AI initiatives.

Building the Muscle

Organizations don’t naturally embrace structured skepticism. Here’s how to build the AMS Moment into your culture:

Start small: Don’t mandate it company-wide. Start with one team or one project. Let results speak.

Make it safe: The AMS Moment only works if people can voice concerns without political consequences. If someone raises “Are we sure leadership actually wants this?” and gets shut down, you’ve killed the practice.

Track outcomes: Keep a log of projects where the AMS Moment led to a pivot or investigation, and note what disaster was avoided. These become your case studies.

Celebrate course corrections: When a team uses an AMS Moment to realize they were solving the wrong problem and changes direction, that should be celebrated as rigorously as shipping a feature. You avoided wasted engineering months.

Make it routine: The AMS Moment shouldn’t feel like a special event. It should be as normal as sprint planning or retrospectives.

The Paradox of Slowing Down to Speed Up

The AMS Moment will feel like overhead. It will feel like it’s slowing you down. And in the short term, it is. You could have started coding already.

But consider the alternative: six months of engineering effort building the wrong thing, or building the right thing in a way that creates more problems than it solves. Consider the opportunity cost of what you didn’t build while you were pursuing a doomed approach.

As Jeff Bezos wrote in his 2016 letter to shareholders (referenced in Working Backwards), some decisions are one-way doors—hard to reverse—and others are two-way doors—easy to undo. The AMS Moment helps you identify which is which, and ensures you’re treating one-way-door decisions with appropriate gravity.

Conclusion: The Courage to Question

The software industry celebrates builders. We lionize teams that move fast and break things. But the most mature engineering organizations have learned that sometimes the most valuable thing you can do is stop, question your assumptions, and make sure you’re not sprinting in the wrong direction.

The AMS Moment—”Are we Missing Something?”—isn’t about being negative. It’s about being thorough. It’s about creating a space where the newest team member can raise concerns without fear, where pattern recognition gets validated rather than assumed, and where the excitement of building something new doesn’t override the discipline of building something right.

In the age of AI coding agents and rapidly evolving technology, this discipline matters more than ever. The cost of building the wrong thing has never been higher, and the pressure to move fast has never been more intense.

Before you draw your next architecture diagram, before you spin up your next LLM fine-tuning job, before you commit to your next big technical initiative—stop.

Ask: “Are we missing something?”

The answer might save your project.

---

References & Further Reading

• Kahneman, Daniel. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011.
• Bryar, Colin, and Bill Carr. Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin’s Press, 2021.
• Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.
• Beyer, Betsy, et al. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, 2016.
• Bezos, Jeff. “2016 Letter to Shareholders.” Amazon, 2017.