Your SaaS Platform Probably Doesn't Need a Rewrite. It Needs to Grow Up.

 

There is a moment in the life of many successful software products when someone finally says it: "We need to rewrite this thing."

 

The developers are frustrated. Releases are getting harder. Bugs seem to appear in places nobody expected. Customers have workflows nobody completely understands anymore. There are integrations nobody wants to touch.

 

Someone inevitably looks at the old platform and says:

• "If we could just start over..."
• I've seen this story before.
• And sometimes a rewrite really is necessary.
• But quite often, the technology isn't the real problem.

The organization has simply outgrown the way it builds and manages software.

 

Success Creates Its Own Technical Debt

We normally talk about technical debt as though someone did something wrong.

 

That's not always fair.

 

Some technical debt is simply the cost of moving quickly. 

 

A company gets a new customer who needs something immediately. A developer creates a workaround. Sales lands another major customer with slightly different requirements. Another exception gets added.

 

• The company grows.
• Revenue grows.
• The platform grows.
• And everyone celebrates as they should.
• But something else has been growing quietly in the background.

Complexity.

 

• The temporary workaround becomes permanent.
• The exception becomes a feature.
• The feature gets another exception.

Before long, nobody remembers exactly why certain things work the way they do. They just know changing them might break something.

 

That's when healthy growth debt can begin turning into dangerous operational debt.

 

The Financial Statements May Not Warn You

 

This is where things become particularly interesting from a leadership perspective.

 

• A software company can look financially healthy while its technology platform is becoming increasingly unhealthy.
• Revenue may still be growing.
• EBITDA may look good.
• Customer churn may remain low.
• Yet inside the organization, something very different is happening.
• Release cycles are getting longer.
• Developers are becoming increasingly cautious about deployments.
• More engineering capacity is spent fixing problems instead of creating capabilities.
• Customer-specific workarounds multiply.
• New developers take longer to become productive.

And the product roadmap gradually changes from:

 

• What should we build next?

to:

• What can we safely change without breaking something?

 

Those are two very different companies.

 

Low churn doesn't necessarily mean customers love your product, either. Sometimes customers remain because switching platforms is difficult, expensive, or disruptive.

Stable revenue can hide an enormous amount of operational fragility.

 

The Most Dangerous Phrase May Be "Don't Touch That"

 

Several warning signs show a platform drifting from innovation into maintenance mode.

• One of my favorites is deployment anxiety.
• Everyone knows that part of the system.
• Maybe only one developer understands it.
• Maybe nobody completely understands it.
• Eventually the institutional knowledge becomes:  Don't touch that unless you absolutely must.

That's not just technical debt anymore.   That's organizational risk.

Another warning sign is constant firefighting.

1. Engineering teams become extremely busy while accomplishing surprisingly little strategic work.
2. Everyone is working.
3. Everyone is solving problems.
4. Everyone is exhausted.
5. But the platform isn't really moving forward.

Activity and progress aren't the same thing.

 

Then Someone Suggests the Rewrite

• At this point, a complete rewrite starts sounding incredibly attractive.
• New architecture.
• New framework.
• Clean database.
• Modern APIs.
• No legacy code.
• No ugly compromises.
• A fresh start.

I understand the appeal.

 

The problem is that your old application contains something incredibly valuable that rarely appears in an architecture diagram:  years of accumulated business knowledge.

 

• Every strange conditional statement may exist because five years ago a customer discovered an edge case.
• Every unusual workflow may represent a business requirement somebody forgot to document.
• Every integration may contain lessons learned through years of production failures and fixes.
• That ugly old platform isn't merely code.
• It is institutional memory expressed in software.
• When you rewrite it, you aren't simply replacing technology.
• You're attempting to rediscover years, sometimes decades, of business knowledge.
• And while you're doing that, you still have customers using the old system.
• Now you have two platforms to maintain.

Meanwhile, feature development slows because your best people are rebuilding capabilities customers already have.

 

