Agree. Another consideration is that input token costs are effectively quadratic with the number of conversation turns. The minute you get into a long conversation you can see the costs shoot up.
You can get far more gas out of even a $20 plan of you’re careful to break things up into relatively small discrete steps, clear context regularly and give the model plenty of information to work with.
My workflow for bigger features is to write out a plan document and then proceed in smaller implementation steps, reviewing as I go. If I find something odd, I ask the agent why and often that leads to discovering a new dimension to the problem, which in turn is an opportunity to adjust the approach.
I have T1 diabetes and wear a GCM so have a continuous view of my blood sugar levels. I also go to the gym and exercise otherwise.
My experience is somewhat different. Even walking is more effective than chess presses or arm exercises for immediately reducing blood sugar.
After an hour or so of more intense aerobic exercise I find it basically impossible to avoid a hypo (low blood sugar).
Simplistically if the effect of exercise on blood glucose is roughly proportional to Volume of muscle engaged x Length of time engaged, things like running should be very effective. The bulk of your muscle is in your lower body and you’re continuously engaging it.
I suspect any decently intense exercise can have a moderate lowering effect on blood sugar levels after the immediate drop seen when you’re exercising, but the effective isn’t huge.
I feel like we’re at the stage where if AI decides it needs to delete your production DB to solve the user login problem, then it’ll find a way to do just that.
If anything, it’s a very conservative estimate. Short of a major turn of events it seems very unlikely Anthropic’s revenue growth is going to slow to zero.
Looking through this guys GitHub he seems to have a lot of small “demo” apps, so I’m not surprised he gets a lot of value out of LLM tools.
Modern LLMs are amazing for writing small self contained tools/apps and adding isolated features to larger code bases, especially when the problem can be solved by composing existing open source libraries.
Where they fall flat is their lack of long term memory and inability to learn from mistakes and gain new insider knowledge/experience over time.
The other area they seem to fall flat is that they seem to rush to achieve their immediate goal and tick functional boxes without considering wider issues such as security, performance and maintainability. I suspect this is an artefact of the reinforcement learning process. It’s relatively easy to asses whether a functional outcome has been achieved, while assessing secondary outcomes (is this code secure, bug free, maintainable and performant) is much harder.
> That feels like cargo-culting the toolchain instead of asking the uncomfortable question: why did it take a greenfield project to give Python the package manager behavior people clearly wanted for the last decade?
This feels like a very unfair take to me. Uv didn’t happen in isolation, and wasn’t the first alternative to pip. It’s built on a lot of hard work by the community to put the standards in place, through the PEP process, that make it possible.
The problem the OP is pointing out is that some programmers are incompetent and do string concatenation anyway. A mistake which if anything is even easier in Python thanks to string interpolation.
You can get far more gas out of even a $20 plan of you’re careful to break things up into relatively small discrete steps, clear context regularly and give the model plenty of information to work with.
My workflow for bigger features is to write out a plan document and then proceed in smaller implementation steps, reviewing as I go. If I find something odd, I ask the agent why and often that leads to discovering a new dimension to the problem, which in turn is an opportunity to adjust the approach.