The one-shot vibe-coded C compiler is a good example. Sure it created a compiler that could pass the basic tests. But it was no where near a plausible or useful compiler you’d use in a production system.

Someone who knows compilers reviewed it and was able to prompt Claude or Gemini to fix the issues. But still… you’re not going to be able to do that unless you know what to look for.

On an enterprise development team doing boring, Line of Business software? Might have a chance at rolling the dice and trusting the agents and tests and processes to catch stuff for you but I’d still be worried about people who don’t know what questions to ask or have deep expertise to know what is “good,” etc.

My game is just in my spare time while I'm looking for work and the scope of the project is small so that I can finish it, release it, and start working on the next one. I'm not trying to build an engine or anything. Just a game. Not even the best game I can make.

I can iterate on it fast because I know the structures. I can refactor it fast because I've built an intuition for a process over time that keeps code amenable to changes over time. I know I'm not going to make the right decisions at the start so I avoid committing to generalizations, etc.

Editing code is pretty fast for me. Again, years working with a particular setup. I still have expandable snippets, multi-cursor editing and a host of macros for common editing motions.

Checking changes... pretty fast. I'm getting to the point where I might invest in using dynamic reloading for my in-development builds. I suspect it will take a few hours to do at most. Not a big deal. For now I have a basic system that just watches for file changes and recompiles/re-runs the program.

In a different context, working on a team in a large multi-million line codebase... I dunno what other people find it's like but I've never found it terribly slow to write/edit code or ship features. I can usually knock most tasks out at a reasonable pace especially when my familiarity with the area of the code I'm working in increases. I usually find my priorities shift with the demands of users, the business, etc. Some times I work on shipping new features quick. Other times it's making sure what we ship the right things and done well so that we don't leak PII.

Either way... actually writing the code isn't the slowest part, in my experience. It's all the other stuff: the meetings, the design, maintenance, documentation, understanding the problem domain, actually shipping the code to production, etc that takes up the most time for me.

You do need enough people to make complex systems. We can do more together than we can on our own. Linux started out with a small team but it is large today.

It runs against my experience though and I can’t seem to explain why.

My observation in my original post is that I don’t see why writing code is the bottleneck. It can be when you have too much of it but I find all the ancillary things around shipping code takes more time and effort.

Thanks for the discussion!

Let’s imagine we’re going to make a new operating system to compete with Linux.

If we have a team of 10 developers we’re probably not going to finish that project in a month.

If we’re going to add 100 developers we’re not going to finish that project in a month.

If we add a thousand developers we’re still not going to finish that project in a month.

But which team should ship first? And keep shipping and release fastest?

My bet would be on the smaller team. The exact number of developers might vary but I know that if you go over a certain threshold it will slow down.

People trying to understand management of software projects like to use analogies to factory lines or building construction to understand the systems and processes that produce software.

Yet it’s not like adding more code per unit of time is adding anything to the process.

Even adding more people to a factory line had diminishing returns in efficiency.

There’s a sweet spot, I find.

As for Google… it’s not a panacea of efficiency from what I hear. Though I don’t work there. I’ve heard stories that it takes a long time to get small changes to production. Maybe someone who does work there could step in and tell us what it’s like.

As a rule though, I find that smaller teams with the right support, can ship faster and deliver higher quality results in the long run.

My sample size isn’t large though. Maybe Windows is like the ultimate operating system that is fast, efficient, and of such high quality because they have so many engineers working on it.

It sounds like your team is the exception? Many folks I talk to have similar stories.

I've worked with teams to build out a well-oiled continuous delivery system. With code reviews, integration gating, feature flags, a blue-green deployment process, and all of the fancy o11y tools... we shipped several times a day. And people were still afraid to ship a critical feature on a Friday in case there had to be a roll-back... still a pain.

And all of that took way more time and effort than writing the code in the first place. You could get a feature done in an afternoon and it would take days to get through the merge queue, get through reviews, make it through the integration pipeline and see the light of production. All GenAI had done there was increase the input volume to the slowest part of the system.

People were still figuring out the best way to use LLM tools at that time though. Maybe there are teams who have figured it out. Or else they just stop caring and don't mind sloppy, slow, bloated software that struggles to keep one nine of availability.

I’m talking from personal experience of well over twenty years as both a developer, and for a while, a manager.

The slow part isn’t writing code.

It’s shipping it. You can have every one vibe coding until their eyes bleed and you’ve drained their will to live. The slowest part will still be testing, verifying, releasing, and maintaining the ball of technical debt that’s been accumulating. You will still have to figure out what to ship, what to fix, what to rush out and what to hold out until it’s right, etc. The more people you have to slower that goes in my experience. AI tools don’t make that part faster.

