8 ms·

I am becoming more and more convinced that AI cant be used to make something better than what could have built before AI. You never needed 1000s of engineers t

I am becoming more and more convinced that AI cant be used to make something better than what could have built before AI. You never needed 1000s of engineers to build software anyway, Winamp & VLC were build by less than four people. You only needed 1000s of people because the executive vision is always to add more useless junk into each product. And now with AI that might be even harder to avoid. This would mean there would be 1000s of do-everything websites in the future in the best case, or billions of doing one-thing terribly apps in the worst case. percentage of good, well planned, consistent and coherent software is going to approach zero in both cases.

pousada 7mo ago
> percentage of good, well planned, consistent and coherent software is going to approach zero So everything stays exactly the same?
- Chance-Device 7mo ago
  Underrated comment. The reason that everyone complains about code all the time is because most code is bad, and it’s written by humans. I think this can only be a step up. Nailing validation is the trick now.
  - oblio 7mo ago
    Validation was always the hard part, outside of truly novel areas - think edges of computer science (which generally happen very rarely and only need to be explored once or a handful of times). Validation was always the hard part because great validation requires great design. You can't validate garbage.
- falloutx 7mo ago
  I get this comment everytime I say this but there are levels to this. What you think is bad today could be considered artisan when things become worse than today.
  - bartread 7mo ago
    I mean, you've never used the desktop version of Deltek Maconomy, have you? Somehow I can tell. My point here is not to roast Deltek, although that's certainly fun (and 100% deserved), but to point out that the bar for how bad software can be and still, somehow, be commercially viable is already so low it basically intersects the Earth's centre of gravity. The internet has always been a machine that allows for the ever-accelerated publishing of complete garbage of all varieties, but it's also meant that in absolute terms more good stuff also gets published. The problem is one of volume not, I suspect, that the percentages of good versus crap change that much. So we'll need better tools to search and filter but, again, I suspect AI can help here too.
- co_king_3 7mo ago
  > So everything stays exactly the same? No, we get applications so hideously inefficient that your $3000 developer machine feels like it it's running a Pentium II with 256 MB of RAM. We get software that's as slow as it was 30 years ago, for no reason other than our own arrogance and apathy.
  - rkomorn 7mo ago
    I find it hard to disagree with this (sadly). I do feels things in general are more "snappy" at the OS level, but once you get into apps (local or web), things don't feel much better than 30 years ago. The two big exceptions for me are video and gaming. I wonder how people who work in CAD, media editing, or other "heavy" workloads etc, feel.
    - co_king_3 7mo ago
      > I wonder how people who work in CAD, media editing, or other "heavy" workloads etc, feel. I would assume (generally speaking) that CAD and video editing applications are carefully designed for efficiency because it's an important differentiator between different applications in the same class. In my experience, these applications are some of the most exciting to use, because I feel like I'm actually able to leverage the power of my hardware. IMO the real issue are bloated desktop apps like Slack, Discord, Spotify, or Claude's TUI, which consume massive amounts of resources without doing much beyond displaying text or streaming audio files.
      - upboundspiral 7mo ago
        The problem with CAD is that mechanical engineering is still deeply proprietary, especially up and including the software stacks. There is basically no "open source" in mechanical engineering. So you are relegated to super heavy legacy applications that coast by through their integrations with other proprietary tools. Solidworks is much heavier then FreeCAD but FreeCAD didn't have integrations with simulation tools, with CAM software, used a different geometry engine than industry standard, etc, so when a company tried to turn FreeCAD into a product they failed. The only open source one sees in mechanical engineering comes out of academia, which while interesting, faces the problem that once the research funds dry up or the project finishes the software is dumped into the open in hard to find places, and is not further developed. I remain hopeful in the potential for open source, I believe that to have a truly accessible and innovative industry a greater level of openness is needed, but it is yet coming. I think CAD is a good place to start, as it is not a space where lots of hidden and closely guarded tricks are needed like in Finite Element Analysis. For personal uses FreeCAD is getting there. Snappier than Solidworks, but the workflow layout needs some work. I am also looking at projects such as https://zoo.dev https://zoo.dev. In mapping the design 1to1 to code (while keeping gui workflow as well) I think they have a real chance of offering enough value that new companies will be interested in trying out their approach. It opens the doors to automation analysis, and generation that while possible with something like Solidworks is cumbersome and not well documented.
