What a STEAM Curriculum Gets Wrong About Full-Stack Software Engineering

The message came in at 11:40 on a Tuesday. A friend building a roguelike by himself — netcode, shaders, the signing pipeline that pushes the Steam build — had four days of runway and no music. That same month he had written a deterministic physics solver from scratch. What he could not do was tell me whether the eight-bar loop he had generated sat in a key that would fight the UI blips already sitting in the project.

He apologized for asking. That's the part that stayed with me.

This is the shape of full-stack software engineering now. The stack kept growing sideways until it stopped being a stack: backend, frontend, infra, some data work, some model-serving, the privacy policy, the invoice nobody has paid — and then, because the build ships with sound, a strand of the arts that nobody assigned you.

Which is roughly where the STEAM curriculum walks in, twenty years late, holding a clipboard.

What a STEAM curriculum actually is

STEAM is science, technology, engineering, arts, and mathematics taught as one connected subject instead of five separate rooms. The A carries the whole argument. Folding art and design into a STEM program is supposed to change how the other four are learned — the claim being that someone who has built a thing under an aesthetic constraint, where correct isn't a passing test but a judgment call, comes back to the engineering differently. It grew out of arts-education advocacy in the 2000s and hardened into policy across a lot of school districts.

That's the classroom version. The version I care about is what happens to a thirty-four-year-old who owns a production database and now owes somebody twenty seconds of music by Friday: what does the arts strand cost, and what does it actually buy?

There are three honest answers on the table, and they lead to different Tuesdays.

The three curricula

Breadth-first — the STEAM version. You learn the neighboring domains ahead of need, as a system. Some theory, some color, some composition, some typography. Nobody assigns it. You assign it to yourself, usually at night, usually instead of sleeping.

Depth-plus-purchase — the T-shape. One deep spike, distributed systems or compilers or whatever your spike is, and everything else gets bought, delegated, or licensed. You don't learn audio. You hire audio, or you buy the pack and hope the terms hold.

Demand-driven — the build-shaped version. You learn what the sprint requires at the moment it requires it, ship, and let the knowledge decay. Most solo builders live here whether they chose it or not.

Four criteria, applied honestly

Cost per week. Breadth-first is the expensive one and it stays expensive. Nobody who has actually tried to hold five domains open at once describes it as balanced. It's a standing tax paid in evenings, and the bill arrives whether or not the quarter went well.

Shelf life. This is where the ranking flips. Tool knowledge depreciates — the interface you memorized this year gets redesigned, the model you tuned your prompts against gets retired, and the hours are gone with it. Knowing that a minor key reads as unresolved, that a loop wants its transition on a bar line, that low-end mud is usually two instruments occupying the same 80–200 Hz — none of that expires. It was true on a four-track and it's true in a browser.

Transfer. Thin ice, and I'd rather say so than sell it. The idea that studying one domain makes you better at an unrelated one is the oldest promise in education and the least reliably demonstrated. I've watched it work in my own studio and I still don't trust my own account of it.

Thursday at 11pm. This is where it actually gets decided, and demand-driven wins outright. It ships. It also produces the exact message my friend sent me — the one where you have a file and no basis for judging it.

What quietly decides it

Run those four criteria out and the winner isn't a curriculum. It's a split.

Demand-driven gets the file made. It should — a deadline is not a seminar. But the thing that made my friend send that message at midnight wasn't a missing skill. He had the loop. He couldn't evaluate it. He had no vocabulary for the difference between a track that was wrong and a track that was merely unfamiliar to him, so he did what any careful engineer does with an unverifiable output: he stopped and asked someone.

That's the real return on the arts strand, and it's narrower than STEAM's advocates tend to claim. Breadth-first does not make you a composer. Two years of evenings won't. What it buys is the ability to hear that a render is mushy and say why — the pad is swallowing the kick, the loop point clicks, the vocal is smeared in a way no amount of regeneration will resolve. In a workflow where you can generate forty candidates before lunch, the bottleneck was never production. It's judgment. Generation is cheap now; taste never got cheaper.

So: learn on demand, and spend the standing tax on ears rather than on hands.

Twenty seconds of loop, and the forty minutes it costs

For the engineer with four days and no music, in order:

1. Fix the tempo before you prompt anything. At 96 BPM in 4/4 a bar is 2.5 seconds, so eight bars is exactly 20 seconds. Pick a BPM whose bar math lands on whole seconds and your fades, stingers, and level-transition timings stop fighting you. You'll know it worked when the loop length is a round number instead of 21.33 seconds.
2. Name the key, and match it to sound you already have. If your UI blips were recorded around C and G, ask for A minor and they'll sit inside the harmony instead of next to it. When it worked, the menu click stops sounding like an accident.
3. Write the prompt with the reasoning attached. Here's the one I sent back:

Slow-burn synthwave loop, 96 BPM, A minor, detuned analog bass,
brushed hi-hats only, no drums until bar 5, tape hiss, no vocals,
seamless loop, instrumental

Every clause is doing work. The BPM and key are for step 1 and 2. "No drums until bar 5" gives you a quiet half you can use as the exploration layer. "No vocals" is there because vocal renders are still the mushiest output most tools produce, and the most tangled to clear.

4. Ask for stems and the highest-resolution file the tool will give you. Separate stems mean you can duck the pad under dialogue later instead of regenerating the whole cue. (It's the first thing we check when we compare tools here, and it's worth checking whoever you use.) It worked if you can mute the bass and still have a usable bed.
5. Read the license before the render, not after. Terms differ by tool and by tier, and they get revised — commercial use, monetized video, resale, and "you may need to keep proof of generation" are all separate questions. Save the terms you agreed to, with the date. I can describe the shape of these agreements; I can't promise you what yours says.

Forty minutes, and the deadline stops being a character question.

The part I can't close

What I can't tell you is whether the breadth is doing the work. Researchers have spent decades trying to show that training in one domain lifts performance in an unrelated one, and the effect keeps shrinking as the studies get more careful. Maybe the engineers who chase five domains were already the kind of people who'd hear the pad swallowing the kick.

So I'll leave it where the evidence leaves it: does learning to hear actually transfer into how you build — or do we just call it transfer, years later, because it's a kinder story than admitting we were never going to sit still?