Silicon Valley Gets High On Its Own Supply – Monkeynoodle.Org

Skip to content

Uncategorized

Silicon Valley Gets High On Its Own Supply

Published by

Jack Coates

on

June 27, 2026

this is your brain on drugs 1989 newspaper ad<br>" data-image-caption="this is your brain on drugs 1989 newspaper ad<br>" data-large-file="https://monkeynoodle.org/wp-content/uploads/2026/06/1989-11-26-ad-this-is-your-brain-this-is-your-brain-on-drugs2-wm-1030x779-1.jpg?w=1024" />

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...