That's an expensive way to discover that the old software wasn't the only problem.

 

You Can't Rewrite an Organizational Problem

 

This is the part I believe technology and business leaders sometimes overlook.

 

Suppose the original platform suffered from:

• weak product governance,
• constantly changing priorities,
• inadequate QA,
• unclear architectural ownership,
• customer-specific customization,
• interrupt-driven development, and
• no dedicated capacity for modernization.
  
  

Now imagine building a brand-new platform...     

using the same organization and processes.

• Question: What do we think is going to happen?
• Answer:  Eventually you'll have a beautiful new codebase carrying many of the same problems as the old one.

Because you replaced the technology without changing the system that produced it.

 

A rewrite is not automatically a transformation.

 

Mature Platforms Evolve

 

The alternative isn't ignoring technical debt.  Quite the opposite.

• Healthy technology organizations treat modernization as part of operating the business.
• They continuously refactor high-risk areas.
• They automate testing and deployment.
• They establish architectural standards.
• They create clear ownership.
• They invest in observability.
• And perhaps most importantly, they resist solving every customer's problem with another piece of custom code.
• Whenever possible, mature platforms become configurable rather than customized.
• That's a subtle distinction with enormous consequences.
• Customization says: We'll change the software for you.
• Configuration says: We designed the platform so it can adapt to you.

One scales.  The other eventually becomes a collection of exceptions pretending to be a product.

 

Engineering Needs Room to Improve the Engine

 

There is also an uncomfortable economic reality here.

 

If 100% of engineering capacity is allocated to customer requests, features, and production problems, then effectively 0% is being invested in the future health of the platform.

 

Eventually, that bill comes due.

 

Organizations need intentional modernization capacity.

• Not someday.
• Not "when things slow down."
• Because things rarely slow down.

Technical leadership must deliberately balance innovation, stability, and modernization.

 

That means sometimes saying:  "We're going to spend engineering capacity improving something the customer may never directly see."

 

• Better deployment pipelines.
• Automated testing.
• Architecture improvements.
• Monitoring.
• Refactoring.
• Standardization.

Those things aren't distractions from product development.

 

They are what make continued product development possible.

 

Technical Debt Eventually Becomes Financial Debt

 

This is where the technology conversation becomes a business conversation.

 

Technical debt doesn't remain technical forever.

 

Eventually, it appears somewhere on the financial side of the organization.

 

• Higher support costs.
• Longer development cycles.
• More engineers required to deliver the same amount of functionality.
• Slower customer onboarding.
• Increasing infrastructure costs.
• Reduced innovation.
• Missed opportunities.
• Margin compression.

Eventually, the company realizes it isn't simply maintaining software.

 

• It's paying interest on years of deferred decisions.
• The Question Leaders Should Be Asking

So instead of immediately asking: "Should we rewrite the platform?"

 

I think leadership teams should start with several different questions. 

 

1. What operational risks are currently hidden beneath stable revenue?
2. Are we scaling our architecture or simply scaling our workarounds?
3. How much engineering capacity is going toward innovation versus maintenance?
4. Are we building a platform, or are we maintaining hundreds of customer-specific exceptions?

And perhaps the most important question: If we built the entire platform again tomorrow but kept the same leadership structure, priorities, processes, and engineering practices, would we eventually end up right back where we are today?

 

If the answer is yes, the problem probably isn't the codebase.

 

Technology platforms don't become sustainable because they're new.

 

They become sustainable because the organizations responsible for them develop the discipline to continuously evolve them.

 

The goal shouldn't be to build software that never becomes old.  That's impossible.

 

The goal is to build an organization capable of helping its technology grow old gracefully while continuously making it better.

 

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

From Personal Habit to Team Habit: Getting Your Team to Build an AI Toolbox

A few weeks ago I wrote about building a personal AI toolbox — using Claude, ChatGPT, and GitHub Copilot for different stages of work instead of arguing over which one is "best." That post landed with a lot of people individually. But it also surfaced a question I didn't expect: okay, but how do I get my team to actually work this way?

 

