Extensible Software in the age of LLMs

This is the right general idea, but it does read as an ad for Cloudflare OS.

Every tech company is scrambling to be the stable foundation for people in enterprise to build cute little one-off apps safely. It's a perfectly fine pattern, but it's hard to imagine a world where Cloudflare becomes the default. Much easier to imagine Google or Microsoft adopting whatever UI/UX patterns work well and tying into enterprise data natively.

As I said elsewhere: The future of tools like github is a platform for manual testing, where you write a prompt, the AI proposes a change and you can experiment with the UI and attach notes for the next iteration. AI can take user requests, prioritize, aggregate into tickets, and turn them into pull requests.

For a lot of end users, this may be enough, no programmers will be needed to get software built and shipped. For the rest, it lets programmers fill the remaining gaps, doing the manual testing to make sure the system works correctly, test for regressions and make sure the LLMs add those to the test suite, and then manage monitoring the rollouts. The bulk of development work going forward is manual verification that the LLM understood the user request correctly.

I'm not as sure that this idea of plugins will pan out; AI will want to make changes to support what it produces.

I see a different future. A future where software developers are approached by clients with requirements in the form of an LLM generated program. They do it because they are at a point where LLM fails to make new changes without breaking existing stuff.

Maybe it won't be a program, but just some LLM context as some data dump.

This program or context will take up the role of a PM. Developers will refer to the program, or ask context for clarifications and the developer will build the actual program with or without the help from LLMs.

> It took me thirty minutes with Codex and GPT-Sol. The thing is fast, it does not ask me for anything, and it does the one job I wanted: it launches applications.

This is quite funny, actually. When I wanted something similar (just play MP3s, without playlists, special indexes, etc), it also took me 30 minutes.

In 2002.

I still use it daily - a wish application displays entries matching the filter using the locatedb to get a list of all MP3s to find them and mpg123 to play them. This is the application that I have used the longest in my life, unchanged and unmodified from day 1, and it still tickles me that it took 30m.

I'm pretty certain, had LLMs not existed, that I can make an application finder using locatedb (perhaps store a private index as well) and a GUI in about 30m using wish as the front-end.

(Just for reference, here's my no-frills MP3 player) ---------------------------------------------

    #!/usr/bin/wish
    # Copyright Lelanthran K. Manickum 2002, provided under BSD license
    #

    set version "1.0"

    proc playSong {songname} {
       set rc [catch { exec killall -9 mpg123 }]
       if {$songname=="\[Stop Playback]"} {
          .midFrame.lblPlaying configure -text "Stopped"
          return 0;
       }
       set rc [catch { exec mpg123 --loop -1 "$songname" & }]
       if {$rc==0} {
          .midFrame.lblPlaying configure -text "Playing: $songname"
       }
    }

    proc locateSongs {pattern} {
       .lstResults delete 0 999999999
       set tmpvar [split [exec locate -i "*$pattern*.mp3"] "\n"]
       .lstResults insert 0 "\[Stop Playback]"
       foreach title $tmpvar {
          .lstResults insert 1 $title
       }
    }

    frame .topFrame 
    frame .midFrame

    entry .topFrame.entSearchString -text "Search String"
    button .topFrame.btnSearch -text "Search" -command {locateSongs [.topFrame.entSearchString get]}
    listbox .lstResults -yscrollcommand {.sby set} -xscrollcommand {.sbx set}
    scrollbar .sby -orien vert -command {.lstResults yview}
    scrollbar .sbx -orien horiz -command {.lstResults xview}
    label .midFrame.lblPlaying -text "Stopped"

    locateSongs ""
    focus .topFrame.entSearchString

    bind .topFrame.entSearchString <Return> ".topFrame.btnSearch invoke"
    bind .lstResults <Double-B1-ButtonRelease> {playSong [.lstResults get active]}
    bind .lstResults <Return> {playSong [.lstResults get active]}


    grid .topFrame -row 0 -column 0 -sticky nsew
    grid .topFrame.entSearchString -column 0 -row 0 -sticky nsew
    grid .topFrame.btnSearch -column 1 -row 0 -sticky nsew
    grid .midFrame -column 0 -row 1 -sticky nsew
    grid .midFrame.lblPlaying -column 0 -row 0 -sticky nsew
    grid .lstResults -column 0 -row 2 -sticky nsew 
    grid .sby -column 1 -row 2 -sticky nsew 
    grid .sbx -column 0 -row 3 -sticky nsew 

    grid rowconfigure .topFrame 0 -weight 1
    grid columnconfigure .topFrame 0 -weight 1
    grid rowconfigure . 2 -weight 2
    grid columnconfigure . 0 -weight 2

    wm protocol . WM_DELETE_WINDOW {
        set rc [catch { exec killall -9 mpg123 } ]
        destroy .
    }

    wm title . "Simple Music Player - v$version"
    wm geometry . 700x500

This is exactly what I did a few days ago: I created my own "small software" to solve my own need: https://news.ycombinator.com/item?id=49330939. Let me tell you: it works, it works really well, and I don't feel like, "Hey, the options out there are better."

In fact, the options available are outdated in terms of frameworks and bloated with features to please all kinds of customers. They try to do everything but end up doing everything poorly.