GitHub CEO: manual coding remains key despite AI boom

In No Silver Bullet, Fred Brooks argues that the hard part of software engineering lies in essential complexity - understanding, specifying, and modeling the problem space - while accidental complexity like tool limitations is secondary. His point was that no tool or methodology would "magically" eliminate the difficulty of software development because the core challenge is conceptual, not syntactic. Fast forward to today: there's a lot of talk about AI agents replacing engineers by writing entire codebases from natural language prompts. But that seems to assume the specification problem is somehow solved or simplified. In reality, turning vague ideas into detailed, robust systems still feels like the core job of engineers.

If someone provides detailed specs and iteratively works with an AI to build software, aren’t they just using AI to eliminate accidental complexity—like how we moved from assembly to high-level languages? That doesn’t replace engineers; it boosts our productivity. If anything, it should increase opportunities by lowering the cost of iteration and scaling our impact.

So how do we reconcile this? If an agent writes a product from a prompt, that only works because someone else has already fully specified the system—implicitly or explicitly. And if we’re just using AI to replicate existing products, then we’re not solving technical problems anymore; we’re just competing on distribution or cost. That’s not an engineering disruption—it’s a business one.

What am I missing here?

Most problems businesses face have been seen by other businesses; perhaps some knowledge is in the training set or perhaps some problems are so easy to reason through that a LLM can do the "reasoning" more-or-less from first principles and your problem description.

I am speculating that AI will help with both sides of the No Silver Bullet dichotomy?

Once you remove all the roadblocks with syntax and language blindspots, the high cost of refactoring, the tedium of adding validation and tests, the challenges of integrating systems... suddenly, the work becomes more pure. Yes, you need to know how to do advanced structural things. But you don't need to learn very much about all the rest of it.

And we very quickly get to a point where someone who can break down problems into tidy Jira tickets is effectively programming. Programming was never really about learning languages but making computers do things, which is a transferrable skill and why so many engineers know so many languages.

I've seen it written that the main reason managers tend to want to get rid of SWEs is because they don't understand how to interface with them. Using an LLM solves that problem, because you don't need a nerd to operate it.

It's certainly how actually using AI in earnest feels, I have been doing my best to get agents like Claude to work through problems in a complex codebase defined by enormous amounts of outside business logic. This lack of ability to truly intuit the business requirements and deep context requirements means it cannot make business related code changes. But it can help with very small context code changes, ie incidental complexity unrelated to the core role of a good developer, which is translating real world requirements into a system.

But I will add that it shouldn't be underestimated how many of us are actually solving the distribution problem, not technical problems. I still would not feel confident replacing a junior with AI, the core issue being lack of self-correction. But certainly people will try, and businesses built around AI development will be real and undercut established businesses. Whether that's net good or bad will probably not matter to those who lose their jobs in the scuffle.

Oh god please kill me

Even the simplest tickets sometimes that end up requiring a one line change can require hours of investigation to fully understand/stamp the effects of that change.

And perhaps I havent used the greatest or latest, but in my experience LLMs break down hard st anything sufficiently large. They make changes and introduce new errors, they end up changing the feature, or worst case just ouright break everything.

Id never trust it unless you have an extensive amount of good tests for validation

Software engineering for any non-trivial problem means a baseline level of essential complexity that isn't going away, no matter the tool, not even if we someday "code" directly from our minds in some almost-free way via parallel programming thought diffusion. That's because (1) depth and breadth of choice; and (2) coordination/socials, mostly due but not uniquely related to (1) are the real bottlenecks.

Sure, accidental complexity can shrink, if you design in a way that's aligned with the tools, but even then, the gains are often overhyped. These kinds of "developer accelerators" (IDEs, low-code platforms, etc.) are always oversold in depth and scope, LLMs included.

The promise of the "10x engineer" is always there, but the reality is more mundane. For example, IDEs and LSPs are helpful, but not really transformative. Up to a point that people are being payed right now and don't use them at all, and they still deliver in a "economically justifiable" (by someone) way.

Today it's LLMs. Tomorrow it'll be LISP Machines v2.

So it seems AI will just let us stretch further and make more accidentally complex systems.

That’s because software is nebulous enough that you can get away with promising the moon to customers/boss, but in the next meeting, you’re given a reality check by the SWEs. And then you realize the mess you’re thrown everyone in.

Managers knows how to interface with SWEs well (people interface with professionals all the time). Most just hates going back to the engineers to get real answers when they fancy themselves as products owners.

E.g the most complex deployments are not the ones that are the least error prone or require the least amount of intervention.

And I’m saying this as someone who kind of adopted AI pretty early for code and who learned how to prompt it.

