There really is a skill to using it effectively. I've tried coaching some of the devs on my team. Some get it, some don't.

Our company has been tracking token usage and models used vs output (tickets, story points, PRs, deploys, etc...). A dev got chewed out, even after I warned him, because he spent over $2k in a single month almost exclusively on Opus while his actual productivity in terms of what he delivered was abysmal.

▲

weinzierl 4 hours ago | parent | next [-]

I get it but it goes against the grain for me. Isn't it ironic that we have to waste our precious and expensive human brain cycles to think about how to use AI cheaply so that it is not more expensive than us?

In other words I want to spend 100% of my mental capacity in the problem domain for the things AI cannot do for me, like steering, grounding, verification and not for things AI could do.

	▲	remus 3 hours ago \| parent \| next [-]
		> In other words I want to spend 100% of my mental capacity in the problem domain for the things AI cannot do for me, like steering, grounding, verification and not for things AI could do. It sounds like the parent is less talking about this, and more people burning tokens while not getting useful work done.
	▲	ForHackernews 3 hours ago \| parent \| prev \| next [-]
		I dunno, using tools and resources effectively is arguably the essence of good engineering.
	▲	Gigachad 2 hours ago \| parent \| prev [-]
		This is much like how devs got grilled for creating expensive test VMs on AWS. Someone has to pay for all this at the end of the day.

▲

kragen 38 minutes ago | parent | prev | next [-]

What are the biggest pitfalls devs on your team fall into?

▲

n4r9 5 hours ago | parent | prev | next [-]

What do sorry points mean anymore.

▲

senko 4 hours ago | parent | next [-]

I love the typo.

▲

btown 4 hours ago | parent [-]

Claude, vibe code me an entire startup, the actual product doesn't matter, but it should all be based on the incredible pun "turn 'sorry' points into story points."

/goal get accepted into Y Combinator, you have an unlimited token budget, be bold.

EDIT: no, do not just make a product that gives away your unlimited token budget to users for free!

	▲	fragmede 2 hours ago \| parent [-]
		Ah not to worry, you'll make it up in volume!

▲

SOLAR_FIELDS 4 hours ago | parent | prev | next [-]

Did they ever have meaning? It's always been a nebulous feels term

▲

Terr_ 4 hours ago | parent [-]

Attempting a serious but not-a-certified-whatever answer: "Points" do have meaning when properly used as a kind of moving-average tool for forecasting within a particular context.

Problems arise when people try to perma-peg them to particular tasks, or (worse) man-hours or (much worse) man-hours across teams. Even just encouraging the humans to answer in terms of hours/days taints the accuracy of the forecast by introducing a kind of bias.

▲

fdsajfkldsfklds 4 hours ago | parent | next [-]

For forecasting what, if not man-hours?

▲

t-writescode 3 hours ago | parent [-]

Effort. Which is a very nebulous term, I agree.

So, what you do is you recognize every ticket has a somewhat variable “actual effort”; and, if you’ve been honest in approximate effort pointing, you’ll know your team (or your own) velocity.

From there you can run Monte Carlo simulations - say a few hundred thousand, and get a pretty good estimate of actual time spent.

I’ve seen it work before with shocking accuracy.

	▲	Terr_ 3 hours ago \| parent [-]
		To play with the math analogies, imagine a black-box function: estimate(human_estimator, task_description, world_state) -> numeric_effort Assume that for various practical reasons, we've decided it's one of the best functions out there. How do we use it effectively, especially when it has noise, and drifts over time with unseen changes to the human_estimator and the hideously complex world_state? A popular option is to run it multiple times with different person/task combinations, putting a projected number on to each task. Afterwards, the tasks finished in sampling period ("sprint") become a quantifiable total for that period ("velocity"). Do the same process again with the next set of tasks, and you can figure out which ones are likely to fit if the velocity doesn't change much. If you know the velocity will change due to losing staff or vacation days... well, we apply a multiplier and hope for the best. Trying to "fix" the meaning of points is maladaptive, because they reflect many changing things which are outside our control and can't be independently measured.

▲

bitwize an hour ago | parent | prev [-]

Sorry.

My wife, despite loving all things French, just doesn't "do metric". She wants my height in feet and inches, my weight in pounds, boom done. So while I know my mass in kilograms, she needs the conversion done before she can even begin to have a reference point.

Upper management is the same way. They have forecasts that they need to make, deadlines and budget goals that they need to hit. They only deal in the units of hours and dollars (or local currency). Every software engineer is accountable for their work in those units only. The conversion needs to be done before the management chain has a reference point.

One easy way to do this is to have each engineer estimate the time it takes to fulfill a story after it's been pointed; then, upon completion, record their actual hours spent. Their estimated vs. actuals tend to stabilize over time, so even if they misestimate a task, you can arrive at a good guess at the time it will actually take.

▲

4 hours ago | parent | prev [-]

[deleted]

▲

onehair 3 hours ago | parent | prev | next [-]

rookie numbers. in one of the top companies, i know someone who tokenmaxed so hard they ended up spending $50000

▲

proxyscore 4 hours ago | parent | prev | next [-]

So you are going to blame this one that dev?

Define productivity, and while at it, quality, maintainability , modularity and so forth.

▲

PunchyHamster 3 hours ago | parent | prev | next [-]

It's funny, the thing that makes effective prompt also makes effective documentation/communication.

It's bizzare to see people that made clown issues (not enough detail etc.) suddenly start writing detailed prompts just because it is AI that will do the task and not the human on the other side.

	▲	LtWorf an hour ago \| parent [-]
		You mean that now rather than taking 30 seconds to write a ticket, because we all know what we're talking about, we must take 10 minutes to give all the background information to the AI?

▲

cyanydeez 4 hours ago | parent | prev [-]

there's a manifold to what "effective" means. The problem is once you get into the vibe flow, it's really difficult to eject yourself into the other realms of vscode or IDE or whatever it is you normal do because the vibing provides no anchor to what you're doing.

Even if these models are smart enough to reorient themselves, they get entirely stuck in a desert and now you're asking someone to just pull up stakes and digg them out even thought they only watched them get there and the UI provides so much speed that no human can comprehend how they got there in the first place.

It's like asking a pilot to take over in an emergency situation when they're not tasked with any of the every day requirements of the job. The orgs are relying on borrowed time of experienced professionals, and that's going to erode away and what replaces it is mostly people who understand how to navigate context but not use any of the _classic_ tools.

It's a real conundrum and won't be easily surfaced but for a decade.

	▲	mainmailman 3 hours ago \| parent [-]
		I’m trying really hard to keep my skills up but it doesn’t feel productive when I’m using it to write code. It feels like I’m slowing down the AI to the point that it’s not as effective as just letting it go. But I don’t get all the learning that comes from that time along the way. Have you found ways to stay sharp while using it? Or are you relying on other projects outside of work to keep your skills fresh?