4 ms·

This isn't possible in every industry but it certainly is in the software space. With modern tooling and automation, one person can accomplish quite a lot. As

This isn't possible in every industry but it certainly is in the software space. With modern tooling and automation, one person can accomplish quite a lot. As with most paradigm shifts, many are sleeping on this. But expect small teams to be behind more and more of the most influential software of the next decade. And the traditional mindset on what is a company and how growth happens will also evolve.

ChrisMarshallNY 3y ago
I suspect that AI will be an accelerator for this. It's not gonna replace us. It will help us to be more productive.
- actionfromafar 3y ago
  Some stuff won't be needed in more quantity. So if what was needed had five people and now three people can do that same job, two are let go. Of course, things will sort themselves out eventually, but whenever fast shifts occurs, a lot of throwing under a lot of buses will occur in the meantime.
- passion__desire 3y ago
  Each software framework, whether they be java, python, js frameworks, would have its own finetuned llm, which the foundation maintaining the framework would provide. It's the next evolution of documentation. Instead of consulting the docs, people would consult these doc-llms. Thank God, we have llama 2 for this purpose.
- nicbou 3y ago
  It will replace some people, and the benefits of productivity will be reaped by someone else.
- lionkor 3y ago
  The biggest issue for founder-type programmers is not code volume, its code quality. Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit. Strong dependencies on half-assed internal data structures, stretch marks everywhere ("we did it like this because we had time pressure, and it was wrong, and now we cant get rid of it"), weird protocols ("we will just use a stringly-typed header for our high performance TCP communications, its easier to debug!"), lack of documentation ("no bro, the code is the documentation!"), and very little if any devops or testing (lol testing). Thats good that way, too, otherwise products would never be launched. Thats why a lot of engineers will not launch a product, ever - their standards are too high and theyre too hung up on doing it right, that their window of opportunity for their niche fades. The one thing I haven't seen a single startup or upcoming product struggle with is quickly churning out a lot of code that mostly/fully does the job and sells. Unless AI can replace engineers like me, half of who's job experience is cleaning up, streamlining and refactoring these "quick launch" codebases, in order to make the code last even if core engineers leave and to make onboarding easier, we are NOT going to see a massive revolution of AI programming tools.
  - BoorishBears 3y ago
    Simply not true, and this post represents the biggest fallacy most technical founders struggle with. The most common problem is they never ship anything. Or they ship something no one needs. Or they ship something people need but don't know how distribution works so those people never find it. I'm someone who's spent enough time writing high quality code that my default thinking is in line with yours, but the truth is it's a privilege to get to a place where you can afford to hire people to clean up your "quick launch" codebase. Even if you look at it from a place of personal pride, there is more pride in proving your idea solves real problems for real people today, than there is in chasing an ideal codebase that scales better tomorrow when you don't even have proof anyone wants it.
  - lelanthran 3y ago
    > The biggest issue for founder-type programmers is not code volume, its code quality. > Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit. I dunno your background, but I think you have it almost completely, 100% incorrect in your first paragraph, while being completely, 100% correct in your second. The summary is this: if you're launching a product, you want to do it as soon as possible, damn the quality of the code as long as the quality of the product is sufficient. The reason for this is because, 9 times out of 10, you're going to be throwing all that code away anyway! It's rare that the first product you ship is successful. And if it does get successful? Well, then you have the money to redo it, refinish it, polish it, address tech debt, whatever. There's only two outcomes: the product succeeds or it fails. If, in the rare case, you launch a successful product and the code is clean, perfect, etc, you haven't gained anything over the person who launched a half-assed, broken-but-still-sufficient successful product. The competitor can still get his product to your standards because they succeeded. If you fail, then you have spent unnecessary time determining what doesn't work, while the competitor has spent less time and can attempt another product after his failure, while you're still perfecting your first failure.
    - lionkor 3y ago
      I absolutely agree with you, and I should have phrased my first sentence better: The biggest issue for founder-type programmers [when their product is successful and now they need to grow it] is not code volume, its code quality.
