1. Context

CS1101S is an introductory computer science course that teaches core programming concepts using Source, a JavaScript-like language. Along the way, the course runs a few optional creative contests that let students apply these ideas outside of standard problem sets.

Past contests include Beautiful Runes (visual art with Source runes) and The Choreographer (programmatically generated curves). I was especially drawn to Game of Tones, the sound contest, because it felt the most programmable - instead of hand-tuning visuals, it’s about generating music through code, which made it a perfect candidate for automation.

2. Finding the right song

Constraints

Sounds simple enough, right? Not really. There were some surprisingly tight constraints I had to consider when choosing the song:

• MIDI availability (non-negotiable)
  • This is an obvious requirement, and also the biggest bottleneck of all
  • Automating music without a MIDI file is extremely difficult (I tried)
• Complexity
  • Multiple layers, non-trivial melody
  • Interesting enough that hand-coding would be tedious
• Source-friendly
  • Simple instrumentation
  • Minimal timbre, effects, or texture
  • Sounds that can realistically be approximated from scratch in Source

(Source’s sound module is fairly minimal. There are only a few built-in waveforms, and there’s no large library of presets like you’d find in a DAW. Anything that relies on rich instruments, effects, or sound design becomes very hard to reproduce in Source.)

• Performance constraints
  • Reasonable note count
  • Should not lag or freeze the runtime

(For the contest, other students vote by actually running your code on their own machines. That means performance directly affects first impressions — long wait times would almost certainly hurt votes. For context, I’ve seen submissions with 2-3 minute wait times.)

Searching for songs

I tried several directions initially, but most failed:

• Game soundtracks
  • Often Source-friendly in terms of complexity
  • Public MIDIs are rare or nonexistent
• Rhythm game songs
  • Fanmade MIDIs are often available (shoutout to @Uaaaaak!)
  • Extremely dense and layered, which makes it really difficult to replicate and optimize in Source
  • Usually include heavy effects and rich instruments

Song: (From maimai) “raputa” sasakure.‌UK × TJ.hangneil

Listening note: Extremely dense layering, rapid note changes, and the use of complex instrumentation make this impractical to reproduce or optimize in Source.

• Mainstream pop / OP-style arrangements
  • MIDIs are not usually available, which already limits candidate songs
  • When MIDIs are available, the arrangements tend to be structurally simple
  • Automation offers little advantage over manual coding

Song: Yorushika - Hitchcock

Listening note: Structurally simple with sparse layering, meaning automation offers little advantage over hand-coding.

After filtering through a lot of mainstream pop candidates, Lagtrain (by inabakumori) stood out as one of the few that actually satisfied all the constraints.

• A usable MIDI was available (Shoutout to Latency!)
• Fairly layered, but simple enough to be implemented in Source
• Manageable note density and acceptable performance

It wasn’t the most complex song structurally, but it crossed the point where automation had a clear advantage.

Song: inabakumori - Lagtrain

Listening note: Just complex enough to benefit from automation, but simple enough in terms density to run smoothly in Source.

In the end, this felt less of a musical problem and more of an engineering and design problem: choosing the right input to match the system you’re building.

3. Technical details

Instrument Selection and Reduction

The original MIDI file contained around 15 instrument tracks. Generating all of them in Source would have been impractical, both in terms of sound quality and performance. Many tracks were either textural, redundant, or too subtle to meaningfully contribute once translated to Source’s limited sound system.

To address this, I filtered the MIDI down to five core instruments, using MidiEditor to listen to and isolate tracks one by one:

• Vocal
• Piano
• Ocarina
• Percussion
• Bass

This preserved the identity of the song while significantly reducing complexity and runtime cost. The result doesn’t need to be perfect, it just needs to be a good balance between expressiveness and practicality.

Mapping Instruments to Source Sounds

Source’s sound module is extremely basic: a handful of waveforms, ADSR envelopes, and simple effects. No presets, no filters, and no built-in tools for tasks beyond layering and envelopes. Every instrument has to be built from scratch.

Most of the sound design process was iterative and empirical. I relied heavily on:

