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

211–220 of 231 posts

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

#211

Post by Sammi »

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

Then how will you know if it's the wrong thing? If you're not user testing then you're just guessing.

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

#212

Post by senko »

skydhash wrote: post #108
senko wrote: post #73

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. Heh, depends on what you do. Many times the stakeholders can't explain what they want but can clearly articulate what they don't want when they see it. Gener…

> Generate a few alternatives, have them pick, is a tried and true method in design. It was way too expensive when coding was manual, so often you need multiple rounds of meetings and emails to align. Why do you need coding for those. You can doodle on a whiteboard for a lot of those discussions. I use Balsamiq[0] and I can produce a wireframe for a whole screen in minutes. Even faster than prompting. > If you don't…

I've been using Balsamiq since back in 2012 (perhaps earlier, can't find an earlier reference in email), when it was all in Flash/Flex (IIRC).

For UX, approach like that can often work. For non-UI stuff, more complex processes and exploration (because nobody is actually sure what's going to work best), the handwaving is just deluding everyone.

I've been on enough demos where customers pretended they understood the concepts only to be surprised later, or going back and forth for months on what they actually need, to know that:

> If you think coding was a bottleneck, that means you spent too much time doing when you should have been thinking

is cute, but naive.

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

#213

Post by petcat »

discreteevent wrote: post #173
petcat wrote: post #94

Earlier quoted context omitted.

Compilers can generate wrong output in many different ways. And they're all analogous to the same ways that a sophisticated LLM can generate wrong outputs. The compiler relies on: * Careful use of the ENV vars and CLI options * The host system, or the compilation of the target executable (for cross-compiling) * It relies on the source code specifically How is this really different from careful prompt engineering, and…

> How is this really different from careful prompt engineering, and an extensive proposal/review/refine process? So different that those concepts don't even exist. I don't have to carefully prompt my compiler in case it might misinterpret what I'm saying. My compiler comes with a precisely specified language. I never, ever, review the output of my compiler.

> I don't have to carefully prompt my compiler in case it might misinterpret what I'm saying.

Yes you do. You give it flags, you give it ENV vars.

> My compiler comes with a precisely specified language.

No, it doesn't.

> I never, ever, review the output of my compiler.

Yes, that's the whole point of the exercise. Have you ever reviewed the -S output from GCC? No? So do you really know what your code is doing?

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

#214

Post by throwway262515 »

furyofantares wrote: post #6

> The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in…

[dead]

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

#215

Post by supermdguy »

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…

> Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out)

This has helped me a lot. Normally I'd feel really attached to big refactors because of sunk costs, but when AI does a huge refactor it's easier to honestly decide that it wasn't worth it and unnecessarily increased complexity.

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

#216

Post by datsci_est_2015 »

petcat wrote: post #78
ruszki wrote: post #58

Earlier quoted context omitted.

Legalese is nowhere near precise, and we have a whole very expensive system because it’s not precise.

It is an attempt the be precise, and to remove doubt. But you're right that doubt still creeps in.

Doubt still creeps in? The entire purpose of the Judiciary branch across all governments that possess one is the interpretation of legal documents. It’s one of the greatest sources of uncertainty in human governance.

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

#217

Post by 000ooo000 »

rubslopes wrote: post #192
brailsafe wrote: post #168

Earlier quoted context omitted.

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

Developer discovers context switching tax

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

#218

Post by bdangubic »

000ooo000 wrote: post #217
rubslopes wrote: post #192

Earlier quoted context omitted.

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.

Developer discovers context switching tax

context switching is amateur stuff. he needs additional 4 terminals to watch over the 4 that are doing the work and just alert him when they misbehave

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

#219

Post by nunez »

furyofantares wrote: post #13
furyofantares wrote: post #6

> The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in…

The post also smells heavily LLM-processed. I feel like I've been had by someone pumping out low effort blog posts.

This reads like old agile blog posts from six years ago (which makes sense, seeing as how the organizational problems then are the same as the organizational problems now). It doesn't feel like AI wrote it to me.

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

#220

Post by rifty »

onlyrealcuzzo wrote: post #56
furyofantares wrote: post #6

> The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in…

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…

While I find your frequent use of 'it turns out' to remind me of https://jsomers.net/blog/it-turns-out .. I do think there may be supportive logic to be had. A lot of software previously wasn't simply hand done, it was done along with implementing libraries of code or using snippet libraries. So, software engineers had already abstracted away coding a lot of the reusable parts between projects they will be now in-house developing with AI.

If so, it might be true that in many cases writing code wasn't as big of the story as some people think for some other people in the industry. I imagine there were many people though who toiled by hand a lot of code they didn't need to before for lack of experience or awareness, and so for them this a big increase in speed.

Post reply on HN