platform-problem-monitoring-core

https://github.com/dx-tooling/platform-problem-monitoring-co... could have a useful approach, too: it finds patterns in log lines and gives you a summary in the sense of „these 500 lines are all technically different, but they are all saying the same“.

I did another session with the sole focus being on code quality improvements. The commit with all changes that Cursor/claude-3.7-sonnet(thinking) has done is at https://github.com/dx-tooling/platform-problem-monitoring-co.... As you can see, I've fed your feeback verbatim: I have received the following feedback regarding this codebase: "The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: @utils.py. All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves, to a raciness in load_json where it's checked for file existence with an if and then carrying on as if the file is certainly there..." I

I guess we are slowly but steadily approaching splitting-hairs-territory, so not sure if this is still worth it… However. I‘m not quite sure where I complained. Certainly not in the post. And yes, I’m very convinced that the result turned out a lot better than it would have turned out if an unexperienced „vibe coder“ had tried to achieve the same end result. Actually pretty sure without my extensive and structured requirements and the guard rails, the AI coding session would have ended in a hot mess in the best case, and a non-functioning result in the worst case. I‘m 100% convinced that these two statements are true and relevant to the topic: That a) someone lacking my level of experience and expertise is simply not capable of producing a document like https://github.com/dx-tooling/platform-problem-monitoring-co... And that b) using said

wrap_long_lines shares those characteristics: https://github.com/dx-tooling/platform-problem-monitoring-co... Where things are placed in the project seems rather ad hoc too. Put everything in the same place kind of architecture. A better strategy might be to separate out the I and the O of IO. Maybe someone wants SMS or group chat notifications later on, instead of shifting the numbers in filenames step11_ onwards one could then add a directory in the O part and hook it into an actual application core.

> Once again, the AI agent implemented this entire feature without requiring me to write any code manually. > For controllers, I might include a small amount of essential details like the route name: [code] Commit history: https://github.com/dx-tooling/platform-problem-monitoring-co... Look, I honestly think this is a fair article and some good examples, but what is with this inane “I didn’t write any of it myself” claim that is clearly false that every one of these articles keeps bringing up? What’s wrong with the fact you did write some code as part of it? You clearly did. So weird.

The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: https://github.com/dx-tooling/platform-problem-monitoring-co... All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves, to a raciness in load_json where it's checked for file existence with an if and then carrying on as if the file is certainly there... In a nutshell, if the rest of it is like this, it simply sucks.