[dead]
AI usage patterns in software teams
41–50 of 154 posts
Re: AI usage patterns in software teams
#42[flagged]
Re: AI usage patterns in software teams
#43Re: AI usage patterns in software teams
#44Earlier quoted context omitted.
And then more hours cleaning it up and re-prompting.
[dead]
Companies are tracking token usage across the board. You are in trouble for too less or too many. Unfortunately the token usage is the only measurable thing for most folks so everyone is playing the game, otherwise how else would Anthropic and OpenAI make the money
Re: AI usage patterns in software teams
#45this seems inappropriate. I think its a bad paradigm that just because you use a platform's service, they get intimate details about your usage. And for them to be so bold about publishing the statistics they've stolen from their customers data? Gives me a reason to never recommend my org use this platform.
The data is aggregated, and you cannot possibly identify a single user from what's been published. I see no issue here.
Re: AI usage patterns in software teams
#46This looks like measuring what is easy to do, rather than what really matters. PR open counts, issues created , ceos/founders spending more time on linear don't automatically lead to better outcomes (in my experience they are often negatively correlated:-) )
I'd be interested to overlay, I don't know, customer satisfaction or anything that can show the follow-on effect of all this output. Linear won't have that information.
My guess is some will jump up (where the team has managed to make themselves move effective and responsive) and many will plummet (doesn't need explaining).
Then there might be something to look at.
Re: AI usage patterns in software teams
#47Earlier quoted context omitted.
And then more hours cleaning it up and re-prompting.
I program as a hobby, personal projects because I can. I recently set up a local llm to see what the fuss is about and other than the few ringer solutions my experience is as you described. 2min promping, 5min waiting, 3hrs debugging or just doing it myself. I am very likely doing it wrong, and it does speed up some aspects, but I wouldn't say I trust llm code any more than my own. Until it runs and throws an error,…
Local llms aren’t super exciting unfortunately.
Re: AI usage patterns in software teams
#48Earlier quoted context omitted.
And then more hours cleaning it up and re-prompting.
I program as a hobby, personal projects because I can. I recently set up a local llm to see what the fuss is about and other than the few ringer solutions my experience is as you described. 2min promping, 5min waiting, 3hrs debugging or just doing it myself. I am very likely doing it wrong, and it does speed up some aspects, but I wouldn't say I trust llm code any more than my own. Until it runs and throws an error,…
I don't think setting up a local LLM is a reasonable way to get a good idea of how enterprises are using this stuff.
Re: AI usage patterns in software teams
#49Earlier quoted context omitted.
because my manager will ping me and say "anon you aren't prompting enough" like they never heard of Goodhart's law before.
Write a script to make random prompts and use tokens. Not like they look at what you’re actually prompting.
No, don’t be silly, they get ai to spy on you en masse instead. Nobody has to look at anything anymore for it to be actionable.
Re: AI usage patterns in software teams
#50Earlier quoted context omitted.
And then more hours cleaning it up and re-prompting.
[dead]
In my experience?
It used to be that one person had one to three codebases they knew intensely at my company. If you needed a bug in codebase X fixed, person Y was the one to do it and if they aren't available, person Z can do it, just not as quickly.
Now every person on my team has to handle tickets for every single codebase. There are about two dozen different large codebases involved here.
It's a ludicrous antipattern because person Y still needs to review the PR that person A generated for codebase X, and it will take them about as much time to wrangle the 2000 line PR (oh boy do LLMs love their mocks for unit tests) as it would have been for them to do the 50 line code change.
On top of that, it has "allowed" us to add feature after feature onto codebases not designed for them without refactoring. Is it good that this Flask API went from a purpose built service that interacted with the data analytics for product A stored in database X, and now our sales guys can sell product B, C, and D stored in database X? Uh, I'm sure it's great for them. Oh, and now it all can be stored in database X, Y, or Z depending on what the customer wants or what sales promised them. Great. Now I'm looking at a Flask app.py that's 12,000 lines of repeated code.
It has allowed poor designs to still produce working code. For a while. We seem to be getting a lot of bugs lately that look really bad to customers because it's for really simple shit. And I can't help but notice that happening to all the various products and sites I use too...