• Tweaking waveforms and ADSR parameters
• Reading Source documentation
• Googling synthesis techniques
• Most importantly: just plain trial and error (listening and tweaking the code over and over - it took a lot of time)

For melodic instruments like vocals, ocarina, and bass, I used simple waveforms (triangle/square) combined with ADSR envelopes:

• Ocarina: triangle + softer ADSR
• Vocal: square + sharper envelope
• Bass: short attack + low sustain

However, percussion required a different approach. Instead of pitched notes, I combined noise, basic oscillators, and aggressive envelopes to approximate drums:

• Kick: sine + phase modulation
• Snare: tone + white noise
• Hi-hats: shaped white noise with different decay times

Fun fact: I found that Source’s built-in cello instrument actually approximated a piano chord better than the piano itself. This led to me using layered cello chords to represent piano chords, which sounds pretty cursed, but it works..

With the instruments in place, the next step was turning the MIDI itself into playable Source code.

From MIDI to Source: a tiny compiler pipeline

The filtered MIDI file contained nearly 1,000 notes combined. It’s clear that manually writing note(...) calls was no longer viable. The MIDI file already had everything I needed — I just need to translate it into something Source could actually understand.

I cut off the song at 49 seconds, which is exactly right after the intro ends and the first verse starts. In theory, I could code it for the entire song, but for performance purposes, I want to keep loading time under 30 seconds.

Here’s a high-level overview of how MIDI files work:

• Things are broken down into ticks, not time
• MIDI notes are spilt across messages. Each message has a type (note_on / note_off), pitch, and the timestamp (in ticks) of that message.
• Each track/instrument has its own independent list of messages

In short, MIDI doesn’t give you notes directly, it gives you events. Which means I had to pair note_on and note_off messages to get actual notes.

Reconstructing notes from events

This is my general idea to turn MIDI events into real notes:

• Convert tick counts into timestamps (in seconds)
• Keep track of “active” notes (notes that have received a note_on but not a note_off yet)
• A note_on starts a note
• A note_off ends it
• The duration of a note is simply the difference between the two timestamps

Implementing in Source

Source offers 2 ways of combining sounds:

• either simultaneously through the simultaneously(list(...)) command
• or iteratively through the consecutively(list(...)) command

The simplest way would be: For every note at timestamp t, prepend t seconds of silence, then play the note, and then finally play everything simultaneously. This works, but has some serious issues:

• Performance drops extremely fast as song size grows. (From a complexity point of view, this behaves like an O(n²) approach as the number of notes grows.)
• Sounds in later sections would get drowned out or noticeably quieter for unclear reasons.

Hence I settled for a more efficient approach:

• For each instrument, all notes are played consecutively, inserting silence only where needed
• Each instrument track is built independently
• All instrument tracks are then combined using simultaneously(...)

Even though this is a lot more complicated to implement, it scaled much better and loaded significantly faster than my previous approach. (From a complexity point of view, this behaves like an O(n) approach.)

Bonus: A short runtime analysis of the two approaches

In the naive approach, every note scheduled at time t is implemented by:

• inserting t seconds of silence
• followed by the actual note
• then playing all notes simultaneously

If the song contains n notes with increasing start times, this means:

• silence is repeated many times
• each additional note adds more silence than the previous one
• total silence duration grows roughly with the sum of all timestamps

In effect, the total work performed grows quadratically with the number of notes.

In contrast, the final approach builds each instrument track once, inserting silence only between consecutive notes. This ensures that total work grows linearly with the number of notes.

4. Results

The full pipeline and generated Source code are available here.

The final output is a Source program that plays the first 49 seconds of Lagtrain, reconstructed entirely from MIDI data.

The generated code loads in around 15 seconds on my machine and plays back smoothly without noticeable lag. While it’s obviously not a perfect recreation, the melody and timing are surprisingly accurate and clearly recognizable.

This entry ended up winning the Game of Tones contest!

I think the result worked really well because MIDI already encodes strong structural timing, which I could map seamlessly into Source’s sound model.

This ended up taking around 2-3 days for me, with most of the time spent on trial and error. Despite that, I still had a lot of fun in the end, and winning the contest was the cherry on top.

