[flagged]
Now, my entire programming flow does not even include an editor. The tools I use are: pi.dev to write and implement openspec specifications, herdr to manage many pi instances, and ollama to run qwen 3.8 27b on my single 7900 XTX.
Writing good specifications is the key detail here. I will often iterate on a spec for hours until I am happy with it all of the details. Once I am happy with the spec, I can be quite confident that when I tell pi to apply the spec, the changes that I want will be done, and done how I want them, when I come back to check when it reports itself as done.
The landscale is fundamentally different from what it was. Feel free to ignore it, but you can absolutely generate high quality code if you know what you're doing.
Installed this recently to try it out.
>pi.dev to write and implement openspec specifications, herdr to manage many pi instances
Thanks for mentioning the tools you're using successfully. It seems like most people using LLMs are keen to keep their cards close to their chest.
But I all but stopped writing code 13 months ago. At the beginning the code was often bad.
In the last 6 months alone I had received more praise from my customers for excellent work than ever before.
They don’t make normal mistakes like typos and they aren’t lazy so things like tests and checking error cases is usually done.
LLM is incredibly valuable for debugging complex problems, codebase exploration, and planning large changes. But the writing code part itself, I find, LLMs are just not very good at it yet.
Vaguely telling the agent what the issue is and what behavior I expect solves the issue with a fraction of the effort.
Some claim that the tech debt only keeps increasing and that the result will be unmaintainable. This is not my experience, and I don't think it is theirs either. These claims are often entirely speculative.
I doubt that any supposed future extra effort for the AI to add new code is remotely comparable to the upfront effort of you reviewing the code manually.
I know that this is the case today for native mobile apps, and I speak from hundreds of hours of experience over the last four months on such a project where I stopped reviewing the code.
We are already here today, and this balance is only going to further shift to the point where it is obvious that the hands-on approach is no longer competitive.
And neither one of those statements is very convincing to me.
Anyway, I think we shared our viewpoints, and neither of us is going to change their mind until either my project fails spectacularly, or you change your approach in the future to use AI more autonomously.
FWIW, I've also had bugs the agent fixed that I probably never would've figured out without LLMs - LLMs are definitely useful! But I need to keep understanding how the code works so I can take over the reigns when the LLM fails.
Without such prompting and a conciseness and clarity pass you get a slop grenade.
They overall work better with tests, and Rust is a great language for them. Overall they do better with lots of walls and alarms that go off if they mess up. I don’t need nearly as much of this, can mentally simulate it, which is a good “are we superintelligence yet” reality check. Still not even as good as my wet meat brain. But impressive given what was possible even two years ago!
The result is still not as clean as a good programmer but it’s better than the slop grenade you get first pass.
GPT 5.6 sol and Astra can now one shot incredible stuff.
The solution required reverse engineering and internals knowledge that most human engineers don't even have.
The question is no longer "Can an LLM write code?". It can. The problem is that certain humans refuse to put in the effort required to properly utilize these tools.
LLMs as things that know what's in the manual are AAA+. Extremely helpful. Very good at making a rough draft of something filled with a lot of stupid mistakes and no new abstractions. That's what your transparent window thing is. Something that you could never ship, is probably too big and doing senseless things for no intelligible reason, and definitely has bizarre bugs.
This application, named Seymore, is being evaluated for purchase by several tech companies. (It helps having good industry contacts)
There was a ton of interesting engineering required to make this work at 60 fps+ without resorting to hacks or using private APIs. Most macOS engineers wouldn't even know where to start.
I've shipped code that is used by billions of people and all you just did was spew a bunch of bullshit. As someone who has built their own LLM from scratch, I have an extremely good idea of what they can and can't do.
If you don't know how to use these tools, you'll end up with crap. If you DO know how to use them, they are incredibly useful.
What they are saying is increasingly difficult to defend, but they will do it anyways. I see the same arguments at my job, and I just gave up arguing against
Some engineering problems (such as designing a performant thread-quantum algorithm) require depth accumulated over years of working on real systems at scale. That is not elitism; it is simply how specialized expertise works. Experience is unevenly distributed, and that matters when evaluating technical claims.
When I say I trust LLM generated code, I mean that in a qualified, engineering sense. I do not treat an LLM as a slot machine: enter a prompt, paste the output, and hope. I use a deliberate workflow for decomposition, prompting, review, testing, validation, and integration. Developing that workflow took substantial time and experimentation.
The useful question is not “Can an LLM write code without oversight?” It obviously cannot, at least not reliably for nontrivial work. The question is whether an experienced engineer can build a process that makes LLM output trustworthy enough for particular classes of work. In my experience, the answer is yes. But the process, judgment, and willingness to do the work are the hard parts.