I’m not the only one struggling to explain to people why letting an “artificial intelligence” like ChatGPT write your software is not such a good idea. Alberta of the Albert Tech channel on YouTube has tried before and not quite gotten there yet. But now she’s got a better idea, and the inspiration came from Spotify.
Last month, Spotify co-CEO Gustav Söderström claimed that the best developers at his company “have not written a single line of code since December.” I’m also not the only one struggling to explain why “coding” is a very misleading term for software development, but that’s a smaller group than the group of people warning about the perils of letting A.I. do software development.
Söderström’s statement led Alberta to imagine: What would happen if a manager at some company banned software developers from using their keyboards, requiring them to develop all the software by prompting an A.I.? Hilarity ensues for the fictional company Alberta works at, but it’s no laughing matter in real life.
The skit hits on the main problem with A.I. When an A.I. produces an order page for a product, it’s not grounded on the lived experience of being a buyer wanting a low price for a product nor the lived experience of being a seller wanting a high price for your product. It’s the result of plagiarism filtered through a pseudorandom number generator.
There are legitimate reasons to include a drop-down menu in an order page. For example, if the water machine company offers three different models, the order page might have a drop-down menu with those three models. The three models might be priced differently, but the price would depend on which model the prospective buyer chooses.
<select name="model" id="water-machine">
<option value="hot-cold">Hot / Cold</option>
<option value="hot-cold-sparkling">Hot / Cold / Sparkling</option>
<option value="sparkling">Sparkling</option>
</select>
That’s not “coding.” That’s just marking up text. You can try it yourself on W3Schools. And somehow professional Web developers were able to do that before A.I. came along. To make the price change according to the model chosen would probably involve some JavaScript, which is a little more involved, but also something professional Web developers were able to do without help from A.I.
While I doubt a typical business would wind up using an A.I. created by a direct competitor as in the skit, one still has to wonder whether the healthy self-interest of the A.I. supplier aligns with the healthy self-interest of the end user.
It stands to reason that companies in real life will follow Spotify’s example. Maybe not by banning keyboards outright. Though I can imagine how some real life bosses might think that’s what they should do, on account of how some of the articles about this have been written. “The company's best developers stopped touching keyboards in December,” reads a subheading in the article about this at Techloy.
Sarah Perez’s article for TechCrunch doesn’t mention keyboards at all, but does give some idea of the software Spotify is using.
Spotify pointed out it shipped more than 50 new features and changes to its streaming app throughout 2025. And, most recently, it has rolled out more features, like AI-powered Prompted Playlists, Page Match for audiobooks, and About This Song, which all launched within the past few weeks.
At Spotify, engineers are using an internal system called “Honk” to speed up coding and product velocity, the company told analysts on the call. This system allows for things like remote, real-time code deployment using generative AI, and specifically Claude Code.
“As a concrete example, an engineer at Spotify on their morning commute from Slack on their cell phone can tell Claude to fix a bug or add a new feature to the iOS app,” Söderström said. “And once Claude finishes that work, the engineer then gets a new version of the app, pushed to them on Slack on their phone, so that he can then merge it to production, all before they even arrive at the office.”
Spotify credited the system in helping to speed up coding and deployment “tremendously.”
“Deployment” means that the software is getting put to use by the intended end users, such as Spotify’s paying customers (subscribers to Spotify Basic or Spotify Premium).
“Coding” here refers to the development of that software. But Spotify’s software developers haven’t been doing actual coding from long before they started using A.I.
What software developers at Spotify were doing was writing programs in programming languages like C++, Java, Python and Scala, then using the appropriate compilers for those programming languages to convert the program source into actual machine-executable code.
Actual machine-executable code can look like this:
%&/*??',( )*+,&/*??'8( )*!&?&*?*?+? J*?*?,? 9)??'QRS(4&)*&-&./0102 -.34&Y*?*+?*,??'^_ `a( )*67 *+?,???'(7A8&7 )*2 -.349:;<
I did not write that, I had a Java compiler write that for me. Theoretically, I could have written it myself, but it would have taken me a very long time.
Technically, the excerpt above is for the Java Virtual Machine (JVM), which converts the Java bytecode to machine-executable code for a specific physical chip, like the Apple M2 Pro or the Intel Core Ultra 9 Processor 285K. But if I showed you code for those chips, it would look just as much like gibberish as the Java bytecode.
Spotify’s software developers haven’t been writing executable code either, not even before A.I. came along. Some of them had been writing programs in Scala, which is a programming language primarily for the JVM (Scala was a major inspiration for Kotlin, the primary programming language for Android app development).
Back in 2023, Johanna Reichen wrote about Spotify’s commitment to Scala in the Scala blog.
Since 2018, Spotify has demonstrated its commitment to the Scala ecosystem by serving on the Scala Center’s Advisory Board, initially with one representative. This representation was expanded to two members (with 1 vote) in 2020, reflecting Spotify’s growing involvement and influence within the community.
In the digital entertainment landscape, Spotify is also a leading example of leveraging the Scala ecosystem. Central to Spotify’s unique user experience are their sophisticated, data-processing algorithms, which are developed in Scala. Many developers at Spotify, with their deep expertise in Scala, have significantly contributed to this endeavor, shaping the personalized and enhanced user experience that the company prides itself on.
As an organization, Spotify’s dedication to open source has been clear since its inception, fostered by an engineering team passionate about leveraging and contributing to the open source community. Over time, this has evolved into an integrated system with established policies and legal frameworks. Today, Spotify is not just a consumer of open source but an active contributor, boasting about 150 published projects.
Scio seems to be Spotify’s best known Scala open source project. Here’s an excerpt from Spotify’s GitHub:
final case class Metrics(
version: String,
scalaVersion: String,
appName: String,
state: String,
beamMetrics: BeamMetrics
)
final case class BeamMetrics(
counters: Iterable[BeamMetric[Long]],
distributions: Iterable[BeamMetric[BeamDistribution]],
gauges: Iterable[BeamMetric[BeamGauge]]
)
I’m sure some of you are going to joke that that looks just as much as gibberish as the Java bytecode. And I admit I don’t exactly know what this does. But you have to admit that almost every word of that is an English word that you can find in an abridged English dictionary.
And if you’ve studied a JVM programming language like Java, you can also pick out Scala’s reserved words: “final”, “case” and “class”, and partial credit for “String”. A reserved word has special meaning for the compiler, and associated rules for its use that you have to abide by if you want the compiler to convert your source to executable code.
In the executable code excerpt above, can you pick out the opcodes? The exclamation mark could be the JVM opcode with opcode mnemonic “baload”, which loads a byte or a Boolean from an array. But it could just as easily be a parameter for an opcode. I really don’t know if I copied and pasted starting at an instruction boundary. And this time I did not bother to substitute the “non-printing” characters with “control pictures.”
So you can make some sense of the Scala source. Making sense of the actual code is considerably more difficult, even if you have the complete code. Reverse engineering software is very difficult.
I happened to notice a Scala “@inline” annotation in the Spotify Scio source. It reminded me of the “@switch” annotation. I’m not going to go in depth about either of those here, the curious can look those up in the official Scala documentation. Here suffice it to say that those annotations are directives to the compiler.
Or I should say suggestions, since the Scala compiler may choose to disregard those annotations. But the Scala compiler won’t toss a coin to decide whether or not to honor those annotations, but instead it makes the decision according to well-documented rules.
I listened to Spotify Free as I proofread this article prior to publication. Maybe I should have chosen music I’ve heard before, but instead I went with Philip Glass’s Symphony No. 8. After the first movement, Spotify made me listen to three ads: Kardia Mobile, Legacy Box and LinkedIn. And after the symphony’s finale, it served up ads for The David Pakman Show on Spotify, Hillbilly Queer: A Memoir by J. R. Jamison and Easy Money by Ben McKenzie.
You know what? I am a paying customer. Time is money. And if the A.I. ever screws up the Spotify experience for any of the customers, hopefully the CEOs will pay attention.
