5 ms·

Why "just prompt better" doesn't work

60 points by jinkuan 8mo ago

0xbadcafebee 8mo ago
In summary, the user research we have conducted thus far uncovered the central tension that underlies the use of coding assistants: 1. Most technical constraints require cross-functional alignment, but communicating them during stakeholder meetings is challenging due to context gap and cognitive load 2. Code generation cannibalizes the implementation phase where additional constraints were previously caught, shifting the burden of discovery to code review — where it’s even harder and more expensive to resolve How to get around this conundrum? The context problem must be addressed at its inception: during product meetings, where there is cross-functional presence and different ideas can be entertained without rework cost. If AI handles the implementation, then the planning phase has to absorb the discovery work that manual implementation used to provide. They're emphasizing one thing too much and another not enough. First, the communication problem. Either the humans are getting the right information and communicating it, or they aren't. The AI has nothing to do with this; it's not preventing communication at all. If anything, it will now demand more of it, which is good. Second, the "implementation feedback". Yes, 'additional constraints' were previously encountered by developers trying to implement asinine asks, and would force them to go back and ask for more feedback. But now the AI goes ahead and implements crap. And this is perfectly fine, because after it churns out the software in a day rather than a week, anyone who tries to use the software will see the problem, and then go back and ask for more detail. AI is making the old feedback loop faster. It's just not at implementation-time anymore.
- noduerme 8mo ago
  Well, that or it's taking a situation where the client didn't understand the software but the dev did, and turning it into a situation where no one understands what anyone's babbling about at a meeting. How do you explain the constraints to the stakeholders if you didn't try to solve them yourself and you don't fully understand why they are constraints? [edit] Just to add to this thought: It might be more useful to do the initial exploratory work oneself, to find out what's involved in fulfilling a request and where the constraints are, and then ask an AI to summarize that for a client along with an estimate of the work involved. Because to me, the pain point in those meetings is getting mired in explaining technical details about asynchronous operational/code processes or things like that, trying to convey the trade-offs involved.
noduerme 8mo ago
I found this interesting: >> Small decisions have to be made by design/eng based on discovery of product constraints, but communicating this to stakeholders is hard and time consuming and often doesn’t work. This implies that a great deal of extraneous work and headaches result from the stakeholders not having a clear mental model of what they need software to do, versus what is either secondary or could be disposed of with minor tweaks to some operational flow, usage guidance, or terms of service document. In my experience: Even more valuable than having my own mental model of a large piece of software, is having an interlocutor representing the stakeholders and end users, who understands the business model completely and has the authority to say: (A) We absolutely need to remove this constraint, or (B) If this is going to cost an extra 40 hours of coding, maybe we can find a workflow on our side thet gets around it - or find a shortcut, and shelve this for now so you can move on with the rest of the project. Clients usually have a poor understanding of where constraints are and why some seemingly easy problems are very hard, or why some problems that seem hard to them are actually quite easy. I find that giving them a clear idea of the effort involved in each part of fulfilling a request often leads to me talking to someone directly who can make a call as to whether it's actually necessary.
- colechristensen 8mo ago
  It's almost always more productive for stakeholders to argue about the current solution that exists rather than the hypothetical one you're going to build.
  - ozim 8mo ago
    I agree but there are downsides like shallow feedback. There still going to be loads of explanation because „just a button” can have loads of stuff behind it like staring whole processing pipeline that is not visible for non tech people.
- bitwize 8mo ago
  Such an interlocutor was historically known as the systems analyst, but historically we've put programmers in that position, where they tend to do poorly. https://www.linkedin.com/pulse/tail-wagging-dog-tim-bryce/ https://www.linkedin.com/pulse/tail-wagging-dog-tim-bryce/ Systems analysis is about to make a roaring return, as the need for human programmers wanes thanks to LLMs generating all the code.
charcircuit 8mo ago
>it’s that it can’t refuse to write bad ones It can. It totally is able to refuse and then give me options for how it thinks it should do something.
- refactor_master 8mo ago
  I think it's meant to be taken more in the abstract. Yes, LLM can refuse your request, and yes you can ask it to prepend "have you checked that it already exists?", but it can't directly challenge your super long-range assumptions the same way as another person saying at the standup "this unrelated feature already does something similar, so maybe you can modify it to accomplish both the original goal and your goal", or they might say "we have this feature coming up, which will solve your goal". Without proper alignment you're just churning out duplicate code at a faster rate now.