deleted 3y ago
[deleted]

ChrisMarshallNY 3y ago

I suspect that AI will be an accelerator for this. It's not gonna replace us. It will help us to be more productive.

actionfromafar 3y ago
Some stuff won't be needed in more quantity. So if what was needed had five people and now three people can do that same job, two are let go. Of course, things will sort themselves out eventually, but whenever fast shifts occurs, a lot of throwing under a lot of buses will occur in the meantime.
passion__desire 3y ago
Each software framework, whether they be java, python, js frameworks, would have its own finetuned llm, which the foundation maintaining the framework would provide. It's the next evolution of documentation. Instead of consulting the docs, people would consult these doc-llms. Thank God, we have llama 2 for this purpose.
nicbou 3y ago
It will replace some people, and the benefits of productivity will be reaped by someone else.
lionkor 3y ago
The biggest issue for founder-type programmers is not code volume, its code quality. Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit. Strong dependencies on half-assed internal data structures, stretch marks everywhere ("we did it like this because we had time pressure, and it was wrong, and now we cant get rid of it"), weird protocols ("we will just use a stringly-typed header for our high performance TCP communications, its easier to debug!"), lack of documentation ("no bro, the code is the documentation!"), and very little if any devops or testing (lol testing). Thats good that way, too, otherwise products would never be launched. Thats why a lot of engineers will not launch a product, ever - their standards are too high and theyre too hung up on doing it right, that their window of opportunity for their niche fades. The one thing I haven't seen a single startup or upcoming product struggle with is quickly churning out a lot of code that mostly/fully does the job and sells. Unless AI can replace engineers like me, half of who's job experience is cleaning up, streamlining and refactoring these "quick launch" codebases, in order to make the code last even if core engineers leave and to make onboarding easier, we are NOT going to see a massive revolution of AI programming tools.
- BoorishBears 3y ago
  Simply not true, and this post represents the biggest fallacy most technical founders struggle with. The most common problem is they never ship anything. Or they ship something no one needs. Or they ship something people need but don't know how distribution works so those people never find it. I'm someone who's spent enough time writing high quality code that my default thinking is in line with yours, but the truth is it's a privilege to get to a place where you can afford to hire people to clean up your "quick launch" codebase. Even if you look at it from a place of personal pride, there is more pride in proving your idea solves real problems for real people today, than there is in chasing an ideal codebase that scales better tomorrow when you don't even have proof anyone wants it.
- lelanthran 3y ago
  > The biggest issue for founder-type programmers is not code volume, its code quality. > Most founding code of products I have seen is the most fucked up, horrible, over- or under-engineered, hacky, buggy, usually platform-specific and NIH covered pile of hot shit. I dunno your background, but I think you have it almost completely, 100% incorrect in your first paragraph, while being completely, 100% correct in your second. The summary is this: if you're launching a product, you want to do it as soon as possible, damn the quality of the code as long as the quality of the product is sufficient. The reason for this is because, 9 times out of 10, you're going to be throwing all that code away anyway! It's rare that the first product you ship is successful. And if it does get successful? Well, then you have the money to redo it, refinish it, polish it, address tech debt, whatever. There's only two outcomes: the product succeeds or it fails. If, in the rare case, you launch a successful product and the code is clean, perfect, etc, you haven't gained anything over the person who launched a half-assed, broken-but-still-sufficient successful product. The competitor can still get his product to your standards because they succeeded. If you fail, then you have spent unnecessary time determining what doesn't work, while the competitor has spent less time and can attempt another product after his failure, while you're still perfecting your first failure.
  - lionkor 3y ago
    I absolutely agree with you, and I should have phrased my first sentence better: The biggest issue for founder-type programmers [when their product is successful and now they need to grow it] is not code volume, its code quality.

deleted 3y ago

[deleted]