4 ms·
Something else that frames this conversation well is to consider the experience for a non programmer, inspecting the AI results to some query. We view this all
by jossclimb 4y ago
Something else that frames this conversation well is to consider the experience for a non programmer, inspecting the AI results to some query. We view this all through very adept and skilled eyes that know how to code an how to read code. Imagine you don't know anything about programming...
* You don't know what a function is (or a method / class)
* You don't even understand variables, static types, bools/ints/strings
* You have no idea about an entry point such as main, how returns work
* You have no idea about OOO, organising code over multiple files
* You don't know what a socket is, you don't understand I/O, file handling
To top it all, code looks alien to you, you have no idea how to read it.
The only individuals who would be able to bridge the knowledge above, would likely become programmers anyhow.
- it_citizen 4y agoThe biggest effort when I write code is to make it readable for other developers. The day where non tech people start using AI to produce non critical software and start interacting with code as a black box, simply telling the AI what they want and pointing the edge cases to correct, how much simpler development will become for AIs?
- czx4f4bd 4y agoAdding to your list: * You don't have experience with basic technical decision making -- e.g. why would you pick Java vs. C vs. Python vs. Go vs. any other language, and how would that decision change if you were building a web app vs. mobile app vs. embedded software? * You don't have a familiar set of tools and established preferences for the aforementioned decisions -- i.e. if an experienced programmer is building a web app, there are probably specific languages and tools they're inclined to reach for. * You don't know about application deployment and productionization. How do you get your project somewhere people can use it? You don't know about deploying code to servers or running it in Docker or K8s or PaaS. * You don't have the practiced logical thought process for things like algorithm design, debugging, figuring out user bug reports, identifying edge cases, predicting user behavior, etc. * You don't have the experience with things that experienced programmers find "obvious" -- e.g. if you're building a web app, you need an authentication system, registration flow, password reset, etc. I think the main effort to address this will be LLM-driven low-code solutions. Imagine something like Airtable, but with an integrated LLM assistant that can make changes to your app and write code to implement business rules and automation. This gets rid of problems like choosing your tech stack, deployment, etc. and it minimizes the amount of code the LLM has to create. I imagine this will have effects comparable to those of spreadsheet software: non-programmers will be able to build custom tools with a newfound ease and some will end up learning a lot of programming skills in the process. And, much like with spreadsheets, these tools will end up becoming business critical in unexpected ways and will turn out to be a huge pain in the ass to maintain. They'll find that parts of their business logic don't work as expected and that they can't figure out how to prompt the LLM to get it to implement the rules the right way. The users of these tools will basically have to learn some programming anyway or they'll have to hire experienced programmers to figure the problems out for them.
- thewebcount 4y agoYeah, I think this nails it. I think about the non-trivial parts of writing code, and I think about all the previous failed attempts at this sort of thing, and I remain unimpressed so far. I think specifically about things like optimizations and wonder how an LLM would deal with that. In the last week I’ve written code that dealt with file I/O slowness, thread contention, thread deadlock, etc. In order to even begin fixing these problems, I had to first identify what the cause was by debugging them. Then I had to reason about how the program works to think up a good fix for the issue in our specific case. There are no stack overflow answers for some of the problems I fixed this week. Heck, at one point in the past, I even wrote some code that we thought about getting patented. It was an interesting solution to the problem. And the problem itself was not a common one (but not unheard of). There’s a small amount of literature on it, but not a ton. I don’t see LLMs being a threat to this type of work. But in talking about it, I do see how some other type of AI might assist with it.