3 ms·
Adding 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 lan
by czx4f4bd 4y ago
Adding 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.