So far so good...

The LLM has now created the Document model. The coding was easy; writing this commentary took much longer than writing the code and setting the LLM to work.

The process worked well. So far, it has been a good process, with one caution: make sure you write good tests.

What next?

I plan to build the services, then the controllers, followed by the NLP code that will work out the semantics of the text in a queue. After that, I'll integrate the repositories with Neo4j and build the front end.

Initially, though, the rest of the project will require all the models. I planned to write the classes with empty functions, write the tests, and use a better prompt this time.

I started filling out the Chapter class with empty functions and created an empty Paragraph class. Then I realised that the LLM could create the other classes for me because they were essentially carbon copies.

Similarly, I could get it to create the tests... Hmmm. I said we should not let the LLM create tests, but my prompt would tell it to create the classes using the same ideas as Document and duplicate my tests for the new classes. The tests would be the same as those I created; I would only be asking it to do the duplication.

What follows started as a prompt and then became a design document:

The system of models is a hierarchy of classes as so:
Document has a list of Chapter objects.
Chapter has a list of Paragraph objects.
Paragraph has a list of Sentence objects.
Sentence has a list of Phrase objects.
Phrase has a list of Token objects.

A token is either a word, or punctuation,
or white space, and white space can be any
combination of one or more space, newline, or
tab character.
A Token will be enumerated as either:
- TOKEN_IS_WORD
- TOKEN_IS_PUNCTUATION
- TOKEN_IS_WHITESPACE
and the text of the Token will follow the limitations
imposed by its enumerated type.

A Token does not have a list of any other objects.

So I copied that into a file in the design_documents directory. Then I referenced it in the prompt.

That worked very well. I created an almost empty Token class. Because I was lazy, I then asked it to create the enum class described in the documentation.

Then I created a stub Token class with comments, and wrote the test_token.py and prompted it to fill in the blanks.

This worked very well, took hardly any time, except the time I spent writing up the description of the Token class. I admit that I changed the design of the Token class half-way through and asked the LLM to fix up the documentation and the tests.

Wasn't I saying, "Don't let the LLM write tests"? This is an exception to my rule, I'm not a dictator.