That's a harder problem than it sounds, and it's worth separating from the personal version.

 

Why "just use AI" doesn't work as team guidance

Most teams I've seen approach AI adoption the same way they approach a new tool rollout: pick one platform, license it, tell everyone to use it. That works fine for something like a ticketing system, where the whole point is that everyone uses the same one.

 

It doesn't work for AI, because — as I wrote last time — different tools genuinely do different jobs well. Standardizing on a single platform for a team doesn't eliminate the "which tool for which job" problem. It just hides it, because now everyone is quietly using the wrong tool for at least some of their work, and nobody's saying so out loud.

 

The result is usually one of two failure modes: people quietly stop using the mandated tool for the tasks it's bad at, or they force it to work anyway and produce mediocre output while telling themselves "well, that's just what AI does."

 

What actually changes at the team level

The individual "routing" skill I described last time — knowing which tool fits which stage of work — still matters. But at the team level, three additional things become the real work:

1. Shared vocabulary for the stages. If I say "let's ChatGPT this" and my teammate says "let's Claude this," we're actually agreeing on something useful — that this is early-stage shaping work versus deep project work — even if it sounds like we're just naming brands. Getting a team to name the stages of work, not just the tools, is what makes routing something you can talk about instead of something everyone does silently and differently.
2. Permission to use more than one tool. This sounds obvious, but it's the single biggest blocker I've seen. Procurement and IT naturally want to minimize the number of licensed tools, for good reasons — cost, security review, support burden. But if a team is only allowed one AI platform, you've reintroduced the exact problem the personal toolbox approach was meant to solve. Part of the leadership job here is making the case that two or three well-chosen tools, used deliberately, produce better outcomes than one tool used for everything.
3. Visibility into how people are actually using each tool. Not surveillance — just enough shared practice that the team learns from each other. If one engineer has figured out that Copilot handles a particular kind of refactor well, and another is fighting through the same kind of refactor manually, that's a five-minute conversation that saves real time. Most teams have no mechanism for this kind of exchange because "how I use AI" isn't normally treated as something worth discussing out loud.

What this looks like in practice

On my own team, the shift wasn't a policy — it was a habit. We started naming, casually, which "mode" a task was in before jumping into a tool. Is this a strategy conversation, or is this project work? Is this something that needs deep context, or is it a quick inline assist? Once that became a normal question to ask out loud, people naturally reached for different tools without needing a mandate.

 

The other change was simply normalizing "I used two tools for this." Early on, there was a faint sense that switching tools mid-task meant you'd picked wrong the first time. Once that stigma went away — once "I sparred with ChatGPT on the approach, then built it out in Claude" became a completely unremarkable thing to say in a standup — the whole team's AI use got noticeably more effective.

 

The leadership takeaway

If you're leading a team through AI adoption, the temptation is to simplify the decision for people: pick one tool, roll it out, move on. I understand the appeal. But the simplification is actually removing the thing that makes AI valuable in the first place — the ability to match a fluid, capable tool to the actual shape of the work in front of you.

 

The job isn't to pick the tool for your team. It's to build a team that knows how to pick.

 

#ArtificialIntelligence #ChatGPT #ClaudeAI #GitHubCopilot #Leadership #SoftwareDevelopment #Technology

 

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Building Your AI Toolbox: A Practical Guide to Using Claude, ChatGPT, and Copilot Together

Earlier this month I made the case that comparing AI platforms head-to-head misses the point. The question I keep seeing — "which AI is better?" — isn't really the question that matters. What matters is which tool fits the job in front of you.

That post seemed to resonate with people, so I want to go one step further. Because knowing that you should have an AI toolbox doesn't help much if you don't actually know how to use one. Owning a toolbox and knowing your workflow are two different things.

So here's what my workflow actually looks like, tool by tool, and the thinking behind it.

The problem with picking a "favorite"

