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

The economics of software teams: Why most engineering orgs are flying blind

viktorcessan.com

Post reply on HN
Print view View original

21–30 of 299 posts

Re: The economics of software teams: Why most engineering orgs are flying blind

#21

Post by iamflimflam1 »

boron1006 wrote: post #18

> A messy codebase is still cheaper to send ten agents through than to staff a team around. And even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today. I’ve been on 2 failed projects that have been entirely AI generated and it’s not that agents slow down and you can just send more agents to work on projects for longer, it’s…

Very much like humans when they drown in technical debt. I think the idea that a messy codebase can be magically fixed is laughable.

What I might believe though is that agents might make rewrites a lot more easy.

“Now we know what we were trying to build - let’s do it properly this time!”

Re: The economics of software teams: Why most engineering orgs are flying blind

#23

Post by nishantjani10 »

boron1006 wrote: post #18

> A messy codebase is still cheaper to send ten agents through than to staff a team around. And even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today. I’ve been on 2 failed projects that have been entirely AI generated and it’s not that agents slow down and you can just send more agents to work on projects for longer, it’s…

this is the part of the article that I did not sit well with me either. Code is agent generated, agent can debug it but will alway be human owned.

unless anthropic tomorrow comes in and takes ownership all the code claude generates, that is not changing..

Re: The economics of software teams: Why most engineering orgs are flying blind

#24

Post by tweetle_beetle »

InfinityByTen wrote: post #7

When I see someone just throwing a lot of numbers and graphs at me, I see that there are in to win an argument, and not propose an idea. Of late, I've come across a lot of ideas from Rory Sutherland and my conclusion from listening to his ideas is that there are some people, who're obsessed with numbers, because to them it's a way to find certainty and win arguments. He calls them "Finance People" (him being a Market…

As with most things, isn't the truth somewhere in the middle? True cost/value is very hard to calculate, but we could all benefit by trying a bit harder to get closer to it.

It's all too common to frame the tension as binary: bean counters vs pampered artistes. I've seen it many times and it doesn't lead anywhere useful.

Re: The economics of software teams: Why most engineering orgs are flying blind

#25

Post by bonesss »

leokennis wrote: post #3

> The obvious objection is that code produced at that speed becomes unmanageable, a liability in itself. That is a reasonable concern, but it largely applies when agents produce code that humans then maintain. Agentic platforms are being iterated upon quickly, and for established patterns and non-business-critical code, which is the majority of what most engineering organizations actually maintain, detailed human fam…

Ceding the premise that the AGI is gonna eat my job, my job involves reading the spec to be able verify the code and output so the there’s a human to fire and sue. There are five layers of fluffy management and corporate BS before we get to that part, and the AGI is more competent at those fungible skills.

With the annoying process people out of the picture, even reviewing vibeslop full time sounds kinda nice… Feet up, warm coffee, just me and my agents so I can swear whenever I need to. No meetings, no problems.

Re: The economics of software teams: Why most engineering orgs are flying blind

#26

Post by Cthulhu_ »

iamflimflam1 wrote: post #21
boron1006 wrote: post #18

> A messy codebase is still cheaper to send ten agents through than to staff a team around. And even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today. I’ve been on 2 failed projects that have been entirely AI generated and it’s not that agents slow down and you can just send more agents to work on projects for longer, it’s…

Very much like humans when they drown in technical debt. I think the idea that a messy codebase can be magically fixed is laughable. What I might believe though is that agents might make rewrites a lot more easy. “Now we know what we were trying to build - let’s do it properly this time!”

Potentially, yes, but as with other software, you need to know AND have (automated) verifications on what it does, exactly.

And of course, make the case that it actually needs a rewrite, instead of maintenance. See also second-system effect.

Re: The economics of software teams: Why most engineering orgs are flying blind

#28

Post by kaon_2 »

pydry wrote: post #12
leokennis wrote: post #3

> The obvious objection is that code produced at that speed becomes unmanageable, a liability in itself. That is a reasonable concern, but it largely applies when agents produce code that humans then maintain. Agentic platforms are being iterated upon quickly, and for established patterns and non-business-critical code, which is the majority of what most engineering organizations actually maintain, detailed human fam…

Exactly. I think it's been a while since I've read an LLM hot take which couldnt have been written by an LLM and this one is no exception. There's a 99% chance that the training materials on sale are equally replaceable with a prompt.

True. And yet, as an organization when you buy OP's training, you don't buy the material. You buy the feeling that you make your organization becomes more productive. You buy the signal to your boss that you are innovative and working to make your organization more productive. And you buy the time and headspace from your engineers that they are thinking if at least for 2 hours about making the organization more productive. The latter can be well worth the cost, and the former surely too.

Re: The economics of software teams: Why most engineering orgs are flying blind

#29

Post by anonymous908213 »

lynx97 wrote: post #19
Smaug123 wrote: post #8

Earlier quoted context omitted.

"Flying blind" is a completely standard idiom originating from flying while blinded by e.g. cloud or darkness. Its meaning is a figurative transplant of a literal description.

I know it’s an idiom. The point is that it still uses blindness as a stand-in for incompetence/unsafe guessing . Being common doesn’t make it harmless. Common just means we’ve normalized it. And you defending it shows that weve normalized it to a point where the double-meaning is seemingly only apparent to blind people.

It absolutely does not use blindness as a stand-in for incompetence, that is your own outrage-seeking interpretation of it. A neutral interpretation would be that "flying blind" is to "operate without perfect information". It is a simple description of operating conditions, not a derogatory term in any way. Your reply is worded in such a way as to indicate that you think the person you're replying to deserves to be shamed for 'defending' it, but having a disability does not entitle you to browbeat the world into submission and regulate all usage of any words associated with your disability as you see fit. This is quite benign and people are perfectly well within their right to object to somebody trying to police plainly descriptive language.

Re: The economics of software teams: Why most engineering orgs are flying blind

#30

Post by danpalmer »

> even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today

Citation needed. A human engineer can grok a lot in 10 days, and an agent can spend a lot of tokens in 10 days.

Post reply on HN