4 min read AI Process Improvement

Are many AI workflows allowing poor develment techniques?

Tools like Zapier, N8N, Make, and other no-code automators are brilliant. They enable rapid prototyping, empower teams to solve problems in the moment, and allow us to test new ideas with incredible speed. I use them for Proofs of Concept myself and am as enthusiastic as everyone else in what we can quickly achieve.

There is a (not new) dangerous assumption taking hold in many organisations: that these tools and workflows are a substitute for genuine process re-engineering.

We are building increasingly critical operations on what amounts to digital duct tape.

We all get excited at what these tools and workflows can do:

  • A sales lead from a webform automatically creates a CRM record and a Slack alert. The LLM element then scrapes publically available info about that lead and appends it to the CRM record.

  • A finance team’s workflow ‘watches’ an inbox for PDF invoices, uses an AI tool to parse them, and pushes the data to an accounting system.

  • A marketing team’s process to auto-publish social media content from a shared spreadsheet.

These automations feel like progress. And while effective in the short term, this reliance on digital duct tape creates significant risks:

  • The sales lead webform is renamed during a website update: new leads are silently lost in the void. Or worse: the lead misspells their own company name and your CRM is now hopelessly incorrect.

  • When a supplier changes their own accounting system (and therefore invoice format), payments are delayed for weeks because our workflow can’t parse the

  • And when a column is accidentally deleted from the marketing spreadsheet, the wrong content is sent to thousands of followers.

There are some fundamental flaws in using these tools without proper thought and skilled developer design:

  • They’re fragile: Exposed to the slightest change in any connected system: a renamed field, a new value, a changed IP address, causing the entire process to fail silently.

  • They’re chaotic: They exist outside of proper governance. They are undocumented, uncontrolled (or worse: tied to a specific employee’s email address), and often have no error handling, leading to hidden costs, delays, and critical mistakes.

The technical debt here is significant, and the real danger is far greater.

This isn’t to say we should abandon these tools. And we can mitigate the risks by applying good (and perhaps less glamorous) development principles:

  • Establish proper governance. Every automated workflow must have a clear owner responsible for its monitoring, maintenance, and eventual decommissioning.

  • Build in robust logging, error checking, and alerting. If something stops working, the right people must be informed immediately with details of what went wrong, ensuring no data is lost.

  • Use separate development and production environments. A workflow should never be built or modified ‘live’. Test every change in a safe staging area to catch issues before they impact the business.

  • Implement version control and documentation. Every change should be tracked and reversible, preventing the ‘who changed what?’ mystery when things break.

  • Ensure you’re using the right tool for the job. Most enterprise software has (or is rolling out) workflow capabilities. While likely harder to develop with, they will be more robust and integrated than external tools.

The other critical question we need to consider with these workflow tools is:

Are our outputs becoming irrelevant?

Do we risk becoming world-class experts at optimising workflows for outputs that are rapidly becoming irrelevant.

Think about it: Is your team using a fragile AI workflow to perfect the creation of SEO-optimised articles? This is an amazing optimisation of a 2023 process. And in a world where large language models are changing search forever, is that output even the right thing to be creating in 2026?

As leaders, our responsibility is to move beyond tactical tweaks and re-imagine the work itself. This requires asking fundamentally different questions.

Instead of asking: “How can we optimise this process with AI?”

We must ask: “What would this process look like if AI did 80% of the work?”

Instead of asking: “How can AI help deliver this output for my stakeholder?”

We must ask: “In a world of AI, is this output still relevant to my stakeholder?”

I’ve since explored this thinking further in a hierarchy for deciding what to automate — before building the AI tool, ask whether the problem should exist at all.

When we use powerful AI simply to patch a broken or outdated process, we turn a strategic asset into a long-term liability. True digital transformation doesn’t come from optimising the old; it comes from having the courage to ask if the old is still needed at all.

What are your thoughts?