New AI models are shipping all the time, with fresh prompting guides accompanying each launch. The notes from one iteration to the next provide fairly generic instructions: Be more direct. Stop asking it to think step by step. Say each thing once. Trim your examples.

Odds are you’ve got a pile of saved prompts, Claude skills and projects, and the like, so those guides stop reading like advice and start reading like a punch list. Do I have to update all of this? Some of it? Which parts? I’ve built my fair share of skills and prompts, notably a weekly reporting workflow and productivity system, so I have a firsthand understanding of the confusion and frustration.

Most of this used to be somebody else’s problem. When a software application or system upgrade threatened to break something, IT owned the migration. Now, every knowledge worker is the IT department for their own AI setup. There’s no maintenance plan for that custom GPT you built at 11pm on a Sunday, and you are the emergency support tech when it stops working.

I’ve been through this cycle of break/fix a whole bunch of times, and here’s where I’ve landed: Sometimes the model really did get worse for your task. Providers do ship regressions, and Anthropic wrote a whole postmortem about three of them last fall. More often, though, when a prompt breaks on a new model, the prompt you built was doing two jobs to try and bend the AI in the direction you wanted it to generate.

The brief and the tricks

Everything in a prompt is one of two things:

The brief is the actual request. That entails information like who you are, what you need, what context matters, and additional details that inform the standard of quality, e.g. “I run partner marketing at a healthcare software company. Draft a follow-up email to a webinar attendee. Here are two past emails that got replies. Under 150 words, and don’t oversell.”

The tricks are everything you bolted on to make a particular model behave: “Think step by step.” “You are a world-class copywriter.” “Take a deep breath“ (The longer version of that last one was discovered through an LLM-driven prompt-optimization process and improved a particular math-benchmark setting, rather than being generally helpful). The instruction you pasted in three times because it kept getting ignored also falls under this category, as does the weird formatting workaround for a bug that got fixed two releases ago. And, who can forget the classic: MAKE NO MISTAKES!

Your brief is the core of what you want. It describes your work, and your work doesn’t care what the model version is. The tricks are accreted like defunct orbiting satellites from old model weaknesses, which is why the migration guides keep telling you to cut them. They’re usually dead weight at best, but can sometimes actively hinder your productivity. OpenAI’s own guide shows a “be THOROUGH” block that helped older models but made GPT-5 call search over and over, and Anthropic now tells people to rewrite “CRITICAL: You MUST use this tool” as, simply, “Use this tool when.”

Providing examples of good work to an AI tool is a tricky case, because they have the potential to both help and harm the output. The two past emails in the above brief are important, concise, and clear. They set the standard of quality, and they’ll do that job on any model. Shoving ten examples you piled up to force an old model into a format it kept fumbling is a brittle construct that degrades the quality of the output. When a guide says trim your examples, it means the latter kind.

My standard process to audit my prompts is asking one question line by line. Is this describing what I want, or coaxing a particular model into behaving? Structure, output format, and a role you use to customize the output all count as describing (the model makers still recommend them). Rip out the pile of other stuff trying to coax a model; chances are you will get better results.

Put your context in files, not in the prompt

Take the same idea of reducing clutter further. The prompt should be the smallest part of your setup.

Most serious AI tools now give you somewhere to keep context that outlives any single interaction, like project files or uploaded docs. That’s where you should place information that a prompt can reference. For many businesses, that means things like the tone guide, brand standards, your two best report examples, the glossary of internal acronyms nobody outside your company could possibly decode. A new model will still read your files a little differently, but there’s a difference between re-testing a setup you can understand and doing archaeology inside one giant pasted mega-prompt.

Keep a cheap test set

Teams that ship AI software run evals before they swap models. Think of evals as a ‘practice test’ for AI models; a standardized set of tasks used to check if the model still performs reliably after an update. Steal their idea! Save three to five real tasks, each with an output you know was good. Then, when a new model drops, run those tasks before you trust it with live work.

When you’re performing this testing on a new model, it’s important not to grade the new output by how closely it matches your saved one, because a better answer won’t match, and different isn’t worse. Grade it against the brief. And run the task you care about most a few times, since the same model won’t give you the same answer every time.

This is maintenance now

I’d love to tell you this is a one-time fix. It isn’t. AI tooling is personal infrastructure now, and infrastructure wants a little upkeep. When a major model lands, a quick audit grounded in briefs that focus on goals and outcomes should suffice for most people.My weekly reporting workflow has survived the last two model swaps without an edit, because everything in it describes the report instead of managing the model.