I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people.

You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday.

This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead.

The real bottle necks are people and releasing systems into production. Every line of code change is a liability. There’s risk tolerance to manage in order to achieve five-nines.

A well-sized team that has worked together a long time can outperform a massive team any day in my experience.

I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard.

I’ve had to rework parts of the code as I’ve progressed. I’ve had to live with decisions I made early on. It’s code. It’s fine.

I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less.

Agree with writing less code though. The economics of throwing out 37k lines of code a week is… stupid in the extreme. If we get paid by the line we could’ve optimized for this long before LLM’s were invented. It’s not like more lines of code means more inventory to sell. It’s usually the opposite: the more bugs to fix, the more frustrated customers, the higher churn of exhausted developers.

Block, for example, said that they had experienced record profits… in spite of their, “hiring spree.”

This is just capitalism working as usual, only more of it, faster.

AI has a part in it. So does austerity policies and the rise of a certain political climate.

These tools are nothing alike and the reductionism of this metaphor isn’t helpful.

I highly doubt that.

Empirical studies show that humans have very little effect on error rates when reviewing code. That effect disappears quickly the more code you read.

Most programmers are bad at detecting UB and memory ownership and lifetime errors.

A piece of wood comes off the table it’s cut or it’s not.

Code is far more complex.

How long until people get exhausted with the new volume of code review and start "trusting" the LLMs more without sufficient review, I wonder?

I don't envy Linus in his position... hopefully this approach will work out well for the team.

A table saw isn't a probabilistic device.

It’s not LLMs replacing workers, it’s people. People who have a lot of money and don’t sell their labour for a paycheque. And the systems that compel them to such actions.

It’s already bad. I’m not looking forward to the future. These systems are terrible. It’s a future without people that they want for some reason. I’d rather deal with people incompetent, tired, annoyed people than an LLM.

To those reading this thread though, be wary of the answers LLMs generate: they're plausible sounding and the LLM's are designed to be sycophants. Be wary, double check their answers to your queries against credible sources.

And read the source!

How many bytes is a pointer in C? How many bytes is a shared pointer in C++? What does sysctl do? What about fsync?

What is a mutex lock? How is it different from a spin lock?

You want to find the n nearest points to a given point on a 2-D Cartesian plane. Could you write the code to solve that on your own?

Can you answer any of these questions without searching for the answer?

I don't use LLMs and I learn things fine. Always have. For several decades. I care deeply about the underlying code and systems. It annoys me when people say they do and they cannot even understand how the computer works. I'm fine with people having domain-specific knowledge of programming: maybe you've only been interested in web development and scripting DOM elements. But don't pretend that your expertise in that area means you understand how to write an operating system.

Or worse: that it prevents you from learning how to write an operating system.

You can do that without an LLM. There's no royal road. You have to understand the theory, read the books, read the code, write the code, make mistakes, fix mistakes, read papers, talk to other people with more experience than you... and just write code. And rewrite it. And do it all again.

I find the opposite is true: those who use LLM coding exclusively never enjoyed programming to begin with, only learned as much as they needed to, and want the end results.

But I will demand my money back or sue you if your crappy code leaks my personal information, destroys my property, performs worse than advertised, or otherwise harms me in some way.

There was sloppy code before LLMs. It’s what they were trained on. And it’s why they generate slop.

All that code that was rushed out to meet an arbitrary deadline made up by the sales team, written by junior and lazy senior developers, pushed by the, “code doesn’t matter,” folks. Code written by the enterprise architecture astronauts with a class hierarchy deeper than the Mariana Trench. A few years down the line you get bloated, slow, hard to maintain spaghetti piles of dung. Windows rendering text that stutter when you scroll them. Virtual keyboards that take seconds to pop up. Browser tabs that take more available memory than was available to send astronauts to the moon and back.

When humans write it you generally have a few people on a team who are concerned with these things. They try to reign in the slop generating, “always be shipping,” people. You need a mix of both. Because each line of code is a liability as much as it’s a new feature.

If it does all go down in flames, even floor value is not going to be that valuable.

I can't predict the future but it's smelling a lot like a recession already under way that is bigger than the sub-prime crash.

I don’t know what SaaS has to do with FOSS. The point of FOSS was to allow me to modify the software I run on my system. If the device drivers for some hardware I depend on are no longer supported by the company I bought it from, if it’s open source, I can modify and extend the software myself.

The Copy Left licenses ensure that I share my modifications back if I distribute them. It’s a thing for the public good.

Agent-based software development walls people off from that. Mostly by ensuring that the provenance of the code it generates is not known and by deskilling people so that they don’t know what to prompt or how to fix their code.