- gosub100 7mo ago
  No, wealth gets more concentrated. Fewer people on the team will be able to afford a comfortable lifestyle and save for retirement. More will edge infinitesimally closer to "barely scraping by".
zsoltkacsandi 7mo ago
Completely agree. There is a common misunderstanding/misconception in product development, that more features = better product. I’ve never seen a product/project manager questioning themselves: does this feature add any value? Should we remove it? In agile methodologies we measure the output of the developers. But we don’t care about that the output carries any meaningful value to the end user/business.
- antupis 7mo ago
  It’s more about operational resilience and serving customers than product development. If you run early WhatsApp like organisation just 1 person leaving can create awful problems. Same for serving customers especially big clients need all kinds of reports and resources that skeleton organisation can not provide.
  - zsoltkacsandi 7mo ago
    Yeah, that’s a misconception too based on my experience. I’ve seen many people (even myself) thinking the same: if I quit/something happens to me, there will be no one who knows how this works/how to do this. Turned out the businesses always survived. There was a tiny inconvenience, but other than that: nothing. There is always someone who is willing to pick up/take over the task in zero amount of time. I mean I agree with you, in theory. But that’s not what I’ve seen in practice.
- 9rx 7mo ago
  > I’ve never seen a product/project manager questioning themselves: does this feature add any value? Should we remove it? To be fair, it is a hard question to contend with. It is easier to keep users who don't know what they're missing happier than users who lost something they now know they want. Even fixing bugs can sometimes upset users who have come to depend on the bug as a feature. > In agile methodologies we measure the output of the developers. No we don't. "Individuals and interactions over processes and tools". You are bound to notice a developer with poor output as you interact with them, but explicitly measure them you will not. Remember, agile is all about removing managers from the picture. Without managers, who is even going to do the measuring? There are quite a few pre-agile methodologies out there that try to prepare a development team to operate without managers. It is possible you will find measurement in there, measuring to ensure that the people can handle working without mangers? Even agile itself recognizes in the 12 principles that it requires a team of special people to be able to handle agile.
kvgr 7mo ago
I just build a programming language in couple of hours, complete with interpreter with claude code. I know nothing about designing and implementing programming languages: https://github.com/m-o/MoonShot https://github.com/m-o/MoonShot.
- oblio 7mo ago
  You built something. Now comes the hard or impossible part: is it any good? I would bet against it.
  - kvgr 7mo ago
    Oh, thank you for informing me.
    - oblio 7mo ago
      Well, I can turn this around: "Oh, thank you for informing me that Claude built a compiler. Whoop-de-do".
- lietuvis 7mo ago
  Took a quick look, this seems like a copy of writing an interpreter in go book by Thorsten Ball, but just much worse. Also using double equals to mutate variables, why?
  - kvgr 7mo ago
    Just because i wanted it to. I made some design choices that i found interesting.
    - deleted 7mo ago
      [deleted]
  - kvgr 7mo ago
    Also i didn't read that book, if there are similarities in language it must be accident or claude steering me to what he knows. And if its the interpreter design, than it probably if from that book. And they told us, that they don't memorise the material.
