My duties as a data scientist and forensic investigator involve writing lots of "little toy apps" for ETL and analysis.
BTW, why the disparaging reference to "little toy apps"?
BTW, why the disparaging reference to "little toy apps"?
It's an unmaintainable, single use piece of software (that doesn't even implement the features, it just glues together already existing code) that any CS student could write in a week. Congrats on getting a really fast CS student I guess ? Not to mention the fact that perfectly viable, better alternatives are available in many places.
It's like me nailing two 2x4s together to make a shelf. Yeah, sure, I made it myself and I didn't need any woodworking knowledge, but let's just hope I don't put grandma's heavy china on it.
The upside is that I can produce a shit-ton of one-shot code in record time, so I've got time to face the downside.
search_documents "search term" --bm25 --table-prefix some_project | fulltext -hl -v | less
search_documents "search term" --bm25 --table-prefix some_project | metadata
find /some/path/*.pdf | insert_documents --table-prefix some_project
I would estimate that I only wrote 5% of the code in the project with the rest coming from the LLM.
Sure, it's just a few hundred lines of code but it's been stable and helpful to get through some very large tranches of discovery material.
As a programmer (which is the requisite to build such tools even with LLMs), I have a plethora of tools to do the tasks, what I choose and how much time I invested in in that depends on something similar to this chart, but with an added dimension: interest.
Take for example the URL extraction. For one single occasion, I'd probably use VIM and macros to quickly do it. If it were many pages, I'd write a script. If it were infrequent, but recurrent, I'd take the time to write a better script and would only write a web page if the use case was shared with other people or if I wanted a cross platform solution.
I believe the first question one should ask before building is why. That leads you to find a better UX than shoehorning everything inside a web app.
In that aspect, I am hopeful. Maybe if "waste of time" activities are commoditized, "professionals" can instead focus on "what is important," whatever that might be.
What LLMs promise is endless drag. I try to structure my work to ensure that the final velocity is high.
This app for example - which runs OCR against PDF files entirely in the browser - was assembled by pasting in an example of PDF.js usage and an example of Tesseract.js usage and having it figure out the rest: https://simonwillison.net/2024/Mar/30/ocr-pdfs-images/
The kind of project I work on is more like this: Build an Android app for a quiz game. The quiz takes a list of random question from a set. Each set is a package that can be installed and upgraded when online. While the app is free, there is an activation code to be able to download the main packages. The app should work offline except for the activation and downloading packages. It also should notify when a new version is ready for a package. etc...
I don't know if LLMs could have helped me at the time (pre 2020), but I doubt it. Not because the code was complex, but mostly how cohesive the whole thing should be while taking care they're not tightly coupled and be maintainable by a single person. The IDE was a great helper once I got the design and the architecture outlined, mostly because it was deterministic and I already know what the end result should be.
The best current LLMs GPT-4o, Gemini 1.5 Pro, Claude 3.5 Sonnet - are just about at the point now where I'd expect them to be able to get a useful chunk of your Android spec there done. Which is pretty wild!