The best way to make AI worth your time is to make it work towards a predictable output. TDD is really good for this : you write your test cases and you make the AI do the work.

But when you want a visual result ? It will have no feedback of any clue, will always answer "Ok, I solved this" while making things worse. Even if the model is visual, giving it screenshots as feedback is useless too.

Small businesses often understand domain less, not more, because they cannot invest as much as big businesses in building expertise. They may achieve something within that limited understanding, but the outcome will limit their growth. Of course, AI can help with discovery, but it may overcomplicate things. Product discovery is an art of figuring out what to do without doing too much or not enough, which AI has not mastered yet.

Stakeholders (client, managers) have been "vibe coding" all along. They send some vague descriptions and someone magically gives back a solution. Does the solution completely work? No one knows. It kinda works, but no one knows for sure.

Most of the time, it's actually the programmers' understanding of the domain that fills out the details (we all know what a correct form submission webpage looks like).

Now the other end has become AI, it remains to be seen whether this can be replicated.

After using Claude Code to vibe code some stuff, it seems to me that AI doesn't eliminate accidental complexity, it just creates more of it and takes away some of the pain of really bad APIs.

Obviously we don‘t as phone numbers can be split in up to 4 fields with conflicting varieties of validation or just be one field.

millions of forms around the web would like to have a word… :)

SWEs are also about the most expensive kind of employee imaginable. I imagine that’s incentive enough.

- Articles about tricky nature of tech debt aren't written by people who call the shots on whether the team can spend the entire next week on something that a customer can't see.

- Articles about systems architecture aren't written by people who decide how much each piece of work was significant for business.

- Books on methodologies are optional read for engineers, not essential for their job, and adoption happens only when they push it upwards.

Most of the buzz about AI replacing coding is coming from people who don't see a difference between generating a working MVP of an app, and evolving an app codebase for a decade and fixing ancient poor design choices in a spaceship which is already in flight.

I've even seen a manager who proposed allocating 33% time every day on 3 projects, and engineers had to push back. Such old and common knowledge that it doesn't work is apparently still not a job requirement in 2025. Despite that organizing and structuring project time allocation is management competency and not an engineering skill, it is de-facto entirely up to engineers to make sure it's done right. The same managers are now proud to demonstrate their "customer focus" by proposing to ask AI to resolve all the tech debt and write all the missing tests so that engineers could focus on business requests, and same engineers have to figure how to explain why it didn't just work when they tried.

To talk about complexity is to repeat the same old mistake. I am sure most engineers already know and I am yet to see an experienced engineer who believes their job will be taken by simple prompts. The problem we should be talking about should be titled something like,

"Software Engineering Has Poor Management Problem, and AI is Amplifying It"

on this topic I suggest everybody who works in our industry to read Peter Naur's "Programming as Theory Building"[1] and a nice corollary from Baldur Bjarnson: "Theory-building and why employee churn is lethal to software companies"[2]

[1]: https://pages.cs.wisc.edu/~remzi/Naur.pdf [2]: https://www.baldurbjarnason.com/2022/theory-building/

Downside is there is much more non essential busy work because of which people had their jobs and now loads of those people will lose the job.

People who do work on real essential complexity of systems are far and between. People who say things like "proper professionals will always have work" are utter assholes thinking mostly that "they are those proper professionals".

In reality AI will be like F1 racing team not needing pit workers and have only drivers, how many drivers are there like 20 so it is 10 teams each having 2 drivers. Each team has 300-1000 people that do all the other things.

If you go to corporate level let's say 1 person working on essential complexity requires 10-20 people doing all kinds of non essential stuff that will be taken over by AI, or to be realistic instead of 10-20 people that person will need headcount of 5.

That is still 15 people out of job - are those people able to take over some essential complexity in a different company or different area of the same company, some would but it is also if they would like to do it. So those people will be pushed around or end up jobless, bitter whatever.

That is not great future coming in.

A terrifyingly large percentage of people employed to write software cannot write software. Not even a little. These are the people that can be easily replaced.

In my prior line of work I wrote JavaScript for a living. There were people doing amazing, just jaw dropping astounding, things. Those people were almost exclusively hobbyists. At work most people struggled to do little more than copy/paste in a struggle just to put text on screen. Sadly, that is not an exaggeration.

Some people did what they considered to be advanced engineering against these colossal frameworks, but the result is just the same: little more than copy/paste and struggle to put text on screen. Yes, they might be solving for advanced complexity, but it is almost always completely unnecessary and frequently related to code vanity.

Virtually none of those people could write original applications, measure anything, write documentation, or do just about anything else practical.

> So how do we reconcile this?

