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

Development speed is not a bottleneck

pawelbrodzinski.substack.com

Post reply on HN
Print view View original

81–90 of 153 posts

Re: Development speed is not a bottleneck

#81

Post by flail »

ciconia wrote: post #40

The article sort of glosses over this, but to me the real question is delivering value over the long run . This takes patience and tenacity not just from developers but also from management. Making a product that lasts and that evolves and that delivers for your clients is definitely a lot more challenging (and finally rewarding) than vibe-coding an MVP in a couple of weeks. I have the impression that in that regard…

That's just another great vantage point to consider when looking at product development.

Accompanying many early-stage startups in their journey, I see how often the development (which we're responsible for) takes a back seat. Sometimes the pivotal role will be customer support, sometimes it will be business development, and often product management will drive the whole thing.

And there's one more follow-up thought to this observation. Products that achieved success, inevitably, get into a spiral of getting more features. That, in turn, makes them more clunky and less usable, and ultimately opens a way for new players who disrupt the niche.

At some point, adding more features in general makes things worse--too complicated, too overwhelming, making it harder to accomplish the core task. And yet, adding new stuff never ceases.

In the long run, the best tactic may actually be to go slower (and stop at some point), but focus on the meaningful changes.

Re: Development speed is not a bottleneck

#82

Post by uhura »

This kind of stance cannot be made without properly setting the context for the software. It is very clear that different software backgrounds have different needs a different development strategies that are more efficient.

LLMs are a tool that added a new dimension to explore. While I haven't like many felt actual gains, others are finding, and time will allow us to better judge if those can lead to long term impacts in the economy.

Just based on what I've been reading and experiencing: - Short term POCs can reach validation stage faster. - Mature cloud software needs a lot of extra tooling (LLMs don't understand the codebase, lack of places to derive good context from, and so on). - Anything in between for cloud seems to be a hit or miss, where people are mostly trading first iteration time for more refactoring later down the line.

From another perspective, areas of software where things are a lot more about numbers (cpu time, memory consumption, and so on), may benefit a lot from faster development/coding as the validation phase is either shorter or can be executed in parallel.

The key reality here is that I've been observing higher expectations for deliveries without a proof that we actually got better at coding in general. Which means that sacrifices are being made somewhere.

Re: Development speed is not a bottleneck

#83

Post by khazhoux »

goalieca wrote: post #5

Development is always a bottleneck. Writing lines of code usually isn’t. I end up pumping out more leetcode during an interview than I do during a week or two on real products. No one has meaningfully measured lines of code as a metric of productivity since my career began in the mid-2000.

On the other hand, there’s tons of people here on HN who will claim that there’s zero connection between lines of code written and developer productivity. Obviously, deleting bad/unused code is good. And obviously, some tricky bugs are fixed in one line. But you can’t build something new without some (usually, very many) lines of code.

No code -> no software.

Re: Development speed is not a bottleneck

#84

Post by chrisweekly »

thenanyu wrote: post #11

It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…

Yes - and tightening the OODA (Observe, Orient, Decide, Act) loop is essential for organizational velocity.

Re: Development speed is not a bottleneck

#85

Post by gyrovagueGeist »

ACCount37 wrote: post #77
giancarlostoro wrote: post #43

Earlier quoted context omitted.

I can agree with this sentiment. It does not matter how insanely good LLMs become, if you cannot assess it quickly enough. You will ALWAYS want a human to verify and validate, and test the software. There could be a ticking timebomb in there somewhere. Maybe the real skynet will kill us with ticking time bomb software bugs we blindly accepted.

The threshold of supervision keeps rising - and it's going to keep rising. GPT-2 was barely capable of writing two lines of code. GPT-3.5 could write a simple code snippet, and be right more often than it was wrong. GPT-4 was a leap over that, enabling things like "vibe coding" for small simple projects, and GPT-5 is yet another advancement in the same direction. Each AI upgrade brings forth more capabilities - with…

In the middle term, I almost feel less productive using modern GPT-5/Claude Sonnet 4 for software dev than prior models, precisely because they are more hands off and less supervised.

Because they generate so much code, that often passes initial tests, looks reasonable, and fails in nonhuman ways, in a pretty opinionated style tbh.

I have less context (and need to spend much more effort and supervision time to get up to speed to learn) to fix, refactor, and integrate the solutions, than if I was only trusting short few line windows at a time.

Re: Development speed is not a bottleneck

#86

Post by flail »

titzer wrote: post #10
vessenes wrote: post #6

