My Programming Job Has Become an Intelligence Buying Job

Someone still has to orchestrate. I read every decision the LMs make and will stop and pause it and test it's assumptions and output. Sure that will occur less and less, and the feedback loop may go up a few levels (I.e. it breaks in production and requires a team of investigators, a code detective, and a techno-theologist, perhaps), but the feedback from the real world (nature vs nurture) will still occur. The laws of thermodynamics and system equilibrium still apply, and the need for those to architect and orchestrate will still be needed.

In the future, I see a small percentage of benevolent system-thinkers, hackers, and architects still at the helm. And, even if 95% of the time they are the guy who feeds the dog that protects us from touching the machines, occasionally nature will force us to convene and tell the machines what to do (or at least bargain with them).

The rest of humanity will go back to the default state: digging potatoes out of the ground in a village of 200 down by the river.

    > …to refactor and improve the quality of a microservice.
    > …
    > It worked. It vastly improved the code base…

That sounds like an amazing learning opportunity!

Would you be up for sharing before refactor and after refactor versions of your experiment in a public repo?

Thanks in advance.

Unfortunately not, it's private company code. But I can share the prompt I used for the refactoring:

  - 1. Read the whole code of the repository.
  - 2. Read the TASKS.md file if it exists.
      - 2.1. If it exists and is not empty, pick a refactoring task from the list. Choose the most appropriate.
          - 2.1.1. Refactor the code according to the task description.
          - 2.1.2. Commit the changes to git.
          - 2.1.3  Remove the task from TASKS.md
          - 2.1.3. You are done.
      - 2.2. If it doesn't exist or is empty:
          - 2.2.1. Identify the parts of the code that could be refactored, following the following principles
              - A class should have a single responsability
              - The dependencies of the class should be mockable and injected at class instanciation
              - Repeated code should be factored into functions
              - Files shouldn't be longer than 1.5K lines
          - 2.2.2: If using the previous insights you think there is valuable refactoring work to be done:
              - 2.2.2.1 Write a list of refactoring tasks in TASKS.md
              - 2.2.2.2: You are done.
          - 2.2.3: If there is no more refactoring to be done, notify me with 'say "I am done with refactoring"'

The TASKS.md file will be created and filled by the model. The prompt needs to be run repeatedly in a loop until it decides there's nothing to be done anymore.

The service was in go, but this doesn't matter.

    > …If you don't measure it, you don't see 
    > it until something breaks in production…
    > …
    > …the slow, silent divergence between
    > what you intended and what actually exists…

What's your take on the absence of any mention of tests in the OP's loop steps?