siriusastrebe 8mo ago
Can this be solved by a question answer session? You ask the coding assistant for a brand new feature. The coding assistant says, we have two or three or four different paths we could go about doing it. Maybe the coding assistant can recommend a specific one. Once you pick the option, the coding assistant can ask more specific questions. The database looks like this right now, should we modify this table which would be the simplest solution, or create a new one? If you will in the future want a many-to-one relationship for this component, we should create a new table and reference it via a join table. Which approach do you prefer? What about the frontend, we can surface controls for this in on our existing pages, however for reasons x, y, and z I'd recommend creating a new page for the CRUD operations on this new feature. Which would you prefer? Now that we've gotten the big questions squared away, do you want to proceed with code generation, or would you like to dig deeper into either the backend or the frontend implementation?
- jaggederest 8mo ago
  You're describing existing behavior of codex and claude at the moment, for what it's worth. They don't always catch every edge case (or even most) in depth or discuss things thoroughly, depending on the prompt, but if you say "ask questions and be sure to clarify any ambiguity or technical issues" they'll run right through many of the outstanding concerns.
  - Foobar8568 8mo ago
    And neither will really code to the "Spec". They will miss a few requirements even for a spec that is less long than your screen. Codex seems to be more thorough for it, but needs a lot of baby sitting, Claude will be happy to tell you he is done while missing half of them but will implement through the stack. Tests will be generally crap for both of them. So while I am happy to have those, it doesn't replace development knowledge. Claude will be happy to kill security features to make it works.
- wmeredith 8mo ago
  This is how I use Cursor IDE with its Planning mode.