Alienate your workforce by setting high standards, like a bar exam to become a lawyer. Fire those people that fail to rise to the occasion. Moving forward employ people who cannot meet the high standards only as juniors or apprentices, so that the next generation of developers have the opportunity to learn the craft without rewarding failure.

Until you do. LLMs are great ar building prototypes but at some point if you don’t know what you’ll doing you’ll end up with an unmaintainable mess and you won’t have anyone to fix it.

I mean LLMs perhaps are capable of doing that too but they still need to be guided by people who are capable of understanding their output.

Being able to reduce the number of engineers that you need by e.g. 80% would still be a great deal though.

I think there is a promise of that in AI and LLMs (but I remain skeptical, because I it needs a formal and not ad hoc definition). The idea you can build the systems using a fuzzy human language and the things will somehow work out.

What they have: An undergraduate intern who is a former used car salesperson used to BSing their way through life.

They've started a business selling the exact opposite message to everyone who will buy it

It sounds to me like a corporate equivalent of a drug-fueled rager. They want everything good now while deferring all the expenses to tomorrow.

This would work if the world was willing to pay for software. So at the very least you'd have to outlaw the ad-based business model, or do what lawyers do: things that are absolutely critical for software development (think "program needs to be approved or it won't execute", that deep) that normal people aren't allowed ... and unable ... to do.

This is very much up for debate and the weakest point of the argument I think. If developers are now 2-3x (remains to be seen..) as productive what will happen to the job market?

I suppose it depends on how much potential software is there that's not currently viable due to cost? How much would scope be increased on current products?

(and certainly Google's newest AI model is actually a step backwards on this front)

Add to that that nothing changes for difficult work. Writing a driver still requires hardware knowledge ... of the actual hardware. Which AI doesn't have ... and doesn't make any attempt to acquire.

I've seen articles that this part can actually be fixed. If you create a loop where the AI is forced to slowly build up low-level knowledge it can actually find this sort of things. But you need 10 expert AI researchers to do anything like this.

(frankly I don't see how this part could be fixed by better AI models)

What's in danger is the coding job consisting of "write me a form with these 20 fields". The 100% repetitive ones.

The only purpose of software is automation. All cost factors should derive from that one source of truth. As a result the only valid concerns should be:

* Lowering liabilities

* Increasing capabilities

From a business perspective that means not paying money for unintended harms, and simultaneously either taking market share from the competition or inventing new markets. If your people aren't capable of writing software or your only options are free choices provided to you then you are the mercy of catastrophic opportunity costs that even the smallest players can sprint past.

GenAI is such a boon at present because it occasionally delivers acceptable mediocrity to PMs and Stakeholders who will accept said mediocrity because they have no real clue what they (or their customers) actually want. It’s a system of roles and output that delivers based on patterns in incomprehensively large data sets, provided to humans who cannot hope to validate that information is accurate or legitimate (and not just random patterns in a large enough data set), but passed along as gospel from digital machinegods. To a withering empire obsessed with nostalgia and whose institutions are crumbling beneath them, GenAI appears as a savior; to those confident in their position in the world order, it is merely a thin tool in a larger toolbox, to be used toward greater ends rather than middling output.

Those who understand the specification problems are in a position to capitalize off such monumental shifts, while those blindly chasing get-rich-quick schemes, grifts, and fads will be left behind.

What happens after that, I have no idea.

Seems like OpenAI (or whoever wins) could easily just start taking over whole industries at that point, or at least those that are mostly tech based, since it can replicate anything they can do, but cheaper. By that point, probably the only tech jobs left will be building safeguards so that AI doesn't destroy the planet.

Which sounds niche, but conceivably, could be a real, thriving industry. Once AI outruns us, there'll probably be a huge catastrophe at some point, after which we'll realize we need to "dumb down" AI in order to preserve our own species. It will serve almost as a physical resource, or maybe like a giant nuclear reactor, where we mine it as needed but don't let it run unfettered. Coordinating that balance to extract maximal economic growth without blowing everything up could end up being the primary function of human intelligence in the AI age.

Whether something like that can be sustained, in a world with ten billion different opinions on how to do so, remains to be seen.

That doesn't sell stock. Firing high paying employees sells a lot of stock.

I don't think anyone thinks engineers are going away. But companies will hire less employees to do the same amount of work, and they won't pay engineers more.

just look at software: cost of duplication is basically zero and here we are paying subscriptions (to huge profits) every month for it

switching to a true post-scarcity economy is gonna take more than just technology i think...

2. The level of expertise and skill required to set it up and maintain

decades of building garbage-barely-working forms is a proof that we just do not know (much like we (generally) don't know how to center a div on the page so once-per-year, without fail, top story on HN is "how to center a div" :) ).

Is this just business domain knowledge and good communication?