Most of the AI discourse I see online is framed as a competition. Someone posts a benchmark, someone else posts a counter-example, and the comments turn into a debate about which platform "wins." I understand the impulse — we like rankings, they're easy to argue about, and picking a favorite feels like it saves you the work of thinking further.

But the ranking impulse breaks down the moment you actually try to use these tools for real work. A tool that's excellent at one stage of a task can be mediocre at another stage of the same task. If you judge it only on the stage where it's weak, you conclude "this AI isn't very good," when really you just used a screwdriver to turn a bolt.

The fix isn't finding the one tool that's good at everything. It's noticing that your work itself has stages, and matching the tool to the stage.

The three stages of a piece of work

When I look back at how I actually get things done, three distinct modes show up over and over:

1. Shaping the problem. This is the messy, early part — before you know exactly what you're building, sometimes before you're even sure the idea is a good one. You need something to push back on you, ask the annoying follow-up question, and help you find the holes in your own thinking.

2. Doing the real work. Once the idea is solid enough to act on, the job changes completely. Now you need depth and continuity — something that can hold the whole shape of a project, a codebase, or a document, not just one clever exchange.

3. Executing in the flow. This is the moment-to-moment part — writing the actual code, making the actual edit — where you don't want a conversation at all. You want something quietly keeping pace with you.

Three different jobs. Three different tools, for me.

How I actually use each one

ChatGPT, for shaping the problem. Before I write a line of code or open a document, I want to know I'm solving the right problem in the first place. I'll bring ChatGPT a half-formed idea — a technical approach, a leadership challenge, a strategy question — and use the back-and-forth to stress-test it. It's less "give me the answer" and more "help me find out where I'm wrong." That adversarial, sparring-partner quality is what makes it useful here. I'm not looking for agreement; I'm looking for friction.

Claude, for the real work. Once an idea turns into actual work — a project, a codebase, a document that needs real structure — that's when Claude takes over for me. It holds context across a whole piece of work rather than a single exchange, and that matters enormously once you've moved past brainstorming and into building something that has to hang together. Give it a technical problem or a messy codebase and it can work through it methodically rather than needing to be re-oriented every few minutes.

GitHub Copilot, for the flow. Copilot doesn't get a dedicated "session" the way the other two do. It's just there, inline, while I'm actually writing code — finishing a line, suggesting the next one, staying out of the way otherwise. It's less a tool I deliberately reach for and more a tool that's already in my hand when I need it.

The skill isn't prompting — it's routing

Here's the pattern underneath all of this: the tool changes as the work changes. Early-stage thinking, deep project work, and in-the-moment execution are three different modes, and trying to force one AI to do all three is where people get frustrated and conclude "AI isn't that useful for X."

It's not that the AI failed. It's that it was doing a job it wasn't built for.

I think this is where a lot of the "prompt engineering" conversation misses the bigger picture. Getting better at prompting one tool only gets you so far if you're using the wrong tool for the stage of work you're in. The more valuable skill — the one that's actually going to compound over time — is routing: recognizing what stage of work you're in and knowing which tool matches it, before you even open the app.

A rough framework, if you want one

If it helps to have something concrete, here's roughly how I decide:

• Am I not sure what I'm building yet? → Start with a sparring partner. Push on the idea until it either survives or falls apart.
• Do I know what I'm building, and does it require holding a lot of context across a real project? → Move to a tool built for depth and continuity.
• Am I already doing the work, and just need help keeping pace? → Use whatever lives inline, in the flow, with the least friction.

It's not a rigid rule, and there's plenty of overlap — any of these tools can do a decent job outside its "home" stage. But defaulting to this kind of routing has made my own work noticeably less frustrating, because I'm no longer expecting one tool to be everything at once.

The real competitive advantage

The future of AI probably isn't about picking one AI platform and becoming an expert in it. It's about building a toolbox and learning, almost instinctively, which tool to reach for depending on the job in front of you.

