havkom

They are great instruction followers in general. This is, one single bad instruction during months of work can mess things up.

I am mostly worried about the current AI use in management. I’ve met a few with ”AI hubris” making poor managerial decisions that stem from their poor usage of ChatGPT (not understanding the importance of context, model sycophancy, etc).

Some people that are immune to listen to people with more experience will continue to be ”junior” forever. They may eventually not have the title junior, but they really are.

There are fundamental differences. Many people expect a positive gradient of quality from AI overhaul of projects. For translating back and forth, it is obvious from the outset that there is a negative gradient of quality (the Chinese whispers game).

My tip is: don’t use SDK:s for agents. Use a while loop and craft your own JSON, handle context size and handle faults yourself. You will in practice need this level of control if you are not doing something trivial.

What about GLP-1 antagonists to lower inflammation / hs-CRP?

Does this matter much? Git is a ”distributed source control system”. Are you using git in the wrong way? :)

Reminds me of C#.. IDisposible and IAsyncDisposible in C# helps a lot to write good mechanisms for things that should actually be abstracted in a nice way (such as locks handling, queue mechanisms, temporary scopes for impersonation, etc).

I tried:

-red

and:

red-red-red

But it did not work and did not get any response. Maybe I am stupid but should this not work?

What is the difference between them? Both seems like quite trivial implementations?

Good investigation!

Software developers nowadays barely know about transactions, and definitely not about different transaction models (in my experience). I have even encountered "senior developers" (who are actually so called "CRUD developers"), who are clueless about database transactions.. In reality, transactions and transaction models matter a lot to performance and error free code (at least when you have volumes of traffic and your software solves something non-trivial).

For example: After a lot of analysis, I switched from SQL Server standard Read Committed to Read Committed Snapshot Isolation in a large project - the users could not be happier -> a lot of locking contention has disappeared. No software engineer in that project had any clue of transaction models or locks before I taught them some basics (even though they had used transactions extensively in that project)..

The big threat of LLM:s is not the diminishing skills of established skilled developers, but rather the skill set building of junior developers.

try catch - where you catch the right types of errors at the right level is hard to beat.

However, many make the mistake to handle any errors at the wrong level. This leads to really buggy and hard to reason about code and in some cases really bad data inconsistency issues.

A rule of thumb is to never catch a specific error which you are not in a good position to handle correctly at that precise level of code. Just let them pass through.

Amen!

How to apply these rules on junior co-workers (who think they know what is best from reading a hyped blog post)?