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
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.
> 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.