The real competitive advantage may not be having access to AI — at this point, most people do. It may be knowing which AI to use, when to use it, and how to move between them without losing momentum.

That's the part I'm still refining. But it's already changed how I work.

#ArtificialIntelligence #ChatGPT #ClaudeAI #GitHubCopilot #Leadership #SoftwareDevelopment #Technology

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

 

Building Your AI Toolbox: Why I Use Claude, ChatGPT, and GitHub Copilot Differently

There seems to be a constant debate happening around artificial intelligence: Which AI platform is the best?

Is it ChatGPT? Claude? GitHub Copilot? Something else?

I think we may be asking the wrong question.

I have spent most of my career working with technology, and one thing technology teaches you very quickly is that there is rarely one tool that is best at everything.

Think about the toolbox you have at home. You probably have screwdrivers, wrenches, sockets, pliers, hammers, drills, and dozens of other tools. Nobody opens that toolbox and asks, "Which one of these is the best tool?"

The answer would be obvious: It depends on what you're trying to accomplish.

I believe we should start thinking about AI the same way.

AI Is Becoming a Toolbox

Over time, I have found myself using Claude, ChatGPT, and GitHub Copilot differently.

There is certainly overlap between them. All three continue to evolve, and each can perform tasks that might traditionally be associated with another platform. But that doesn't mean they feel the same when you're actually working with them.

Each has developed strengths that make me reach for it in different situations.

Claude: When I Want to Build

Claude has become particularly interesting to me when it comes to software development.

When I have a coding project, existing codebase, technical problem, or something that needs to be built and iterated upon, Claude can be an extremely capable development partner.

What I find valuable isn't simply its ability to generate code. Writing code is only one part of software development.

Understanding an existing application, following dependencies, recognizing patterns, making changes without unnecessarily disturbing other parts of the system, troubleshooting problems, and iterating on a solution are often much more important.

That makes Claude interesting as more than a code generator. It can become part of the development environment itself.

For someone who understands technology but may not necessarily spend every day writing code, tools like this can also dramatically reduce the distance between having an idea and actually building something.

GitHub Copilot: AI Where Developers Already Work

GitHub Copilot approaches the problem from another direction. Instead of asking developers to leave their normal workflow and go somewhere else to interact with AI, Copilot brings AI directly into the development process.

That is an important distinction.

Developers already spend their days inside editors, repositories, pull requests, and development tools. Having AI available inside that environment makes it a natural companion.

It can assist with writing code, understanding unfamiliar code, generating tests, explaining functions, suggesting improvements, and handling some of the repetitive work developers deal with every day.

The value isn't necessarily replacing the developer. It's reducing friction.

A good power tool doesn't replace the carpenter. It allows the carpenter to accomplish more with the skills and experience they already have.

I see Copilot in much the same way.

ChatGPT: My Sparring Partner

My relationship with ChatGPT is somewhat different.

I certainly use ChatGPT for technical questions and coding. It is more than capable of helping in those areas. But where I personally find it particularly valuable is as a sparring partner for ideas.

Sometimes I don't need someone to give me an answer. I need something that helps me think.

I may start with a business problem, a technical strategy, a leadership challenge, an architecture decision, a product idea, or simply a half-formed thought. Then I start asking questions:

What am I missing? What assumptions am I making? What happens if we approach this differently? What are the risks? How would I explain this to an executive? How would I explain the same thing to an engineer? What would someone who disagrees with me say?

Those conversations can be incredibly valuable.

For me, ChatGPT becomes less of an answer engine and more of a thinking environment.

The AI doesn't have to make the decision. I still make the decision. But having something available that can challenge an idea, organize my thoughts, explore alternatives, and help turn a rough concept into something actionable can dramatically accelerate the thinking process.

The Tools Are Starting to Overlap

There is an important caveat to all of this: These categories are not permanent.

Claude can absolutely help with strategy and writing. ChatGPT can absolutely build and troubleshoot software. GitHub Copilot continues expanding beyond simple code completion.

