Live data from Hacker News

AI usage patterns in software teams

linear.app

101–110 of 154 posts

Re: AI usage patterns in software teams

#101
post #68

Earlier quoted context omitted.

Fundamentally though, an agent cannot produce great code, because great code requires intent, which is the opposite of the statistical mean. You will get a solution that works with a proper workflow, but you won't get one that scales or would be truly maintainable. Which is also what you get with random midwit drive-by contributors, but faster. I'll give it that.

[flagged]

Do you people ever think of anything else other than pitching your next SaaS startup thing?

Holy crap. Does your home have mirrors?

Re: AI usage patterns in software teams

#102

Earlier quoted context omitted.

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,…

A normal agentic loop will have the agent using a type system and basic tests to do some basic validation of changes. A good agentic loop would give the agent a very easy way to verify if it’s on the right track. I think agents are better than many humans at writing error free code (runtime errors, not bugs. The code could still be buggy or incorrect.)

Once agents run autonomously for longer periods preventing vision drift becomes as important as correctness.

Epiq solves this with an architecture that supports workflow auditing, allowing you to time-travel state in a filtered view to reconstruct what happened, when, by who, and where intent started drifting, while also allowing you to correlate the evolution of the board with the corresponding commits.

https://ljtn.github.io/epiq

Re: AI usage patterns in software teams

#103
post #96
post #84

Usage does not correlate with valued output or ROI. This article smells like a bad attempt to say hey guys our customers see ROI without any actual evidence that they do. Also, somewhat amusingly, the “founder” consistently being at the top of the use curve might just have something to do with everyone else also using it, but that more implies people are using it because the chief at the top wants them to use it… not…

> Usage does not correlate with valued output or ROI This sounds possible but how can we know? It could just as well correlate. Effort of all kinds correlates with success even when it's not obvious or not... linear.

[dead]

Re: AI usage patterns in software teams

#104

Earlier quoted context omitted.

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…

[dead]

> spent millions on AI contracts

The key question is how much value has been delivered on the other end for a given cost. Well used, tokens would be cheap at 10x the price right now.

Re: AI usage patterns in software teams

#105

Earlier quoted context omitted.

Absolutely, have warned my juniors of this. Doesn't stop malicious compliance though, I can just prompt and burn tokens with source material from my assigned tickets for no reason perfectly fine. I look at my colleagues' screens and they're prompting shit like 'restart this program' and 'is [service] running correctly'. I have below average prompt frequency because I know crazy shit like #!/bin/bash and ps aux. It's…

I tried hard to tokenmaxx one month and couldn’t do it as for most tasks, I’ve already figured out the solution while reading the ticket and vim/emacs-fu is more enjoyable than prompting and waiting. And for other tasks, I just knew the technology to do something with the least amount of effort.

[dead]

Re: AI usage patterns in software teams

#107

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…

>> 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.

If that's true things are truly hopeless for pre-school/school children who are not in position to jump on the train just yet.

Re: AI usage patterns in software teams

#108
post #68

Earlier quoted context omitted.

A normal agentic loop will have the agent using a type system and basic tests to do some basic validation of changes. A good agentic loop would give the agent a very easy way to verify if it’s on the right track. I think agents are better than many humans at writing error free code (runtime errors, not bugs. The code could still be buggy or incorrect.)

Fundamentally though, an agent cannot produce great code, because great code requires intent, which is the opposite of the statistical mean. You will get a solution that works with a proper workflow, but you won't get one that scales or would be truly maintainable. Which is also what you get with random midwit drive-by contributors, but faster. I'll give it that.

I'm not sure I agree that LLMs solve for the statistical mean

But more importantly: isn't what you call "intent" just a series of optimization goals? You want your code to satisfy the constraint of being correct™, while also maximizing various other goals like being maintainable, easy to understand, having few lines of code, as little tight coupling as possible, etc. Goals that often conflict, but when given two implementations you could likely tell which hits the better tradeoff (in your engineering experience)

Those are all things that theoretically - with a tight enough specification and enough compute - a constraint solver could solve. No human intent necessary.

The issue is more that we can't fully specify all those side goals, and even if we could the LLM would struggle following them. A classic paperclip maximizer problem (where nobody told the paperclip maximizer to keep the planet inhabitable and all the other side conditions we implicitly assume)

Re: AI usage patterns in software teams

#109

Earlier quoted context omitted.

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,…

A normal agentic loop will have the agent using a type system and basic tests to do some basic validation of changes. A good agentic loop would give the agent a very easy way to verify if it’s on the right track. I think agents are better than many humans at writing error free code (runtime errors, not bugs. The code could still be buggy or incorrect.)

[dead]

Re: AI usage patterns in software teams

#110
post #68

Earlier quoted context omitted.

Fundamentally though, an agent cannot produce great code, because great code requires intent, which is the opposite of the statistical mean. You will get a solution that works with a proper workflow, but you won't get one that scales or would be truly maintainable. Which is also what you get with random midwit drive-by contributors, but faster. I'll give it that.

I'm not sure I agree that LLMs solve for the statistical mean But more importantly: isn't what you call "intent" just a series of optimization goals? You want your code to satisfy the constraint of being correct™, while also maximizing various other goals like being maintainable, easy to understand, having few lines of code, as little tight coupling as possible, etc. Goals that often conflict, but when given two impl…

> I'm not sure I agree that LLMs solve for the statistical mean

The good thing is that you don't have to agree with that, as the fundamental technical reality does it for you. LLMs do work like that. They are just statistics and probabilities.

Post reply on HN