jasode 7mo ago
, Winamp & VLC were build by less than four people. You only needed 1000s of people because the executive vision is always to add more useless junk into each product. Many types of software have essential complexity and minimal features that still require hundreds/thousands of software engineers. Having just 4 people is simply not enough man-hours to build the capabilities customers desire. Complex software like 3D materials modeling and simulation, logistics software like factory and warehouse planning. Even the Linux kernel and userspace has thousands of contributors and the baseline features (drivers, sandbox, GUI, etc) that users want from a modern operating system cannot be done by a 4-person team. All that said, there a lots of great projects with tiny teams. SQLite is 3 people. Foobar2000 is one person. ShareX screensaver I think is 1 developer in Turkey.
- Lalabadie 7mo ago
  But big projects are where the quality of LLM contributions fall the most, and require (continuous, exhausting, thankless) supervision!
  - zozbot234 7mo ago
    Big projects can still be highly modular, and projects built by "1000s of devs" typically are. If your desired change can be described clearly without needing too much unrelated context, the LLM will probably get it right.
- misiek08 7mo ago
  I will use my right to disagree. Maybe not 4 people everywhere, but if you have product with well thought feature set you create those and then you really don't need 1000s people to just keep it alive and add features one by one. I - of course - am talking about perfect approach with everyone focused to not f** it up ;)
cedws 7mo ago
I’m finding that the code LLMs produce is just average. Not great, not terrible. Which makes sense, the model is basically a complex representation of the average of its training data right? If I want what I consider ‘good code’ I have to steer it. So I wouldn’t use LLMs to produce significant chunks of code for something I care about. And publishing vibe coded projects under my own GitHub user feels like it devalues my own work, so for now I’m just not publishing vibe coded projects. Maybe I will eventually, under a ‘pen name.’
- rybosworld 7mo ago
  We've gone from "it's glorified auto-complete" to "the quality of working, end-to-end features, is average", in just ~2 years. I think it goes without saying that they will be writing "good code" in short time. I also wonder how much of this "I don't trust them yet" viewpoint is coming from people who are using agents the least. Is it rare that AI one-shots code that I would be willing to raise as a PR with my name on it? Yes, extremely so (almost never). Can I write a more-specified prompt that improves the AI's output? Also yes. And the amount of time/effort I spend iterating on a prompt, to shape the feature I want, is decreasing as I learn to use the tools better. I think the term prompt-engineering became loaded to mean "folks who can write very good one-shot prompts". But that's a silly way of thinking about it imo. Any feature with moderate complexity involves discovery. "Prompt iteration" is more descriptive/accurate imo.
  - ikr678 7mo ago
    Is there a big enough dataset of 'good' code to train from though?
    - rybosworld 7mo ago
      I (and lots of people) used to think the models would run out of training data and it would halt progress. They did run out of human-authored training data (depending on who you ask), in 2024/2025. And they still improve.
      - 7mo ago
imiric 7mo ago
Wait, surely adding 10x more agents to my project will speed up development, improve the end product, and make me more productive by that same proportion, right? I will task a few of them to write a perfectly detailed spec up front, break up the project into actionable chunks, and then manage the other workers into producing, reviewing, and deploying the code. Agents can communicate and cooperate now, and hallucination is a solved problem. What could go wrong? Meanwhile, I can cook or watch a movie, and ocasionally steer them in the right direction. Now I can finally focus on the big picture, instead of getting bogged down by minutiae. My work is so valuable that no AI could ever replace me. /s
FieryTransition 7mo ago
And Unix was mainly made by two people, it's astounding that as I get older, even tech managers don't know "the mythical man month", and how software production generally scales.
- thunky 7mo ago
  Sorry but 99.999% of developers could not have built Unix. Or Winamp. Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good.
  - sdf2erf 7mo ago
    Thats because the distribution of developer quality and capability is skewed.
  - eqvinox 7mo ago
    > Sorry but a 99.999% of developers could not have built Unix. Or Winamp. > Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good. The problem is that that's the same skill required to safely use AI tools. You need to essentially audit its output, ensure that you have a sensible and consistent design (either supplied as input or created by the AI itself), and 'refine' the prompts as needed. AI does not make poor engineers produce better code. It does make poor engineers produce better-looking code, which is incredibly dangerous. But ultimately, considering the amount of code written by average engineers out there, it actually makes perfect sense for AI to be an average engineer — after all, that's the bulk of what it was trained on! Luckily, there's some selection effect there since good work propagates more, but that's a limited bias at best.
    - thunky 7mo ago
      Agree completely. Where I'm optimistic about AI is that it can also help identify poorly written code (even it's own code), and it can help rewrite it to be better quality. Average developers can't do this part. From what I've found it's very easy to ask the AI to look at code and suggest how to make the code maintainable (look for SRP violations, etc, etc). And it will go to work. Which means that we can already build this "quality" into the initial output via agent workflows.
