Please, LLM, You Can Do These Better

So I have now been almost 100 % relying on LLM to generate my codes for the past few months. But there are still some really nasty problems I’ve been meeting using the latest publicly available LLMs and I really don’t think these should really been a problem these day. I mean, given the fact that the LLMs are already solving millennium prize problems. I often find these thing quite ironic and can’t stop to question if these are some intrinsic limitations in the transformer architecture. I am listing here some of the most annoying problems, for fun and for record. After all, I bet it would be really fun looking backs at these words in 10 years.

LLM can’t understand the username is part of a host

So in my daily work. SSH to a remote server and do some work is a very common thing. And nowadays I am handing off the stuff to the LLMs. But ever so often, I find it tends to get stuck in SSH work mysteriously. And after some time. I will see that it’s attempting to install some python env for me. It turns out to be very stupid. It never ssh to the server with the username I gave it! As a result. It’s in my local user name and It of cause can’t accomplish what it’s asked to do. It then will try to “iron it out” on its own by pulling dependencies. The end result of this is: 1. millions of tokens wasted; 2. half an hour has passed by before you realize something really is not going on correctly and the worst: Your remote server’s environment might have been cooked.

LLMs Like to recompile stuff for you

The other day I was working on a performance improvement project. I had to establish baselines and then do some tweaks here and there and recompile, benchmark to see if the changes are actually taking effect. Everything was working smoothly with my agent. But then I realize it was a bit slow overall as for the feature iteration, even compared to the era without any LLM agents. I then took a closer look at how the agent work it out per iteration: It does some changes in-place -> recompile -> copy out the compiled binary after the change -> revert the changes -> recompile the baseline. So as a result. The baseline is recompiled everytime anything is changed in the source code ! How genius !

LLMs like to play it safe

This is now arguably one of the most complained agent’s drawback in my team. Here is a scenario: You asked your agent to change some interface in one of your module. It made the change perfectly. All the test cases pass. All things look perfect. But then you frowned when you would like to merge the PR because the change seems a bit larger than it should’ve been. Then you are off to scan through the whole PR. After a 20 minutes cautious read. You find that in order to make the change, your agent invented a compatibility layer in the modules depending on the original changed module, which also comes with a 200 line unit test. The added compatibility layer also adds 2 macros and 2 environment variables to your system. These stuff can easily happen under the radar and everyone is very happy: System works, ci passes. All looks good. Until one day, your codebase are 10x bigger and becomes a jungle of environment variables you need to be extra careful to wiggle through just to not shoot on your own feet.