Readit NewsI was and am still surprised that I found nothing of that and even Ubuntu or fedora community look more "enterprise ready" to me these days.
Particularly the first part. I want to add a new feature, but I want to keep things clean. It needs tests, CI, documentation.
It makes exploring new ideas a bit cumbersome, because code tends to create minor distractions that eat up time. You miss a semicolon, or you forget the order of the arguments to a function you just wrote, do you have to flip to another file. Or the test framework needs an update, but the update breaks something so you have to do some changes. It's not just the time either, it's the context switch from the big picture to the very small details, and then back again.
LLM lets me do "one whole step" at a time. Or that's the positive spin on it. Seen another way, I'm further out from the details, and in most things, you have to hit a bit of a wall to really learn it. For senior devs, I lean towards the first, you've already learned what you're going to learn from fixing imports, you are operating on a higher level.
You can predict how some simple narrow edge case neural networks will converge, but this doesn't go all the way to frontier training runs, or even the kind of runs you can do at home on a single GPU. And that's one of the better covered areas.
It comes back to other people's comments about acceptance of the tooling. I don't mind the somewhat messy learning methodology - I can still wind up at a good results quickly, and learn. I don't mind that I have to sort of beat the AI into submission. It reminds me a bit of part lecture, part lab work. I enjoy working out where it failed and why.
Learning is also exponential, the more you do it, the faster it is, because you may already have the foundations for that particular bit.
And you'd be half-right: humans are extremely unreliable, and it takes a lot of safeguards and automated testing and PR reviews etc to get reliable software out of humans.
(Just to be clear, I agree that current models aren't exactly reliable. But I'm fairly sure with enough resources thrown at the problem, we could get reasonably reliable systems out of them.)
There's a reason why so many "laws" of ML are empirical - curves fitted to experimental observation data. If we had a solid mathematical backing for ML, we'd be able to derive those laws from math. If we had solid theoretical backing for ML, we'd be able to calculate whether a training run would fail without actually running it.
People say this tech is mysterious because it is mysterious. It's a field where practical applications are running far ahead of theory. We build systems that work, and we don't know how or why.
We know it’s not the correct answer, but better something close than nothing. (close can be awfully far, which is worse than nothing)
People on HN regularly claim that LLMs are useless if they aren’t 100% accurate all the time. I don’t think this is true. We work around that kind of thing every day.
With your examples:
- Before computers, fraud and human error was common in the banking system. We designed a system that was resilient against this and mostly worked, most of the time, well enough for most purposes even though it was built on an imperfect foundation.
- Highly precise clocks are a recent invention. For regular people 200 years ago, one person’s clock would often be 5-10 minutes off from someone else’s. People managed to get things done anyway.
I’ll grant you that Roman aqueducts, seasons and the sun are much more reliable than computers (as are all the laws of nature).
Two things that help me:
* have a good boilerplate
* ship things that do nothing
i.e. I find it helps to start a project using my good boilerplate then set up builds and releases (so for web projects, put them online) so that the page doesn't look so blank anymore, and I can see my progress in "releases" even if they're just for me/others contributing.