This is just so, so wrong. LLMs change the surface of what's "hard" to do in a coding exercise. Many a project has so much boiler plate, edge cases, etc. that months+ can be taken up dealing with what is ultimately a very boring activity. Add on time to assimilate APIs, bug test, etc. This stuff does matter.

It reads like the author never debugged a program. Development speed is not just the time to write code, but also test, stabilize and debug it, with most of the latter being a risk that might cost you a lot much later. If your engineers have to take a two hour or two day or two week timeout to debug issues from weeks, months, or years back, then that really costs as development time. Vibe coding is going to make this…

Oh, development sure does mean the whole package. Architectural design, automated tests, coding, refactoring, code review and post-review changes, deployment, manual tests, etc.

A question: what if all those activities are to build a feature that will harm user retention or a product no one wants?

A follow-up question: what if we could have known that up front, or there was a simple way to learn that?

Because so often we build stuff that shouldn't have been built in the first place (appalling startup success rate is probably a good enough statistical measure of that). And yes, there are ways to learn that we're building the wrong thing, other than building a fully-fledged version of it.

Re: Development speed is not a bottleneck

#87

Post by BinaryIgor »

Interesting article, but a slightly misleading title.

Other than that the discovery process of what you should build is the hardest and the costliest part, the main conclusion from the article seems to be that if you outsource the first iterations to AI via vibe-coding, you will have much harder time changing and evolving it from there (iterating); to this, I agree

Re: Development speed is not a bottleneck

#88

Post by warkdarrior »

gyrovagueGeist wrote: post #85
ACCount37 wrote: post #77

Earlier quoted context omitted.

The threshold of supervision keeps rising - and it's going to keep rising. GPT-2 was barely capable of writing two lines of code. GPT-3.5 could write a simple code snippet, and be right more often than it was wrong. GPT-4 was a leap over that, enabling things like "vibe coding" for small simple projects, and GPT-5 is yet another advancement in the same direction. Each AI upgrade brings forth more capabilities - with…

In the middle term, I almost feel less productive using modern GPT-5/Claude Sonnet 4 for software dev than prior models, precisely because they are more hands off and less supervised. Because they generate so much code, that often passes initial tests, looks reasonable, and fails in nonhuman ways, in a pretty opinionated style tbh. I have less context (and need to spend much more effort and supervision time to get up…

> I almost feel less productive using modern GPT-5/Claude Sonnet 4 for software dev than prior models, precisely because they are more hands off and less supervised.

That is because you are trained in the old way to writing code: manual crafting of software line by line, slowly, deliberately, thoughtfully. New generations of developers will not use the same workflow as you, just like you do not use the same workflow as folks who programmed punch cards.

Re: Development speed is not a bottleneck

#89

Post by franktankbank »

thenanyu wrote: post #67
franktankbank wrote: post #41

Earlier quoted context omitted.

Feedback from customers is the longest time.

Get it sooner then! By getting to market faster

Its one variable in the sum of all the times. You are asserting without much evidence that the bottleneck is the dev turnaround time. I think for a lot of people there's evidence that its dev is about 10% or less of the back and forth. I've sat on my hands for months while requirements have got sorted and no this wasn't something I could just jump into which I'm sure you'd (wrongly) suggest is the right approach. Have you ever been involved in a profitable project?

Re: Development speed is not a bottleneck

#90

Post by flail »

thenanyu wrote: post #64
flail wrote: post #56

Earlier quoted context omitted.

Since I haven't mentioned the context in the article, it is a small agency with a customer target of early-stage (ideally earliest-stage) product startups. We have literally one half-hour-long sync meeting a week. The rest is as lightweight as possible, typically averaging below 10 minutes daily with clients (when all the decisions happen on the fly). I've worked in the corpo world, too, and it is anything but. We do…

The map is not the territory. Validating against anything other than the actual feature is a lossy proxy. It may be an acceptable tradeoff because building the feature is too costly but that’s the whole discussion at hand.

Sure. And yet, last time I checked, we've had plenty of applications for maps.

I like this metaphor. Looking at a map, we may get a pretty good understanding of whether it's a place we'd like to spend time, say, on vacation.

We don't physically go to a place to scrutinize it.

And we don't limit ourselves to maps only. We check reviews, ask friends, and what have you. We do cheap validation before committing to a costly decision.

If we planned vacations the way we build software products, we'd just go there (because the map is not the territory), learn that the place sucks, and then we'd complain that finding good vacation spots is costly and time-consuming. Oh, and we'd mention that traveling is a bottleneck in finding good spots.

Post reply on HN