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

281–290 of 446 posts

Re: The bottleneck was never the code

#281

Post by datsci_est_2015 »

quikoa wrote: post #261
solatic wrote: post #258

Earlier quoted context omitted.

> Code is a liability You're over-simplifying. Code in and of itself is neither an asset nor a liability. The minimal amount of code needed to solve business needs with no additional complexity is an asset with some maintenance liabilities attached (same as how a farmer's tractor is an asset that needs to be maintained), with depreciation if unmaintained (bitrot). Any code used to build unnecessary complexity is pure…

Yes, if code is only a liability then just delete the code and poof liability is gone.

Would it be fair to say that complexity is a liability, and LOC is an (approximate) measure of complexity?

Re: The bottleneck was never the code

#283

Post by auggierose »

jwoq9118 wrote: post #242
auggierose wrote: post #128

I cringe every time I read the word "load-bearing" in an article.

It instantly made me think this was either written by AI or heavily edited, and I hadn't gotten that sense until the moment I saw load-bearing. I hate that em dashes have been killed by AI as well. Hundreds of years ago Charles Dickens was using them in his novels and today someone will read his books and in ignorance actually think AI wrote it.

I don’t mind em dashes, I use them myself. But load-bearing context, that’s just really bad writing.

Re: The bottleneck was never the code

#284

Post by crabbone »

aspenmartin wrote: post #271
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…

- systemic tech debt is now addressable at scale with LLMs. Future models will be good enough to sustain this, if people don’t believe this I would challenge them to explain why. First consider if you understand what scaling laws are like chinchilla and how RL with verification works fundamentally - I completely agree with you about fundamentally the limitation being the business able to coherently articulate itself…

> systemic tech debt is now addressable at scale with LLMs.

Is there any reason to believe this? I've only seen the evidence of the contrary so far.

My experience with AI coding aides is that they, generally:

1. Don't have an opinion.

2. Are trained on code written using practices that increase technical debt.

3. Lack in the greater perspective department, more focused on concrete, superficial and immediate.

I think, I need to elaborate on the first and explain how it's relevant to the question. I'll start with an example. We have an AI reviewer and recently had migrated a bunch of company's repositories from Bitbucket to GitLab. This also prompted a bunch of CI changes. Some projects I'm involved with, but don't have much of an authority, that are written in Python switched to complicated builds that involve pyproject.toml (often including dynamic generation of this cursed file) as well as integration with a bunch of novelty (but poor quality) Python infrastructure tools that are used for building Python distributalbe artifacts.

In the projects where I have an authority, I removed most of the third-party integration. None of them use pyproject.toml or setup.cfg or any similar configuration for the third-party build tool. The project code contains bespoke code to build the artifacts.

These two approaches are clearly at odds. A living and breathing person would either believe one to be the right approach or the other. The AI reviewer had no problems with this situation. It made some pedantic comments about the style and some fantasy-impossible-error-cases, but completely ignored the fact that moving forward these two approaches are bound to collide. While it appears to have an opinion about the style of quotation marks, it completely doesn't care about strategic decisions.

My guess as to why this is the case is that such situations are genuinely rarely addressed in code review. Most productive PRs, from which an AI could learn, are designed around small well-defined features in the pre-agreed upon context. The context is never discussed in PRs because it's impractical (it would usually require too much of a change, so the developers don't even bring up the issue).

And this is where real large glacier-style deposits of tech debt live. It's the issues developers are afraid of mentioning because of the understanding that they will never be given authority and resources to deal with.

Re: The bottleneck was never the code

#285

Post by AlienRobot »

nayroclade wrote: post #15

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

Textbook example of goomba fallacy.

Re: The bottleneck was never the code

#286

Post by crabbone »

aspenmartin wrote: post #272
leptons wrote: post #247

Earlier quoted context omitted.

And now they're almost forcing us to produce machine-made tech-debt at an industrial scale. The AI craze isn't going to produce the boon some people think it will. And the solution? More AI, unfortunately.

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 better practices (something AI isn't capable of, at least not the kind of AI that's being sold to the programmers today).