5. Closing thoughts

Overall, this project was less about recreating Lagtrain and more about building a small pipeline to translate structured data into a constrained output format. Similar to my previous Bad Apple projects (such as playing it in a terminal), the core challenge was taking an existing data representation and reshaping it so it could survive under very different limitations.

Although the idea sounds simple on the surface, getting it to work smoothly required many careful engineering decisions — from filtering instruments and cutting off the song, to reconstructing notes from events and choosing an efficient playback strategy in Source. Each step involved tradeoffs between accuracy, performance, and practicality.

In the end, it was exactly this process of designing around constraints that made the project fun and rewarding, and turning it into a working, performant result — with a contest win on top — felt especially satisfying.

The problem

One day, I was tasked with building a full stack database management system for my mom’s university, completely on my own. At the time, I was a 12th grader whose entire background was mostly competitive programming, with basically no real world development experience (aside from a few small silly projects and Discord bots).

Early struggles

Fast forward a few days, I tried to learn Vue.js but couldn’t even get a decent layout on the screen. I mean, it’s pretty much expected, after all UI work is not like solving algorithmic problems. Eventually I gave up, grabbed a free template online, and started building on top of it. At least then I had something to work with. Still, progress was slow, and the result doesn’t look very promising.

This was also my first time using AI in a project of this scale. I was not new to the idea of vibe coding (I had used it quite a bit in past AI competitions, it was pretty fire IMO). But this is different. This isn’t code I would write for a few days and forget about. This was a real project with real users and real consequences. Going in, I didn’t even know what best practices for AI coding were supposed to look like.

Discovering Copilot

At first, I treated it the same way I did in competitions: prompt a chatbot, copy the code, and move on. It worked, but felt clunky and limiting. Things changed when I discovered Copilot and agent style workflows (or what people nowadays would call “vibe coding”). Suddenly, one or two sentences could turn into hundreds of lines of code.

That was the moment I truly felt the power everyone was talking about. It was also when I started going a little too deep down the rabbit hole.

2. When vibe coding felt like a superpower

The magic

Ideas that would normally take hours were suddenly taking five minutes. I would type a couple of sentences, and an entire new page would just appear out of nowhere. I did not have to spend hours reading documentation, thinking through layout designs, or debugging random typos just to get something on the screen.

It really felt like Stack Overflow on steroids. Even ideas I struggled to clearly explain somehow came out looking right. The output felt complete, polished, and (at least on the surface) correct. It was kind of insane. A full page of functionality that would normally take forever just to piece together was suddenly there.

The realization

That was when things really clicked for me. I started to understand why people were worried about AI taking over. This was not even like the old prompt and copy workflow I was used to. It genuinely felt like the AI was doing the work for me (at least, that is what I thought).

3. When things start to go wrong

Hallucinations

As I keep going, problems started to surface. Simple prompts kept spitting out massive chunks of code. Entire pages would show up from a short (and vague) description. But that’s exactly the problem. Those pages almost always came with way more than I asked for:

• Extra features
• Abstractions
• Layers of logic I never planned on building

I didn’t specify enough, and the AI happily made those decisions for me.

Loss of understanding

And when the code finally appeared, half the time I didn’t even know what I was looking at. I just trusted what it spat out and moved on. It felt fine initially - I mean, things were still “working”, so why worry? But as the project grew, that shortcut started catching up to me.

Debugging nightmare

Bugs started to show up. Not obvious ones, but the annoying and subtle issues buried somewhere deep inside these giant piles of “clean” code. At that point, typing “fix this” into a prompt isn’t going to cut it. There wasn’t really any other way besides diving into the code myself the old-fashioned way.

Trying to understand what was going on in those files was… not fun. Every bug took tens of minutes just to understand what’s going on, let alone fix. Debugging often felt slower than if I’d just written everything by hand from the start. And even when I did “fix” something, it didn’t feel like real understanding. It felt more like patching holes on a boat that was sinking faster than I could keep up.

Limits of AI

