Wagner James Au / New World Notes

Author, strategist, virtual world reporter

recent posts

about

LLMs May be the Trojan Horse That Modernizes Software Development — Charity Majors

Charity Majors Honeycomb LLM AI

Charity  Majors, who once helped keep the utterly tangled spaghetti of Second Life's servers operational back in the day, and now puts that wisdom to practice as co-founder/CTO of observability service HoneyComb, has a pretty thought-provoking post on how large language models are changing the nature of programming:

You can make a surprising amount of improvements to an LLM based product without even touching any prompt engineering, simply by examining user interactions, scoring the quality of the response, and acting on the correctable errors (mainly data model mismatches and parsing/validation checks). You can fix or handle for these manually in the code, which will also give you a bunch of test cases that your corrections actually work! These tests will not verify that a particular input always yields a correct final output, but they will verify that a correctable LLM output can indeed be corrected.

You can go a long way in the realm of pure software, without reaching for prompt engineering. But ultimately, the only way to improve LLM-based software is by adjusting the prompt, scoring the quality of the responses (or relying on scores provided by end users), and readjusting accordingly. In other words, improving software that uses LLMs can only be done by observability and experimentation. Tweak the inputs, evaluate the outputs, and every now and again, consider your dataset for representivity drift.

Her surprising conclusion (at least I'm surprised) is she sees a near future were programmers will regularly use LLMs as part of their everyday toolchest:

I hypothesize that over the course of the next decade, developing with LLMs will stop being anything special, and will simply be one skill set of many, alongside mobile development, web development, etc. I bet most engineers will be writing code that interacts with an LLM. I bet it will become not quite as common as databases, but up there. And while they’re doing that, they will have to learn how to develop using short feedback loops, testing in production, observability-driven development, etc. And once they’ve tried it, they too may become extremely unwilling to go back.

In other words, LLMs might ultimately be the Trojan Horse that drags software engineering teams into the modern era of development best practices. (We can hope.)

Emphasis hers (and mine). Her unique argument, coming from her unique perspective as head of an observability company, is that the sheer unpredictability of LLM output is richly suited for how software actually operates in the modern world. While I'm still skeptical about the feasibility/desirability of LLMs for the creation of cultural content (books, articles, etc.), Charity's case for LLMs in development is pretty strong.

Read the whole thing here.

Posted in

One response to “LLMs May be the Trojan Horse That Modernizes Software Development — Charity Majors”

  1. Gwyneth Llewelyn Avatar
    Gwyneth Llewelyn

    Hmm.
    Ok, so, I’m not a professional programmer, in the sense that nobody pays me to write X lines of code per hour, so my own thoughts don’t really reflect what professionals might think about it.
    In the world of computer science, we have something that is close to the Holy Bible of Programming — a massive, multi-volume encyclopedia of algorithms and data structures created by professor emeritus Donald Knuth, The Art of Computer Programming. It’s supposed to be “everything you ever wanted to know about computer programming but were afraid to ask (and read the answer!)” and was started back in 1968; Knuth (now 85) is still working on Volume 5, due to be released on 2030, and he says he has plans for writing Volumes 6 and 7 (one can naturally only wonder if he’s still be around, or if it will be ChatGPT writing it for him), assuming, he admits, that “nobody has said anything about the subjects I plan to cover”.
    Well, the whole point of Knuth’s encyclopedia is that his massive collection of data structures and algorithms can be used to essentially tackle any problem in computer science (at least, in sequential programming; for distributed programming, Andrew Tanenbaum’s reference material is probably the authoritative source) — and that’s by no means a light claim.
    It also happens to be nearly correct, in the sense that there are reasonably few “new” algorithms and data structures that might have been “discovered” after Knuth wrote his massive books. Most we have today, indeed, are variations or sophistications of what Knuth had already catalogued decades ago (Volume 1 came out in 1968). Sure, sometimes, those algorithms have been tweaked beyond recognition to be applied to specific problems that didn’t exist back then when Knuth wrote about them; but you should see them more as engineering tweaks to a solid theoretical knowledge base, and less as “something completely new”.
    In this day and age, the expression “data structures and algorithms” are a bit out of fashion; people prefer to call them patterns instead. Patterns are templates for tackling a specific programming need or issue, which can be applied according to a best practice layout, and should be guaranteed not only to work, but to be the best (or close to the best) solution to that particular issue that has been discovered so far. You can think of patterns as “applied Knuth”, so to speak: pulling from the wisdom from computer science theoretical masters, and developing templates to apply them to the daily tasks that a computer programmer needs to do over and over again — such as connecting to a database to safely retrieve data, or to search for a keyword in a very large document, etc.
    This kind of tasks is repetitive, boring, and essentially the same, with just minor details added here and there. Current-generation professional programmers, therefore, are highly skilled in applying whatever pattern (or template) fits best the issue at hand, and then adding the necessary tweaks to adapt it to the specificities — e.g. not all databases are invoked in the same way, the commands might be different, and, of course, depending on the programming language being used, some patterns might be harder to apply than others.
    Ultimately, therefore, it’s quite possible to imagine a near future where a computer programmer loads their Integrated Development Environment (IDE), gets the specifications of what it needs to develop, and feed it into a LLM which is specifically trained for that task. The LLM identifies the class of the problem and proposes a set of patterns to address it — that’s well within what we can do today. The LLM might additionally pull appropriate reference material from Knuth, Tanenbaum, and others. All of these theoretical work is described in terms of pseudo-language, with many application examples, and it’s very likely that a rule-bound LLM could, in theory, generate a substantial part of the code for whatever programming language is being used. Not ChatGPT as we know today — which just comes up with gibberish that might not even be valid language — but something a bit more sophisticated which will apply lots of validation to the code to ensure that it is essentially correct. Programmers already use those tools, integrated into their IDEs, which will tell them what is wrong with their code well before it’s fed into a compiler — thus saving precious hours of looking for that stray semicolon in thousands of lines of code that threw an unexpected error.
    Because programmers have added and integrated such tools more and more — all for the sake of making the tedious bits take less time to implement, while at the same time making the programmer’s life so much easier, when it’s their IDE or code editor that deals with cross-referencing all the lines of code and automatically figure out what each part of the code is supposed to be. Drop in a few comments, and you can reasonably expect some sort of AI to try to figure out what exactly the programmer wants to do, go through its references, and propose a pattern which is better adapted to deal with this specific task.
    We’ve already using so many tools to aid computer programmers that AI-enhanced bits will be almost imperceptibly built-in as well. Programmers hate to write the same code over and over again in each project they join; they’ll be glad to have an AI to write it for them.
    Also, these days, it is said that more time is spent by professional developers in devising tests to ensure their code is correct, than in actually writing lines of code; similarly, pros will also document their code in much more detail than ever before (having lots of new tools to do so), which, in turn, allows them to generate the full descriptive text for their code almost automatically, without the need of having it as a separate task (formerly delegated to “technical writers”!). If all of these secondary — but necessary! — things can be fully automated and delegated to AI, well, the more time the programmer will have to tackle those areas that can only be done by a human (at least, for now!).
    This, IMHO, is an inevitable development. We already have several hundreds of such automated tools available. While one or two decades ago, the first generation of these tools were ultra-expensive and only affordable by top Silicon Valley software giants, today, many of these are free to use, and built-in into popular software repositories such as GitHub, or at least integrated with it. The consequence is that code, these days, usually is of much higher quality than ever before — if you can validate it automatically, then there is a far better chance that it will be able to face the “real world” (which contains… argh… users!!… the bane of every programmer!) unscathed. In some environments — even open-source projects! — using those tools is mandatory, not an option, if you wish to contribute code to a project. It will be vetted first by an automated tool, and only then presented to the project leader for final approval, and merged with the other contributor’s code.
    It’s not by chance that open-source software can, these days, be as good as professionally written code by software giants with unlimited resources: many of the tools they use do essentially the same, just for free. And these tools are getting better and better; soem might not have much AI built into them (yet!), but some do: they give tips and suggestions for the programmer to change their code in order to get a performance boost or making it more secure and less prone to intrusion attacks.
    All in all, and looking how software is being developed in 2023, even by humble amateur programmers like your truly, I can very well expect Charity’s predictions to come true, and they will come true much faster than expected. The vision of having AI helping out humans by taking over their tasks — especially those that are boring and repetitive! — in order to increase overall productivity and enhance employee satisfaction (“you don’t need to write a single line of testing code! we do it for you! rejoice, for now all your time can be spent in the really creative aspects of your code, not wasted in mindless, boring tasks!”) will become real very, very quickly, and it will be wholeheartedly embraced almost instantly by a whole generation of programmers.
    Although there are still quite a lot of “old school” programmers claiming that it’s better to tackle a problem by yourself, starting from scratch, instead of wasting time searching for a solution on Google (and then wasting even more time trying to adapt it to your case), the truth is not that black-and-white. Sure, you can learn a lot by “reinventing the wheel” yourself, as opposed to buy a shiny new wheel, ready to be fit into your system. But in a production environment, such an approach might only be useful in edge cases, where programmers are developing code for unique scenarios where none of the automated tools out there (present and future) are able to come up with a solution — because such solutions haven’t been invented yet.
    But these are edge cases. The simple truth is that 99% of all code around there is essentially built to address the same problems — over and over again — which have been around for decades. Knuth’s encyclopedia is not in current usage because of the reverence programmers have towards an Old Great Master; it’s used (even if they don’t know it) because the solutions that Knuth points out have been proven to give the best possible answer to a specific issue in a certain context. View your task at hand under the magnifying glass of Knuth’s words, and if you can adapt any of his work to deal with your task — your problem is solved, and you can move on, fully confident that whatever Knuth has written has been tested over the decades and just works.
    (The challenge, of course, is to present the problem/task/issue in such a form where Knuth’s solutions can eventually be applied; this may be automated in the future, but, right now, it’s a human programmer’s job to figure out.)
    In the present — not in an imaginary future! — most professional programmers in their cubicles essentially apply patterns, algorithms, data structures, libraries, and frameworks to develop software. They already have to do that simply because time is an extremely limited resource (and thus, according to the laws of economy, very expensive!), which means that computer programmers have to use as many “shortcuts” to keep themselves within budget & time limitations. This really means reusing every tiny bit of code you can, in order to limit the time wasted in writing it; if AIs are able to provide such code — or at least figure out what the best strategy is in a certain scenario, and advise the programmer to use template A or library B or Knuth’s algorithm C to “fix” the issue — that will be the cause of much rejoice for computer programmers, endlessly bored with repetitive tasks as well as for their employers, who are well aware that “boring code” takes as much precious time to develop as “exciting new breakthroughs” — but there is quite a lot more of the former than the latter! Thus, AIs might reduce (or eliminate!) the need of wasting time with “boring code”, and let programmers focus on the “exciting new breakthroughs” instead — to the satisfaction of everyone.
    In due time, however, “exciting new breakthroughs” will slowly be incorporated in AI tools as well and be part of their repository of ready-made, pre-programmed solutions. Consequently, the time spent by programmers in “exciting new breakthroughs” will be less and less, and it’s not impossible that these will be further spaced out in time. In other words: Knuth dedicated his whole life and career to assemble all his algorithms and data structures over the decades. AIs can do the same — in real time, at neck-breaking speeds — and assemble volumes of information about computer code employed to address an issue in the same time Knuth takes to autograph one of his books.
    Therefore, it’s also foreseeable that, in the future, you will need less programmers, and that those that are still able to get a job will be merely the crème de la crème — merely because the “junior programmer”‘s tasks will be so automated that any half-decent AI will able to do their work easily enough. Sure, such code will require human supervision to be merged with the existing codebase — but that’s also true for “junior programmers” today. Humans already review code written by less-experienced humans, as part of their jobs, so they can perfectly well do the same with AI-generated code.
    And at some moment in time, even the team leader’s or supervisor’s role will be replaced by new automation tools that automatically reviews code to see if it does what it’s supposed to do, and if it can be successfully merged with the existing codebase created by other developers. In fact, as I type this paragraph, that “moment in time” is today: we already have such tools, or tools that come as close as possible to such requirements, merely because… well, code reviewing is also a very boring and repetitive task, but it’s essential and crucial that it’s well done with the utmost regard to correctness and the lowest tolerance for any sort of error. Humans are good in doing that (we’re wonderful pattern matchers, after all!), but it’s an activity that takes time, which is what programmers do not have to spare; AIs, by contrast, can do those jobs also well enough (they are, after all, good pattern-matchers as well, and, in many scenarios, they can easily beat humans in pattern-matching, being faster for several orders of magnitude).
    As you can see, this approach of integrating AI into software development and computer programming comes from the bottom up and will slowly prune — dramatically! — the large hierarchy of programmers required to develop an industry-grade application. This naturally has consequences, some of which very positive — cheaper applications for end-users, higher profit margins for software houses — and some that might not be that positive, such as putting junior developers, as well as mid-range team leaders and below-average computer programmers, out of a job…

    Like

    Reply

Leave a comment