Comment by skydhash
It can only be automated if the only thing you care about is having the code/text, and not making sure they are correct.
> Given this code, extract all entities and create the database schema from these
Sometimes, the best representation for storing and loading data is not the best for manipulating it and vice-versa. Directly mapping code entities to database relations (assuming it's SQL) is a sure way to land yourself in trouble later.
> write documentation for these methods
The intent of documentation is to explain how to use something and the multiple why's behind an implementation. What is there can be done using a symbol explorer. Repeating what is obvious from the name of the function is not helpful. And hallucinating something that is not there is harmful.
> write test examples
Again the type of tests matters more than the amount. So unless you're sure that the test is correct and the test suite really ensure that the code is viable, it's all for naught.
...
Your use cases assume that the output is correct. And as the hallucination risk from LLM models is non-zero, such assumption is harmful.
Well, of course I check the output and correct it as needed. It is still much faster than writing it myself. And less boring.
As for the documentation part — I infer that you hadn't used state of the art models, had you? They do not write symbol docs mechanistically. They understand what the code is _doing_. Up to their context limits, which are now 128k for most models. Feed them 128k of code and more often than not it will understand what it is about. In seconds (compared to hours for humans).