Not Everything Gets More Important. Some Decisions Get Cheaper to Change.
Every other note here argues that some piece of engineering discipline matters more now, not less, because AI tooling raises the cost of getting it wrong. That's true, but it would be a mistake to conclude that everything got higher-stakes. Treating every decision as newly critical is its own failure mode, usually one that shows up as months spent bikeshedding a choice that didn't need that much weight. It's worth being precise about what actually changed and what didn't.
The clearest example: choice of language, platform, and coding standards. For a long time, this was a decision you had to get close to right early, because changing your mind later meant an expensive, risky migration, often risky enough that teams simply lived with the original choice for a decade rather than pay that cost. That's part of why so much energy went into getting it right up front, and why so many early-stage teams spent longer than they should have debating a stack decision that, in hindsight, mattered less than shipping something.
What actually changed the math
With the rest of the discipline in place (clear requirements, real documentation and context, a test suite that operates at the right levels, etc.), an AI-assisted migration from one language or platform to another becomes meaningfully cheaper than it used to be. Mechanical translation work, the kind that used to be a dreaded, multi-quarter project done by hand, is exactly the kind of task agentic tooling accelerates well, provided it has something reliable to check its work against. I just completed doing a version of this, migrating a legacy MATLAB codebase to modern C++ on RTLinux with agentic AI tooling doing a meaningful share of the mechanical translation, work that would have been a much larger and slower undertaking by hand alone.
That's a real shift, and it changes what's worth optimizing for early. Locking in a language or framework decision out of fear of future migration cost is buying insurance against a risk that's gotten noticeably cheaper.
The decisions that stay expensive to fix later are the ones the other notes here are about:
Unclear requirements you didn't write down.
Undocumented behavior nobody captured.
No change-detection baseline, code with no reliable way to detect if you changed it.
Those are what determine whether a future migration, AI-assisted or not, is safe. Language choice increasingly isn't.
The important caveat
None of this means language and platform choice doesn't matter at all, or that you should pick carelessly. It means the cost of being wrong, or changing your mind later, has gone down, specifically because the other pieces are in place. Without good requirements, documentation, and test coverage, an AI-assisted migration is exactly as risky as it always was, arguably riskier, since a tool can now produce a confident, wrong migration faster than a person could.
The lower cost is conditional, not automatic. It's the payoff for having done the unglamorous work described in the rest of these notes, not a substitute for it.
I am not saying "stop worrying about your stack." But rather, "spend your worry where it still pays off." That's a different allocation of attention than software engineering culture has generally assumed, and it's worth deciding on purpose rather than by habit.
If you're sitting on a language or platform decision made years ago that no longer fits, and you've been assuming the migration cost is what it always was, that assumption is worth revisiting.
Read: Encase It in Amber Before You Refactor It → See Legacy Modernization →