3 ms·

Well it is volume business. <1% of advanced skill developers will find AI helper useless but for 99% of IT CRUD peddlers these tools are quite sufficient. All i

by geodel 2y ago

Well it is volume business. <1% of advanced skill developers will find AI helper useless but for 99% of IT CRUD peddlers these tools are quite sufficient. All in all if employers cut down 15-20% of net development costs by reducing head counts, it will be very worthwhile for companies.

WgaqPdNr7PGLGVW 2y ago
I suspect it will go a different direction. Codebases are exploding in size. Feature development has slowed down. What might have been a carefully designed 100kloc codebase in 2018 is now a 500kloc ball of mud in 2024. Companies need many more developers to complete a decent sized feature than they needed in 2018.
- outworlder 2y ago
  It's worse than that. Now the balls of mud are distributed. We get incredibly complex interactions between services which need a lot of infrastructure to enable them, that requires more observability, which requires more infrastructure...
  - WgaqPdNr7PGLGVW 2y ago
    Yeah. You can fit a lot of business logic into a 100kloc monolith written by skilled developers. Once you start shifting it to micro services the business logic gets spread out and duplicated. At the same time each micro-service now has its own code to handle rest, graphql, grpc endpoints. And each downstream call needs error handling and retry logic. And of course now you need distributed tracing. And of course now your auth becomes much more complex. And of course now each service might be called multiple times for the one request - better make them idempotent. And each service will drift in terms of underlying libraries. And so on. Now we have been adding in LLM solutions so there is no consistency in any of the above services. Each dev rather than look at the existing approaches instead asks Claude and it provides a slightly different way each time - often pulling in additional libraries we have to support. These days I see so much bad code like a single microservice with 3 different approaches to making a http request.
- geodel 2y ago
  Agree. But we are already in that loop. A 50KLOC properly written "Monolith, hence outdated" app is now 30 micro services of 20KLOC surface + 100KLOC of submerged in terms of convenience libraries with kubernetes, grafana, datadog, servicemesh and so on. From what I am seeing companies are increasingly using off the shelf components so KLOC will keep rising but developer count would not.
imiric 2y ago
Sure, but my specific question was fairly trivial, using a mainstream language and a popular library. Most of my work qualifies as CRUD peddling. And yet these tools are still wasting my time. Maybe I'll have better luck next time, or maybe I need to improve my prompting skills, or use a different model, etc. I was just expecting more from state of the art LLMs in 2024.

by geodel 2y ago

WgaqPdNr7PGLGVW 2y ago

I suspect it will go a different direction. Codebases are exploding in size. Feature development has slowed down. What might have been a carefully designed 100kloc codebase in 2018 is now a 500kloc ball of mud in 2024. Companies need many more developers to complete a decent sized feature than they needed in 2018.

outworlder 2y ago
It's worse than that. Now the balls of mud are distributed. We get incredibly complex interactions between services which need a lot of infrastructure to enable them, that requires more observability, which requires more infrastructure...
- WgaqPdNr7PGLGVW 2y ago
  Yeah. You can fit a lot of business logic into a 100kloc monolith written by skilled developers. Once you start shifting it to micro services the business logic gets spread out and duplicated. At the same time each micro-service now has its own code to handle rest, graphql, grpc endpoints. And each downstream call needs error handling and retry logic. And of course now you need distributed tracing. And of course now your auth becomes much more complex. And of course now each service might be called multiple times for the one request - better make them idempotent. And each service will drift in terms of underlying libraries. And so on. Now we have been adding in LLM solutions so there is no consistency in any of the above services. Each dev rather than look at the existing approaches instead asks Claude and it provides a slightly different way each time - often pulling in additional libraries we have to support. These days I see so much bad code like a single microservice with 3 different approaches to making a http request.
geodel 2y ago
Agree. But we are already in that loop. A 50KLOC properly written "Monolith, hence outdated" app is now 30 micro services of 20KLOC surface + 100KLOC of submerged in terms of convenience libraries with kubernetes, grafana, datadog, servicemesh and so on. From what I am seeing companies are increasingly using off the shelf components so KLOC will keep rising but developer count would not.

imiric 2y ago

Sure, but my specific question was fairly trivial, using a mainstream language and a popular library. Most of my work qualifies as CRUD peddling. And yet these tools are still wasting my time. Maybe I'll have better luck next time, or maybe I need to improve my prompting skills, or use a different model, etc. I was just expecting more from state of the art LLMs in 2024.