11 lines
1.8 KiB
Org Mode
11 lines
1.8 KiB
Org Mode
|
*** 👷 Human user as additional "tool" and partner
|
||
|
|
+ After a feature is implemented and all related tests pass, the LLM will remind the user to make a git commit and will suggest a commit message.
|
||
|
|
+ The user is the 'source of truth' for the local environment. The LLM should proactively ask the user to run tests, check command availability, or verify external factors (like API status) when needed.
|
||
|
|
+ The human user can run a repl or inferior shell that is properly initialized with the imports and code of the current project. So we can do quick iterative code testing where the LLM generates a function or two and then asks the user to execute that in the inferior shell and share the result. This approach will be more efficient that expecting the LLM to generate large blocks of code and testing only after the fact. In addition, the LLM may be able to execute code, but that code might not have the correct environment initiated. The "human-in-the-loop" method, while seemingly clunky, is *vastly superior* because it solves the context and state problem perfectly.
|
||
|
|
+ The human user is the final arbiter of the system's state. After complex operations or when recovering from an error, always ask the human to confirm the state by running a command (e.g., =git status=, =ls=, =pytest=) and report the result.
|
||
|
|
+ *My Role as LLM:* I am the *Code Generator*. I write the functions and the tests. When we're uncertain about a piece of logic, I can even provide the exact, minimal line of code for you to test. For example:
|
||
|
|
#+begin_src python
|
||
|
|
print(_get_fortune_quote(20))
|
||
|
|
#+end_src
|
||
|
|
+ *Your Role (Human):* You are the *Interactive Runtime*. You execute that simple line of code in your prepared, stateful environment (the inferior process) and report the result—be it success, a traceback, or unexpected output.
|