81–90 of 100 posts
Defining a bespoke system config was always something that never had the time, desire, or deep familiarity with various config formats to do. With Claude Code or ChatGPT can now generate Wezterm/tmux/neovim/etc config files and get exactly what I want not knowing a single thing about specific config file formats.
When you find a rigid workflow that is both widely applicable and useful, that's how the most valuable companies are made. Those workflows can scale up with little intervention giving them incredibly high yield.
I think the new challenge is introducing flexibility in a controlled manner so we can minimize the added inconsistency needed to achieve broader goals. That way the workflow can find the right balance between robustness and flexiblity for the task at hand.
IME getting LLMs to write flexible code is not easy and one of my biggest turnoffs for coding agents. The code they tend to produce is usually more standardized and lacking of context. It'll "work" but that doesn't mean it "works".
And I think almost everyone is aware of malleable software, it isn't very niche. If you took a programming class your teachers probably told you to write functions and make them small and self contained. A lot like the Unix Philosophy[0].
One thing I find different about this style is that it tends to shift time away from writing lines of code to planning. Which, again, the planning part is what the LLMs tend to be weak at[1]. You can't plan everything but a benefit of flexible code is that you can adapt to new challenges and requirements. It's a good style because a constant in software development is that the requirements by the end of the project (does it end?) are going to be different from those you started with. If your code is inflexible then you have to hack around your existing code. But if it is flexible you add the new routines and leverage existing ones as much as possible. But for that to happen the existing routines should be decently singular in purpose. Function call overhead tends not to be the bottleneck but if the profiler says they are then yeah, fuse functions as need.
[0] https://en.wikipedia.org/wiki/Unix_philosophy
[1] I find their strengths are in writing generic routines, helping narrow in on fuzzy or difficult to describe things that are hard to google, helping you get up to speed on a novel codebase, ditto for a library or language, or simply just throw away code. But not for things where foresight is necessary. But yes great when your job is to glue things together. It's just that if you're doing a lot of gluing there's probably a better way
I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation. But, at the same time, there are two issues: - Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty…
> Companies can be really complex
> The best software around is the one that's opinionated.
tikhonj jokingly suggests emacs but even as a vim user I fully agree. Like they say, the beauty of it is that the complexity draws from simpler foundations. It is written as an environment rather than just as a text editor. Being written that way lets it adapt to many different situations and is what has kept both vim and emacs alive and popular after all these years. There's a constant in software development: requirements change with time. The point of writing an environment is that you're able to adapt to these changes. So any time you write a tool that tool is built out of that environment. Anything short of that means the tool won't be able to adapt as time marches on.
I definitely agree that writing software like this is hard but I'm not sure if it is harder. It takes more work up front but I'd argue it takes less work in the long run. It's just that in the long run many efforts are distributed across different people and time. But hey, good flexible code also tends to be much easier to read and that's big short term benefit to anyone coming into a mature project.
I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation. But, at the same time, there are two issues: - Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty…
The best software around is Emacs. Does that count as "opinionated" in your view? In some ways it is—Emacs does a lot of things its own way, completely unbothered by mainstream conventions—but, at the same time, it's also totally malleable in the sense of this article. What makes Emacs great is a consistent and coherent conceptual foundation coupled with remarkably flexible code, letting you adjust Emacs to your need…
Earlier quoted context omitted.
In my first job I had to work with healthcare software and it horrified me. There is a standard for interop, HL7, but every system implements HL7 in its own special way so there are "integration engines" to massage the data so that they all conform to the same standard. It's a gigantic grift.
The history of HL7 is kind of nuts. It was originally developed for copper wire communication in 1979. Formalization was ongoing until maybe the early 1990s and lots of proprietary usage arose, because back in the 1990s none of these systems really inter-operated and everything eventually ended up on paper. It wasn't until after the ACA that a lot of interoperability pushes really got going at scale. Before that you…
I was working on automating health insurance claims processing on a mainframe system.
In their key interface, a key form had 8 blanks for ICD codes. If more than 8 codes were needed, a child claim was created and linked to the parent claim.
This was a long project, so I was staring at this interface for months, as linked child claims made automation more complex than it needed to be. (E.g. if a parent claim had aged, been archived, and needed to be reloaded to active overnight before processing the child claim)
Finally, I started asking around. "This is a computer system. Why are there a finite number of fields for something that might need more?"
Nobody knew. Project continued. I continued asking different people.
Finally, I asked a guy who had been working in the industry since the 1960s...
"Oh, because that's how many fields there were on the paper version of the form that preceded the mainframe app."
Which seems insane, until you think it through. There were innumerable downstream processes of that paper form.
Changing the number of fields on the digital version would have cascaded that change downstream to all those processes. In the interest of rapid implementation, the optimal approach was to preserve everything about the form.
And then nobody had a reason to go to the bother to change it for the next 50 years. (And that was a process within a single company!)
Earlier quoted context omitted.
It doesn't need to be AGI to build complex software. A human software developer can build a complex software system and perform other complex tasks with the same body (play an instrument, fly an aircraft, etc.). Doing all of that with the same resources is what AGI is needed for. Just software, well I'm sure an LLM can eventually become an expert just like it learnt how to play Go.
AGI usually means "equivalent to human" while digital super intelligence generally means "smarter than all humans put together". In any case I agree that once we reach "equivalent to human" naturally it can do anything we do. That should be enough to end office jobs imo.
Earlier quoted context omitted.
The history of HL7 is kind of nuts. It was originally developed for copper wire communication in 1979. Formalization was ongoing until maybe the early 1990s and lots of proprietary usage arose, because back in the 1990s none of these systems really inter-operated and everything eventually ended up on paper. It wasn't until after the ACA that a lot of interoperability pushes really got going at scale. Before that you…
The koan that unlocked why healthcare technology is the way it is for me: I was working on automating health insurance claims processing on a mainframe system. In their key interface, a key form had 8 blanks for ICD codes. If more than 8 codes were needed, a child claim was created and linked to the parent claim. This was a long project, so I was staring at this interface for months, as linked child claims made autom…
People keep saying things like this, but what's an actual example of a viable product created that way? Talk is cheap, I want to see it.
Earlier quoted context omitted.
I agree with you, though I’m not sure I fully understand your point about game studios. That seems like an area where software could evolve in ways that make perfect sense. For example, dynamic worlds, unique missions, unscripted characters, and so forth.
My comment is about companies self-serving with malleable & bespoke software. Niantec is unlikely to spend time making a bespoke GenAI version of Jira, just because it's cheaper to do so now than it was before. Every minute they spend making the bespoke project management software is a minute they're not making the next PokemonGo, so they'll pay a third party like Confluence handsomely to produce a predictable projec…