Use of LLMs

As LLMs are still relatively new tools in software development, I trust that transparency about their use is important to keep human judgment at the core or programming. The following is a simple statement of fact about my workflow for the projects shown on this website, and my sense of the risks and benefits of using LLMs when programming.

The thinking:

Writing new programs first requires to think about the logic of the problem and the architecture of the solution.

LLMs are very useful there, as they are likely to "know" the solution to many of the common problems already encountered by other programmers.

In the thinking phase, I mostly use LLM to inform myself about the common ways to solve a specific problem in different settings.

This often helps me to identify (or if necessary design) the proper solution architecture for the problem at hand.

The writing:

LLMs are also very useful when writing code, making syntactic errors nearly impossible and streamlining low-level logic.

Letting LLMs write code is also where using LLMs can become dangerous, as that code will actually run on your machine, performing all the (potentially harmful) tasks a computer can do, and making the "programmer" blind to what is really happening (if the programmer doesn't exercise the proper caution).

This is thus where caution (and commonsense !) should most be used. My personal approach when writing code (or Apps) posted on this website is the following:

- In non-critical applications and early prototype phase, I will sometimes let LLMs write code I will not immediately review in the first instance. Just trying to "get something up and running".

- Whenever safety is involved or real understanding necessary (i.e. in nearly any professional-like case) a second pass will be needed to understand what the code does in detail, and make sure it leads to (1) the proper outcome (2) no unwanted side effect. And if necessary hard-code specific behaviors.