241–250 of 260 posts
Earlier quoted context omitted.
You missed documentation. There was never time for that until now.
IME LLM docs are worse than useless the majority of the time. It's like most LLM writing, an inscrutable wall of text that simultaneously says nothing and too much at the same time.
> LLMs' increased rate of adoption in 2026 is largely due to them becoming reliable enough to run effectively in automated feedback loops Is that really from improvements in LLMs, or from improvements in the feedback loops?
I've found a variant of the Gell-Mann Amnesia effect with regards to LLM coding. They're really magical if you're not familiar with the language, domain, or frameworks you are trying to use. But if you're familiar with those things then you'll often catch them lying to your face and producing a lot of plausible nonsense.
It used to be terrible for car repair advice, now it's mostly right.
0.25x because I scope bigger now and then I may get a few "free" React components but largely doing all that work of putting it together. Wouldn't trade it though. Feel like I can overall do more with less time and energy. At the end of the day, AI is making me work more (good thing). If you count that as productivity, then sure.
> AI is making me work more (good thing) How is that good?
The work I'm doing is for myself (I'm not GP). But work isn't just "my job for the man." You can build things for your home, your shop, your family, your business if you have one.
Well, it's interesting. I've been using LLM's for coding for over two years. My findings are somewhat consistent: Feed it jobs in small chunks and it can be a great auto-complete, beyond that and it turns into a mess very quickly. I'm two weeks into a project that has been interesting and also has confirmed the above yet again. I am porting a Windows application written in Python to C# using Avalonia UI. I have never…
I don't think it proves that. It proves it doesn't run and visually inspect the program. That's because the harness is lacking, not the llm.
When you do web dev with the thing, you can have it screenshot the browser and it turns out it has no problem understanding things like "buttons should be visible." You just haven't allowed it to look. You yourself admit that a human makes the same mistake, but sees it.
Anyway, have your model build itself a way to take and review screenshots of the app.
This reminds me of themes I recently saw in [Harness Engineering is not Enough: Why Software Factories Fail]( https://www.youtube.com/watch?v=Ib5GBkD555M ) (Warning: the last 3 slides seem like an advertisement). One thing I liked is how Dex has a little graphic he glossed over showing software development is - 25% planning & aligning with other teams - 25% coding - 25% testing/verifying - 25% code review/rework One…
> - 25% planning & aligning with other teams
> - 25% coding
> - 25% testing/verifying
> - 25% code review/rework
[0] https://aws.amazon.com/jp/blogs/devops/ai-driven-development...
I have a weird issue with using AI for coding. I can code something entirely by myself at my baseline speed; call it 1x. Or I can use Claude to do it, and it does it in 1/10 - 1/4 of the time. The problem, however, is that to review Claude’s code properly takes 2-3x the amount of time it would have taken me to write it all by hand. So my two choices are basically “YOLO, LGTM” and hope I can revert if it breaks someth…
You write the feature with one agent, and have different agents do the review, each with their own rules and context. Each review agent can even focus on different things, such as security, or adherence to your stylistic or architectural preferences.
This can find all kinds bugs and edge cases the first agent missed, and that you might never have thought of yourself, even with careful human review.
for me, almost all of the work is specs I am no longer: - reading docs for hours and hours - typing (barely at all) - writing code - manually doing tight debug loops - using an IDE to do this I had to give up reading or even controlling the code and focusing on behavior/design-level control (not superficial, still dictating overall technical architecture) i have agents doing everything from writing the code, verifyin…
> to do this I had to give up reading or even controlling the code and focusing on behavior/design-level control (not superficial, still dictating overall technical architecture) how do you verify the behavior? are you still writing or at least reading tests or just doing manual testing?
interestingly my input is still pretty important
Earlier quoted context omitted.
> AI is making me work more (good thing) How is that good?
I wrote a whole thing and realized the answer is a lot more philosophical. I don't know why working more is good. Maybe its dormant Protestant work ethic still finding a use case in my secular mind