sdf2erf 7mo ago
What youre pointing at is the trade off between concentration of understanding vs fragmented understanding across more people. The former is always preferred in the context of product development but poses a key person risk. Apple in its current form is a representation of this - Steve did enough work to keep the company going for a decade after his death. Now its sort-of lost on where to go next. But on the flip side look at its market cap today vs 2000.
prng2021 7mo ago
“You never needed 1000s of engineers to build software anyway” What is the point of even mentioning this? We live in reality. In reality, there are countless companies with thousands of engineers making each piece of software. Outside of reality, yes you can talk about a million hypothetical situations. Cherry picking rare examples like Winamp does nothing but provide an example of an exception, which yes, also exists in the real world.
- caminante 7mo ago
  IMHO, it's flamebait. Your quoted text is provably false -- e.g., MSFT Windows, AWS, etc. and appeals to idealism of lean project teams.
level09 7mo ago
I see it differently. for me AI has been less about building more/fast, and more about unlocking potential that was always out of reach. Knowledge gaps that would've taken years to fill, new angles I wouldn't have thought to explore on my own. It's not that it makes more software. it just makes you more capable of tackling things you couldn't before.
phendrenad2 7mo ago
You need 1000 engineers because you have poor engineering leadership, or no engineering leadership, and engineering is a black hole that management shovels money into where it falls directly onto a huge plane of middle managers who do the best they can with their limited power and understanding. Meanwhile your sales team is writing specifications for the next version of the product, which they already promised to customers, and they hired an outside consultant to transform it into 500 spec documents written in damn near legalese, which will appear one day on the lead engineer's desk with no foreshadowing. It turns out that throwing more engineers at the problem helps here because you'll run out of tasks to assign to all of them and some will roam the halls and accidentally connect distributed knowledge back together.

pousada 7mo ago

> percentage of good, well planned, consistent and coherent software is going to approach zero So everything stays exactly the same?

Chance-Device 7mo ago
Underrated comment. The reason that everyone complains about code all the time is because most code is bad, and it’s written by humans. I think this can only be a step up. Nailing validation is the trick now.
- oblio 7mo ago
  Validation was always the hard part, outside of truly novel areas - think edges of computer science (which generally happen very rarely and only need to be explored once or a handful of times). Validation was always the hard part because great validation requires great design. You can't validate garbage.
falloutx 7mo ago
I get this comment everytime I say this but there are levels to this. What you think is bad today could be considered artisan when things become worse than today.
- bartread 7mo ago
  I mean, you've never used the desktop version of Deltek Maconomy, have you? Somehow I can tell. My point here is not to roast Deltek, although that's certainly fun (and 100% deserved), but to point out that the bar for how bad software can be and still, somehow, be commercially viable is already so low it basically intersects the Earth's centre of gravity. The internet has always been a machine that allows for the ever-accelerated publishing of complete garbage of all varieties, but it's also meant that in absolute terms more good stuff also gets published. The problem is one of volume not, I suspect, that the percentages of good versus crap change that much. So we'll need better tools to search and filter but, again, I suspect AI can help here too.
