GitHub CEO: manual coding remains key despite AI boom

Personally, I define the job of a software engineer as transform requirements into software. Software is not only code. Requirements are not only natural language. At the moment I can't manage to be faster with the AI than manually. Unless its a simple task or software. In my experience AI's are atm junior or mid-level developers. And in the last two years, they didn't get significant better.

Most of the time, the requirements are not spelled out. Nobody even knows what the business logic is supposed to be. A lot of it has to be decided by the software engineer based on available information. It sometimes involve walking around the office asking people things.

It also requires a fair bit of wisdom to know where the software is expected to grow, and how to architect for that eventuality.

I can't picture an LLM doing a fraction of that work.

I think that's my problem with AI. Let's say I have all the requirements, down to the smallest detail. Then I make my decisions at a micro level. Formulate an architecture. Take all the non-functionals into account. I would write a book as a prompt that is not able to express my thoughts as accurately as if I were writing code right away. Apart from the fact that the prompt is generally a superfluous intermediate step in which I struggle to create an exact programming language with an imprecise natural language with a result that is not reproduce-able.

This is a really good point.

At a certain point, huge prompts (which you can readily find available on Github, used by large LLM-based corps) are just....files of code? Why wouldn't I just write the code myself at that point?

Almost makes me think this "AI coding takeover" is strictly pushed by non-technical people.

AI is less useful when I'm picking through specific, careful business logic.

But we still have lots of boilerplate code that's required, and it's really good at that. If I need a reasonably good-looking front-end UI, Claude will put that together quickly for me. Or if I need it to use a common algorithm against some data, it's good at applying that.

What I like about AI is that it lets me slide along the automation-specificity spectrum as I go through my work. Sometimes it feels like I've opened up a big stretch of open highway (some standard issue UI work with structures already well-defined) and I can "goose" it. Sometimes there's some tricky logic, and I just know the AI won't do well; it takes just as long to explain the logic as to write it in code. So I hit the brakes, slow down, navigate those tricky parts.

Previously, in the prior attempt to remove the need for engineers, no-code solutions instead trapped people. They pretended like everything is open highway. It's not, which is why they fail. But here we can apply our own judgment and skill in deciding when a lot of "common-pattern" code is required versus the times where specificity and business context is required.

That's also why these LLMs get over-hyped: people over-hype them for the same reason they over-hyped no-code; they don't understand the job to be done, and because of that, they actually don't understand why this is much better than the fanciful capabilities they pretend it has ("it's like an employee and automates everything!"). The tools are much more powerful when an engineer is in the driver's seat, exercising technical judgment on where and how much to use it for every given problem to be solved.

No software job I've done has come with clear, explicit requirements. Its all been a mess under the hood and half my job has been figuring out specifically what they even want

> But we still have lots of boilerplate code that's required, and it's really good at that

Copy and paste with find and replace has never taken me that long for boilerplate though. The time saved here is razor thin imo

Back in the day, there used to be professionals known as systems analysts whose job it was to determine the business logic. The information system went through several phases of stepwise refinement. First the requirements were determined: WHO needs WHAT information, WHERE, WHEN, and WHY. (And from WHOM do they get it?) Then, a series of procedures were developed to be implemented either manually or by computer (The "Playscript" format by Les Matthies was particularly useful for the former; standard flowcharts for the latter). Each piece of data, its type, and its purpose was also identified and registered in a standard vocabulary. The programmers only got in on it towards the end: once the major decisions had been made, they wrote the code instructing the computer on HOW to do it. Their focus was on the HOW; the WHAT was not in their job description, and was usually beyond their capability. It takes holistic, big-picture thinking and great social skills to develop an understanding of an entire business division and come up with a plan to implement an information system for that division. The programmers' work entailed about 15% of the total work, and was mainly concerned with the technical details of getting the procedures to be automated running on a computer. These days, with AI, that 15% figure could be reduced even further, perhaps by a factor of five or ten. In the big-iron era, programming was really that simple. The hard decisions had already been made before the first line of code was written. You may think it stodgy and inflexible to develop software this way, but that's how grown-ups did it, and studies showed that it was significantly cheaper than the scattershot, agile-like approach where the programmers where in the lead in terms of systems design.

What's happened since the 1970s is, programming has undergone prestige inflation to the point where programmers are looked to for decisions regarding the actual business procedures, and usually they just don't have the business knowledge or wherewithal to do that. The systems analyst has faded into memory. And as Milt Bryce said, "If this country built bridges the way it builds systems, we'd be a nation run by ferry-boats."

My strategy has almost always been to copy the code example from the docs of whatever css framework I’m using, especially for forms. Then there’s a threshold where I use the project as source instead.

LLMs are nowhere near even junior level and if you really think any model is comparable to your orgs mid level developer you have a hiring problem

I think it's a common problem to officially have mids who are really just juniors with a modicum of time in the industry and the same goes for seniors who are really just mids.

I agree, but also I don't believe LLMs are on junior level. In hands of a senior LLMs might be like a summer intern level, maybe.