Re: The bottleneck was never the code

#287

Post by arnitdo »

esafak wrote: post #75
abduhl wrote: post #34

Earlier quoted context omitted.

Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable. I’ve noticed this push to try to clothe hypocrisy in made up virtues like intellectual curiosity and mental plasticity a lot lately. All I can think…

Abduhl, the nature of the job has changed; before it was coding, now it is managing the AI coding. What was and remains valuable is delivering value. This principle has not changed.

If your job was only coding then you are the most replaceable of the bunch. Traditional software engineering is a broader domain that, as rightly pointed out, will require you to actually *sit and talk* with the worst communicators you'll meet in your life.

Looking at a slice of most folks' workday and calling it their whole job is in my opinion, incorrect.

Re: The bottleneck was never the code

#288

Post by aerhardt »

nayroclade wrote: post #15

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

I've been selling and managing my own projects for over six years, so I don't count myself in the antisocial camp. But LLMs haven't changed the fact that I like to have at least five hours of deep work every day.

Re: The bottleneck was never the code

#289

Post by aspenmartin »

crabbone wrote: post #284
aspenmartin wrote: post #271

Earlier quoted context omitted.

- systemic tech debt is now addressable at scale with LLMs. Future models will be good enough to sustain this, if people don’t believe this I would challenge them to explain why. First consider if you understand what scaling laws are like chinchilla and how RL with verification works fundamentally - I completely agree with you about fundamentally the limitation being the business able to coherently articulate itself…

> systemic tech debt is now addressable at scale with LLMs. Is there any reason to believe this? I've only seen the evidence of the contrary so far. My experience with AI coding aides is that they, generally: 1. Don't have an opinion. 2. Are trained on code written using practices that increase technical debt. 3. Lack in the greater perspective department, more focused on concrete, superficial and immediate. I think,…

You are not wrong about anything you’re saying but like I said this misses the forest for the trees. I’m talking about like the next ~2 years. There is a common idea that we don’t understand this technology or what will happen performance wise. We know a lot more about what’s going to happen than people think. It’s because none of this is new. We’ve known about neural nets since the 40s, we know how RL works on a fundamental level and it has been an active and beautiful field of research for at least 30-40 years, we know what happens when you combine RL with verifiable rewards and throw a lot of compute at it.

One big misconception is that these models are trained to mimic humans and are limited by the quality of the human training data, and this is not true and also basically almost entirely the reason why you have so much bullishness and premature adoption of agentic coding tools.

Coding agents use human traces as a starting point. You technically don’t have to do this at all but that’s an academic point, you can’t do it practically (today). The early training stages with human traces (and also verified synthetic traces from your last model) get you to a point where RL is stable and efficient and push you the rest of the way. It’s synthetic data that really powers this and it’s rejection sampling; you generate a bunch of traces, figure out which ones pass the verification, and keep those as training examples.

So because

- we know how this works on a fundamental level and have for some time

- human training data is a bootstrap it’s not a limitation fundamentally

- you are absolutely right about your observations yet look at where you are today and look at say Claude sonnet 3.x. It’s an entire world away in like a year

- we have imperfect benchmarks all with various weaknesses yet all of them telling the same compelling story. Plus you have adoption numbers and walled garden data that is the proof in the pudding

The onus is on people who say “this is plateauing” or “this has some fundamental limitation that we will not get past fairly quickly”.

Re: The bottleneck was never the code

#290

Post by aspenmartin »

visarga wrote: post #274
aspenmartin wrote: post #271

Earlier quoted context omitted.

- systemic tech debt is now addressable at scale with LLMs. Future models will be good enough to sustain this, if people don’t believe this I would challenge them to explain why. First consider if you understand what scaling laws are like chinchilla and how RL with verification works fundamentally - I completely agree with you about fundamentally the limitation being the business able to coherently articulate itself…

> BUT the benefit now is you can basically prototype for free. But.. so can your competitors. And that changes the value proposition.

How do you mean?
Post reply on HN