Picture a typical Monday morning catchup with Slack. “Great news,” says Bob, “I was experimenting this weekend and AI can automatically extract, maintain, and translate strings! Now we can finally do that localization project we’ve been ignoring for years!” Leadership chimes in with “LFG!” A few hours later, the rest of the problem has surfaced. Strings are different lengths and won’t fit in the allocated space. Control placements assume left-to-right instead of right-to-left. We don’t have palette control and some color schemes are culturally inappropriate, never mind that colorblindness is a thing. We’d still be relying on field engineers and customers to validate translations. Bob’s great and all, but he isn’t going to solve all those things, he’s busy with higher priority projects and was just having fun. But in a few weeks a deal will be hung up on lack of Japanese support and leadership will say “what, wasn’t that solved?”
I like to think of this pattern as Silicon Valley getting what it gives. We’ve Silicon Valley’d ourselves. “Here’s a speedy solution for the easiest 20% of the problem, we’re going to sell it as a solution to 100% of the problem of course, some assembly required lol.” Extracting and translating strings seems like the hard part, because it’s the part that lots of people know they can’t do. Only a few people can read the source code and find the strings to translate, and even fewer can safely make changes. Only a few people know what the software does well enough to describe it in two or more human languages. Only a few people have the patience to manage reflowing user interfaces to support English, Arabic, or Korean as needed. It’s exceedingly rare for a single person to be able to do all three parts and available on short notice for each release’s change window, which is why enterprise software translation service providers exist. It’s a significant boost if an AI tool can extract XLAT files from source code and translate them, just like Unicode was a significant boost over code pages, but it’s not a complete systemic solution to localization.
Writing code is being accelerated by AI. The rest of the system is not. What’s the rest of the system you ask? It’s the interfaces between the software and reality. Lorin Hochstein and Avery Pennerun are very succinct on the underlying issue: software is part of a system that is under massive pressure to be effective, safe, and efficient. A modern SaaS company doesn’t just make software. Open source had already driven baseline costs to a very low point, and venture-subsidized AI providers are a sharp and (temporary? permanent?) inflection to the software cost reduction trend. So what do these billion-dollar companies sell? They sell services that happen to be built on software because that’s currently more efficient than services built on butts in seats. That service and software combo is a system, a sociotechnical system if we want to crack out the ten dollar words. It has to interface with the customer’s people, systems, and other services to do anything useful, and each of those interactions is an opportunity to succeed or fail. The actual delivery of value from the vendor to the customer is a combination of people’s activities and processes with a surprisingly small amount of software. Tech is a people business.
Making software is an important part of that people business, so vendors have processes focused on making software. Efficiency of a process is only one part of an overall system that uses several processes to produce an outcome. Say that you put a massive engine into a tiny car, the car might be fun but it’s far from safe. The car needs a system for going fast, sure, but it’s also got systems for turning and stopping, and those systems are now getting doubled input from the go-fast part. As in cars, so in software. Now maybe we’ll revise the whole system, or maybe we’ll just fumble around blaming each other and disrupting some shit, but those activities are always occurring within the Rasmussen model of work space. Increasing efficiency comes from decreasing safety which eventually produces increasing cost. The vendors behind these software bubbles offer hopium of decreased cost and increased efficiency, while their internal operations grow ever more expensive and less efficient.
The biggest open question is effectiveness: can the new tooling make a solution that is more effective than the old way of doing things? The answer can be yes, particularly when the task is one of intellectual drudgery. Context collection and maintenance for instance: most people don’t like doing it, and maintaining cross-team access to the data is a political minefield to continually renegotiate. Giving the computer access to discover and maintain context across Salesforce, Jira, and Notion is a potential game-changer to classic SIEM and O11y problems. In fact, if one looks back over recent decades of enterprise software solutions from SAP, CA, IBM, HP, Microsoft, BMC, and more, the promises of efficient automation and increased output aren’t exactly new. Why haven’t they delivered? Maintaining context is hard. As one CIO told me long ago when describing a systems automation project, “I spent three million dollars with that vendor to get everything working, and I’ve since spent a million dollars a year keeping it working.” That cost was going into data normalization, data movement, data storage, data access, rules maintenance, and process updates. Some software problems, and lots of people problems.
And what about safety? What’s sought here is a pool of tasks that don’t require human authorization to complete automatically but haven’t been automated via cheaper methods because of the lack of contextual information. After all, “if this then that” business scripting isn’t a new invention, though it may be unmaintained and thereby a target for an AI-powered solution. Look at how many times over the last twenty years problems like “sync my travel into my calendar” have been tackled, and yet that task still requires manual intervention today. There’s inherently not a lot of money in these high-safety, low-value tasks, so they don’t attract recurring investment for maintenance. So a vendor sales team is going to gravitate to problems that are worth money… and have lower amounts of safety. You can save thousands of dollars per month by automatically decommissioning customer environments after contract lapse, which is also a great way to lose millions per year during difficult negotiations. See also, “we’ll just automatically roll back the PR that caused the outage!”, “block the IP the attacker is coming from!”, and “let’s quarantine the [service|laptop|user] with the detected security issue”.
A crucial thing to remember about tasks becoming easier to complete through technology is that the ease is delivered equally to all at the same time. Said differently, if the value is in a software technology, then everyone will use it via open source or reverse engineering. If the value is in a centralized hardware investment, that vendor is equally willing to sell the ability you’re buying to your competitors and customers. All the parts that are easier for you now are also easier for them, and therefore valueless, if not now then soon. The arbitrage you’re hoping for is only present if the customer is unable to write the same prompt for some reason. A much more reliable source of arbitrage is solving hard problems, such as the maintenance of context in a sociotechnical system. Gathering system-impacting context from dozens of business relevant systems, making sense of it, and serving as a blame sink if that process goes wrong is worth lots of money, according to my CIO friend a couple of paragraphs back. Offering a truly localized package is worth more than a poorly-done attempt. AI software development can certainly be part of a salable solution, just as open source software is, but the valuable, complete solution is a lot more than rapidly delivery of the easy parts.
Monkeynoodle.Org 