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

The bottleneck was never the code

thetypicalset.com

Post reply on HN
Print view View original

291–300 of 446 posts

Re: The bottleneck was never the code

#291

Post by janalsncm »

fmbb wrote: post #236
paldepind2 wrote: post #100

From the article: > Jevons Paradox: when something gets cheaper, you tend to use more of it, not less. That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper. What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), bu…

> Obviously usage of something goes up when it gets cheaper. Sure. But is it not also obvious that when usage of a resource becomes more efficient, the price of that ”usage” becomes cheaper? So usage goes up obviously because efficiency increases. It is called a paradox because some people naively think that increasing efficiency is a good way to decrease consumption. Almost everything that is called a ”paradox” is t…

It’s surprising (not using the term paradox) in situations where demand was seen as inelastic.

An example of probably inelastic demand is the cost of diamonds which has fallen as synthetic diamonds enter the market. But people typically don’t buy more engagement rings than before.

With code it could be different. People might think that the amount of code that needs to be written is fixed, so the ability for a person to write code implies a reduced demand for people who write it.

In reality, bringing the cost down may unlock new use cases, so the number of actual coders might increase.

Re: The bottleneck was never the code

#292

Post by arnitdo »

dyauspitr wrote: post #89
jugg1es wrote: post #17

I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company's I have work…

It’s part of the problem but AI also can crush this on pure lines of code and functionality alone. It can put out 100,000 lines of somewhat decent code in a day. That usually takes months or years of manual coding for a team.

There is a reason that kLOC / FP were rightly shunned out of being measurable metrics years ago. The same clown show seems to be resurging with "tokens". There is, in my opinion, no real formula or metric that you can define for "good" code or "bad" code. Tickets and ceremonial activities, however abstract that into a N-nary status value that seems easier to judge upon.

Re: The bottleneck was never the code

#293

Post by IshKebab »

TheLudd wrote: post #120
IshKebab wrote: post #113

Earlier quoted context omitted.

No, we pay less for it. But there's much higher demand so overall use goes up.

Right. That is not a paradox as stated. The paradox would be: * a TV used to be really expensive. So a home just had one * over time TVs become half the price. * now a home has 3 TVs, i.e paying 150% of what they initially payed.

It is a paradox. The paradox is that increasing the efficiency of resource usage can lead to more resource usage.

If you think that isn't a paradox because you can fairly easily explain why that is the case, you need to go and check what "paradox" means.

Re: The bottleneck was never the code

#294

Post by aspenmartin »

crabbone wrote: post #286
aspenmartin wrote: post #272

Earlier quoted context omitted.

The solution truly is more AI, yes. > AI craze isn't going to produce the boon some people think it will. What’s the boon you don’t think it will produce?

No. It's not more AI. The solution is designing and sticking to development process that is more resilient to errors than the one that's currently happening. This isn't a novel idea. Code reviews weren't always part of the process, neither was VCS, nor bug tracker etc. The way AI is set up today, it's trying to replicate the (hopefully) good existing practices. Possibly faster. The real change comes from inventing be…

What better practices do you mean? Are you saying we just need different more agentic-friendly practices that ensure scaled reliability beyond what we can manually check? If so I totally agree.

AI is 100% capable fundamentally of making new processes. Look I mean it’s not like I think opus 4.7 is all you need, but how can you argue with the fact that adoption since 4.5 has been an inflection point? That’s kind of proof that reliability has reached a level that serious usage is possible. That’s over a period of months. When you zoom out further you see this is extremely predictable even a few years ago, despite the absolute hissy fits thrown on HN when CEOs began saying this.

Agentic coding is verifiable and this implies there are very few practical limits to what it can do. Combine that with insanely active research on tackling the remaining issues (hallucinations — which are not a fundamentally unsolvable problem at a practical level, context rot, continual learning etc)

Re: The bottleneck was never the code

#295

Post by arnitdo »

HarHarVeryFunny wrote: post #121

> What may save us it that agents are unreasonably good at reading exhaustively. An agent will read every PR comment, every closed issue, every commit message, every stale design doc ... > Not just “this module exists,” but “this module is weird because the migration had to preserve old behavior,” or “this benchmark matters because a previous optimization silently changed the distribution.” The thesis here is that an…

Even if writing new code is not the problem or the bottleneck anymore, a major blocker is one CoreService.java file someone wrote 10 years ago that is keeping the whole system glued together. Only they know how it works, and how to keep it working. Parroting my own words from a while back, inferred intent is not the same as initial intent. This is just reverse engineering except somewhat automated

Re: The bottleneck was never the code

#296

Post by trjordan »

Yes, but: writing code always teaches you something.

I've worked at founder-sized startups and $xxb dollar public companies. I've never read a product spec, a pitch deck, or a PRD that describes a solution that, if implemented in the way described, would solve the problem. Building the thing teaches you how it should behave.

Software is a complex, interactive medium. Iterating in the code, with people who understand the problem and care to see it solved, is the only way I've seen valuable products get created. Meetings and diagrams help, but it's not until you write some working software that you know whether you have something.

Re: The bottleneck was never the code

#297

Post by simonbw »

runeks wrote: post #269
paldepind2 wrote: post #100

From the article: > Jevons Paradox: when something gets cheaper, you tend to use more of it, not less. That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper. What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), bu…

> What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), but still the total usage of that resource increases. Why is this stated as a paradox? One simple cause is the given task being performed more than it was before because it is now cheaper (since it uses fewer resources).

In most real-world use of the term, a paradox isn't something that's impossible, it's just something that intuitively seems wrong when you first think about it.

"I got a Prius so now I am spending more money on gas" sounds ridiculous, but it would be an instance of this paradox.

Re: The bottleneck was never the code

#298

Post by tomjakubowski »

nomel wrote: post #280
tikhonj wrote: post #114

Earlier quoted context omitted.

Ceremonies and tickets aren't especially effective for actual collaboration. They're primarily tools for making work legible and controllable to management. There is a reason (well, many reasons) that, if I'm working on a creative project with somebody outside a company, we would never think of reaching for Scrum ceremonies or Jira. It is more than perfectly consistent to complain about that while valuing collaborati…

I require Jira for all my work to protect myself from three things, definitely not productivity: 1. µManagement asking "What have you even been doing?" Now they have a dashboard, and I have a nice record. 2. Protect me from people who wouldn't tell me problems existed, but would tell their managers they were blocked by those problems. Now, the understanding is that if the Jira doesn't exist, then the problem doesn't…

This is a good way of using a ticket tracker: bottom-up, where engineers, testers, and other stakeholders are empowered to create and manage tickets as a means of communicating about their work and what they are blocked on. It's part of the writing culture mentioned in TFA.

In some places, the ticket tracker works top-down: only the manager creates tickets, and the manager makes measurements about tickets closed, velocity, and so on to assess the productivity of their team.

I think the great divide on JIRA and JIRA-likes often comes down to which culture people have been exposed to.

Re: The bottleneck was never the code

#299

Post by skiing_crawling »

As software engineer, we should collectively realize that this is all cope. Every article or comment about how AI will never be smart enough, etc, etc will only be true until its not. One of our main valuable skill sets is now partially automated. Some of us are completely obsolete and its coming for the specialists and more experienced ones within a decade tops. You're not going to convince anyone that "um actually we're better because we bike shed more".

Stuff like this is ridiculous and comes off as frantically trying to save your ass. Its pretty obvious at this point that we will just throw more matmuls at it until it can do this or something equivalent.

> Agents cannot do osmosis. They do not get context by being in the room, by half-hearing the planning conversation, or by carrying the memory of the last incident.

Post reply on HN