co_king_3 7mo ago
> So everything stays exactly the same? No, we get applications so hideously inefficient that your $3000 developer machine feels like it it's running a Pentium II with 256 MB of RAM. We get software that's as slow as it was 30 years ago, for no reason other than our own arrogance and apathy.
- rkomorn 7mo ago
  I find it hard to disagree with this (sadly). I do feels things in general are more "snappy" at the OS level, but once you get into apps (local or web), things don't feel much better than 30 years ago. The two big exceptions for me are video and gaming. I wonder how people who work in CAD, media editing, or other "heavy" workloads etc, feel.
  - co_king_3 7mo ago
    > I wonder how people who work in CAD, media editing, or other "heavy" workloads etc, feel. I would assume (generally speaking) that CAD and video editing applications are carefully designed for efficiency because it's an important differentiator between different applications in the same class. In my experience, these applications are some of the most exciting to use, because I feel like I'm actually able to leverage the power of my hardware. IMO the real issue are bloated desktop apps like Slack, Discord, Spotify, or Claude's TUI, which consume massive amounts of resources without doing much beyond displaying text or streaming audio files.
    - upboundspiral 7mo ago
      The problem with CAD is that mechanical engineering is still deeply proprietary, especially up and including the software stacks. There is basically no "open source" in mechanical engineering. So you are relegated to super heavy legacy applications that coast by through their integrations with other proprietary tools. Solidworks is much heavier then FreeCAD but FreeCAD didn't have integrations with simulation tools, with CAM software, used a different geometry engine than industry standard, etc, so when a company tried to turn FreeCAD into a product they failed. The only open source one sees in mechanical engineering comes out of academia, which while interesting, faces the problem that once the research funds dry up or the project finishes the software is dumped into the open in hard to find places, and is not further developed. I remain hopeful in the potential for open source, I believe that to have a truly accessible and innovative industry a greater level of openness is needed, but it is yet coming. I think CAD is a good place to start, as it is not a space where lots of hidden and closely guarded tricks are needed like in Finite Element Analysis. For personal uses FreeCAD is getting there. Snappier than Solidworks, but the workflow layout needs some work. I am also looking at projects such as https://zoo.dev https://zoo.dev. In mapping the design 1to1 to code (while keeping gui workflow as well) I think they have a real chance of offering enough value that new companies will be interested in trying out their approach. It opens the doors to automation analysis, and generation that while possible with something like Solidworks is cumbersome and not well documented.
gosub100 7mo ago
No, wealth gets more concentrated. Fewer people on the team will be able to afford a comfortable lifestyle and save for retirement. More will edge infinitesimally closer to "barely scraping by".

zsoltkacsandi 7mo ago

Completely agree. There is a common misunderstanding/misconception in product development, that more features = better product. I’ve never seen a product/project manager questioning themselves: does this feature add any value? Should we remove it? In agile methodologies we measure the output of the developers. But we don’t care about that the output carries any meaningful value to the end user/business.

antupis 7mo ago
It’s more about operational resilience and serving customers than product development. If you run early WhatsApp like organisation just 1 person leaving can create awful problems. Same for serving customers especially big clients need all kinds of reports and resources that skeleton organisation can not provide.
- zsoltkacsandi 7mo ago
  Yeah, that’s a misconception too based on my experience. I’ve seen many people (even myself) thinking the same: if I quit/something happens to me, there will be no one who knows how this works/how to do this. Turned out the businesses always survived. There was a tiny inconvenience, but other than that: nothing. There is always someone who is willing to pick up/take over the task in zero amount of time. I mean I agree with you, in theory. But that’s not what I’ve seen in practice.
9rx 7mo ago
> I’ve never seen a product/project manager questioning themselves: does this feature add any value? Should we remove it? To be fair, it is a hard question to contend with. It is easier to keep users who don't know what they're missing happier than users who lost something they now know they want. Even fixing bugs can sometimes upset users who have come to depend on the bug as a feature. > In agile methodologies we measure the output of the developers. No we don't. "Individuals and interactions over processes and tools". You are bound to notice a developer with poor output as you interact with them, but explicitly measure them you will not. Remember, agile is all about removing managers from the picture. Without managers, who is even going to do the measuring? There are quite a few pre-agile methodologies out there that try to prepare a development team to operate without managers. It is possible you will find measurement in there, measuring to ensure that the people can handle working without mangers? Even agile itself recognizes in the 12 principles that it requires a team of special people to be able to handle agile.

