logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·31.10.26
← Back to news

AI, Tools and Transformation

Original article
ben-evans.com|133 points|60 comments|by firexcy|Sep 6, 2026

AI, Tools, and Transformation

The modern American corporation is essentially a digital archipelago. A typical large firm manages a sprawling ecosystem of software, ranging from:

  • Horizontal "Big Iron" Systems: Massive records-of-truth like SAP or Workday.
  • Vertical SaaS: Hundreds of specialized applications tailored to specific niches.
  • The "Shadow" Layer: A chaotic web of custom scripts, automated workflows, and the ubiquitous 10MB spreadsheet that somehow keeps an entire department afloat.

Often, leadership lacks a comprehensive map of this landscape—they don't truly know what is installed, what is actually providing value, or where the budget is leaking. Despite this abundance of tools, the workday remains plagued by monotonous boring, repetitive drudgery.


The Allure of the AI Shortcut

There is a classic trope in engineering:

"An engineer is someone who will spend an hour automating a task that would have taken ten minutes to do manually."

AI fundamentally alters this equation. Now, the "tool" can be constructed in five minutes. More importantly, the creator doesn't need to be a coder or a technical architect. You can simply prompt a model to build the utility for you—or, even more radically, have the AI perform the task directly.

We are moving toward a world where software is:

  1. Dynamic
  2. Generative
  3. Spontaneous
  4. Free-form

In theory, we can achieve Automation↑\text{Automation} \uparrowAutomation↑ while simultaneously achieving Software Volume↓\text{Software Volume} \downarrowSoftware Volume↓.

The "Silicon Valley Bubble" Fallacy

For those of us who build tools, this prospect is intoxicating. However, this optimism often ignores the reality of how people actually work and how organizations evolve.

The core issue is that most people are not tool-builders. They don't instinctively look at a tedious process and think, "How can I re-engineer this workflow?"

ProfessionPrimary FocusNot Focused On...
Matrimonial LawyerCase strategy & client needsLegal discovery software architecture
Enterprise SalespersonProduct fit & competitor intelSales enablement productivity tools

While platforms like Excel attempt to bridge this gap via templates (the File →\rightarrow→ New menu), these are merely suggestions. Even "Claude for X" implementations are helpful increments, but they aren't a systemic cure.

The Role of the "Forward-Deployed Engineer"

Because the people performing the tasks often don't see the opportunity for automation, we see the rise of the "forward-deployed engineer." This is a builder who can walk into a law firm or an architecture studio and spot the "low-hanging fruit" that the practitioners overlook.

The Forward-Deployed Checklist:

  • Identify repetitive manual data entry.
  • Spot "spreadsheet-as-a-database" bottlenecks.
  • Map the gap between current effort and AI capability.
  • Prototype a solution in real-time.

The Hard Truth About Innovation

Making code easier to write does not make problem-solving easier. Many of the most successful software breakthroughs weren't obvious solutions to obvious problems. Often, the problem itself was hidden, bundled, or entirely undefined until someone redefined the category.

def solve_problem(problem):
    if problem.is_obvious():
        return create_tool(problem)
    else:
        # This is the hard part AI can't do alone
        problem = redefine_and_unbundle(problem)
        return iterate_until_success(problem)

The difficulty isn't the construction of the tool; it's the conceptualization of what the tool should actually do. Furthermore, implementing a solution in a corporate environment isn't a technical hurdle—it's a political and regulatory one. A change in "accounts payable" might involve:

  • 500 employees.
  • 5 different departments.
  • 3 legacy systems.
  • 4 different regulatory frameworks.

This requires a formal purchase decision and an 18-month sales cycle, not just a clever prompt.

The Spectrum of Software: Institutional vs. Improvised

Software exists on a continuum from top-down mandates to bottom-up hacks.

1. Institutionalized Software: These are the dedicated tools where the "correct" way to perform a task has been codified. Consistency is the priority.

2. Improvised Software: This is the "fuzzy" space. When a task is too unique for SAP, users turn to freeform substrates:

  • CSV files
  • Screenshots
  • Conference calls
  • Shared folders

The lifecycle of a business process usually follows this path: it starts as an improvisation to handle an exception; if that exception becomes a frequent, high-stakes occurrence, the company eventually institutionalizes it into a formal system. The tragedy is that many companies never realize they have a path to institutionalize until the improvisation has already become a chaotic liability.