291–300 of 337 posts
And therein is the problem most perfectly expressed. He prompted that all the data should be real and validated and then simply trusted that it was. That was for a data driven project. People will do that for countless things, even critical things.
Earlier quoted context omitted.
> I haven’t used Fable/Mythos yet, but my experience with recent version of Opus, GPT 5.5 and recent Chinese models is that promoting again isn’t guaranteed to fix the underlying issues, nor is it guaranteed to not introduce more issues. That's not really the point though. That presumes models are only useful if they are one-shot models. That is false. I mean, what if your prompt successfully changes 20 source files…
> That presumes models are only useful if they are one-shot models That’s not at all what I’m saying. I’m saying that in my experience across multiple models, the follow up prompts don’t fix prior underlying issues. They usually patch on top instead, unless you give them significant and time consuming guidance. I want them to be more useful outside of one-shot uses, but I find that they currently miss the mark.
That's not my experience at all, and I have been using models that are far from being cutting edge. Even in the cases where a model generates utter nonsense, a couple of clarifying questions is all it takes to get it back on track.
But that might be a factor of the project being worked on, and the extension of the changes being asked.
Earlier quoted context omitted.
Isn't it common to refer to all software like that? "Let my look at my JIRA", "I can't find anything using my Outlook's search function", "My Powerpoint is acting up today", "My browser just crashed" are all sentences I might say during a normal work day
better than "The JIRA" , or "The Google" or "The Spotify"
Earlier quoted context omitted.
You don't need LLM for that. You make _all_ projects low-stakes by working on green field project using (insert buzzword soup of the day) and leaving for a new green field opportunity (that requires experience with buzzword soup of the day) before the project ships.
In the LLM world you never get a chance to get paid to work on those greenfield projects because the person with the idea is churning the prototyping and discovery work themselves. If you want to get paid to work on software, you get involved after its found success and the stakes get higher. (Which assumes there are still significant areas where economies of scale reward that vs everybody just having their own DIY v…
Earlier quoted context omitted.
The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. The only way I see AI coding working in the long run is if we go back to a Water…
> The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. That's so far been called software development. All software developed by peop…
This is what he built: https://isochronic-passage-chart.netlify.app/ Doesn’t work too well on mobile but looks interesting
Earlier quoted context omitted.
The point is, if road engineers changed their process and materials, and to you it felt like driving on the same road, with the same wear and tear and potholes, you wouldn't even notice. If AIs can generate code that looks ridiculous to humans but over time has the correct performance, the correct behaviour, no-one outside of software engineers will know or care.
> The point is, if road engineers changed their process and materials, They do those in labs, and then studies are made to prove that it can replace the current composition. They do not invent those on the spot and let the drivers QA the road. > If AIs can generate code that looks ridiculous to humans but over time has the correct performance, the correct behaviour It’s on you to prove that this big “if” can be reali…
Not really. This is a discussion about what code looks like if AI can write applications that are as good, stable, correct as humans.
I think they can, better than most programmers at the moment, with the correct guardrails and supervision. But in time, I think we may not need to review the code at all, but instead verify correctness and performance only. The AI can write the code however it likes.
Obviously I don't have a proof for this, but based on the progress I've seen so far, if someone forced me to bet one way or the other, this is what I'd bet on.
Earlier quoted context omitted.
I think a lot of us have stopped talking to each other about this. I see it the other way round to you. I see constant scepticism and doubt that LLMs can build anything useful, and whenever provided with examples, the goalposts just move. And at my own firm, I think every developer is generating most of their code using agentic coding. We're still sceptical enough that we are doing the usual heavy handed human review…
> I see constant scepticism and doubt that LLMs can build anything useful, and whenever provided with examples, the goalposts just move. > I see people telling us that they cannot write decent production code, and this is just wrong. At least for me, that has never been the counterpoint that I’ve been making. I’ve never cared about code itself, especially with languages like Java and Kotlin, where you basically autoc…
We're not at the stage to measure yet. We may be behind others, not sure. Actually, this isn't quite true. I was interested, so a created an ad-hoc report (with AI) on PRs landed per week over time. This has gone up over the last 6 momths. But that is hard to say why that is. It might just be people are raising smaller PRs because it becomes easy to have the AI split things up, while before, people were too lazy to do this.
Our bottleneck is still that we want humans to review. Sometimes we spot errors, but our pre-existing testing frameworks are very robust already, so if these pass, we're very confident to release to production, and the agent is excellent at understanding the existing testing frameworks and adding to them for new stuff.
So in our team, we don't often see blatant logic errors. It is mostly to do with things like using a pattern that is used elsewhere in the codebase (or not at all) and doesn't belong in our specific section of the code (we have a large monorepo). These become fewer as we enhance our ruleset (AGENTS.md or CLAUDE.md) for our particular developers.
Earlier quoted context omitted.
The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. The only way I see AI coding working in the long run is if we go back to a Water…
> The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. That's so far been called software development. All software developed by peop…
And that’s pretty much where you are wrong. Take any long running open source project and you can see the craftsmanship that goes into it. It may not be perfect, but hacks are clearly marked as such.
Earlier quoted context omitted.
The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. The only way I see AI coding working in the long run is if we go back to a Water…
> The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed. That's so far been called software development. All software developed by peop…
The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade.
Your LLM, with its higher throughput, may put you in that game breaking situation next week.