kvgr 7mo ago

I just build a programming language in couple of hours, complete with interpreter with claude code. I know nothing about designing and implementing programming languages: https://github.com/m-o/MoonShot https://github.com/m-o/MoonShot.

oblio 7mo ago
You built something. Now comes the hard or impossible part: is it any good? I would bet against it.
- kvgr 7mo ago
  Oh, thank you for informing me.
  - oblio 7mo ago
    Well, I can turn this around: "Oh, thank you for informing me that Claude built a compiler. Whoop-de-do".
lietuvis 7mo ago
Took a quick look, this seems like a copy of writing an interpreter in go book by Thorsten Ball, but just much worse. Also using double equals to mutate variables, why?
- kvgr 7mo ago
  Just because i wanted it to. I made some design choices that i found interesting.
  - deleted 7mo ago
    [deleted]
- kvgr 7mo ago
  Also i didn't read that book, if there are similarities in language it must be accident or claude steering me to what he knows. And if its the interpreter design, than it probably if from that book. And they told us, that they don't memorise the material.

jasode 7mo ago

, Winamp & VLC were build by less than four people. You only needed 1000s of people because the executive vision is always to add more useless junk into each product. Many types of software have essential complexity and minimal features that still require hundreds/thousands of software engineers. Having just 4 people is simply not enough man-hours to build the capabilities customers desire. Complex software like 3D materials modeling and simulation, logistics software like factory and warehouse planning. Even the Linux kernel and userspace has thousands of contributors and the baseline features (drivers, sandbox, GUI, etc) that users want from a modern operating system cannot be done by a 4-person team. All that said, there a lots of great projects with tiny teams. SQLite is 3 people. Foobar2000 is one person. ShareX screensaver I think is 1 developer in Turkey.

Lalabadie 7mo ago
But big projects are where the quality of LLM contributions fall the most, and require (continuous, exhausting, thankless) supervision!
- zozbot234 7mo ago
  Big projects can still be highly modular, and projects built by "1000s of devs" typically are. If your desired change can be described clearly without needing too much unrelated context, the LLM will probably get it right.
misiek08 7mo ago
I will use my right to disagree. Maybe not 4 people everywhere, but if you have product with well thought feature set you create those and then you really don't need 1000s people to just keep it alive and add features one by one. I - of course - am talking about perfect approach with everyone focused to not f** it up ;)

cedws 7mo ago

I’m finding that the code LLMs produce is just average. Not great, not terrible. Which makes sense, the model is basically a complex representation of the average of its training data right? If I want what I consider ‘good code’ I have to steer it. So I wouldn’t use LLMs to produce significant chunks of code for something I care about. And publishing vibe coded projects under my own GitHub user feels like it devalues my own work, so for now I’m just not publishing vibe coded projects. Maybe I will eventually, under a ‘pen name.’

rybosworld 7mo ago
We've gone from "it's glorified auto-complete" to "the quality of working, end-to-end features, is average", in just ~2 years. I think it goes without saying that they will be writing "good code" in short time. I also wonder how much of this "I don't trust them yet" viewpoint is coming from people who are using agents the least. Is it rare that AI one-shots code that I would be willing to raise as a PR with my name on it? Yes, extremely so (almost never). Can I write a more-specified prompt that improves the AI's output? Also yes. And the amount of time/effort I spend iterating on a prompt, to shape the feature I want, is decreasing as I learn to use the tools better. I think the term prompt-engineering became loaded to mean "folks who can write very good one-shot prompts". But that's a silly way of thinking about it imo. Any feature with moderate complexity involves discovery. "Prompt iteration" is more descriptive/accurate imo.
- ikr678 7mo ago
  Is there a big enough dataset of 'good' code to train from though?
  - rybosworld 7mo ago
    I (and lots of people) used to think the models would run out of training data and it would halt progress. They did run out of human-authored training data (depending on who you ask), in 2024/2025. And they still improve.
    - 7mo ago

