Tag: programming

Non-exhaustive list of things I'm doing when I'm writing code, that don't look like "writing code":

• thinking
• researching
• contextualising
• testing
• measuring
• documenting
• communicating
• planning
• future-proofing
• educating
• learning
• expressing
• anticipating
• discovering
• inventing
• experimenting
• debugging
• analysing
• monitoring

For all its faults, an AI agent might "write code" faster than me.

But that's only a part of the process.

My typing speed is not the bottleneck.

Today, an AI review tool used by my workplace reviewed some code that I wrote, and incorrectly claimed that it would introduce a bug because a global variable I created could "be available to multiple browser tabs" (that's not how browser JavaScript works).

Just in case I was mistaken, I explained to the AI why I thought it was wrong, and asked it to explain itself.

To do so, the LLM wrote a PR to propose adding some code to use our application's save mechanism to pass the data back, via the server, and to any other browser tab, thereby creating the problem that it claimed existed.

This isn't even the most-efficient way to create this problem. localStorage would have been better.

So in other words, today I watched an AI:
(a) claim to have discovered a problem (that doesn't exist),
(b) when challenged, attempt to create the problem (that wasn't needed), and
(c) do so in a way that was suboptimal.

Humans aren't perfect. A human could easily make one of these mistakes. Under some circumstances, a human might even have made two of these mistakes. But to make all three? That took an AI.

What's the old saying? "To err is human, but to really foul things up you need a computer."

Highlight of my workday was debugging an issue that turned out to be nothing like what the reporter had diagnosed.

The report suggested that our system was having problems parsing URLs with colons in the pathname, suggesting perhaps an encoding issue. It wasn't until I took a deep dive into the logs that I realised that this was a secondary characteristic of many URLs found in customers' SharePoint installations. And many of those URLs get redirected. And SharePoint often uses relative URLs when it sends redirections. And it turned out that our systems' redirect handler... wasn't correctly handling relative URLs.

It all turned into a hundred line automated test to mock SharePoint and demonstrate the problem... followed by a tiny two-line fix to the actual code. And probably the most-satisfying part of my workday!