Twirrim
The fact that I had to throw an LLM at it to cut down the slop and turn it into something more succinct and comprehensible is nuts. For myself, I'd be embarrassed if I released something with that kind of README on it.
> The problem it’s trying to solve is that generating valid SQL doesn’t necessarily produce the right answer. An AI might find a column called revenue, but still choose the wrong dataset or misunderstand whether that figure includes things like refunds. Auto Ontology adds information about what the data means to help it make those decisions.
and then the one paragraph summary at the end:
> My reading: it’s a database chat application built around a reusable catalogue of business meaning. The question worth testing is whether that catalogue makes answers measurably more correct—and how much human work it takes to get the definitions right.
We went from difficult to manipulate buttons through to multi-function buttons where controls get hidden through some incomprehensible maze of menu options, to now where it sometimes feels lucky if you even get an option to manually set the time at all.
Honestly, if work was to come at me with a buy-out offer, and I was in a position to be able to afford to not work for a few years, I'd probably accept. Maybe go find some non-tech work for a little bit to stretch the dollars and ensure I have health insurance.
We're in such a bubble at the moment, things are going to get really rough.
I'm mostly starting to have some success telling TPMs and engineers to ask chatgpt to give them appropriate code that generates more accurate answers.
I had a team proudly show me how they were feeding their dashboard data into an LLM to predict growth needs, instead of doing basic linear regression or any number of pre-existing basic statistical analysis. The part that depressed me the most on that was it was a bunch of engineers that did it, the people you'd most hope would understand what an LLM is/does.
I'm not sure anything says what your editorialised title, and comment link says.
They were calling out that an NGINX CVE that was Important took 20 days. They're saying nothing about what classification Amazon has set on PHP,.
> So, from the CVE publication to an available fixed package it took 20 days, not a month.
They specifically call out that it's not the same as the Nginx case:
> In contrast to the PHP's case, that CVE wasn't Critical, but only Important, that doesn't have the same urgency.
The carrier has been letting them down every single step of the way (and to add insult to injury, I have to use that damn "Shop" app to track the delivery.) From a pick up on the 1st of October, they've supposedly had the package go back and forth between Los Angeles and here a couple of times.
Not sure what the price difference is for them to have used this carrier, but it can't be worth it compared to the fuss both of us are having trying to get the carrier to actually deliver the shipped product. The vendor is going to send a second one if the delivery doesn't happen to day like the carrier pinky promises it will (they've promised for 3 days straight it was going to be delivered that day, so I'm not holding my breath)
Nearly 20 years ago I had such a wonderful debugging experience when the power grid where I lived sent a "switch to backup" message and then milliseconds later a cancellation. The colo's power system got jammed between generator and mains electricity and everything rapidly ran out of UPS backup power and died. I found so many dependency loops between servers that day, took me hours to get things back up and running.
I've found type hints to be remarkably useful and catch significantly more bugs than I ever would have thought, and have quickly picked up the practice of using them wherever I code. My general finding is that if I have to struggle to put useful type hints in place, I probably need to rethink my code.
I even type hint my unit tests because I've learned that sometimes type incorrectness means my tests haven't been testing what I thought they were testing.
Frameworks like pydantic[0] can help you turn those type hints into something runtime enforcing too.
[0] https://pydantic.dev/docs/validation/latest/get-started/
I've waded through unfamiliar code at 3am trying to figure out just why the hell things broke this time more times than I can care to remember, particularly trying to tease apart the ways that code has organically grown compared to the original intent. If I'm subjected to one more piece of "spooky at a distance" injected behaviour code I'll probably scream loud enough to be heard half way across the country.
It's still just leaps and bounds more readable than what people are slopping together (I do have some co-workers that have been extremely tightly focused on avoiding "slop" with their AI and doing a lot of tuning, and it's certainly preferable to the ones that haven't)
Your code used to be a masterpiece, so well crafted it's easy for AI to tweak and modify because you've got everything so logically organised and scoped... and now this is what you're producing? Hard to debug monstrosities that only an LLM can realistically bolt new features or tweaks onto, because it can do the kinds of refactoring necessary each time.
We use to talk about the fact that code should be readable because you spend more time reading it than writing it, but I think that misses the key part that readable code is also typically easier to debug. If you can read and understand the code, you can follow the logic when things are wrong in production, and you can more easily reason about the emergent properties of interactions between the complex systems that are involved.
It's down at the moment (Not sure if it'll return?) but Chat Jimmy[0] produced by Taalas[1] was powered by an ASIC running Llama 3.1 8B, and hitting 17,000 tokens/sec. It was amazing to use, you'd no sooner have hit enter than you had a full response back. I actually found its speed to be a problem for interactive stuff, as every answer got several paragraphs I'd then wade through, vs a model populating text closer to my reading speed.
I appreciate, there are differences between an 8 billion parameter model and something GPT-4-ish, but we're currently in the middle of a race between a half dozen or so companies to produce the next best frontier model, which requires their infrastructure to be dynamic.
We really don't always need newer better faster stronger models, there's quite a lot of room for "good enough" where getting 17kt/s at significantly lower power would be amazing.
At least in the later stages of life Sun sales folks were literally selling the company into bankruptcy. They'd find out what competitors were offering, undercut it to the degree they'd make a loss, just to get the contract and their sweet commission.
To not realise you've got this going on really speaks to how little they were interested in the actual running of the business.
2013-2014 would be about right, they were still in SEA when I joined in 2013 but were actively working on decommissioning it.
The amount of data S3 stores "automatically replicating" to other geographical locations would make things prohibitively expensive, especially when you consider the daily delta, and how much of that is ephemeral or frequently mutated data that is stored. The bandwidth costs alone would be eye-watering, let alone the storage costs.
S3 cannot make any automated decision about whether data is, or isn't important, and if they did they'd only open themselves up to lawsuits if they guessed wrong. That's why it's made an option for the end user to enable replication if they want to, or choose to replicate their own data.
Feels all too often like it has been replaced with "We switched from $A to $B, the reasons will shock you!" (Followed inevitably by "We switched from $B to $C").