And even not talking about the bugs, I still hit the limits of vibe coding. Bigger features are always a gamble. Lots of times the AI would get stuck in loops, endlessly adding and removing files for no apparent reason. Other times it would partially rewrite or outright corrupt files that were already working.

I can’t count the number of times where I stared at the screen, watching it go back and forth, before sighing and typing git reset --hard HEAD, starting over. It felt even more exhausting than debugging myself (and I have plenty of experience debugging in competitions!)

Wake-up call

That was the wake-up call. If I kept using AI the same way, the project wasn’t going to get easier, it was only going to get harder to manage. I had to rethink how I was using this tool, or consider starting over.

4. Second attempt

New project

After finishing this project, I wasn’t really happy with it. Even though everything worked fine, it didn’t feel like I learnt anything from this project besides patching the monstrosity that I generated over and over. But there is a chance to redeem myself. I took on another full-stack project, with pretty much the same requirements as the first one, but on a much bigger scale:

• More users
• More data
• More features
• Higher expectations

Still solo, no team, no guidance, no code reviews, and no safety net besides Git.

New mindset

However, my mindset had changed. I stopped thinking in terms of “ask it to build this giant thing and pray that it works” and started breaking things down into small, manageable chunks. Not only would the AI be able to easily digest that, but it also is for my own growth and experience (I still want to learn something, after all).

I figured, If I couldn’t even explain a task clearly, do I really expect the AI to handle it properly and reliably?

Planning

This time, I actually planned things before writing code (way more than I did before, it was pretty overwhelming). For example, in the frontend, I’d sketch out the layouts in PowerPoint, screenshot them, and send them along with specific instructions

(I have no idea if this is good practice 🙏 pls forgive me frontend people)

This usually meant the AI got it mostly right on the first try, and I only had to make small changes afterwards. For the backend, I clearly defined my MongoDB models in a single prompt, how auth and middleware should work, and asked the AI to lay out a detailed plan for endpoints before generating anything.

More mistakes

That said, there were still times where I messed up like the past project. One time I somehow ended up with a file that was almost 1900 lines long (what?). Every little change added up, and I kept telling myself to clean it later.

When I finally tried to refactor it (because the AI literally can’t add features without outright corrupting the file), that turned into two straight hours of painful back and forth. The AI kept hallucinating, breaking stuff, and just did weird things in general. It wasn’t a fun time, but there were plenty of lessons learned afterwards.

Learning things the hard way

That experience forced me to learn some real software engineering lessons the hard way (I guess it’s the best way to learn, after all..?). I started caring more about:

• Structure
• Splitting files into managable chunks
• Actually thinking about sustainable coding

I learned to stop making giant commits with thousands of lines and with nonsense commit messages like asfjahsflkhf. Because well, smaller commits just make everything easier to track, organize, and actually debug when things go wrong.

Prompting

As the project went on, I also got better at prompting. I became more specific, scoped things tighter, and stopped overwhelming the AI with too many things at once. I even started using a separate AI just to help write better prompts.

I also added tests later on, which helped a lot. Tests made it obvious when something broke and gave me more confidence moving forward.

My overall experience

The project was still huge and beyond my experience level. But this time, it actually felt managable. I wasn’t constantly fighting the codebase anymore. It felt like I was actually in control.

5. Takeaways

AI Coding is still coding !!

One thing I learned the hard way is that AI assisted coding is still just coding. The only difference is that instead of writing code directly, you’re writing “code” in human language, but still for a machine.

You can’t really expect to make something without hyper-specific details in code, so why would it be any different wth AI coding? If you don’t understand what you’re building, the AI will happily guess for you (and those guesses will add up over time).

Does vibe coding actually work?

Yes (kind of). Even with AI, coding skills, planning, and even basic project management still matter just as much. AI is wonderful at turning clear intent into code and saving you from spending time writing tedious code over and over again, but it cannot decide what should exist in the first place or why. That part still very much needs a human.

Will AI replace programmers?

Probably not. AI just changes how we develop software. You still need someone to “code” the AI with clear goals, structure, and constraints. Vibe coding can get you started, but it won’t really carry a meaningful project on its own.