Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI usage patterns in software teams

linear.app

Post reply on HN
Print view View original

141–150 of 154 posts

Re: AI usage patterns in software teams

#141

Post by cmiles8 »

stuartjohnson12 wrote: post #139
cmiles8 wrote: post #126

Earlier quoted context omitted.

If that was true then there wouldn’t be a giant ROI crisis fueling calls of an AI bubble burst imminent. If the answer was “the ROI is clear” then folks would just say that.

The debate about ROI isn't about whether everyone is going to throw their hands up and stop using AI tooling - the debate is about where that value is going to be captured. It's pretty clear that using some degree AI assistance for programming is on the whole faster and better than writing code by hand for the majority of applications, and it's clear that the degree to which it's better than writing code by hand is i…

ROI doesn’t mean “does it help.” Few question if it helps.

ROI is about how much its costs vs the value of the “help.” That’s where the present crisis is. Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That’s a clear no at this point hence the growing panic.

Re: AI usage patterns in software teams

#142

Post by nozzlegear »

lukebitts wrote: post #119
nozzlegear wrote: post #36

Earlier quoted context omitted.

> But these days, AI just generates code following the existing patterns of the codebase Is this sarcasm?

I read these kinds of comments and wonder what makes reality so different for us. I personally have found AI has the easiest time in the world following existing patterns. At my workplace, our frontend code is so well organized most of the time all the AI has to do is copy and paste an implementation from somewhere else and change the names, and it gets right pretty much 100% of the time

Could be a symptom of which languages we use and which languages are in their training sets. I primarily write F#, which is a functional language that's compatible with the object-oriented C#. When AI tries to write code in my F# codebases, it almost always ignores the existing patterns/styles and tries to write it like an OO language. It has a weird desire to use mutability instead of the default immutability, for loops instead of pipes/monads, huge if/else blocks instead of pattern matching, etc. This is all very un-idiomatic for F#, not what a human programmer would write unless they were deliberately trying to write it like C#.

Maybe it's better in Fable/Sol, but it was a problem in Opus when I still used Claude, and it's still a problem with the Qwen and Deepseek models I use now. Either way, it seems to me that your code has to already conform to the patterns they want to write, or you're going to end up with new patterns.

Re: AI usage patterns in software teams

#143

Post by Majromax »

cmiles8 wrote: post #141
stuartjohnson12 wrote: post #139

Earlier quoted context omitted.

The debate about ROI isn't about whether everyone is going to throw their hands up and stop using AI tooling - the debate is about where that value is going to be captured. It's pretty clear that using some degree AI assistance for programming is on the whole faster and better than writing code by hand for the majority of applications, and it's clear that the degree to which it's better than writing code by hand is i…

ROI doesn’t mean “does it help.” Few question if it helps. ROI is about how much its costs vs the value of the “help.” That’s where the present crisis is. Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That’s a clear no at this point hence the growing panic.

> Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That looks like a clear no at this point.

That's only a potential crisis for those who have made concrete investments.

On the use side, the 'cost' of AI spans more than two orders of magnitude. Looking at recent models (= 45) on OpenRouter, the output cost ranges from $50/MTok (Fable) to $0.153/MTok (DeepSeek Flash 0731).

From the perspective of a user of LLM/agent assistance, there's very likely a range where the benefits outweigh the costs.

If the ROI for the model developers isn't there, then that just impairs the future trajectory of the field. Current models are just bits that aren't going anywhere, and as long as they can be served (in inference) above their marginal cost they will continue to be so-delivered.

Re: AI usage patterns in software teams

#144

Post by Majromax »

kyllo wrote: post #140
stuartjohnson12 wrote: post #139

Earlier quoted context omitted.

The debate about ROI isn't about whether everyone is going to throw their hands up and stop using AI tooling - the debate is about where that value is going to be captured. It's pretty clear that using some degree AI assistance for programming is on the whole faster and better than writing code by hand for the majority of applications, and it's clear that the degree to which it's better than writing code by hand is i…

On the value capture question, it's really not clear that the ability to write code at superhuman speed actually translates to an increase in the speed with which we can create new, better technology products that customers will pay more money for, vs. just enabling layoffs.

You could say the same thing about compilers versus assemblers, high-level languages versus low-level ones, and services and libraries versus monolithic programs.

All other things being equal, increasing the speed of some part of the development process will increase the overall pace of development. However, By Amdahl's law that increase will be sublinear, and that is why we should take "pull requests" as an imperfect metric.

We also don't get to pick the form that 'better technology products' take. While we'd probably like to keep cost(/effort) and complexity constant and increase robustness and performance, the market equilibrium might be 'worse is better' and reward whiz-bang features and lower effort.

Re: AI usage patterns in software teams

#145

