←back to thread

GitHub CEO: manual coding remains key despite AI boom

(www.techinasia.com)
358 points andrewstetsenko | 9 comments | 23 Jun 25 20:50 UTC | HN request time: 0.957s | source | bottom
Show context
agentultra ◴[23 Jun 25 22:06 UTC] No.44360677[source]▶
… because programming languages are the right level of precision for specifying a program you want. Natural language isn’t it. Of course you need to review and edit what it generates. Of course it’s often easier to make the change yourself instead of describing how to make the change.

I wonder if the independent studies that show Copilot increasing the rate of errors in software have anything to do with this less bold attitude. Most people selling AI are predicting the obsolescence of human authors.

replies(6): >>44360934 #>>44361057 #>>44361209 #>>44361269 #>>44364351 #>>44366148 #
soulofmischief ◴[23 Jun 25 22:40 UTC] No.44360934[source]▶
Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer's knowledge as needed, navigate unfamiliar APIs without relying on reference, build out initial features, do code review and so much more.

Even if code is the right medium for specifying a program, transformers act as an automated interface between that medium and natural language. Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual.

> Most people selling AI are predicting the obsolescence of human authors.

It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.

This replacement might not happen tomorrow, or next year, or even in the next decade, but it's clear that we are able to build capable models. What remains to be done is R&D around things like hallucinations, accuracy, affordability, etc. as well as tooling and infrastructure built around this new paradigm. But the cat's out of the bag, and we are not returning to a paradigm that doesn't involve intelligent automation in our daily work; programming is literally about automating things and transformers are a massive forward step.

That doesn't really mean anything, though; You can still be as involved in your programming work as you'd like. Whether you can find paid, professional work depends on your domain, skill level and compensation preferences. But you can always program for fun or personal projects, and decide how much or how little automation you use. But I will recommend that you take these tools seriously, and that you aren't too dismissive, or you could find yourself left behind in a rapidly evolving landscape, similarly to the advent of personal computing and the internet.

replies(5): >>44361398 #>>44361531 #>>44361698 #>>44362804 #>>44363434 #
1. interstice ◴[23 Jun 25 23:48 UTC] No.44361398[source]▶
> Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual.

It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else. I've yet to see one that can back itself out of a logical corner.

replies(4): >>44361560 #>>44361615 #>>44361738 #>>44366056 #
2. recursive ◴[24 Jun 25 00:15 UTC] No.44361560[source]▶
> It will also still happily turn your whole codebase into garbage rather than undo the first thing it tried to try something else.

That's not true at all.

...

It's only pretending to be happy.

3. soulofmischief ◴[24 Jun 25 00:24 UTC] No.44361615[source]▶
That's a combination of current context limitations and a lack of quality tooling and prompting.

A well-designed agent can absolutely roll back code if given proper context and access to tooling such as git. Even flushing context/message history becomes viable for agents if the functionality is exposed to them.

replies(1): >>44362513 #
4. jcalvinowens ◴[24 Jun 25 00:42 UTC] No.44361738[source]▶
This is it for me. If you ask these models to write something new, the result can be okay.

But the second you start iterating with them... the codebase goes to shit, because they never delete code. Never. They always bolt new shit on to solve any problem, even when there's an incredibly obvious path to achieve the same thing in a much more maintainable way with what already exists.

Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them. Until then, I remain a hater, because they only seem capable of the opposite :)

replies(2): >>44361791 #>>44362962 #
5. soulofmischief ◴[24 Jun 25 00:51 UTC] No.44361791[source]▶
You'd be surprised what a combination of structured review passes and agent rules (even simple ones such as "please consider whether old code can be phased out") might do to your agentic workflow.

> Show me a language model that can turn rube goldberg code into good readable code, and I'll suddenly become very interested in them.

They can already do this. If you have any specific code examples in mind, I can experiment for you and return my conclusions if it means you'll earnestly try out a modern agentic workflow.

replies(1): >>44361967 #
6. jcalvinowens ◴[24 Jun 25 01:20 UTC] No.44361967{3}[source]▶
> You'd be surprised

I doubt it. I've experimented with most of them extensively, and worked with people who use them. The atrocious results speak for themselves.

> They can already do this. If you have any specific code examples in mind

Sure. The bluetooth drivers in the Linux kernel contain an enormous amount of shoddy duplicated code that has amalgamated over the past decade with little oversight: https://code.wbinvd.org/cgit/linux/tree/drivers/bluetooth

An LLM which was capable of refactoring all the duplicated logic into the common core and restructuring all the drivers to be simpler would be very very useful for me. It ought to be able to remove a few thousand lines of code there.

It needs to do it iteratively, in a sting of small patches that I can review and prove to myself are correct. If it spits out a giant single patch, that's worse than nothing, because I do systems work that actually has to be 100% correct, and I can't trust it.

Show me what you can make it do :)

7. jashmatthews ◴[24 Jun 25 02:58 UTC] No.44362513[source]▶
Can we demonstrate them doing that? Absolutely.

Will they fail to do it in practice once they poison their own context hallucinating libraries or functions that don’t exist? Absolutely.

That’s the tricky part of working with agents.

8. unshavedyak ◴[24 Jun 25 04:57 UTC] No.44362962[source]▶
> because they never delete code. Never.

That's not true in my experience. Several times now i've given Claude Code a too-challenging task and after trying repeatedly it eventually gave up, removing all the previous work on that subject and choosing an easier solution instead.

.. unfortunately that was not at all what i wanted lol. I had told it "implement X feature with Y library", ie specifically the implementation i wanted to make progress towards, and then after a while it just decided that was difficult and to do it differently.

9. olavfosse ◴[24 Jun 25 13:29 UTC] No.44366056[source]▶
My Claude is happy to git restore and try a different approach when it walked itself into a corner ;)