- I’m interested in earnings correlating with feature releases. Maybe you’re pushing 100% more bugs, but if you can sell twice as many buggy features as your neighbor at the same time, it could be that you could land more contracts.
It’s definitely a raise to the bottom scenario, but that was already the scenario we lived in before LLMs.
- I second the persistence. Some of the most persistent code we own is because it’s untested and poorly written, but managed to become critical infrastructure early on. Most new tests are best-effort black box tests and guesswork, since the creators have left a long time ago.
Of course, feeding the code to an LLM makes it really go to town. And break every test in the process. Then you start babying it to do smaller and smaller changes, but at that point it’s faster to just do it manually.
- The crusade against gluten probably did it. Tofu lives as un-refrigerated grey blobs and tempeh never even made it to the shelf, probably because of hormone-disrupting soybeans. But hyper-engineered single cell meat? Now that’ll sell.
- Gemini routinely makes up stuff about BigQuery’s workings. “It’s poorly documented”. Well, read the open source code, reason it out.
Makes you wonder what 97% is worth. Would we accept a different service with only 97% availability, and all downtime during lunch break?
- I think group 3 is a bit of a reach. Most people just treat it as a commodity. You need a break after shopping? Coffee. Meeting someone to talk over something for 30 minutes? Coffee. Need a cozy place to sit and get some work done? Coffee. For none of these do people have to engage with the community or be caffeine addicts.
- > We shall be able to rid ourselves of many of the pseudo-moral principles which have hag-ridden us for two hundred years
Still haven’t gotten rid of work for work’s sake being a virtue, which explains everything else. Welfare? You don’t “deserve” it. Until we solve this problem, we’re not or less heading straight for feudalism.
- > Go to any Asian country and houses, healthcare and cars are priced like commodities, not luxuries.
What do you mean? Several Asian cities have housing crises far worse than the US in local purchasing power, and I'd even argue that a "cheap" home in many Asian countries is going to be of a far lower quality than a "cheap" home in the US.
- If you've ever read a blog on trading when LSTMs came out, you'd have seen all sorts of weird stuff with predicting the price at t+1 on a very bad train/test split, where the author would usually say "it predicts t+1 with 99% accuracy compared to t", and the graph would be an exact copy with a t+1 offset.
So eye-balling the graph looks great, almost perfect even, until you realize that in real-time the model would've predicted yesterday's high on today's market crash and you'd have lost everything.
- Originally I used Pandera, but it had several issues last
* Mypy dependency and really bad PEP compliance * Sub-optimal runtime check decorators * Subclasses pd.DataFrame, so using e.g. .assign(...) makes the type checker think it's still the same type, but now you just violated your own schema
So I wrote my own library that solves all these issues, but it's currently company-internal. I've been meaning to push for open-sourcing it, but just haven't had the time.
- Should have done GME stocks only. Now THAT would’ve been interesting to see how much they’d end up losing on that.
Just riding a bubble up for 8 months with no consequences is not an indicator of anything.
- I honestly don't get why you'd hate pandas more than anything else in the Python ecosystem. It's probably not the best tool in the world, and sure, like everybody else I'd rewrite the universe in Rust if I could start over, and had infinite time to catch up.
But the code base I work on has thousands and THOUSANDS of lines of Pandas churning through big data, and I can't remember the last time it lead to a bug or error in production.
We use pandas + static schema wrapper + type checker, so you'll have to get exotic to break things.
- There's been a translate button for years which hooks deep into every nook and cranny of the website's HTML. It works great, it's built in and many restaurants even advertise it for tourists, because it's a zero-effort translation of their existing menu. Plus, it's low-data when you're inside a 1-bar basement restaurant.
Using an LLM to translate the visible part of a PDF on a mobile... seems like the worst possible solution to the problem.
- Actually, big orgs are doing exactly that; slapping a chatbot onto their support ticket backlog. Being really, actually “data driven” is hard, and must happen from the bottom up. So instead there’s chatbots in their frontend and support backend, but the backend doing the actual lifting probably hasn’t changed one bit.
- I wonder how many market inefficiencies this creates. People with worse education, people who cheated their way to a job opening compared to a better candidate, etc. Basically counteracting the productivity gains AI was supposed to bring.
- > There were some UI glitches
Interesting that a next-gen open-source-based agentic coding platform with superhuman coding models behind it can have UI glitches. Very interesting that even the website itself is kind of sluggish. Surely, someone, somewhere must have ever optimized something related to UI rendering, such that a model could learn from it.
- IO and global state is also just inputs that can be part of arrange-act-assert. Instead of mocking your database call to always return "foo" when the word "SELECT" is in the query, insert a real "foo" in a real test database and perform a real query.
Again I've heard "but what if my database/table changes so rapidly that I need the mock so I don't need to change the query all the time", in which case you ought to take a moment to write down what you're trying to accomplish, rather than using mocks to pave over poor architectural decisions. Eventually, the query fails and the mock succeeds, because they were completely unrelated.
So far I've only seen mocks fail eventually and mysteriously. With setups and DI you can treat things mostly as a black box from a testing point of view, but when mocks are involved you need surgical precision to hit the right target at the right time.
- Right? Maybe there's a follow-up: "...and that's why I built this stick-in-wet-clay emulating pen". I'm thinking it'd be like stamping, mostly.
- If you ask Silicon Valley, any organizational problem can be a technical problem if you try hard enough.
- Consider this simple example: Storing all your sensitive user data in one centralized location (e.g. a US server) would be great for any kind of analytics and modeling to tap into, and is technically very easy to do, but it also violates virtually every country's data privacy laws. So then you have to set up siloed servers around the world, deal with data governance, legal stuff, etc.
Sure, it then becomes a technical challenge to work around those limits, but that may be cost/time prohibitive.
Remember blue check marks? The EU is not happy about those.
https://ec.europa.eu/commission/presscorner/detail/en/ip_25_...