Even if writing new code is not the problem or the bottleneck anymore, a major blocker is one CoreService.java file someone wrote 10 years ago that is keeping the whole system glued together. Only they know how it works, and how to keep it working.
Parroting my own words from a while back, inferred intent is not the same as initial intent. This is just reverse engineering except somewhat automated
There is a reason that kLOC / FP were rightly shunned out of being measurable metrics years ago.
The same clown show seems to be resurging with "tokens".
There is, in my opinion, no real formula or metric that you can define for "good" code or "bad" code.
Tickets and ceremonial activities, however abstract that into a N-nary status value that seems easier to judge upon.
If your job was only coding then you are the most replaceable of the bunch. Traditional software engineering is a broader domain that, as rightly pointed out, will require you to actually *sit and talk* with the worst communicators you'll meet in your life.
Looking at a slice of most folks' workday and calling it their whole job is in my opinion, incorrect.
> Could I have written it without Claude? Yes, definitely. But I was able to produce the code in a few days while having a fever of 100-102, which I definitely couldn't have done on my own.
While I admire your strength in attempting it, this just adds one more brick to the wall of precedents that "what's stopping you from just sending one prompt, it'll just take 30 seconds and you can do it in bed!"
You could sum it up into a simple equation as
Features Shipped = Features/Hour * Developer Hours
Developer hours has remained a constant, and F/H has gone up. I am of the opinion that the ideal is the inverse.
That's an excellent point. To be fair, I allowed myself to work on this while I was sick only because it was fun. This was a bit like scratching an itch, because I'd had the germ of an idea for a while and wanted to get it out of my head. You're absolutely right that it sets a dangerous precedent: the easier it becomes to do work, the easier it is to demand work of the people doing it. The boundaries need to be firm.
On the other hand, this was also a case where Claude really did help me finish something more quickly than I could have without it. So in thi scase I do think it lowered the number of developer hours per feature.
Watch token budget be included as part of employee TC figures - I feel this is an eventuality due to rising costs and "true pricing" slowly creeping in.
Current ventures feel moreso like a pilot program (you bought a private jet, now get a couple of your pilots to actually fly it) versus having an entire fleet of jets, and having to pay salaries to all those pilots, plus account for their fuel charges.
Right now all expenses are relatively "someone else's {problem,money,infra}".
Personally, I'd recommend the pointed 'docker {container,image,volume} prune' commands for scheduling granularity/control. At least, filtering as you've also shown.
The 'system' context captures networks; much to my dismay, this has been a problem for no fewer than three employers. It's painfully common for things to expect the networks to persist. They don't really consume resources, so I see no reason to invite the systematic heartburn.
When? When there's disk pressure. Maybe some longer term (weekly, monthly?) to keep a lid on things. The image cache provides a benefit, no sense fighting it. At our rate, daily pruning means I might lose hours (through a week) repeatedly pulling the same images.
They seem to be the result of an image-gen model to me
If this is the unvetted and unbased information they are putting out in public facing-blogs, only the stars would know what data is being "presented" in their boardrooms
> And don’t get me started with storing datetime with timezone (e.g “4/2/2007 7:23:57 PM -07:00“). In sql server you have datetimeoffset; in Postgres you fuck off :-)
`TIMESTAMPTZ` / `TIMESTAMP WITH TIME ZONE` exists?
> AI will generate a working mess all day long if you let it. The pressure to write good code has to come from the developer actually reviewing what comes out and pushing back
You are reinventing the wheel again with yet another form of reinforcement learning. I don't use any form of LLM assistance for coding, but if I have to continually tell it what to do, how to do it, what not to do, what assumptions to make - I would rather stimulate my neurons more by doing that damn thing itself.
The narrative of "Yeah it will do everything, provided you tell it how to do everything!" seems baseless, personally. Even if you emulate the smartest human possible, can you emulate an idiot?
reply