Egregious #$@%-up

Hello, loves!

Ow! I noticed yesterday that Buzz has partially lost his mind. We’d best fix that right up. Brief LLM-AI insight near the end

Back on the 17th, we gave Buzz the ability to distinguish between the flower he wants, a yellow one, and another flower found in the Dungeon, a pink one. Apparently, I forgot to commit that code at the end of the session. Sometimes I do forget, as I get distracted by summing up, or the prospect of an iced chai, or something. Tiny fool!

We’ll see what is in the repo and in PyCharm history. And I have an advantage that most people do not, which is that most of the code appears in the article. Arrgh. A look at the article source tells me that I wrote that article in the afternoon, and a look at the repo tells me that I didn’t commit anything between 0936 on that date, and 9 AM on the morning of the 19th. Let’s see what’s in that commit. Nothing good, just the two states we now have. We needed three states to get the behavior that is lost.

PyCharm keeps history. Let’s see what it has for us.

Good news! It has history back that far, perhaps even further. PyCharm provides diffs between whatever version you look at and the local. I’ll judiciously push from history back over to current. With a bit of care that should get us close, perhaps even just where we need to be.

I’ve moved over what I think is the right stuff. However, assessing my understanding and confidence, I am sure the code is close to what we need, but I am in no way confident that it is right. Worse yet, we have no useful tests for this object. Even worse, I didn’t go back and try to figure out what tests might have been in there. I am surely a fool for that, and might go back and check history, but first I’m going to run this and see what explodes.

  File "/Users/ron/PycharmProjects/dungeon/src/main.py", line 77, in add_content
    add_bee(factory)
  File "/Users/ron/PycharmProjects/dungeon/src/main.py", line 140, in add_bee
    bee = factory.quest_giver(name="Buzz", quest_item=quest_item, seeking_sentences=seeking_sentences,
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ContentFactory.quest_giver() missing 2 required keyword-only arguments: 'wrong_items' and 'wrong_item_sentences'

Hm, I thought I had done main well enough. I guess not. Back to history. Found the change, moved it in.

  File "/Users/ron/PycharmProjects/dungeon/src/content.py", line 43, in interaction
    elif interactor.has_any(wrong_items):
         ^^^^^^^^^^^^^^^^^^
AttributeError: 'Interactor' object has no attribute 'has_any'

OK, I never checked that. Found, inserted.

  File "/Users/ron/PycharmProjects/dungeon/src/state_machiine.py", line 31, in event
    current_transition.hook(receiver)
  File "/Users/ron/PycharmProjects/dungeon/src/quest_giver_denizen.py", line 39, in _wrong_item_hook
    interactor.announce(next(self.knowledge.wrong_item_sayings))
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'types.SimpleNamespace' object has no attribute 'wrong_item_sayings'

If this process was being done against tests, it would be almost reasonable. SInce I have to run the whole program each time, it is less so. Anyway we can find that, no doubt.

I think this problem is due to a refactoring after the 17th, where I renamed ‘sayings’ to ‘sentences’. No, it’s a missing line, found and inserted and Buzz is running as intended.

Some tests were failing. I think there are more tests for Buzz than I remembered. They’re all running now, but let’s see if perchance I wrote new ones that got lost in the … how shall I put this … grotesque screw-up.

Nope, no redemption there. There’s no test for the wrong sayings. Tests are all green. I’ll play a bit more in the dungeon just to see if I spot anything, but I think we’re good. All seems to be well.

Before I commit this, I’ll review the local against the top commit. Changes look good, only affecting the third state in Buzz. Commit: recover Buzz’s brain, no hope for Ron’s.

Reading the article again, it’s clear that I just decided I was done and walked away. And next time out, I didn’t look to see if I needed a save point. I think I need to make a little sign about this to remind me. I need to improve, in two ways (in this regard only, there are many other ways outside the current frame). I need to check at session end to see whether to commit or (rarely) roll back. And when I begin a session, I need to check the state of the repo to see whether we are on a clean commit.

Summary

I was lucky, in that PyCharm has saved all that history, and that it wasn’t too awful to troll through and find the changes that I needed. Had that not been the case, I would still have had the article to refer to. Had that not been the case, there would be nothing for it but to code the feature again. It might have been a bit tedious, because the QuestGiverDenizen and all its works and all its pomps are rather complicated, but even without the article to refer too, there wasn’t that much to it.

LLM-AI

Note that I reviewed the code, which I myself had written, deciding whether to accept it as part of the feature or not. Note that despite my familiarity with the code and my undoubted if spotty brilliance, I made the wrong decisions, or failed to notice something, at least three times, in less than 100 lines of code.

What does that tell us about our chances of doing effective review of the code an LLM writes for us?

It tells us that we are not capable of doing a good job of that.

So it wouldn’t have been a complete disaster, just an embarrassing mistake among many, and doubtless some ribbing from the rest of the team.

The main lesson here is about my process. I’ll think how best to improve it. See you next time!