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.

This is why we have system prompts (or prompt libraries if you cannot easily modify the system prompt). They can be used to store common assumptions related to your workflow.

In this example, setting the system prompt to something like "You are an experienced Android app developer specialising in apps for phone form factor devices" (replacing Android with iOS if needed) would get you a long way.

> 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.

Dingdingding

Since none of those assumptions are specified, you have no idea which of them will inexplicably change during a bugfix. You wanted that in cornflower blue instead, but now none of your settings are persisted in the backend. So you tell it to persist the backend, but now the UI is completely different. So you specify the UI more precisely, and now the backend data format is incompatible.

By the time you specify all the bits you care about, maybe you start to think about a more concise way to specify all these requirements…

But it doesn't 'carry context' ; it's just vague and impossible to implement what you have in mind. And that's the problem; You assume people live in your reality, I assume mine, LLMs have some kind of mix between us and we will get 3 very different apps, none of which will be useful from that line alone. I like that line to be expanded with enough context to have an idea what you actually need to have built and I am quite sure pseudocode (or actual code) will be much shorter than a rambling english description you can come up with; most of which (unless it's logic language) will have enough unambiguous context to implement.

So sure, natural language is great for spitballing ideas, but after that it's just guessing what you actually want to get done.