Yes, coding agents have reduced the skills/knowledge required to operate workloads on virtualized hardware. K8S and its ecosystem has changed so that it now provides 90% of what you need from the public cloud providers. Big changes that make 8-15X savings by running your own workloads.
I think it will be the big players who move first, as they have most to save and have the resources to make it happen.
It certainly feels like Netflix is now a k8s shop.
And it probably only a matter of time until they start repatriating workloads to optimize for costs. Then the world will sit up and notice.
It took me 5 years to get the boat - a 22ft daycruiser with toilet. That was 15 years ago, haven't looked back. Got a daycruiser from the UK. Drove there, bought a trailer there, drove it home. Arbitrage during the financial crisis - half the price of the same boat in Sweden at the time.
I lead a European owned and operated Data/AI company, Hopsworks. We are the only competitor to Databricks/Snowflake/etc based-in and from Europe. We can still compete, as we have a deep research/industry background (ex-MySQL and KTH folks).
Crossing the chasm is harder from here. Even if you build a great product (we are best at real-time AI) - we had a paper at SIGMOD 2024 where we showed higher thoughput/lower latency by a factor of 4-40X Databricks, AWS Sagemaker, and GCP vertex - we lack the echo chamber. (Try the mental exercise where Databricks' peers acknowledge massive over-performance through a peer-reviewed paper and imagine how much noise it would generate). Still, we can replace our competitor at their largest European customer, Zalando, for real-time AI. But it's a much harder slog than it should be due to the 10X lower round sizes (due to 10X smaller VC fund sizes). European pension funds place way more money in US VC funds than in EU VC funds - that is self-defeating.
How could they release something that doesn't support atomic rename and has no prospect of supporting atomic rename? Lots of workloads will crash and burn on this layer.
Files can be immutable if you have mutable metadata - but S3 does not have mutable metadata, so you can't rename a directory without a full copy of all its contents.
Immutable files can be solved by chunking them, allowing files to be opened and appended to - we do this in HopsFS. However, random writes are typically not supported in scaleout metadata file systems - but rarely used by POSIX clients, thankfully.
S3 Files was launched today without support for atomic rename. This is not something you can bolt on. Can you imagine running Claude Code on your S3 Files and it just wants to do a little house cleaning, renaming a directory and suddenly a full copy is needed for every file in that directory?
The hardest part in building a distributed filesystem is atomic rename. It's always rename. Scalable metadata file systems, like Collosus/Tectonic/ADLSv2/HopsFS, are either designed around how to make rename work at scale* or how work around it at higher levels in the stack.
I say this quite a lot to data scientists who are now building agents:
1. think of the context data as training data for your requests (the LLM performs in-context learning based on your provided context data)
2. think of evals as test data to evaluate the performance of your agents. Collect them from agent traces and label them manually. If you want to "train" a LLM to act as a judge to label traces, then again, you will need lots of good quality examples (training data) as the LLM-as-a-Judge does in-context learning as well.
There has been a lot of proposals to dam up massive unpopulated sea-facing valleys in Mayo and Donegal and use pumped hydro with seawater. Was a bit topic 15 years ago, but never happened. All that happened was the silvermines pump hydro plant that seems behind schedule.
The reference in the text to Anthropic’s “Towards Understanding Sycophancy in Language Models” is related to RLHF (reinforcement learning with human feedback).
Claude code uses primarily different "pathways" in Anthropic LLMs that were not post-trained with RLHF, but rather with RLVF (reinforcement learning with verifiable rewards).
So, his point about code being produced to please the user isn't valid from where I am sitting.
Here is an article I wrote this week with a section on Feldera - how it uses its incremental compute engine to compute "rolling aggregates" (the most important real-time feature for detecting changes in user behavior/pricing/anamalies).
They need to fix the addresses. In Stockholm, all of the companies are placed in the old town. At Hopsworks, we are in Sodermalm (hipster) - we are not old school money.
I gave a talk at PyData Berlin on how to build your own TikTok recommendation algorithm. The TikTok personalized recommendation engine is the world's most valuable AI. It's TikTok's differentiation. It updates recommendations within 1 second of you clicking - at human perceivable latency. If your AI recommender has poor feature freshness, it will be perceived as slow, not intelligent - no matter how good the recommendations are.
TikTok's recommender is partly built on European Technology (Apache Flink for real-time feature computation), along with Kafka, and distributed model training infrastructure. The Monolith paper is misleading that the 'online training' is key. It is not. It is that your clicks are made available as features for predicitons in less than 1 second. You need a per-event stream processing architecture for this (like Flink - Feldera would be my modern choice as an incremental streaming engine).
I got turned off in the first paragraph with the misuse of the term "back pressure". "back pressure" is a term from data engineering to specifically indicate a feedback signal that indicates a service is overloaded and that clients should adapt their behavior.
Backpressure != feedback (the more general term). And in the agentic world, we use the term 'context' to describe information used to help LLMs make decisions, where the context data is not part of the LLM's training data. Then, we have verifiable tasks (what he is really talking about), where RL is used in post-training in a harness environment to use feedback signals to learn about type systems, programming language syntax/semantics, etc.
If they are exploding categorical variables using OHE and storing the columns - that is the wrong thing to do. You should only ever store untransformed feature data in tables. You apply the feature transformations, like OHE, on reading from the tables, as those transformations are parameterized by the data you read (the training data subset you select).