For instance, if an AI model could complete a one-hour task with 50% success, it only had a 25% chance of successfully completing a two-hour task. This indicates that for 99% reliability, task duration must be reduced by a factor of 70.
This is interesting. I have noticed this myself. Generally, when an LLM boosts productivity, it shoots back a solution very quickly, and after a quick sanity check, I can accept it and move on. When it has trouble, that's something of a red flag. You might get there eventually by probing it more and more, but there is good reason for pessimism if it's taking too long.
In the worst case scenario where you ask it a coding problem for which there is no solution—it's just not possible to do what you're asking—it may nevertheless engage you indefinitely until you eventually realize it's running you around in circles. I've wasted a whole afternoon with that nonsense.
Anyway, I worry that companies are no longer hiring junior devs. Today's juniors are tomorrow's elites and there is going to be a talent gap in a decade that LLMs—in their current state at least—seem unlikely to fill.
As with most script languages, you can hit the ground running in a very procedural sort of way, as you don't even have to define a main entry point. You just start coding.
But Python certainly has an object model. If I'm not mistaken, everything in Python is an object. Like even functions.
I suppose there are some aspects of the class implementation that feel a little tacked on? Like the way you need to manage the self reference manually where it may be implicitly handled for you in other languages. At least the way you call
super()
now is a lot less kludgy.One thing I miss a bit in Python is method overloading. In a general sense, function overloading is not an OOP feature per se, but I find it useful in OOP, particularly with object initializers. You can sort of achieve it with
@functools.singledispatch
but it's pretty janky. For initialization, I prefer keeping the__init__
method pretty rudimentary and writing factory functions to do more complex initializations. And with@dataclass
, you can forego writing an__init__
altogether if you do it that way.