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

If you thought code writing speed was your problem you have bigger problems

andrewmurphy.io

Post reply on HN
Print view View original

191–200 of 231 posts

Re: If you thought code writing speed was your problem you have bigger problems

#191

Post by operatingthetan »

nemo44x wrote: post #72
operatingthetan wrote: post #37

Earlier quoted context omitted.

I know you're being cheeky but we are definitely heading in that direction. We will see frameworks exclusively designed for LLM use get popular.

I think that’s possible too but the trouble is training them. LLMs are built on decades of human input. A new framework, programming language, database, etc doesn’t have that. We are in the low hanging fruit phase right now.

If it knows the language already a new framework is a piece of cake. A few MD files explaining it is enough for the pattern recognition to kick in. I've had one LLM create a novel framework and pass them to another and it's trivial for a fresh instance to pick it up.

Re: If you thought code writing speed was your problem you have bigger problems

#192

Post by rubslopes »

brailsafe wrote: post #168
bvirb wrote: post #127

When we (the engineering team I work on) started using agents more seriously we were worried about this: that we'd speed up coding time but slow down review time and just end up increasing cycle time. So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out y…

> The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced. I've already passed through this phase and have given up on it. I'm sure everyone's experience will vary, but I just find it introduces either sufficiently more context switching or detracts sufficiently…

I've tried the "4 agents running at the same time in different projects/features" and I felt literally dizzy. I still do the "check something else while the agent runs", and I often forget about that terminal window for many minutes, only to remember about it several tasks later.

Re: If you thought code writing speed was your problem you have bigger problems

#193

Post by adwn »

apsurd wrote: post #186
adwn wrote: post #172

Earlier quoted context omitted.

> But for startups, side-hustles, VC-pitches and the inner-workings of companies and so on (HN crowd) coding was never the problem. I'd say you're 180° wrong. Getting to an MVP fast is the most immediate problem when you've started a startup. Iterating on ideas fast is the most immediate problem once you've released your MVP. You need an MVP to get users, and you need to to iterate to find product-market fit. Perfect…

This isn't in defense of perfectly crafted code. It's about NO CODE. Do not write (ai-moar) code! It's not the code that is the problem. I understand the need for MVP to bring an idea into reality. It's the feedback that's valuable not the code. This is not about the code. So why is the argument "write more code"? In any case, I have yet to create a product on my own that has done well financially. So what the hell d…

> So why is the argument "write more code"?

It isn't, that's what you injected. The argument was "write [the same amount of] code faster". And that is undoubtedly a good thing, because execution speed can make or break your startup.

Re: If you thought code writing speed was your problem you have bigger problems

#194

Post by 4ndrewl »

Tried this at numerous companies, small and large.

The engineers get this, or are willing to learn. Some (by no means most) scrum/agile leads get it.

The problem is the 'product class' don't get it, aren't interested and by-and-large don't have the aptitude to understand. Try tp explain cycle time, or cumulative flow diagrams to a Product Manage, Product Owner, Service Owner and they most often just brush it away as 'a technical thing'

The problem only gets worse as the Peter principle begins to kick in and thin out the talent towards the top end of the org.

Re: If you thought code writing speed was your problem you have bigger problems

#195

Post by twelvevaginas »

If LLMs didn’t forget everything ~500 lines ago I would be sipping Mai Tais.

The lies about “agentic teams” and stacking GPUs in your apartment would come true.

The only thing stopping a Jira board from self-implementing is context size limitations.

Instead we have StackOverflow: Interactive Mode

I disagree - if we really did have fully automatic task-to-PR that would basically solve it.

Yeah sure you have product design and feature scoping this and that but the engineering problem is solved in the way the arithmetic problem is solved.

Re: If you thought code writing speed was your problem you have bigger problems

#196

Post by hintymad »

giancarlostoro wrote: post #184
hintymad wrote: post #176

