rosenfeld

Did I even tried to pretend the article wasn't generated with Claude's help?

I even shared the initial prompt in some comment in this thread. I don't understand what is the matter with also using AI help with generating articles. I still reviewed the article and put all the ideas I wanted to discuss in that article. I don't see why people are often complaining about this. The article content is much more important than how it was generated.

As long as you're working alone, that makes sense. Otherwise, some team will have to review all your refactoring PRs...

The prompt was actually huge, containing all the central ideas of the articles in details. I actually found my first prompt in case you're curious:

---

Human contexts are way more limited compared to computers. We can't reason about complex software when they go through many branches with so many implications. It's just too hard for humans to keep track of all interconnected pieces. So humans have historically split the system parts into manageable modules that can be understood in isolation and then we spend some time connecting those parts. That's how we can keep the context reasonable for human understanding.

So, when senior engineers found themselves lost while trying to debug an issue in a complex system they would naturally decide to pause and rewrite or refactoring the confusing piece of the system to make it manageable so developers can easily understand what's going on and review future changes.

Usually a system doesn't start that confusing. But as requirements change developers add additional branches and code until the code is no longer manageable. Sometimes the requirements changed significantly since the code was first written and all we have in the code are exceptions rather than the rule. That's usually when historically senior developers would take the time to rewrite that part of the system so they can reason about it.

But AI agents are not as limited as humans context-wise and they can reason about those confusing (to humans) systems and make sense of it. So they simply keep adding additional branches to the existing mess without ever suggesting a major refactoring like a senior developer would do in those cases, unless there's specific harness to tell agents to act like that.

This article is about bringing this into attention so that developers can policy themselves and keep asking themselves whether it's time for a major refactoring instead of relying on the AI agents and trust them because they no longer understand the code because it's too complex for humans to follow. Can you draft an article focused on this concern?

Yes, of course, they're limited, but it doesn't compare to the limit humans face. We can't hold a lot of context on our minds when investigating a bug when the code is too complex with huge methods, lots of branches, several callers and so on. It doesn't mean agents are perfect but they don't care as much as humans if the code is a mess because they can find logic in mess, we can't.

But the part that agents don't get lost is actually part of the prompt, not something Opus wrote on its own. Of course they get lost sometimes but the idea of the article is to explain that agents can often make more sense of tangled code than humans when the bounds are not well defined.

I think I used Opus actually. But my prompt was huge, basically the article content. I told Opus what I wanted to approach in the article with all the relevant details I wanted to include and it created the article. Then I reviewed it.

I feel your pain, that's what I've been doing for the past whole week. I'm trying to fix some ancient bugs (there are lots of them in this codebase) but each Claude review detects so many issues that might happen on some rare cases that it takes days until it stops complaining and I can get some peer approval to get the fix merged.

Yes, I've also noticed a few occasions when Claude would get it wrong, but in most cases it's able to find issues I didn't even consider because of a very deep analysis in a confusing (to humans) code. It detects some rare situations where a defect could exist. This happens when I explicitly ask Opus to review a PR and there's some harness around this ability, but I'm really impressed at how deep their analysis can be and correct as well. Of course, sometimes they're going to fail, but I don't see them getting lost often.

Awesome, good to hear that :-)

Fixed or not, PG is awesome anyway. Thanks for helping to make it the best database I've worked with so far :-)

Yes, that could be an option if this was supposed to be a permanent script. However, I was trying very hard to finish the migration of the deals to the new template and the script was quite big and complex. I didn't talk about the script so that I could focus on this specific part that affected it, but the way some people are judging it's like I had put a lot of thoughts in this part of script. It wasn't the case. This was a minor part of the script. I hadn't thought about using nextval() to create the mapping table when I first wrote the script, so it looked like adding a temporary column to store the old id would be the simplest solution for the mapping problem. I had that gut feeling telling me it wasn't the right thing but as long as it worked, for a one-off script, I didn't really care if it allowed me to finish the porting earlier. Writing a trigger would take more time and code than adding a temporary column, just like using nextval() to create the temp table is less work than writing the trigger. Most people seem to ignore that this was a one-off script that won't ever be used again.

