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

151–160 of 231 posts

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

#151

Post by bcassedy »

tovej wrote: post #42
petcat wrote: post #20

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and…

Is this a copypasted response? I've seen the exact same bs in other AI threads on this site.

This user has posted the parent post nearly verbatim twice. And the exact same responses about determinism several times.

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

#152

Post by ohyoutravel »

_under_scores_ wrote: post #117
ohyoutravel wrote: post #99

Earlier quoted context omitted.

No I mean you. The person to whom you are responding is a bot. No judgment, just pointing this out in case you don’t want to waste human brain cycles.

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 devnotes responding to myylogic, who are both LLMs.

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

#153

Post by slopinthebag »

closewith wrote: post #102
onlyrealcuzzo wrote: post #56

Earlier quoted context omitted.

AI is really good when: 1. you want something that's literally been done tons of times before, and it can literally just find it inside its compressed dataset 2. you want something and as long as it roughly is what you wanted, it's fine It turns out, this is not the majority of software people are paying engineers to write. And it turns out that actually writing the code is only part of what you're paying for - much…

> It turns out, this is not the majority of software people are paying engineers to write. The above are definitely the majority of software people are paying developers to write. By an order of magnitude. The novel problems for customers who specifically care about code quality is probably under 1% of software written. If you don't recognise this, you simple don't understand the industry you work in.

Non-novel problem != non-novel solution

Most problems are mostly non-novel but with a few added constraints, the combination of which can require a novel solution.

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

#154

Post by zelphirkalt »

raw_anon_1111 wrote: post #79
podgorniy wrote: post #60

Yeah, we again have a solution (LLMs) in search of problems. Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z". -- This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to…

This is categorically not true. For almost all of my 30 years it’s been 1. Talk to the business, solve XYProblems, deal with organization complexity, learn the business and there needs. 2. Design the architecture not just “the code”, the code has to run on something. 3. Get the design approve and agree on the holy trinity - time/cost/budget 4. Do the implementation 5. Test it for the known requirements 6. Get stakeho…

I see step 4 as interwoven with other steps. The implementation ideally takes into consideration the domain and while implementing, potentials for flexibility are potentially revealed, to be taken advantage of, "without programming ourselves into a corner". Implementation also is of course related to maintenance. Maintenance already needs to be taken into account. How easy is it to adapt the system we are building later?

This all happens while we are at the implementation stage and impacts all other aspects of the whole thing. It is a grunt work, but we need elite grunts, who see more than just the minimal requirements.

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

#155

Post by thepasch »

> Someone approves a PR they didn’t really read. We’ve all done it (don’t look at me like that). It merges. CI takes 45 minutes, fails on a flaky test, gets re-run, passes on the second attempt (the flaky test is fine, it’s always fine, until it isn’t and you’re debugging production at 2am on a Saturday in your underwear wondering where your life went wrong. Ask me how I know… actually, don’t). The deploy pipeline requires a manual approval from someone who’s in a meeting about meetings. The feature sits in staging for three days because nobody owns the “get it to production” step with any urgency.

This is the company I (soon no longer) work at (anyone hiring?).

The thing is that they don’t even allow the use of AI. I’ve been assured that the vast majority of the code was human-written. I have my doubts but the timeline does check out.

Apart from that, this article uses a lot of words to completely miss the fact that (A) “use agents to generate code” and “optimize your processes” are not mutually exclusive things; (B) sometimes, for some tickets - particularly ones stakeholders like to slide in unrefined a week before the sprint ends - the code IS the bottleneck, and the sooner you can get the hell off of that trivial but code-heavy ticket, the sooner you can get back to spending time on the actual problems; and (C) doing all of this is a good idea completely regardless of whether you use LLMs or not; and anyone who doesn’t do any of it and thinks the solution is to just hire more devs will run into the exact same roadblocks.

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

#156

Post by andrewstuart »

slopinthebag wrote: post #139
andrewstuart wrote: post #109

These “LLM programming ain’t nothing special” posts are becoming embarrassing for the authors who - due to their anti AI dogmatism - have no idea how truly incredibly fast and powerful it’s become. Please stop making fools of yourselves and go use Claude for a month before writing that “AI coding ain’t nothing special” post. Ignorance of what Claude can actually do means your arguments have no standing at all. “I hat…

What makes you think they haven't? I agree with them and I've been heavily using Claude / Codex for a while now. And I'm slowly trying to use AI more selectively because of these concerns.

Ok tell me tangibly what you are programming, what you ask it to do and I’ll do similar and we can compare outcomes.

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

#157

Post by webdood90 »

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

Ugh, sounds awful. Constantly context switching and juggling multiple tasks is a sure-fire way to burn me out.

The human element in all of this never seems to be discussed. Maybe this will weed out those that are unworthy of the new process but I simply don't want to be "on" all the time. I don't want to be optimized like this.

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

#158

Post by closewith »

onlyrealcuzzo wrote: post #134
closewith wrote: post #102

Earlier quoted context omitted.

> It turns out, this is not the majority of software people are paying engineers to write. The above are definitely the majority of software people are paying developers to write. By an order of magnitude. The novel problems for customers who specifically care about code quality is probably under 1% of software written. If you don't recognise this, you simple don't understand the industry you work in.

As it turns out - "just make this button green" - is not the majority of what people at FAANG are doing... As it turns out - 4 years before LLMs - at least one of the FAANGs already had auto-complete so good it could do most of what LLMs can practically do in a gigantic context. But, sure...

Less than 1% of software developers work at FAANG.

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

#159

Post by darrelld »

nicbou wrote: post #114

I'm a solo dev. In fact I'm hardly a dev; it's just a helpful skill. Code writing speed IS a problem, because it takes valuable time away from other tasks. A bit like doing the dishes. I just set up Claude Code tonight. I still read and understand every line, but I don't need to Google things, move things around and write tests myself. I state my low-level intent and it does the grunt work. I'm not going to 10x my pr…

Exactly!

I've been working on a side project that I started in 2020. If I wanted to implement a new feature it was: - Wait for regular work hours to wrap up around 5 or 6 PM - Get dinner and rest / relax until around 8 or 9 PM - Open up the editor, think about the problem, Google things, read stack overflow which gets it 95% of the way there, Google more, dig deeper into the docs finally find what I needed - Write a function, make some progress, run into another roadblock, repeat previous point - Look up and it's now 1AM. I should write tests for this, but I'll add that to the backlog - Backlog only ever grows

Now with AI I describe what I want, it does the grunt work likely cleaner than I ever could, adds tests and warns me about potential edge cases.

I don't know about 10x, but I'm releasing new features that my client cares about faster and I have more time to myself.

All of the negativity around AI writing code sounds like people who would say "You can't trust the compiler, you need to write the machine code yourself"

Will AI fuck up? Yes But I'm the human in the chair guiding it, and learning myself how better to prompt it to keep it from those fuck ups with every iteration.

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

#160

Post by closewith »

slopinthebag wrote: post #153
closewith wrote: post #102

Earlier quoted context omitted.

> It turns out, this is not the majority of software people are paying engineers to write. The above are definitely the majority of software people are paying developers to write. By an order of magnitude. The novel problems for customers who specifically care about code quality is probably under 1% of software written. If you don't recognise this, you simple don't understand the industry you work in.

Non-novel problem != non-novel solution Most problems are mostly non-novel but with a few added constraints, the combination of which can require a novel solution.

Those are exactly the types of problems that LLMs excel at solving.
Post reply on HN