This is going to be the norm across the board as the models have failed to live up to the hype.

I do think LLMs and agents and all are great at helping you through tough problems but we aren’t there yet on getting them to do all the work while we just architect and design. Again, it’s close, and for your use cases you might be there already but for low level and big corporate lift and shifts, it’s not there yet.

I have agents, agents of agents, and I still find myself having to carve big chunks of my project off and feed it to the dogs because it’s garbage code. (GLM-5.2)

▲

K0balt 3 hours ago | parent [-]

Documentation driven development is your friend here. 75% of my workflow is generating documentation, at ever lower levels of abstraction, until it’s just code. The code usually comes out optimal, clean, and bug free (after passing tests) and. Suuuuuper well documented lol.

It’s human in the loop over and over again tho

▲

KronisLV 3 hours ago | parent | next [-]

> 75% of my workflow is generating documentation, at ever lower levels of abstraction, until it’s just code

Some might hate that writing code (which they enjoy) is turning into that, others might doubt the efficacy of doing that and the claims about it working so well.

Personally, I’d say that docs help as long as they’re meaningful and not too long (even AI tools have limited context), but you probably also want to codify what you can into code.

For example I wrote a tool in Go and goja called ProjectLint (not public yet but anyone can do that in a week) where you write custom rules in regular ECMAScript that can check whatever you want - code conventions across languages, project structure and architecture and all the stuff that goes under “In this project, we do X but don’t do Y” that just telling an LLM about (or colleagues) will be worth nothing (even memories and focus are limited), instead CI gates that.

I guess I reinvented a simplified and stack-agnostic version of ArchUnit but whatever, it works for me and I can use the same tool in Python and Java projects and elsewhere as well as parallelize all the read only checks and run sequentially the potential-write ones that might auto-fix stuff.

	▲	K0balt 2 hours ago \| parent [-]
		I’m sure it depends on the project, stack, and dev. I know loc is a terrible metric, but … For me, my human only productivity in the firmware work I do is usually around 100-500 loc a day on good days. Obviously more when clean-slating the initial work on a project , but that’s typically a day or two and the same ratios apply. With ai tools, I roughly 4x that with the same effort, or 2x it working lazily from my phone playing with my 2 year old. The code is typically also more compact so the LOC metric is strong here IMHO. Overall I have about the same number of bad-unproductive days, far less bugs (but worse bug hunts) and 10x better documentation lol. Coding is definitely a different job though.

▲

ufmace 2 hours ago | parent | prev [-]

I tend to feel like, I start out with a rough idea of a program I want to write in my head. I find it easier to just write the code directly than to write a document with sufficient detail about how I want it to work for an LLM to actually write the right code, then have the LLM write the code. And the resulting documentation is about as likely to be useless or a burden as it is to be helpful in the future.

	▲	K0balt 2 hours ago \| parent [-]
		You don’t write the doc. You talk to the LLM about the idea and the anchor points, and have it write the doc.