How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment? When a person writes code, the person reasons out the code multiple times, step by step, so that they don't make at least stupid or obvious mistakes. This level of close examination is not covered in code review. And arguably this is why we can tru…

> How do people ensure that AI don't produce subtle and stupid mistakes that humans usually don't make, like the one in Amazon that deleted the entire production deployment? Right... Because Humans have never ever accidentally rm -rf'd a production system in the wrong spot? GitLab has entered the chat. Or that time an S3 developer purged more than intended, causing internet outages. All the above are from 2017. Then…

I was not saying that humans are always right. I was assuming that humans probabilistically would make fewer obvious mistakes, which of course could be wrong and hence my questions. Speaking of QA, we would require AI to generate test cases, right? If so, do we rely on human review to ensure the quality of the test cases?

Re: If you thought code writing speed was your problem you have bigger problems

#197

Post by Bukhmanizer »

Rapzid wrote: post #85
Bukhmanizer wrote: post #64

Earlier quoted context omitted.

I think a lot of the discourse around LLMs fails because of organizational differences. I work in science, and I’ve recently worked with a couple projects where they generated >20,000 LOC before even understanding what the project was supposed to be doing. All the scientists hated it and it didn’t do anything that it was supposed to. But I still felt like I was being “anti-ai” when criticizing it. I understand that i…

I'm starting to see this. It starting to seem like a lot of the people making the most specious, yet wild AI SLDC claims are: * Hobbyist or people engaged in hobby and personal projects * Startup bros; often pre-funding and pre-team * Consultancies selling an AI SDLC as that wasn't even possible 6 months ago as "the way; proven, facts!" It's getting to the point I'd like people to disclose the size of the team and or…

The rule of thumb I have in my head right now is that AI will benefit people with deep specialized knowledge a lot, but people with shallow knowledge or skills can’t build anything that your average SWE with a Claude code subscription can’t replicate in a few hours.

Most LinkedIn influencers, startup bros and consultancies kind of fall into the latter.

Re: If you thought code writing speed was your problem you have bigger problems

#198

Post by _under_scores_ »

ohyoutravel wrote: post #152
_under_scores_ wrote: post #117

Earlier quoted context omitted.

Oh! Whats the tell out of curiosity?

This one in particular is a new account with a high volume of similarly-structured posts over an impossibly short time. Bigger tells are the other two green accounts posting multiple top level comments in this topic that are nearly identical. Perhaps the programmer had an off by one error somewhere. I count at least three top level posters, if not as many as five, in this topic that are LLMs. The real absurdity is de…

That's depressing. Admittedly I was just browsing on my phone whilst waiting for something but the comment read as real.

Re: If you thought code writing speed was your problem you have bigger problems

#199

Post by apsurd »

adwn wrote: post #193
apsurd wrote: post #186

Earlier quoted context omitted.

This isn't in defense of perfectly crafted code. It's about NO CODE. Do not write (ai-moar) code! It's not the code that is the problem. I understand the need for MVP to bring an idea into reality. It's the feedback that's valuable not the code. This is not about the code. So why is the argument "write more code"? In any case, I have yet to create a product on my own that has done well financially. So what the hell d…

> So why is the argument "write more code"? It isn't, that's what you injected. The argument was "write [the same amount of] code faster ". And that is undoubtedly a good thing, because execution speed can make or break your startup.

I agree with that.

Re: If you thought code writing speed was your problem you have bigger problems

#200

Post by array_key_first »

vidarh wrote: post #113
bob1029 wrote: post #11

Earlier quoted context omitted.

> Why can't we figure out the right thing faster by building the wrong thing faster? Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time. This is easily the biggest bottleneck in B2B/SaaS stuff for banking. You can iterate maybe once a week if you have a really, really good client.

The customer doesn't need to be shown every "wrong thing".

In my experience this just makes them lose confidence in you and the company. So when it eventually is right, they're resistant. Worst case you lose the contract.
Post reply on HN