I don't actually regret my approach. It allowed me to deliver the first version for testing earlier and I was able to fix the script later in less than an hour once the problem happened. Maybe other parts of the script were not ideal either, but the migration was successful and this is what really matter to me. It would be a completely different situation if I was writing a permanent code. In those cases I write the code way more carefully and give it quite a lot of thoughts on the future implications.

Maybe I failed to explain it well enough, but I certainly do understand the problem pretty well. If you have any questions just ask and I can tell you the reasons to do what I did.

The reason why I had this problem in the first place is that I wasn't aware that dropped columns would still count towards the columns limit in PostgreSQL. It's not a complaint, it's just ignorance. There's a difference between being ignorant and not understanding the problem after it happens. I never claimed to be an expert on PostgreSQL.

As pstuart mentioned, one of the post mortem was to fix the script, which I did by using a temporary table.

The other part was to enable new columns to be added to that table in case we need in the future. For that part, I locked a few tables for writing, recreated them with a separate name and replaced the old with the new one in order to avoid any downtime or dealing with master-slave set-ups to be able to dump and restore without downtimes. Full vacuum freeze wouldn't reclaim that space back.

Hi, I'm the author of that article. Yes, that was the first thing that came to my mind when I noticed the error messages but it wasn't really an option by that point because I could no longer add new columns to that table. I wanted to enable the deals porting as soon as possible and I didn't know yet by that time how to rewrite the table without asking for some maintenance window, so I decided to go with another solution.

If you're curious why I didn't simply create that column permanently in the first place, the reason is that this was supposed to be a one-off script (it would run multiple times but just during the transition to the new template until all deals would have been ported) and I didn't want to pollute the table or have to remember to drop that column in a future time. There are also other reasons why I don't think it would be a good idea. The script was greatly simplified with the assumption that all rows having a value in the previous_id column would be related to that deal being ported. If I want to keep the same simple logic I'd have to make sure the script would delete any values from that column in the beginning of the transaction and I figured that could increase the chance of conflicts in case of concurrent attempts of porting deals and I didn't want to have to bother about concurrency issues so I didn't want to even think about that. With a temporary column I knew I wouldn't have to worry about that.

"Thanks so much for spending time on this amazing patch. We really appreciate it. However I do not think this is something we want to add right now, because of yadda yadda but in the future this can change. Thanks so much!"

This tells us you are a big liar even if they didn't read your post. If a patch is amazing it should be merged, if it's not then it's obviously not amazing. This kind of message is not useful. You should be more explicit in explaining the reasons you are not accepting the patch. If you don't want the feature other contributors won't even try to write it in another way before convincing you to accept the feature. If you like the feature but didn't like the patch this should be stated if you could be kind enough to explain why you didn't like the patch, they (or others) could try other approaches.

Most of the times I get a PR I'm not interested in, my response is something like this:

"I'm not accepting this PR due to [real reason here]. Please, since I value your time and don't want it wasted, before submitting any PR, please open a ticket to discuss it first. That way I can tell you beforehand whether a change is desired or not and the reasons behind this decision and this would save you some time."

This is one of the reasons I decided to stop contributing to Rails long ago. After wasting too much with two patches that got ignored or rejected I decided contributing to Rails didn't worth my time. I often ask about the new feature before working on it. But their usual response was in the line "send us a PR and we can discuss". I feel this is plain wrong because it doesn't respect the contributor's time. They should think about the feature and decide on whether it's desired, acceptable or not. Even though they say they need to take a look at the code to know, this is not true. It's just laziness. And I'm not willing to take some time I could be practicing Mandolin to spend on some changes that have great chances of being ignored. This is a valuable wasted time.

Finally, back to the original post:

"These are just a few of the techniques we’ve used in the past. I hope if you are a maintainer of a project they are helpful for you, but I would love to know your tips as well."

It's hard to believe so, since the blog doesn't accept comments and the author does not say how he would like to get this feedback. Also this is a very selfish behavior in my opinion. I find it really frustrating when I see some idea being brought to discussion in the wide but without a comments session. Lots of what we learn comes from those discussions, sometimes even more than from the original article. When you say you would like to hear the feedback, this is selfish, because only you are going to get that feedback while other readers might be interested as well.