Solving the Wrong Problem(ufried.com)
ufried.com
Solving the Wrong Problem
https://www.ufried.com/blog/ai_assisted_coding/
25 comments
This is in some ways a circular argument / problem.
Because, what does a well-specified formalisation of a problem solution look like? It looks like a programming language.
Since COBOL, the dream has been a language which is formalised for computers while being understandable and able to be written by "business users".
We've been promised this future by COBOL, Visual Basic, SQL, and many others.
And what does the reality look like? It looks like the business users being upset by the fussiness that formalisation adds.
That's why Excel is still king.
Does adding better visual descriptors of program execution really help communicate solutions?
LLMs are actually a great bridge between, "Here's an idea" and "Here's the idea formalised as a set of problem and solution statements".
They're really good at it. Claude Sonnet 4.5 will output a dozen pages of formalised steps for solving a problem that acts as a good bridge between the domain expert and the programmer.
It makes mistakes. It misunderstands things sometimes. Sometimes it understands things better than the programmer or the domain user, such as when it recently corrected me on my understanding on the OAuth2.0 spec, because I was using a non-standard parameter that Cisco Meraki had mistakenly added to their documentation.
Because, what does a well-specified formalisation of a problem solution look like? It looks like a programming language.
Since COBOL, the dream has been a language which is formalised for computers while being understandable and able to be written by "business users".
We've been promised this future by COBOL, Visual Basic, SQL, and many others.
And what does the reality look like? It looks like the business users being upset by the fussiness that formalisation adds.
That's why Excel is still king.
Does adding better visual descriptors of program execution really help communicate solutions?
LLMs are actually a great bridge between, "Here's an idea" and "Here's the idea formalised as a set of problem and solution statements".
They're really good at it. Claude Sonnet 4.5 will output a dozen pages of formalised steps for solving a problem that acts as a good bridge between the domain expert and the programmer.
It makes mistakes. It misunderstands things sometimes. Sometimes it understands things better than the programmer or the domain user, such as when it recently corrected me on my understanding on the OAuth2.0 spec, because I was using a non-standard parameter that Cisco Meraki had mistakenly added to their documentation.
Agreed. Basically, open some random piece of code. Try explaining it in English with perfect precision. That's what "coding" in natural language would be like. Way more verbose, open to misinterpretation, harder for engineers to follow, still impenetrable to non-engineers, and with the added possibilities of hallucination at code generation time.
LLMs are great (sometimes) for conversational editing where there's a fast, iterative back and forth between description, code, clarification and touch-ups, etc. But trying to avoid code entirely eventually makes everything harder, not easier.
LLMs are great (sometimes) for conversational editing where there's a fast, iterative back and forth between description, code, clarification and touch-ups, etc. But trying to avoid code entirely eventually makes everything harder, not easier.
Right. If an LLM is capable of writing good boilerplate code for you then your programming language is too low level. We need higher level languages which abstract away most of the repetitive patterns. What would a language look like where the code has much higher "entropy" but is still human readable and maintainable? Like could we design a language that combines all of the productivity advantages of APL / Lisp / Prolog but is still usable by average developers?
I would argue that nowadays the libraries and frameworks are more to blame than the languages. We aren't creating the right elegant DSLs. But more importantly we're still expecting people to inherit from library classes — perhaps multiple levels deep — to swap functionality in and out. We could just use functions as first-class objects but instead we have to understand this unnatural intermingling of code and data that's based on "modeling" a supposed concept in the problem domain (rather than the solution domain) that barely makes any sense in and of itself. Like Rich Hickey explained (https://www.youtube.com/watch?v=SxdOUGdseq4), things become complex because you complect them.
You can get a lot of APL / LISP feeling out of carefully written Python or JavaScript. Not the metaprogramming stuff, sure. But a lot of that in LISP depends on homoiconicity, which is one of the biggest things making the language "not usable by average developers".
You can get a lot of APL / LISP feeling out of carefully written Python or JavaScript. Not the metaprogramming stuff, sure. But a lot of that in LISP depends on homoiconicity, which is one of the biggest things making the language "not usable by average developers".
> Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level
Every time people attempted on this they ended up with a programming language that is harder to use than usual programming languages.
SQL was marketed as "fourth-generation programming language."
Two other examples that come to mind: Github Actions, and node-based visual programming.
Every time people attempted on this they ended up with a programming language that is harder to use than usual programming languages.
SQL was marketed as "fourth-generation programming language."
Two other examples that come to mind: Github Actions, and node-based visual programming.
ya I think it's possible to do vastly better than those
Programs aren’t text that you run on a computer though. Programs are text that describe an abstract syntax tree which encodes the operational semantics of the thing you’re computing.
Maybe (likely) you could come up with a more convenient set of operations, but I don’t really see how expressing that as plain text ast is really holding things back.
Maybe (likely) you could come up with a more convenient set of operations, but I don’t really see how expressing that as plain text ast is really holding things back.
Consider that when doing 3d modeling you usually do not work on the mesh data itself but on a visual representation of it. Sometimes you have to go under the hood of this representation to write e.g. shaders.. But you'd like to not do that at all for the daily work.
In particular, the syntax tree is also Just Another Representation of the functionality... But it's still way overspecified, compared to your intent, since it has lots of implementation details encoded in it. Actually it is the tests that get closer to an exact representation of what you intend (but still, not very close). (This is also why I love React and declarative programming: because it lets me code in a way which is closer to the model of what I intend that I hold in my head. Although still not that close).
So, programming seems similar to the mesh data for a model to me. The more you can get a representation which is faithful to the programming intent, the more powerful you are. LLMs demonstrate that natural language sorta does this.. But not really, or at least, not when the 'compiler' is a stochastic parrot. On the flip side it gets you part of the way and then you can iterate from there by other methods.
In particular, the syntax tree is also Just Another Representation of the functionality... But it's still way overspecified, compared to your intent, since it has lots of implementation details encoded in it. Actually it is the tests that get closer to an exact representation of what you intend (but still, not very close). (This is also why I love React and declarative programming: because it lets me code in a way which is closer to the model of what I intend that I hold in my head. Although still not that close).
So, programming seems similar to the mesh data for a model to me. The more you can get a representation which is faithful to the programming intent, the more powerful you are. LLMs demonstrate that natural language sorta does this.. But not really, or at least, not when the 'compiler' is a stochastic parrot. On the flip side it gets you part of the way and then you can iterate from there by other methods.
Incidentally, coming from a half-baked physics background: to me this feels very similar to how, as physics moved closer to the fundamental theories of GR and QFT, it was forced to adopt the mathematical framework of representation theory[1], which is to say, to reckon with the fact that
(a) a mathematical model like a group is a representation of a physical concept, not the concept itself
(b) this process of representing things by mathematical models has some properties that are inescapable, for instance the model must factor over the ways you can decompose the system into parts
(c) in particular there is some intrinsic coordinate-freedom to your choice of model. In physics, this could be the choice of say coordinate frame or a choice of algebraic system (matrices vs complex numbers vs whatever); in programming the choice of programming language or implementation detail or whatever else
(d) the coordinate-freedom is forced to align at interfaces between isolated systems. In physics this corresponds to the concept of particles (particularly gauge bosons like photons, less sure about fermions...); in programming corresponds to APIs and calling conventions and user interfaces---you can have all the freedom you want in the details but the boundaries are fixed by how they interop with each other.
all very hand-wavey since I understand neither side well... but I like to imagine that someday there will be a "representation theory of software" class in the curriculum (which would not dissimilar from the formal-language concepts of denotational/operational semantics, but maybe the overlaps with physics could be exploited somehow to share some language?)... it seems to me like things mathematically kinda have to go in something like this direction.
[1] https://en.wikipedia.org/wiki/Representation_theory
(a) a mathematical model like a group is a representation of a physical concept, not the concept itself
(b) this process of representing things by mathematical models has some properties that are inescapable, for instance the model must factor over the ways you can decompose the system into parts
(c) in particular there is some intrinsic coordinate-freedom to your choice of model. In physics, this could be the choice of say coordinate frame or a choice of algebraic system (matrices vs complex numbers vs whatever); in programming the choice of programming language or implementation detail or whatever else
(d) the coordinate-freedom is forced to align at interfaces between isolated systems. In physics this corresponds to the concept of particles (particularly gauge bosons like photons, less sure about fermions...); in programming corresponds to APIs and calling conventions and user interfaces---you can have all the freedom you want in the details but the boundaries are fixed by how they interop with each other.
all very hand-wavey since I understand neither side well... but I like to imagine that someday there will be a "representation theory of software" class in the curriculum (which would not dissimilar from the formal-language concepts of denotational/operational semantics, but maybe the overlaps with physics could be exploited somehow to share some language?)... it seems to me like things mathematically kinda have to go in something like this direction.
[1] https://en.wikipedia.org/wiki/Representation_theory
> Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level
That's another programming language. And if you think of an even higher level, where you e.g. specify, that you want to get data from a server in a format, and leave it to some other specification how to do that, that is called a program/library. You get that for free from e.g. Github or your OS repos.
That's another programming language. And if you think of an even higher level, where you e.g. specify, that you want to get data from a server in a format, and leave it to some other specification how to do that, that is called a program/library. You get that for free from e.g. Github or your OS repos.
yes I'm asking for higher-level programming languages. Higher even than anything we have today.
I don't think we will ever get the one language that just needs one statement to do anything AS of the language specification. If you have something in mind, where the language gets more capable iteratively by their users, then that is already the state now, we just don't name that a language, this is called software repos. The reason this isn't used solely is a) supply chain risk, which you don't care about with LLMs, and b) that the third-party software often slightly differs from what you want, so while you could use third-party software you choose to still write it yourself.
You might like this post I wrote:
https://open.substack.com/pub/btmc/p/thoughts-on-visual-prog...
ya, we're kinda talking about the same stuff. I appreciate the list of examples.
I have some ideas about how to do this, and I think the basic building block is something like "a partially specified object". For example, suppose you want to write a CLI application. The normal way to do this is write a bunch of, say, Python code that processes the args, does the thing, writes the outputs, prints the help, etc. I think there is a different architecture where you say:
1. I want a CLI application. Okay, this sets up a scaffold with all the parts unfilled out. It doesn't "compile" at the moment but you can still run it and inspect it using something akin to devtools / a visual inspector/debugger, kinda like a level editor in a game engine's authoring tools (picture Unity's editor).
2. next I fill in the commands that I want to run. These have a type (provided by the parent application), which is a union of all the things that that a CLI application can do (flags, args, etc). the CLI library translates these to function calls that don't do anything yet. Now I can call all the commands, print the help, etc, but they don't do anything.
3. Next I implement all the commands, etc.
Now this is all isomorphic to writing a bunch of files of code. But my feeling is that you want to be writing the code by authoring the data structures directly. You have a pre-existing type for "CLI application", and you fill in all the slots. Each change is a diff at the level of the data structure. There's some internal code for how you do the things, but those are calls out into functions that are potentially in another language. Diffs and etc are at the level of the data structure itself, not the underlying code (or rather: the underlying data is code, but the visualization of the diff is in terms of how the data structure changed, not how the code changed).
The goal is then to find a way to generalize this method of authoring across all software, to do it very generically so that your "IDE" is a tool for visualizing abstract applications, of which common architectures (CLI app, library, GUI application, server, website) are just particular libraries, and in which the compilation process turns the thing you're authoring into an actual application in an existing programming language (which is now treated as a data format, like assembly code, rather than the actual language you author things in).
I have some ideas about how to do this, and I think the basic building block is something like "a partially specified object". For example, suppose you want to write a CLI application. The normal way to do this is write a bunch of, say, Python code that processes the args, does the thing, writes the outputs, prints the help, etc. I think there is a different architecture where you say:
1. I want a CLI application. Okay, this sets up a scaffold with all the parts unfilled out. It doesn't "compile" at the moment but you can still run it and inspect it using something akin to devtools / a visual inspector/debugger, kinda like a level editor in a game engine's authoring tools (picture Unity's editor).
2. next I fill in the commands that I want to run. These have a type (provided by the parent application), which is a union of all the things that that a CLI application can do (flags, args, etc). the CLI library translates these to function calls that don't do anything yet. Now I can call all the commands, print the help, etc, but they don't do anything.
3. Next I implement all the commands, etc.
Now this is all isomorphic to writing a bunch of files of code. But my feeling is that you want to be writing the code by authoring the data structures directly. You have a pre-existing type for "CLI application", and you fill in all the slots. Each change is a diff at the level of the data structure. There's some internal code for how you do the things, but those are calls out into functions that are potentially in another language. Diffs and etc are at the level of the data structure itself, not the underlying code (or rather: the underlying data is code, but the visualization of the diff is in terms of how the data structure changed, not how the code changed).
The goal is then to find a way to generalize this method of authoring across all software, to do it very generically so that your "IDE" is a tool for visualizing abstract applications, of which common architectures (CLI app, library, GUI application, server, website) are just particular libraries, and in which the compilation process turns the thing you're authoring into an actual application in an existing programming language (which is now treated as a data format, like assembly code, rather than the actual language you author things in).
Yes, what you describe is similar to other ideas I've had in past. Not necessarily in the specific steps you mentioned but the idea of "I want a CLI application" and the tool I'm using sets up the high-level scaffolding for a CLI application in terms of "CLI application" concepts rather than working at the level of splitting strings or whatever.
"argparse"-style libraries are actually a good example of climbing up the abstraction ladder where you're talking in terms of CLI concepts. But they're usually implemented either as messy metaprogramming hacks or as function/method calls and callbacks.
Instead of doing this, one can imagine editing a data structure, visually, that represents the same information, e.g., I have a treeview of all the subcommands my application supports, I can filter them, I can edit their help information with color like in a wysiwyg editor or markdown instead of writing into string literals on the app, etc.
You did mention that this high level scaffolding wouldn't compile or run, but I don't think that's necessary. Just have it compile and run right away, but simply do nothing useful. As you fill in the pieces it starts doing things.
Incremental development is extremely important or you end up in a UML situation where the intended structure of the program and the real constraints the program is under don't match.
"argparse"-style libraries are actually a good example of climbing up the abstraction ladder where you're talking in terms of CLI concepts. But they're usually implemented either as messy metaprogramming hacks or as function/method calls and callbacks.
Instead of doing this, one can imagine editing a data structure, visually, that represents the same information, e.g., I have a treeview of all the subcommands my application supports, I can filter them, I can edit their help information with color like in a wysiwyg editor or markdown instead of writing into string literals on the app, etc.
You did mention that this high level scaffolding wouldn't compile or run, but I don't think that's necessary. Just have it compile and run right away, but simply do nothing useful. As you fill in the pieces it starts doing things.
Incremental development is extremely important or you end up in a UML situation where the intended structure of the program and the real constraints the program is under don't match.
> Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level?
... And you want a representation of that abstraction to persist on disk?
... But it shouldn't be "text"?
Why not?
And how will you communicate it? You want to prompt in lossy, error-prone, inexact text, and then trust that an opaque binary blob correctly represents the formalization of what you meant? Or go through feedback cycles of trying to correct it with more prompting, but without the ability to edit manually?
> but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually.
Well, sure. But that isn't a problem with text; it's a problem with boilerplate in our designs.
... And you want a representation of that abstraction to persist on disk?
... But it shouldn't be "text"?
Why not?
And how will you communicate it? You want to prompt in lossy, error-prone, inexact text, and then trust that an opaque binary blob correctly represents the formalization of what you meant? Or go through feedback cycles of trying to correct it with more prompting, but without the ability to edit manually?
> but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually.
Well, sure. But that isn't a problem with text; it's a problem with boilerplate in our designs.
you'll communicate it as text or binary data, of course; you just won't operate on it in that form (necessarily).
> Finally, I would like to mention an irony. If you talk with people who use AI agents a lot for software development, they will tell you that the quality of the requirements and the architectural design and documentation make a huge difference regarding the quality of the code produced by the AI agents. Thus, it would be necessary to put more effort into phrasing requirements and designing a good architecture.
> I mean, for at least the last 3 or 4 decades, one of the biggest impediments we had regarding fast and reliable software development were poor requirements and poor architectural design. Human software developers had the same problems with poorly designed and documented requirements and architecture for the last decades, but nobody cared. Instead, the only complaint was that writing software would take too long.
> I mean, for at least the last 3 or 4 decades, one of the biggest impediments we had regarding fast and reliable software development were poor requirements and poor architectural design. Human software developers had the same problems with poorly designed and documented requirements and architecture for the last decades, but nobody cared. Instead, the only complaint was that writing software would take too long.
> Writing production code is a completely different game than (vibe) coding a prototype. To get this right, you need profound knowledge of the programming language, of its ecosystem, of the dos and don’ts of good software design and development, of the additional bolts and screws needed to make the software production-ready, and much more.
Having spent some of my career as an SRE, I would argue that what distinguishes production code from it-worked-on-my-machine code has very little to do with the things at the start of that list and almost everything with the "bolts and screws needed to make the software production-ready", and particularly the 12 factors [0]. With my anecdata, I've had a much more productive time maintaining in production systems written by junior coders who only started using that particular language a few months ago, but are eager to take direction, than experienced developers with profound knowledge and strong opinions held tightly.
With this in mind, I've been quite productive doing "vibe engineering" [1], rigidly controlling the code from the outside as mostly a black box, with extensive precommit testing, focusing my code reviews on preventing weird "going off the rails" issues and adding new tests against them, while not worrying at all about code style.
[0] https://12factor.net/
[1] https://simonwillison.net/2025/Oct/7/vibe-engineering/
Having spent some of my career as an SRE, I would argue that what distinguishes production code from it-worked-on-my-machine code has very little to do with the things at the start of that list and almost everything with the "bolts and screws needed to make the software production-ready", and particularly the 12 factors [0]. With my anecdata, I've had a much more productive time maintaining in production systems written by junior coders who only started using that particular language a few months ago, but are eager to take direction, than experienced developers with profound knowledge and strong opinions held tightly.
With this in mind, I've been quite productive doing "vibe engineering" [1], rigidly controlling the code from the outside as mostly a black box, with extensive precommit testing, focusing my code reviews on preventing weird "going off the rails" issues and adding new tests against them, while not worrying at all about code style.
[0] https://12factor.net/
[1] https://simonwillison.net/2025/Oct/7/vibe-engineering/
Not the same thing, but reminds me of Type III Error: providing the right answer to the wrong question.
https://en.wikipedia.org/wiki/Type_III_error
https://en.wikipedia.org/wiki/Type_III_error
Suppose that an LLM would produce excellent, production-ready code automatically given high-quality architecture and design documentation and proper requirements. Could we offload the code generation to the machine and focus on producing architecture and design documentation? And would that provide meaningful improvements?
I don't know the answer to that. But it's an interesting point that's buried in the article is that companies like to shortchange that part of the process, and it's that part of the process that is the most important to getting good code out of an LLM. I suppose part of the problem with using LLMs is that the providers have a vested interest in collecting fees that are barely less than the fully-loaded cost of the development staff.
So it'll be interesting to see if some companies find themselves ratcheting up on the documentation, and then revisiting the need for the LLM when the LLM pricing rises to the maximum the market can support.
I don't know the answer to that. But it's an interesting point that's buried in the article is that companies like to shortchange that part of the process, and it's that part of the process that is the most important to getting good code out of an LLM. I suppose part of the problem with using LLMs is that the providers have a vested interest in collecting fees that are barely less than the fully-loaded cost of the development staff.
So it'll be interesting to see if some companies find themselves ratcheting up on the documentation, and then revisiting the need for the LLM when the LLM pricing rises to the maximum the market can support.
I find the back and forth more productive. Lots of up front requirements and docs is like waterfall. You do everything up front and don't realize until implementation time that the design is unclear, has flaws and contradictions, etc.
Often it feels more efficient to take shorter steps, try something in code, we how it looks, update docs, show a demo, etc. That was true before LLMs and I think LLMs make it even more true.
Often it feels more efficient to take shorter steps, try something in code, we how it looks, update docs, show a demo, etc. That was true before LLMs and I think LLMs make it even more true.
Nah, we’d still get architecture wrong.
> They respond in much smarter ways than traditional multi-layer perceptrons or traditional RNNs like LSTM networks because their attention mechanisms helps them to make much better sense of the input they were provided by selectively paying more or less attention to different parts of the input (including their output generated so far). This is similar to what humans do.
This is not in any way similar to what humans do.
This is not in any way similar to what humans do.
Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, error-prone, inexact) specification for a program, or at least part of a program, before you go in and modify it by hand? The code itself is just an interchange format, no different than JSON. Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level? AI-text generation makes it faster to write text, but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually. And the LLMs are going to be better working at that level also.
I really wish the people geeking out over LLMs would be geeking out over radical new foundational ideas instead. Picture Bret Victor-style re-imaginings of the whole programming experience. (I have loads of ideas myself which I've been trying to find some angle of attack for.) Hard work at improving the world looks like finding radically new approaches to problems, and there are loads of ways to make the world a better place that are being distracted from by the short-term view of working entirely in the existing paradigm.