If after reading this, you’ve come to the realization that you need to get rid of some old tricks bogging down your set-up, the best time to act is now. The beauty of the situation is that you don’t have to go at it completely alone: you’ll find a willing and eager assistant in Claude, ChatGPT, Gemini, or whatever platform it is you’re using. Just make sure you prompt it correctly.

I’ve spent the last 20 years launching countless digital experiences, leading successful product and technology teams, and working with companies, large and small, in the US and abroad. In that time, this conversation has come up time and time again. An engineer or product lead sits down and says, “I don’t know what the old team was thinking when they wrote this code… but this system is brittle and it’s really holding us back. We just have to start over.”

But, easier said than done. You might be struggling to get your roadmap out the door, you have revenue goals tied to deliverables, and you’re trying to keep your customers happy with the right features, services, and support. The last thing you want to do is watch half your team go into hiding for the next year building their version of a “new” platform.

So you wait on starting the upgrade. Then it comes up in another 6 months, and you wait again.

You keep getting told how bad certain parts of your tech stack are and how they are slowing you down, all while not having the budget or time to give the work the attention it needs.

Sound familiar? It’s happening everywhere right now and affecting most companies that have been around longer than the last couple of years. It’s a result of a generation of builders moving to retirement, the speed of change increasing exponentially, an influx of new tools and solutions, and a growing number of employees and companies wanting desperately to upskill to stay relevant.

The real question is, should you finally rip off the band-aid and tackle the debt? There’s usually not a clear-cut answer. Not every frustration is a stack problem. Sometimes the tech is fundamentally fine and something else is the blocker. You may need help on process, the org, or just some good old fashioned data hygiene.

Here are five signs to look out for that indicate your stack needs a refresh:

• Fear of Deployment

• Knowledge Silos

• Talent Troubles

• Performance Plateau

• AI Blockade

Fear of Deployment

One of the most obvious signs of a system that would benefit from modernization work is that your team or the company view deployments as a “scary” event. Even whispering about deploying brings stakeholders out of the woodwork, suddenly interested in everything the team has been doing for the last several weeks.

Customer support is on high alert, launch & recovery playbooks are reviewed, calendars are cleared, or maybe you even still plan your deployments with some late night monitoring over pizza after all your customers are in bed.

I have a lot of fond memories of doing all of these things and, at the time, it was a sign of diligence, ownership, and accountability. If this is still part of your flow in 2026, you’re paying a heavy tax by not modernizing your technology.

With the tools and solutions available today, it is very possible to have near 100% automated test coverage, continuous integration and delivery pipelines, automated review escalation, agentic triage and break fixes, and a host of other solutions that feel like magic.

If this signal is strong in your organization, you won’t regret investing in modernization. Making it easier for teams to work and deploy, builds team confidence, reduces stress, improves predictability, and increases delivery velocity.

Knowledge Silos

As it relates to modernization, large gaps in information usually come in two flavors: “The people who know about it don’t work here anymore” and “The system was never well documented.” Relying on long-tenured subject matter experts used to mask bad documentation, but that just isn’t a viable strategy anymore.

There is a massive workforce that built many of the late 90s and early 2000s tech companies that is now shifting into retirement age. In addition to this group that is aging out of their professional tech roles, Fortune recently posted about a growing number of engineers retiring early just so they can avoid “dealing” with what AI is doing to their jobs.

In short, companies are losing decades of expertise right as their systems are under more scrutiny than ever. Changing demands on security, integrations, and speed to market are putting teams at a major disadvantage when the people that built the system are no longer around to answer the hard questions.

This isn’t happening just because of retirees, either. Job boards are busier than ever with droves of tech workers recently laid off or desperately trying to leave organizations they feel are preventing them from growing and using newer technology. This shuffling effect means we have more people than ever before trying to learn someone else’s tech stack and codebase, while the experts who understand it are nowhere to be found.

On top of that, even though most people in tech would agree that good documentation is important, it frequently takes a backseat to shipping features. Even if that system you have from 15 years ago was well documented, the inevitable iterations on top of the code leaves docs outdated and irrelevant.

Older monolithic systems with broad scope, limited documentation, and no stewards left standing, leads to a knowledge gap worth addressing. If you find yourself saying “The person who understands that isn’t here anymore,” it’s a good time to start considering a more modern stack that is easier for new recruits and agentic development tools to understand.

Talent Troubles

A related signal to pay attention to when deciding on a modernization effort is your employee satisfaction and retention overall. AI and modern tooling is incredible and it can be used to accomplish a great number of things. But the people you have on board to drive vision and provide judgement matter more than ever.

I’ve seen companies with amazing talent. People who work hard, want to learn, and have a real desire to make the company successful. But they are surrounded by cheap tools, antiquated systems, and underdeveloped processes.

