[deleted] t1_j31mwg2 wrote on January 5, 2023 at 1:06 PM

Reply to comment by Ortus14 in 2022 was the year AGI arrived (Just don't call it that) by sideways

[deleted]

ebolathrowawayy t1_j32ls76 wrote on January 5, 2023 at 5:07 PM

> solving novel problems

What is a novel problem? I've never really come across one and I've been in the field for over a decade. Maybe I am unskilled. I imagine that a day in the life of a typical programmer is ... do X Y and Z feature, don't break CI, move some tasks to the QA column, talk to a dev about an issue they found, fix CI that someone else broke, explain to the manager why Z feature is taking too long and go home. X Y and Z features could be: cobble together a home page, add a physics collider to a component that triggers an event, add a column to a DB and create a new REST endpoint, etc. All super basic ass stuff that eventually turns into a product that prints money for someone higher up.

Where's the novelty in software dev, excepting fields like ML? I predict that 90% of SW engineers do tasks that LLMs can do (including architecture design) within a year.

Edit: I've talked with other programmers a lot about this and architecture design comes up a lot. IMO, architecture design is basically picking your pokemon team. I need fast messaging with 100k users and the app should be accessible to many people across devices and there is no complex data analysis -- Ok Nodejs, React and MongoDB, I choose you!

I need an app that does heavy image manipulation that is resource intensive with a lot of interactive data analysis -- Ok C++, ImageMagick, D3js and Postgres, I choose you! etc. Architecture is simple, I'd like to hear why it isn't.

[deleted] t1_j32qpy5 wrote on January 5, 2023 at 5:36 PM

[deleted]

ebolathrowawayy t1_j32twcm wrote on January 5, 2023 at 5:55 PM

I just don't see it as novel if a customer asks you to build them a website with a data dashboard. I think the majority of work is cobbling together small pieces of stuff in very slightly new ways and that mostly the value comes from displaying domain data, connecting data to other data or connecting users to other users.

If a majority of software work required novel problem solving then I don't think very popular and widely used libraries like React, Angular, Tableau, Squarespace, Unity, etc. would exist. Today's developer picks a couple of libraries, slaps together some premade components and then writes a data parser for a customer's data and does stuff to it. I really do think the majority of work can be done by following medium articles and stackoverflow posts.

Even gamedev, widely considered to be "hard", is really not that novel. It's composed of a bunch of small pieces of code that everyone uses. Most AAA games don't deviate from typical game design patterns, they innovate by pouring money into small details, like horse balls physics in rdr2 or by hiring 1000 voice actors or by creating hundreds of random "theme park" quests that feel amazing or by doubling the number of 3D assets as the last record holding game. But those aren't actually novel things, they're money and time sinks but they're not difficult to implement.

If we're talking about Netflix-scale then yeah that's still novel and not easily done, but 90% of devs aren't doing that. The reason it's difficult is because there aren't a lot of resources on how to go about doing it at scale and what the tradeoffs are of different stacks. If it was deeply and widely documented like React apps are then it would be trivial for a LLM to do.

I think novel software problems that are difficult to automate would be anything that advances the current SOTA, like advancing ML algorithms, implementations of AI that solve intractable problems (protein folding), really anything that can't be easily googled. (Edit: for near future. Once AGI/ASI arrives, all bets are off).

I think a useful rule of thumb for whether or not something can be automated is that if it's well-documented then it's automatable.

I'm not arguing just to argue and I'm sorry if I come across that way. We've had SW team conversations about this at work a few times and I think about it a lot.