There is a kind of conversation I seem to be hearing more often in the AI era: instead of starting with what has already been learned, start over. Revisit the process. Rebuild the framework. Question every assumption from first principles.

This is my observation, not a measured trend. I cannot show that teams are doing this more often because of AI. I do wonder whether the AI boom has made reinvention feel unusually cheap. A new process diagram, planning framework, or implementation can now be generated in minutes. But generating an answer quickly does not mean changing how an organization works is cheap, or that the new answer is better.

First principles are a tool, not a daily ritual

Thinking from first principles is powerful when assumptions have stopped matching reality. It lets us separate facts from inherited habits, find constraints that nobody has questioned, and sometimes see a better path that analogy would miss.

But pulling every decision down to bedrock takes time. It also throws away useful accumulated knowledge unless we deliberately bring that knowledge back in. People have spent decades learning how software teams coordinate work, respond to changing requirements, and discover whether something is actually useful. We should be careful about assuming that a familiar practice is obsolete just because it is familiar.

AI can make the temptation stronger. It can help us brainstorm a new process or write a polished proposal before we have established that our current one is the cause of the problem. The hard part is still learning what is happening in the team and changing the conditions that produce it.

Some of our hardest problems are not new

The problems I have been reflecting on are painfully recognizable: deadlines slip, work takes longer than expected, dates get announced before anyone understands the work, and teams are not aligned on the outcome. Those symptoms deserve investigation. They do not automatically prove that Agile is broken, that waterfall should return, or that we need a brand-new methodology.

For example, the Agile Manifesto's principles already call for frequent delivery of valuable software, business and development working together, working software as the measure of progress, and regular reflection on how to improve. If those things are absent, adopting a different label may leave the underlying problem untouched. If the team is doing them consistently and still failing, that is useful evidence to examine, not a reason to defend the label.

Process names can become a distraction. A team can hold every ceremony and still lack shared priorities. A project plan can look precise while its dates are guesses. Neither more meetings nor a new set of vocabulary creates alignment by itself.

Start with the last failure, not a blank page

Before redesigning a development process, take one recent piece of work that missed its date and reconstruct what happened. What did everyone think the goal was? How was the date chosen? What was unknown? Where did work wait for a decision, another team, or a dependency? When did the first evidence appear that the forecast was wrong?

That investigation might show that the existing process was not followed. Maybe the people doing the work were not part of the estimate, or the team did not deliver a small slice early enough to expose uncertainty. It might show that a practice is being followed but is no longer suitable. Or it might uncover a problem that no process can solve without clearer priorities, faster decisions, or fewer competing commitments.

Use what the team already knows as a starting point. Compare estimates with actual work, make uncertainty visible, break down large efforts, surface dependencies, and check progress against working outcomes rather than confidence in a date. If the evidence points to a real mismatch, change the practice and watch whether the outcome improves.

Save the deep rethink for an inflection point

First-principles thinking is worth the effort when the operating environment has changed, the current approach repeatedly fails even when applied well, or the cost of a wrong assumption is high. It is also worth doing when the team can point to evidence that an established practice is creating a specific problem, rather than simply feeling old-fashioned.

Otherwise, begin with a reasonable existing practice and adapt it. That is not blind tradition. It is respect for prior learning, paired with a willingness to change when the facts call for it. We do not need to rediscover every wheel. We need to notice when the road, the vehicle, or the destination has changed.

My position: First principles are a powerful way to diagnose an inflection point, not a requirement for every process or decision. AI may lower the cost of generating a new answer, but it does not lower the cost of organizational churn or make the answer correct. Start from established practice, inspect the evidence, and rebuild only when there is a clear reason.

I'm curious where others draw that line. Has AI made your team more willing to start from scratch? When has a first-principles rethink genuinely improved a process, and when would adapting what already works have been better?

Sources