The boundaries between these platforms will continue to move. Six months from now, I may use them differently than I do today.

And that's actually part of the point.

We shouldn't become so attached to a particular AI platform that we stop evaluating the tools available to us.

Technology changes. Our toolbox should change with it.

The Bigger Skill Is Knowing Which Tool to Use

For years, organizations have focused on teaching people individual technologies: learn this programming language, learn this database, learn this project management platform, learn this cloud environment.

Those skills still matter. But AI introduces another skill that I think will become increasingly important:

Tool selection.

The most effective AI users may not be the people who know the most prompts or subscribe to the most AI platforms. They may simply be the people who understand their problem well enough to choose the right tool for it.

Sometimes that might mean Claude. Sometimes GitHub Copilot. Sometimes ChatGPT.

And sometimes the best answer might be using all three during different stages of the same project.

Imagine starting with ChatGPT to challenge an idea and develop the requirements. Then moving into Claude to explore the implementation and work through the codebase. Then using GitHub Copilot alongside the development team as the solution is written, tested, reviewed, and maintained.

That isn't three competing AI platforms. That's a toolchain.

AI Doesn't Replace Experience. It Amplifies It.

There is another part of this conversation that I think sometimes gets lost.

AI can generate an impressive amount of information very quickly. But speed isn't the same thing as judgment.

Someone still has to recognize when an answer doesn't make sense. Someone still has to understand the business. Someone still has to recognize technical risk. Someone still has to understand customers, employees, budgets, deadlines, security, and all the other constraints that exist in the real world.

Experience provides that context.

AI can dramatically accelerate what an experienced person is capable of doing, but the person still needs to know where they're going.

A power tool in experienced hands can accomplish remarkable things. The same tool in inexperienced hands can create a remarkable mess.

AI isn't much different.

Stop Looking for the Winner

I don't believe there needs to be a winner between Claude, ChatGPT, GitHub Copilot, or whatever platform comes next.

Competition between these companies will continue, and that's a good thing. It will make the tools better. But as users, we don't have to participate in the rivalry.

We can simply use the best tool available for the job in front of us.

The screwdriver doesn't need to defeat the hammer. The socket wrench doesn't need to replace the drill. They simply need to be there when we need them.

That is how I increasingly think about artificial intelligence.

Build your AI toolbox. Learn what each tool does well. Understand where each one struggles. Experiment with how they work together.

And most importantly, don't become so focused on finding the "best AI" that you miss the larger opportunity.

The advantage isn't necessarily having access to artificial intelligence anymore. More and more people already have that.

The advantage will be knowing which tool to reach for, when to reach for it, and having the experience and judgment to know what to do with the result.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Claude's Computer Control Capabilities: Innovation, Risk, and Lessons from the Past

Anthropic recently introduced capabilities that allow Claude to interact directly with a computer, including opening applications, navigating websites, clicking buttons, entering information, and performing tasks on behalf of a user.

Having worked in technology leadership for more than 25 years, I have learned that every major innovation introduces new opportunities and new risks.

Before anyone accuses me of being opposed to artificial intelligence, let me be clear: I believe AI is transforming the way we work. These tools can improve productivity, reduce repetitive work, assist with troubleshooting, and help people accomplish tasks that once required considerable time and technical expertise.

However, history has also taught us that convenience often comes with a price. Organizations would be wise to understand the security risks before allowing an AI system to interact with their computers, applications, files, and administrative tools.

Haven't We Seen This Before?

For years, IT professionals have relied on Remote Desktop Protocol, better known as RDP, to access and manage computers remotely.

RDP was fast, convenient, and incredibly useful. It allowed employees to work from home, administrators to support servers from another location, and businesses to operate without requiring everyone to be physically present.

Then attackers learned how to exploit it.

Internet-exposed RDP services became a common entry point for ransomware attacks, unauthorized access, credential theft, and data breaches. Organizations spent years learning painful lessons about weak passwords, missing multi-factor authentication, excessive privileges, exposed network ports, and inadequate monitoring.