deleted 8mo ago
[deleted]
lemax 8mo ago
I've tried all the Q&A skills, confidence meters and little hacks to get agents to clarify and propose better solutions. Clarification and planning has gotten a lot better using some skills (e.g. obra/superpowers), but counterproposals and negative feedback are rarely up to snuff with something a staff level colleague would come up with - this seems to be amplified when you already have an extensive PRD or plan together. If a plan is already fleshed out but is inefficient or contains some anti-patterns, I've had better results just throwing these out, taking what I've learned and summarizing tradeoffs in a brand new chat. Once you have a comprehensive plan together, or a fairly full context window, agents have a lot of issues zooming out. This is particularly painful in some coding agents since they're loading your existing code into context and get weighted down heavily by what already exists (which makes them good at other tasks) vs. what may be significantly simpler and better for net-new stuff or areas of your codebase that are more nascent.
PeterStuer 8mo ago
One could counter with "Why 'just meet better' doesn't work". ('stakeholders' aren't realy, they are not comfortable with the required level of detail, lack both in depth business domain, operational domain and technical domain knowledge, bikeshedding fiestas masking incompetence, ...) So if the AI can surface misunderstandings through fast prototyping, this can cut trough lots of meeting BS. In practice, the truth is somewhere in the middle as always.
- jinkuan 8mo ago
  valuable angle to consider, thank you for the comment
Havoc 8mo ago
For me as a hobby programmer that part - scoping, identifying pain points and planning - actually got massively better with coding agents. Previously: send it and figure out issues in they fly Now: write a half page description and ask the LLM to figure out what info is missing from my document to implement That’s absolutely not the same as the team dynamics but in principle it seems to me that LLMs can do work that is directionally “here is a target state” and project manage towards that
incomingpain 8mo ago
AI is like a genie, but instead of three wishes, it gives you 10,000 lines of code that fulfill your prompt exactly while accidentally summoning a demon in your production environment. edit/ The real danger of AI is that it's eager to build exactly what we asked for, even though it's an architecture disaster.
- grim_io 8mo ago
  That just means I've asked it to build a disaster without knowing it. Now instead of me slowly implementing the disaster, I can fix the design and go into the next iteration with a clearer picture in mind.
Eggpants 8mo ago
After Claude failing to fix a bug after 4 attempts, I wrote this prompt and sure enough the bug was fixed. lol. > no it still doesn't work. Do I have to let OpenAI fix this or can you handle it? I can definitely handle this. Let me try a completely different approach - …
thunderbong 8mo ago
For me this was telling - > Coding agents are designed to be accommodating, it doesn’t push back against prompts since it neither has the authority nor the context to do so. It may ask for clarifications upon what was specified, but it won’t say “wait, have you considered doing X instead?” A human developer would, or at least, they’d raise a flag. An LLM produces plausible output and moves on. > This trait may be desirable as a virtual assistant, but it makes for a bad engineering teammate. The willingness to engage in productive conflict is part and parcel to good engineering: it helps broaden the search in the design space of ideas. Whenever non-technical people ask me about LLMs, I tell them this - The goal of an LLM is not to give you correct answers. The goal of an LLM is to continue the conversation.
- cadamsdotcom 8mo ago
  > The goal of an LLM is to continue the conversation. It’s even simpler. The goal of an LLM is to generate the next token. That’s reductive but worth considering. An LLM doesn’t have inherent goals and you aren’t privy to how it was post-trained or what on, so you can’t assume it’ll behave in any particular way.
geldedus 8mo ago
"just use better tools" works, though

60 points by jinkuan 8mo ago

In summary, the user research we have conducted thus far uncovered the central tension that underlies the use of coding assistants: 1. Most technical constraints require cross-functional alignment, but communicating them during stakeholder meetings is challenging due to context gap and cognitive load 2. Code generation cannibalizes the implementation phase where additional constraints were previously caught, shifting the burden of discovery to code review — where it’s even harder and more expensive to resolve How to get around this conundrum? The context problem must be addressed at its inception: during product meetings, where there is cross-functional presence and different ideas can be entertained without rework cost. If AI handles the implementation, then the planning phase has to absorb the discovery work that manual implementation used to provide. They're emphasizing one thing too much and another not enough. First, the communication problem. Either the humans are getting the right information and communicating it, or they aren't. The AI has nothing to do with this; it's not preventing communication at all. If anything, it will now demand more of it, which is good. Second, the "implementation feedback". Yes, 'additional constraints' were previously encountered by developers trying to implement asinine asks, and would force them to go back and ask for more feedback. But now the AI goes ahead and implements crap. And this is perfectly fine, because after it churns out the software in a day rather than a week, anyone who tries to use the software will see the problem, and then go back and ask for more detail. AI is making the old feedback loop faster. It's just not at implementation-time anymore.

noduerme 8mo ago
Well, that or it's taking a situation where the client didn't understand the software but the dev did, and turning it into a situation where no one understands what anyone's babbling about at a meeting. How do you explain the constraints to the stakeholders if you didn't try to solve them yourself and you don't fully understand why they are constraints? [edit] Just to add to this thought: It might be more useful to do the initial exploratory work oneself, to find out what's involved in fulfilling a request and where the constraints are, and then ask an AI to summarize that for a client along with an estimate of the work involved. Because to me, the pain point in those meetings is getting mired in explaining technical details about asynchronous operational/code processes or things like that, trying to convey the trade-offs involved.

noduerme 8mo ago

I found this interesting: >> Small decisions have to be made by design/eng based on discovery of product constraints, but communicating this to stakeholders is hard and time consuming and often doesn’t work. This implies that a great deal of extraneous work and headaches result from the stakeholders not having a clear mental model of what they need software to do, versus what is either secondary or could be disposed of with minor tweaks to some operational flow, usage guidance, or terms of service document. In my experience: Even more valuable than having my own mental model of a large piece of software, is having an interlocutor representing the stakeholders and end users, who understands the business model completely and has the authority to say: (A) We absolutely need to remove this constraint, or (B) If this is going to cost an extra 40 hours of coding, maybe we can find a workflow on our side thet gets around it - or find a shortcut, and shelve this for now so you can move on with the rest of the project. Clients usually have a poor understanding of where constraints are and why some seemingly easy problems are very hard, or why some problems that seem hard to them are actually quite easy. I find that giving them a clear idea of the effort involved in each part of fulfilling a request often leads to me talking to someone directly who can make a call as to whether it's actually necessary.

colechristensen 8mo ago
It's almost always more productive for stakeholders to argue about the current solution that exists rather than the hypothetical one you're going to build.
- ozim 8mo ago
  I agree but there are downsides like shallow feedback. There still going to be loads of explanation because „just a button” can have loads of stuff behind it like staring whole processing pipeline that is not visible for non tech people.
bitwize 8mo ago
Such an interlocutor was historically known as the systems analyst, but historically we've put programmers in that position, where they tend to do poorly. https://www.linkedin.com/pulse/tail-wagging-dog-tim-bryce/ https://www.linkedin.com/pulse/tail-wagging-dog-tim-bryce/ Systems analysis is about to make a roaring return, as the need for human programmers wanes thanks to LLMs generating all the code.

charcircuit 8mo ago

>it’s that it can’t refuse to write bad ones It can. It totally is able to refuse and then give me options for how it thinks it should do something.

refactor_master 8mo ago
I think it's meant to be taken more in the abstract. Yes, LLM can refuse your request, and yes you can ask it to prepend "have you checked that it already exists?", but it can't directly challenge your super long-range assumptions the same way as another person saying at the standup "this unrelated feature already does something similar, so maybe you can modify it to accomplish both the original goal and your goal", or they might say "we have this feature coming up, which will solve your goal". Without proper alignment you're just churning out duplicate code at a faster rate now.

siriusastrebe 8mo ago

Can this be solved by a question answer session? You ask the coding assistant for a brand new feature. The coding assistant says, we have two or three or four different paths we could go about doing it. Maybe the coding assistant can recommend a specific one. Once you pick the option, the coding assistant can ask more specific questions. The database looks like this right now, should we modify this table which would be the simplest solution, or create a new one? If you will in the future want a many-to-one relationship for this component, we should create a new table and reference it via a join table. Which approach do you prefer? What about the frontend, we can surface controls for this in on our existing pages, however for reasons x, y, and z I'd recommend creating a new page for the CRUD operations on this new feature. Which would you prefer? Now that we've gotten the big questions squared away, do you want to proceed with code generation, or would you like to dig deeper into either the backend or the frontend implementation?

jaggederest 8mo ago
You're describing existing behavior of codex and claude at the moment, for what it's worth. They don't always catch every edge case (or even most) in depth or discuss things thoroughly, depending on the prompt, but if you say "ask questions and be sure to clarify any ambiguity or technical issues" they'll run right through many of the outstanding concerns.
- Foobar8568 8mo ago
  And neither will really code to the "Spec". They will miss a few requirements even for a spec that is less long than your screen. Codex seems to be more thorough for it, but needs a lot of baby sitting, Claude will be happy to tell you he is done while missing half of them but will implement through the stack. Tests will be generally crap for both of them. So while I am happy to have those, it doesn't replace development knowledge. Claude will be happy to kill security features to make it works.
wmeredith 8mo ago
This is how I use Cursor IDE with its Planning mode.

deleted 8mo ago

[deleted]

lemax 8mo ago

I've tried all the Q&A skills, confidence meters and little hacks to get agents to clarify and propose better solutions. Clarification and planning has gotten a lot better using some skills (e.g. obra/superpowers), but counterproposals and negative feedback are rarely up to snuff with something a staff level colleague would come up with - this seems to be amplified when you already have an extensive PRD or plan together. If a plan is already fleshed out but is inefficient or contains some anti-patterns, I've had better results just throwing these out, taking what I've learned and summarizing tradeoffs in a brand new chat. Once you have a comprehensive plan together, or a fairly full context window, agents have a lot of issues zooming out. This is particularly painful in some coding agents since they're loading your existing code into context and get weighted down heavily by what already exists (which makes them good at other tasks) vs. what may be significantly simpler and better for net-new stuff or areas of your codebase that are more nascent.

PeterStuer 8mo ago

One could counter with "Why 'just meet better' doesn't work". ('stakeholders' aren't realy, they are not comfortable with the required level of detail, lack both in depth business domain, operational domain and technical domain knowledge, bikeshedding fiestas masking incompetence, ...) So if the AI can surface misunderstandings through fast prototyping, this can cut trough lots of meeting BS. In practice, the truth is somewhere in the middle as always.

jinkuan 8mo ago
valuable angle to consider, thank you for the comment

Havoc 8mo ago

For me as a hobby programmer that part - scoping, identifying pain points and planning - actually got massively better with coding agents. Previously: send it and figure out issues in they fly Now: write a half page description and ask the LLM to figure out what info is missing from my document to implement That’s absolutely not the same as the team dynamics but in principle it seems to me that LLMs can do work that is directionally “here is a target state” and project manage towards that

incomingpain 8mo ago

AI is like a genie, but instead of three wishes, it gives you 10,000 lines of code that fulfill your prompt exactly while accidentally summoning a demon in your production environment. edit/ The real danger of AI is that it's eager to build exactly what we asked for, even though it's an architecture disaster.

grim_io 8mo ago
That just means I've asked it to build a disaster without knowing it. Now instead of me slowly implementing the disaster, I can fix the design and go into the next iteration with a clearer picture in mind.

Eggpants 8mo ago

After Claude failing to fix a bug after 4 attempts, I wrote this prompt and sure enough the bug was fixed. lol. > no it still doesn't work. Do I have to let OpenAI fix this or can you handle it? I can definitely handle this. Let me try a completely different approach - …

thunderbong 8mo ago

For me this was telling - > Coding agents are designed to be accommodating, it doesn’t push back against prompts since it neither has the authority nor the context to do so. It may ask for clarifications upon what was specified, but it won’t say “wait, have you considered doing X instead?” A human developer would, or at least, they’d raise a flag. An LLM produces plausible output and moves on. > This trait may be desirable as a virtual assistant, but it makes for a bad engineering teammate. The willingness to engage in productive conflict is part and parcel to good engineering: it helps broaden the search in the design space of ideas. Whenever non-technical people ask me about LLMs, I tell them this - The goal of an LLM is not to give you correct answers. The goal of an LLM is to continue the conversation.

cadamsdotcom 8mo ago
> The goal of an LLM is to continue the conversation. It’s even simpler. The goal of an LLM is to generate the next token. That’s reductive but worth considering. An LLM doesn’t have inherent goals and you aren’t privy to how it was post-trained or what on, so you can’t assume it’ll behave in any particular way.

geldedus 8mo ago

"just use better tools" works, though