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

Writing Code Was Never the Bottleneck

ordep.dev

Post reply on HN
Print view View original

201–210 of 400 posts

Re: Writing Code Was Never the Bottleneck

#201

Post by lsaferite »

conartist6 wrote: post #184
distalx wrote: post #175

Earlier quoted context omitted.

Any hints on what kind of tools you're creating for the inevitable mess?

https://github.com/bablr-lang/ I'm building a universal DOM for code so that we should see an explosion in code whose purpose is to help clean up other code. If you want to write code that makes changes to a tree of HTML nodes, you can pretty much write that code once and it will run in any web browser. If you want to write code that makes a new program by changing a tree of syntax nodes, there are an incredible numb…

Where does this "universal DOM for code" sit in relation to CSTs and ASTs?

Re: Writing Code Was Never the Bottleneck

#202

Post by dkdbejwi383 »

a_bonobo wrote: post #171
andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

>This lead to a kind of effort inversion, where senior devs spent much more time on these PRs than the junior authors themselves. It's funny, I have the same problem, but with subject matter expertise. I work with internal PR people and they clearly have shifted their writing efforts to be AI-assisted or even AI-driven. Now I as the SME get these AI-written blog posts and press releases and I spend a far more time on…

Part of the solution is pushing back when you spot tons of obvious lazy LLM errors instead of fixing them yourself. Otherwise there's not much incentive for them to improve their effort.

Re: Writing Code Was Never the Bottleneck

#203

Post by pragmatic »

orwin wrote: post #158

I used Sonnet4 to write my last frontend task, fully, with minimal input. It is so much better than ChatGPT it's unbelievable, but while a 6hour coding task was transformed into a 30 minutes supervision task that generated good, but also correct code, I was a bit afraid for new engineers coming into an old project. How are you supposed to understand code if you don't at least read it and fail a bit? I'll continue usi…

LLMs are fantastic at summaries and finding where XYZ happens.

“Where is the customer entity saved to the database?”

Re: Writing Code Was Never the Bottleneck

#204

Post by LtWorf »

aleph_minus_one wrote: post #137
gortok wrote: post #94

Earlier quoted context omitted.

Developers have always loved the new and shiny. Heck, getting developers not to rewrite an application in their new favorite framework is a tough sell. LLM “vibe coding” is another continuation of this “new hotness”, and while the more seasoned developers may have learned to avoid it, that’s not the majority view. CEOs and C-suites have always been disconnected from the first order effects of their cost-cutting edict…

> Heck, getting developers not to rewrite an application in their new favorite framework is a tough sell. This depends a lot on the "programming culture" from which the respective developers come. For example, in the department where I work (in some conservative industry) it would rather be a tough sell to use a new, shiny framework because the existing ("boring") technologies that we use are a good fit for the work…

In my personal experience, web development teams don't really have much to do, so they create work for themselves.

Re: Writing Code Was Never the Bottleneck

#205

Post by superkuh »

Maybe it was never the bottleneck for paid software engineering at incorporated entities but it was definitely, 100%, the bottleneck for most human people.

And now instead of having to get the help or code from an actual programmer, as a non-programmer but technical person, I can generate or alter any small trivial applications I want. I'm not going to be writing an OS or doing "engineering" but if I want to write a GUI widget to display my PCs temps/etc, or alter a massive complex C++ program to have some feature I want (like adding checkpointing to llama.cpp's fine-tune training), suddenly it's trivial and takes 15 minutes. Before it'd take days if it were feasible without help at all.

Re: Writing Code Was Never the Bottleneck

#206

Post by exe34 »

andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

> - Instead of fixing the things in the original PR, I'd often get a completely different approach as the response to my first review. Again, often broken in new and subtle ways.

This kind of thing drove me mad even before LLMs or coding - it started at school when I helped people with homework. People would insist on switching to an entirely different approach midway through explaining how to fix the first one.

Re: Writing Code Was Never the Bottleneck

#207

Post by oytis »

gyesxnuibh wrote: post #198
oytis wrote: post #181

Earlier quoted context omitted.

There are ways to fight it though. Look at Linux kernel for instance - they have been overwhelmed with poor contributions long before LLMs. The answer is to maintain standards that put as much burden on the contributor as possible, and normalizing unapologetic "no" from reviewers.

Does that work as well with non-strangers who are your coworker? I'm not sure. Also if you're organizationally changing the culture to force people to put more effort in writing the code, why are you even organizationally using LLMs...?

> Does that work as well with non-strangers who are your coworker?

Yeah, OK, I guess you have to be a bit less unapologetic than Linux kernel maintainers in this case, but you can still shift the culture towards more careful PRs I think.

> why are you even organizationally using LLMs

Many people believe LLMs make coders more productive, and given the rapid progress of gen AI it's probably not wise to just dismiss this view. But there need to be guardrails to ensure the productivity is real and not just creating liability. We could live with weaker guardrails if we can trust that the code was in a trusted colleague's head before appearing in the repo. But if we can't, I guess stronger guardrails are the only way, aren't they?

Re: Writing Code Was Never the Bottleneck

#208

Post by exe34 »

gyesxnuibh wrote: post #198
oytis wrote: post #181

Earlier quoted context omitted.

There are ways to fight it though. Look at Linux kernel for instance - they have been overwhelmed with poor contributions long before LLMs. The answer is to maintain standards that put as much burden on the contributor as possible, and normalizing unapologetic "no" from reviewers.

Does that work as well with non-strangers who are your coworker? I'm not sure. Also if you're organizationally changing the culture to force people to put more effort in writing the code, why are you even organizationally using LLMs...?

> Does that work as well with non-strangers who are your coworker? I'm not sure.

I imagine if you have a say in their performance review, you might be able to set "writes code more thoughtfully" as a PIP?

Re: Writing Code Was Never the Bottleneck

#209

Post by perlgeek »

> The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication.

I can relate :-)

Our team maintains a configuration management database for a company that has grown mostly organically from 3 to 500+ employees in ~30 years.

We don't have documented processes that would account for most of the write operations, so if we have a question, we cannot just talk to the process owner.

The next option would be to talk to the data owner, but for many of our entities, we don't have a data owner. So we look into the audit logs to see which teams often touch the data, and then we do a meeting with some senior folks from each of these teams to discuss things.

But of course, finding common meeting time slots with several senior people from several teams isn't easy, they're all busy. So that alone might delay something by a few weeks to months.

For low-stakes decisions, we often try to not go through this effort, but instead do things that are easy to roll back if they go wrong.

Once we have identified the stakeholders, have a common understanding among them, and a rough consensus on how to proceed, the actual code changes are often relatively simple in comparison.

So, I guess this falls under "overhead of coordination and communication".

Re: Writing Code Was Never the Bottleneck

#210

Post by netbioserror »

All of these are the exact reasons I don't go overboard with a custom Vim or Helix setup with all sorts of bells and whistles, and just use stock Sublime. The real problem is never the speed at which I can write code. I need to model a complex problem domain. My choice of language and tools virtually eliminate all boilerplate and focus the effort on those modeling and software design problems. I've tried LLMs multiple times, and each time they've proven they cannot help me.
Post reply on HN