| ▲ | rimeice 2 hours ago |
| > "Adding agents to a project with unclear requirements gets you the wrong answer faster." The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements. |
|
| ▲ | Fordec an hour ago | parent | next [-] |
| What's easier to use as inspiration for coming up with a list of requirements?: 1. A blank sheet of paper 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways? |
| |
| ▲ | ben_w 22 minutes ago | parent | next [-] | | > 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways? Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages. That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem. | | |
| ▲ | tarsinge 3 minutes ago | parent [-] | | It goes beyond this, the job is to understand the underlying need. When a clients asks for a button to be bigger, what's in their head is they fear it's not visible enough. Many times the client was happy when I implemented something unrelated but that solved the issue, like changing the colours to increase the contrast between the background and the button, adding space around, etc. so that it pops out more. |
| |
| ▲ | adastra22 28 minutes ago | parent | prev | next [-] | | The latter, clearly? It is far more valuable to have a (badly) working system you can prod and probe than work from fantasy. | |
| ▲ | flyinglizard an hour ago | parent | prev | next [-] | | People are much better than saying what they don’t like than what they do. | | |
| ▲ | bergen 31 minutes ago | parent | next [-] | | Using the "let run multiple agents run amok" approach you surely get a lot of "i don't like that part"-feature requests, yes. In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless. | |
| ▲ | pydry 4 minutes ago | parent | prev [-] | | Theyre also inclined to jump into talking about solutions rather than their actual problem which inhibits analysis of the problem. |
| |
| ▲ | Terr_ an hour ago | parent | prev [-] | | "Oh no problem, I'll just run it again telling the LLM to not do those 20 things, and then we'll have the right answer." /s-mostly | | |
| ▲ | ben_w 15 minutes ago | parent [-] | | It was pretty surprising to me when I realised I could put 5 different bug reports into the same message and it would fix all of them. Not quite as shocking as the original InstructGPT video, but surprising. |
|
|
|
| ▲ | matsemann 27 minutes ago | parent | prev | next [-] |
| Not if you turn off your brain. Never actually stop to question the path you're going down, because the speed is making you blind. Which is what I feel I see more and more. Or how do you even know it's the wrong answer if you didn't think it through before starting? One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it. Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought. |
|
| ▲ | Terr_ an hour ago | parent | prev | next [-] |
| That depends on (A) verification being very low cost and (B) being able to infer the right answer based on wrong ones. Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required. |
| |
| ▲ | ben_w 14 minutes ago | parent [-] | | Good points. This is after all why LLMs are so much better at maths and software than the economy in general. |
|
|
| ▲ | rpunkfu an hour ago | parent | prev | next [-] |
| I was talking about it for a while with colleagues. AI besides other benefits, needs to be treated as great interface for discovery, you have your features baked in, AI uses it via your users and MCP, then you figure out what are actual flows of my users and then you build it |
|
| ▲ | otabdeveloper4 30 minutes ago | parent | prev [-] |
| > erm, Claude, do it again but leave out the bad stuff and make it good this time, mmkay? |