Today, most experienced IT professionals become immediately concerned when they discover that an RDP service has been directly exposed to the internet.

AI-powered computer control is not exactly the same as traditional RDP. It does not necessarily expose a Windows desktop or network port in the same manner.

However, it raises a similar and important question:

What happens when software can not only access a computer, but also interpret information, make decisions, and perform actions on behalf of the user?

That is where the conversation becomes more complicated.

The New Risk: Prompt Injection

Traditional software generally follows instructions written by its developers.

AI agents operate differently. They are designed to interpret natural language, review information, make decisions, and determine which actions should be taken next.

That flexibility is what makes them useful.

It is also what creates a new category of security risk.

Security researchers call one of these risks prompt injection.

Imagine an AI agent is asked to review a website, read an email, open a document, or analyze a PDF. Somewhere within that content, an attacker has inserted instructions intended specifically for the AI system.

Those instructions might tell the agent to ignore the user's original request, reveal sensitive information, open another website, download a file, modify a document, or perform some other unauthorized action.

The instructions may be visible, or they may be disguised within content that appears harmless to the person using the computer.

This creates a difficult problem. The AI must determine which information is legitimate content and which information is an attempt to manipulate its behavior.

Humans already struggle with phishing emails and social engineering attacks. AI agents may now face their own version of the same problem.

The concern is not simply that Claude, or any particular AI platform, is inherently insecure.

The greater concern is that AI agents introduce a new attack surface that businesses and security professionals are still learning how to manage.

Why Computer Control Changes the Risk

A chatbot that only answers questions has limited ability to cause direct harm.

An AI agent that can control a computer is different.

Depending on the permissions it has been given, an agent may be able to:

• Open applications
• Read documents and email
• Access cloud storage accounts
• Navigate internal business systems
• Enter or modify information
• Download and upload files
• Run scripts or terminal commands
• Interact with administrative tools
• Access remote management software
• Make changes using the user's credentials

The more access the agent receives, the greater the potential impact of a mistake, compromised account, malicious instruction, or successful prompt injection attack.

An AI system operating under an administrator's account could potentially have the same access as the administrator.

That is an enormous amount of trust to place in any tool.

The Lessons We Should Already Know

The technology industry has faced this problem before.

Remote monitoring and management platforms, remote access tools, service accounts, domain administrator credentials, and automation systems all provide tremendous value.

They also become extremely attractive targets because they have access to many systems at once.

History has repeatedly shown us that attackers often target the tools trusted to manage everything else.

We have seen serious security incidents involving remote access services, software management platforms, privileged accounts, and administrative utilities. In many cases, the problem was not that the tool had no legitimate purpose.

The problem was that it had broad access, insufficient restrictions, weak authentication, or inadequate monitoring.

The lesson is simple:

The more access a tool has, the more valuable it becomes to an attacker.

An AI agent with access to email, files, browsers, cloud platforms, source code repositories, or administrative systems should therefore be treated as a privileged technology platform, not merely as a convenient assistant.

Account Compromise Is Another Concern

Prompt injection is not the only risk.

Organizations must also consider what could happen if the user's AI account is compromised.

If an attacker obtains access to an account connected to a computer control session, the attacker may be able to misuse the permissions previously granted to the AI platform.

This is especially concerning when users reuse passwords, fail to enable multi-factor authentication, remain signed in on shared devices, or grant broad access without reviewing it later.

The risk becomes even greater when an AI account is connected to other services, including:

• Microsoft 365
• Google Workspace
• GitHub
• Cloud infrastructure
• Customer management systems
• Financial platforms
• Internal applications
• Corporate file shares
• Remote support tools

A compromised account may no longer provide access to just one service. It could become a gateway to several connected systems.

Human Approval Helps, but It Is Not Perfect

AI companies are introducing safeguards intended to reduce these risks.