The first sign of a tech related problem is usually subtle and will come in the form of some quips or side comments in passing, like “The system was slower than a herd of turtles today.”

Then it graduates, usually with employee seniority or comfort level, into some direct feedback. “I can’t do my job like this;” “I’m spending all my time just getting this data filled out;” “I really want to try using this new AI tool but am getting blocked”.

And eventually it leads to something we already discussed in the knowledge silos. “I’ve decided to take another position. Consider this my two weeks notice.”

If you are losing people, struggling with morale, or having difficulty recruiting, it could be time to modernize. Top talent doesn’t want to work on a mountain of tech debt on a system that won’t improve their experience or skillset. This usually isn’t a reason to tear everything down and start over, but it can be a strong contributing factor to account for when building a business case for modernization.

Performance Plateau

Customers are coming, revenue is growing, it all feels like you are finally making the progress on your roadmap you hoped for... And then it happens. A ping from your team saying that your system is redlining and the traffic is slowing the system to a crawl. It took you a decade to get here and now you have a system that was never designed for the volume or new use cases that are being thrown at it.

What do you do? Throw some hardware at it and hope for the best! On to fight another day!

Often this is actually a very prudent path forward. This could get you by for years and you will just reluctantly absorb the infrastructure costs as just part of doing business. But, eventually, the real bill of avoiding performance refactoring will come due when you just can’t handle the load. Features get blocked, roadmaps grind to a halt, and entire systems look like they are on life support.

When your bills from infrastructure providers start to look like hockey sticks, you hear about customers getting frustrated by laggy experiences or crashes, and you watch helplessly as opportunity costs pile up, it is probably a good time to come up with a plan. Strong modern system architectures based on technologies that are efficient and widely used aren’t just good for speed, they’re good for driving down expenses as well.

AI Blockade

The last major signal is that you’re surrounded by requests to use new AI tools or systems and you either don’t know where to start or keep hitting roadblocks.

It usually doesn’t start with a technology issue. It starts with pressure from stakeholders. Your board wants to know your “AI strategy.” Or, a competitor ships something that makes your product look like a dinosaur by comparison. Maybe your own team is sending you links to tools they swear will change everything. So, you decide to greenlight a pilot. And the pilot kind of works, on a clean little slice of demo data someone prepared by hand.

Then, you try to put it in front of real customers and it falls apart. The data the model needs is scattered across systems, half of it trapped in a unreadable format. There’s no clean way to feed it context. Nothing moves in real time. Security is nervous about pointing a shiny new tool at a system that was never designed to be opened up.

For a lot of businesses, AI keeps feeling just out of reach. It’s usually not the AI that’s the problem: Modern AI wants clean, accessible data, clear interfaces to reach it, and an architecture that can move in real time. If your system wasn’t built for any of that, you end up with impressive proofs of concept that don’t survive contact with production.

That said, sometimes what’s blocking AI isn’t your stack at all, it’s a policy nobody will sign off on, a leader who doesn’t believe, a skills gap on the team, or some other internal stigma preventing buy-in. Modernization won’t fix those. But when your best ideas keep dying somewhere between “let’s try this” and “we’re ready to deploy”, the technical foundation is often the culprit.

The AI Blockade is also the signal to watch most closely, because it’s the one with the most upside. The other four are about relieving pain through safer deployments, keeping your people, and taming your infrastructure bill, which are all operational hurdles. But responding to this particular signal is about directly expanding your capabilities. It reveals a problem with an outdated foundation that can’t carry the weight of what you want to build. Modernizing the components that are blocking your path is not only operationally practical, it actively accelerates your ability to innovate and grow.

Closing thoughts

None of these signals exist in a vacuum, and you’ll rarely have just one. They compound. Fear of deployment slows your roadmap, the roadmap stress drives out your best people, their departure widens the knowledge gap, and the whole time the AI opportunity sits there, just out of reach. It’s genuinely never been harder to keep up. The pace of change is relentless, the tools are multiplying faster than anyone can evaluate them, and the people who used to hold it all together are heading for the exits. If it feels like the ground is moving under you, that’s because it is.

But, the silver lining is that it has also never been easier to make the adjustments these signals are urging you to make. The same wave of AI and modern tooling that’s making legacy systems feel so far behind is exactly what makes modernizing them faster, cheaper, and less risky than it has ever been. Work that used to send a team into exile for a year can now happen in a tiny fraction of the time, out in the open, without risking the business.

If any of these signals sound familiar, don’t wait to start making changes. The best moment there’s ever been to modernize, start new, and unblock your teams and your business is now.