Post by rfgplk »

drodgers wrote: post #95
danggggg wrote: post #91

Earlier quoted context omitted.

[dead]

Skill issue. If you make an effort to use the new tools effectively, the gains are wild. Don't fall into a grumpy luddite trap, the train is leaving the station and you'll struggle to catch up if you don't learn and grow. Not using AI for software development in 2027 will be like only knowing how to program via punchcard in 2010. It's new. It's different. It's hard. It's your job. Learn how to use it effectively, emb…

> If you make an effort to use the new tools effectively, the gains are wild. Don't fall into a grumpy luddite trap, the train is leaving the station and you'll struggle to catch up if you don't learn and grow.

Correct, in fact you can tell most AI detractors aren't thinking about this from a _computer science_ point of view. You'll have many people claiming "why prompt an LLM when you can write it and commit it yourself in 45 minutes?" True, you could. But that's a purely _serial_ workload. LLMs are effectively data-independent and they can.. work in _parallel_. Meaning instead of working on a single task, you can juggle multiple simultaneously. So even if you're as fast or faster on a one-on-one basis, you _cannot physically_ be faster than 10 separate sessions running in parallel, working on wholly separate tasks. And that's actually where most 10x gains come from. See Amdahl's/Gustafson's laws.

Re: AI usage patterns in software teams

#146

Post by porridgeraisin »

Majromax wrote: post #144
kyllo wrote: post #140

Earlier quoted context omitted.

On the value capture question, it's really not clear that the ability to write code at superhuman speed actually translates to an increase in the speed with which we can create new, better technology products that customers will pay more money for, vs. just enabling layoffs.

You could say the same thing about compilers versus assemblers, high-level languages versus low-level ones, and services and libraries versus monolithic programs. All other things being equal, increasing the speed of some part of the development process will increase the overall pace of development. However, By Amdahl's law that increase will be sublinear, and that is why we should take "pull requests" as an imperfec…

Yep.

Also, large companies are still experimenting on how to integrate LLMs into their workflows. Due to the fast cadence of releases, people forget that LLMs became robust (regardless of the capability level/parameter count/data size) enough to use semi-reliably in company-specific ways only 1 year ago. And bigger the org, the slower the process. I don't expect it to settle and get productive used across the majority of very large companies for another year atleast.

High prices are mostly a result of DC capacity. As more and more DCs get built out, prices will drop. At a unit level the inference business is extremely sound regardless.

Re: AI usage patterns in software teams

#147

Post by bitwize »

AlexKalWork wrote: post #74

This looks like a "We are so AI native and efficient!!" article. At least, they could delve deeper into how they define the metrics and how they collected the data.

> delve

Butt-head: Huh huh huh. Hey Beavis, he said "delve". Huh huh huh.

Beavis: Yeah, I bet he'll use an em-dash next. Heh heh heh.

Re: AI usage patterns in software teams

#148

Post by lukebitts »

nozzlegear wrote: post #142
lukebitts wrote: post #119

Earlier quoted context omitted.

I read these kinds of comments and wonder what makes reality so different for us. I personally have found AI has the easiest time in the world following existing patterns. At my workplace, our frontend code is so well organized most of the time all the AI has to do is copy and paste an implementation from somewhere else and change the names, and it gets right pretty much 100% of the time

Could be a symptom of which languages we use and which languages are in their training sets. I primarily write F#, which is a functional language that's compatible with the object-oriented C#. When AI tries to write code in my F# codebases, it almost always ignores the existing patterns/styles and tries to write it like an OO language. It has a weird desire to use mutability instead of the default immutability, for l…

To be fair, I do have to remind the AI to follow the codebase's conventions regularly and it is the #1 rule in our team's claude.md. And when I generate plans I ask that every new implementation follow a reference implementation. In your F# projects would something like that help or would it make no difference?

Re: AI usage patterns in software teams

#150

Post by nozzlegear »

lukebitts wrote: post #148
nozzlegear wrote: post #142

Earlier quoted context omitted.

Could be a symptom of which languages we use and which languages are in their training sets. I primarily write F#, which is a functional language that's compatible with the object-oriented C#. When AI tries to write code in my F# codebases, it almost always ignores the existing patterns/styles and tries to write it like an OO language. It has a weird desire to use mutability instead of the default immutability, for l…

To be fair, I do have to remind the AI to follow the codebase's conventions regularly and it is the #1 rule in our team's claude.md. And when I generate plans I ask that every new implementation follow a reference implementation. In your F# projects would something like that help or would it make no difference?

Yeah that's what I've ended up doing and it does help. I do have guidelines set up in my agents.md files, but they're hit or miss. It's best to just tell them directly to "write idiomatic F#," which they seem to understand.
Post reply on HN