Depending on the product and configuration, the system may require the user to approve sensitive actions, such as submitting a form, downloading a file, running a command, or accessing certain information.

These approval steps are important.

However, approval prompts only work when users understand what they are approving.

People are already accustomed to clicking "Allow," "Accept," "Continue," and "OK" without carefully reviewing the request. Over time, frequent approval prompts can become background noise.

An AI agent may ask permission to perform an action, but the user may not fully understand why the action is being requested or what the consequences could be.

Human approval should therefore be viewed as one layer of protection, not a complete security solution.

Does This Mean We Should Avoid AI Agents?

No.

AI agents have tremendous potential.

They may eventually help organizations perform routine troubleshooting, generate documentation, monitor systems, prepare reports, test software, manage repetitive processes, and reduce the burden placed on technical teams.

They may also make advanced technology more accessible to people who do not have traditional technical training.

The answer is not to reject innovation.

The answer is to introduce it carefully.

Businesses should avoid treating AI computer control as an ordinary consumer feature. It should be evaluated using the same security discipline applied to remote access tools, privileged accounts, automation platforms, and administrative software.

Practical Security Recommendations

Organizations considering AI-powered computer control should begin with several basic safeguards.

Require multi-factor authentication. Every account capable of controlling a computer or accessing connected business systems should require strong multi-factor authentication. A password alone should not be considered sufficient.

Follow the principle of least privilege. The AI agent should only receive the access necessary to complete the assigned task. It should not operate under a domain administrator, global administrator, root, or similarly privileged account unless there is a compelling and carefully controlled reason.

Separate everyday and administrative accounts. Users should not perform routine browsing, email, and document work while signed in with administrative credentials. The same separation should apply when using AI agents.

Require approval for sensitive actions. Actions involving software installation, command execution, credential access, financial transactions, security changes, file deletion, or external communication should require explicit human approval.

Restrict access to critical systems. AI agents should not automatically receive access to every server, client environment, cloud tenant, file share, or administrative console available to the user. Access should be limited by role and business need.

Maintain logs and review activity. Organizations should be able to determine what the agent accessed, what actions it attempted, what the user approved, and what changes were made. Logging is essential for accountability and incident investigation.

Review connected applications regularly. Permissions granted to AI platforms should be reviewed periodically. Connections that are no longer necessary should be removed.

Use isolated environments when possible. High risk or experimental tasks should be performed in a sandbox, virtual machine, test environment, or otherwise isolated system rather than on a primary workstation containing sensitive business information.

Train users to recognize AI-specific threats. Employees should understand that malicious instructions can appear inside websites, emails, documents, support tickets, source code, and other content reviewed by an AI agent. Users should be taught to question unexpected actions and unusual approval requests.

A Balanced Path Forward

Claude's computer control capabilities are impressive and may represent an important step forward in workplace productivity.

They may also change the way people interact with computers. Instead of manually opening applications, finding information, and completing each step, users may increasingly describe the desired outcome and allow an AI agent to perform the work.

That is a major shift.

It deserves serious consideration, not panic and not blind enthusiasm.

The security industry has repeatedly learned that powerful administrative capabilities must be introduced with strong authentication, limited permissions, effective monitoring, and clear accountability.

AI agents should be held to the same standard.

Organizations should begin cautiously, limit early use cases, monitor activity closely, and expand access only after they understand how the technology behaves within their environment.

Final Thoughts

Innovation has always required a degree of trust.

However, trust should never mean giving a new technology unrestricted access and simply hoping for the best.

The real question is not whether AI agents will become part of the modern workplace. They almost certainly will.

The more important question is whether organizations will apply the lessons learned from decades of remote access, privileged administration, automation, and cybersecurity, or whether those lessons will have to be learned again.

AI-powered computer control offers remarkable possibilities.

It also places more responsibility on technology leaders, security professionals, vendors, and users to understand what access is being granted and how that access could be misused.

Innovation is exciting. Security is what allows us to keep using it.

Thanks,

Michael Cronin

Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/