461–470 of 498 posts
Earlier quoted context omitted.
The difficulty in measuring productivity is the attribution. How do you know the new plow enabled growth?
because trend and changing fewer variables.
Earlier quoted context omitted.
Not what I do. I'll reformulate the ticket description so that the purpose and as many details as possible about the solution are made clear from the start. Then I tell Opus to go and research the relevant parts of the codebase and what needs to be done, and write its findings to a research.md file. Then I'll review that file, bring answers to any open questions and hash out more details if any parts seem fuzzy. When…
You are making it too hard on yourself. Most people would just paste the ticket URL and type "fix this", then spend the next 3 hours on social media. OTOH, I try hard to provide all possibly relevant context, manually copy/paste logs to reduce context overhead, always ask to produce an implementation plan and review it before making any code changes. Yet I often feel like a dinosaur here, all coworkers who tout "LLM…
Earlier quoted context omitted.
> I just can't figure how _how_ to burn that much money a month responsibly. From my experience, this happens essentially by three means: - Level 0 (beginner users) long lived conversations: If you dont get in the habit of compressing, or otherwise manually forcing the model to summarize/checkpoint its work, you will often find people perpetually reusing the same conversation. This is especially true for _beginners_,…
Missing here: some organizations were rewarding high token usage as productivity without critical evaluation. People were afraid to be in the bottom because outcomes weren't being measured. It is a giant Goodhart's law lesson
Earlier quoted context omitted.
> I just can't figure how _how_ to burn that much money a month responsibly. From my experience, this happens essentially by three means: - Level 0 (beginner users) long lived conversations: If you dont get in the habit of compressing, or otherwise manually forcing the model to summarize/checkpoint its work, you will often find people perpetually reusing the same conversation. This is especially true for _beginners_,…
as a new user of agents, i am realizing i'm using a strategy basically identical to level 0. is the typical approach to just make a CLAUDE.md/AGENTS.md and start a new thread for each task or is it more complicated than that?
Relevant Pragmatic Engineer newsletter with many more cases along these lines, along with how some people are handling them: https://newsletter.pragmaticengineer.com/p/the-pulse-token-s... Tokenmaxxing seems more and more like a way to encourage experimentation and learning, and incidents like this are a part of learning. Like, today devs simply use the most expensive model by default, even to do extremely simple thi…
I feel like you’re on to something. Management will pick this up, and make it part of the sprint planning.
Engineers will pull out their hair wondering how you can do that.
That’s like estimating how many CPU cycles a task will take. How many instructions will your laptop use while you work on something.
Earlier quoted context omitted.
> Just genuinely having 10 worktrees perpetually in parallel and cycling between them in between agent responses. Again, not necessarily bad in itself, but can exponentially conse credits. I'm pretty sure that growth is linear.
Not quite the same scenario, but it's already plausible to have a situation where every subagent is allowed to spawn multiple subagents, in which case we'd have literally exponential credit consumption growth...
Earlier quoted context omitted.
Missing here: some organizations were rewarding high token usage as productivity without critical evaluation. People were afraid to be in the bottom because outcomes weren't being measured. It is a giant Goodhart's law lesson
Give your agent a perfectly working code, insist that the output is not what it should be. Go to lunch. By the time you come back, the poor thing will evaporate a small lake trying to figure it out.
Earlier quoted context omitted.
What!? Companies rewarding high token usage? That's inane, insane, and small brained. Who in their right mind equivocates spending more money to bring more productive. I'll just set up some burn jobs to kill tokens unnecessarily and then everyone else will too and the company will go bankrupt in 10 days. It seems inconceivable for a company to set up a "who can spend the most of our money" leaderboard for any other c…
I have friends at two different companies that are taking a stick, rather than carrot, approach to this. They've set monthly minimums for token usage. Anything less than that gets you dinged in your next performance review. Imagine hiring a carpenter and writing a bad online review for them because they didn't use their hammer enough, even though the end product was on time, on budget, and worked well. I was at a com…
Earlier quoted context omitted.
So..? If it was genuinely worth building before, you would have. Having some kind of cost involved is a force of nature that invokes one to decide whether it is worth doing it or not. Moreover these activities only serve to enhance the wealth and interests of the few. Congrats. Don’t forget to look in the mirror.
It’s not operated for profit. People can just solve (some of) their problems by talking to computers.
I take a peak every month or so at spend for my company and notice more and more are consumed $1k in tokens a month and it is bewildering to me how. I use llms daily, and see anywhere from $200-$400 tops. This is using the most expensive models, in deep thinking mode. So I'm not a Luddite against the usage of them. I just can't figure how _how_ to burn that much money a month responsibly. I genuinely challenge someon…
> I just can't figure how _how_ to burn that much money a month responsibly. From my experience, this happens essentially by three means: - Level 0 (beginner users) long lived conversations: If you dont get in the habit of compressing, or otherwise manually forcing the model to summarize/checkpoint its work, you will often find people perpetually reusing the same conversation. This is especially true for _beginners_,…
I regularly work in a largish monolith. We have micro services too, but most things are in the monolith. Over the years there have been multiple pushes to split it up into micro services. These efforts invariably fail because the _goal_ is the micro service architecture itself instead of something useful to the company, like the ability to do fast releases or better organized code.
Anyways, in the past few months I’ve seen multiple people individually ‘attack’ this insane goal with AI. The first step is always to generate massive amounts of documentation describing the current state of code and proposing areas to split up. Then, after the engineer generates this huge store of documents, they say ‘looked what I created’ and then drop it and move on to some other shiny toy. No one will ever read these documents. They are out of date before they ever get ‘completed’, their sole usage is to waste credits.