imiric 7mo ago

Wait, surely adding 10x more agents to my project will speed up development, improve the end product, and make me more productive by that same proportion, right? I will task a few of them to write a perfectly detailed spec up front, break up the project into actionable chunks, and then manage the other workers into producing, reviewing, and deploying the code. Agents can communicate and cooperate now, and hallucination is a solved problem. What could go wrong? Meanwhile, I can cook or watch a movie, and ocasionally steer them in the right direction. Now I can finally focus on the big picture, instead of getting bogged down by minutiae. My work is so valuable that no AI could ever replace me. /s

FieryTransition 7mo ago

And Unix was mainly made by two people, it's astounding that as I get older, even tech managers don't know "the mythical man month", and how software production generally scales.

thunky 7mo ago
Sorry but 99.999% of developers could not have built Unix. Or Winamp. Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good.
- sdf2erf 7mo ago
  Thats because the distribution of developer quality and capability is skewed.
- eqvinox 7mo ago
  > Sorry but a 99.999% of developers could not have built Unix. Or Winamp. > Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good. The problem is that that's the same skill required to safely use AI tools. You need to essentially audit its output, ensure that you have a sensible and consistent design (either supplied as input or created by the AI itself), and 'refine' the prompts as needed. AI does not make poor engineers produce better code. It does make poor engineers produce better-looking code, which is incredibly dangerous. But ultimately, considering the amount of code written by average engineers out there, it actually makes perfect sense for AI to be an average engineer — after all, that's the bulk of what it was trained on! Luckily, there's some selection effect there since good work propagates more, but that's a limited bias at best.
  - thunky 7mo ago
    Agree completely. Where I'm optimistic about AI is that it can also help identify poorly written code (even it's own code), and it can help rewrite it to be better quality. Average developers can't do this part. From what I've found it's very easy to ask the AI to look at code and suggest how to make the code maintainable (look for SRP violations, etc, etc). And it will go to work. Which means that we can already build this "quality" into the initial output via agent workflows.

sdf2erf 7mo ago

What youre pointing at is the trade off between concentration of understanding vs fragmented understanding across more people. The former is always preferred in the context of product development but poses a key person risk. Apple in its current form is a representation of this - Steve did enough work to keep the company going for a decade after his death. Now its sort-of lost on where to go next. But on the flip side look at its market cap today vs 2000.

prng2021 7mo ago

“You never needed 1000s of engineers to build software anyway” What is the point of even mentioning this? We live in reality. In reality, there are countless companies with thousands of engineers making each piece of software. Outside of reality, yes you can talk about a million hypothetical situations. Cherry picking rare examples like Winamp does nothing but provide an example of an exception, which yes, also exists in the real world.

caminante 7mo ago
IMHO, it's flamebait. Your quoted text is provably false -- e.g., MSFT Windows, AWS, etc. and appeals to idealism of lean project teams.

level09 7mo ago

I see it differently. for me AI has been less about building more/fast, and more about unlocking potential that was always out of reach. Knowledge gaps that would've taken years to fill, new angles I wouldn't have thought to explore on my own. It's not that it makes more software. it just makes you more capable of tackling things you couldn't before.

phendrenad2 7mo ago

You need 1000 engineers because you have poor engineering leadership, or no engineering leadership, and engineering is a black hole that management shovels money into where it falls directly onto a huge plane of middle managers who do the best they can with their limited power and understanding. Meanwhile your sales team is writing specifications for the next version of the product, which they already promised to customers, and they hired an outside consultant to transform it into 500 spec documents written in damn near legalese, which will appear one day on the lead engineer's desk with no foreshadowing. It turns out that throwing more engineers at the problem helps here because you'll run out of tasks to assign to all of them and some will roam the halls and accidentally connect distributed knowledge back together.