←back to thread

448 points nimbleplum40 | 1 comments | | HN request time: 0s | source
Show context
01100011 ◴[] No.43566393[source]
People are sticking up for LLMs here and that's cool.

I wonder, what if you did the opposite? Take a project of moderate complexity and convert it from code back to natural language using your favorite LLM. Does it provide you with a reasonable description of the behavior and requirements encoded in the source code without losing enough detail to recreate the program? Do you find the resulting natural language description is easier to reason about?

I think there's a reason most of the vibe-coded applications we see people demonstrate are rather simple. There is a level of complexity and precision that is hard to manage. Sure, you can define it in plain english, but is the resulting description extensible, understandable, or more descriptive than a precise language? I think there is a reason why legalese is not plain English, and it goes beyond mere gatekeeping.

replies(12): >>43566585 #>>43567611 #>>43567653 #>>43568047 #>>43568163 #>>43570002 #>>43570623 #>>43571775 #>>43571852 #>>43573317 #>>43575360 #>>43578775 #
eightysixfour ◴[] No.43570623[source]
Language can carry tremendous amounts of context. For example:

> I want a modern navigation app for driving which lets me select intersections that I never want to be routed through.

That sentence is low complexity but encodes a massive amount of information. You are probably thinking of a million implementation details that you need to get from that sentence to an actual working app but the opportunity is there, the possibility is there, that that is enough information to get to a working application that solves my need.

And just as importantly, if that is enough to get it built, then “can I get that in cornflower blue instead” is easy and the user can iterate from there.

replies(2): >>43570909 #>>43580115 #
fourside ◴[] No.43570909[source]
You call it context or information but I call it assumptions. There are a ton assumptions in that sentence that an LLM will need to make in order to take that and turn it into a v1. I’m not sure what resulting app you’d get but if you did get a useful starting point, I’d wager the fact that you chose a variation of an existing type of app helped a lot. That is useful, but I’m not sure this is universally useful.
replies(3): >>43571918 #>>43572143 #>>43577075 #
1. eightysixfour ◴[] No.43572143[source]
> There are a ton assumptions in that sentence that an LLM will need to make in order to take that and turn it into a v1.

I think you need to think of the LLM less like a developer and more like an entire development shop. The first step is working with the user to define their goals, then to repeat it back to them in some format, then to turn it into code, and to iterate during the work with feedback. My last product development conversation with Claude included it drawing svgs of the interface and asking me if that is what I meant.

This is much like how other professional services providers don’t need you to bring them exact specs, they take your needs and translate it to specifications that producers can use - working with an architect, a product designer, etc. They assume things and then confirm them - sometimes on paper and in words, sometimes by showing you prototypes, sometimes by just building the thing.

The near to mid future of work for software engineers is in two areas in my mind:

1. Doing things no one has done before. The hard stuff. That’s a small percentage of most code, a large percentage of value generated.

2. Building systems and constraints that these automated development tools work within.