Forem: Rasmus Ros

Writing the Loss Function

Rasmus Ros — Sun, 03 May 2026 19:57:32 +0000

I keep seeing the same argument about AI making us dumber. It's the same argument people had about search engines, and before that books. The usual response is to point at history and say "every generation panics, every generation was wrong, relax." I think that response is half right, and the wrong half is what bothers me.

Tools change what we bother to remember. The people who'd trained their whole lives to memorize 10,000-line oral epics watched the craft die when writing showed up. Long arithmetic in your head used to be normal; calculators arrived and the payoff for keeping that skill sharp went away. Brains didn't shrink. The skills just stopped being worth practicing.

Search engines are the one I lived through. I was a kid when Google replaced Altavista and went from "useful" to being a synonym for finding things. I still remember being amazed that I could search for a zebra and have a picture of one on my screen in only five minutes. Years later I ended up working on search engines as a dev myself in ecommerce, and I've even built one from scratch for Theca.

Only 90s kids will understand that this makes you dumber. (It was genuinely bad.)

I don't memorize phone numbers anymore. I don't memorize directions. I don't even memorize the APIs of libraries I use every week. What I do instead is keep a fairly precise mental index of where things live and what query will retrieve them. That's a real cognitive trade. I gave up some recall and got back a much larger working set of pointers. Net positive, I think, but I notice the trade in a way I didn't when I was nine.

We usually keep teaching

AI tools push the same trade further. They don't just outsource recall, they outsource synthesis: the part where you actually work through a problem and end up with a model of it in your head. I notice this when I let an LLM write code I could have written myself. I get the output, but I didn't build the model, which is usually the part I wanted. The people who worry about atrophy here aren't wrong, and it's worth its own post.

One thing the prior cases got right is that society kept teaching the underlying skill anyway. Calculators didn't kill arithmetic class. Search engines didn't kill the library-science basics on how an index actually works. Some skills got canonized as core, worth practicing even after the tool that automated them arrived, because we collectively decided they mattered. Coding hadn't quite reached that status yet, but I think it would have given another decade. AI may have shown up too early for that to happen.

So the historical pattern mostly holds: tools rewire priorities, some skills fade, others grow, the panic looks silly in retrospect. Where the "relax, every generation panics" crowd gets it wrong is in assuming AI is just the next entry in that list. It might be. But the environment AI is landing in is not the environment the printing press or the early search engine landed in.

The loop is the problem

Books don't optimize you. Calculators don't optimize you. Search engines, at the lookup layer at least, were mostly trying to give you the page you asked for and then get out of the way. Modern search has piled on ads and ranking incentives since, but the core "find it and leave" loop is still recognizable. The dominant information channel today is none of those things. It's a feed, and the feed is an optimizer. The target variable is engagement.

Earlier tools removed friction from a specific task and let you spend the saved effort somewhere else. A feed isn't trying to remove friction from anything you'd recognize as a task. It's trying to keep you in the loop. The reward signal it's chasing (what makes you click, stay, scroll, react) is not the same signal as "this was useful to me." It's often the opposite.

There's data on this now. Heavy social media use predicts elevated depression and anxiety in kids and young adults. Longitudinal studies find the social media use comes first, not the depression.

And then you wire a generative model into the same loop. Generative AI doesn't change the objective, it just gives the loop a faster, cheaper supply tuned to whatever it already rewards.

Left: today's engagement loop, ranking from a human-made pool. Right: the same loop with a generative model in place of the pool.

Adding AI to the stack

My background is in optimization. The recurring question I work on is what a product should actually be optimizing for (PhD on automating A/B testing, Eignex the side project still chasing it). So when I look at "LLMs plus arecommendation feed" it looks to me like the same loop with a much better content supply. Not really a new content medium.

The version running today doesn't even use generation in the loop. The recommender stacks at the big platforms (Meta, TikTok, YouTube) are still doing what they've done for a decade: ranking content other people uploaded. The supply pool was already effectively infinite after years of user-generated content. The change is that a growing share of what gets uploaded is now AI-made, and the existing optimizer ranks the synthetic stuff exactly like everything else.

The scarier version puts the generator inside the loop, per-user posts written for you on demand. That sounds like fiction, and we don't have it. The thing is, we don't need it. The pool of generated content is already absurd enough that something in it fits your viewing history, your current mood, and what you had for breakfast. The optimizer just has to find it. A pool that grows by millions of items a day, at near-zero cost per item, behaves a lot like an on-demand generator.

Each dot is a post in embedding space. Human posts (blue) cluster on popular topics; AI posts (red) fill the gaps.

None of this is hypothetical. AI-generated music has already racked up millions of streams on Spotify before anyone noticed it wasn't human (the Velvet Sundown story last summer was the most visible example). Facebook is saturated with generative slop: fabricated heart-warming stories, sculptures supposedly carved by a 92-year-old grandpa nobody appreciates, content farms running cheap image generators to chase engagement[^slop], and the people reliably engaging with it skew much older. The TikTok-side version of the same dynamic is "Italian brainrot", absurd AI-generated creatures with names like Tralalero Tralala and Bombardiro Crocodilo, captioned with nonsense-Italian audio dubs, pulling hundreds of millions of views from a much younger audience.

Facebook's own VP described the dynamic in plain terms to Futurism earlier this year: "if you, as a user, are interested in a piece of content which happens to be AI-generated, the recommendations algorithm will determine that, over time, you are interested in this topic." None of this uses particularly sophisticated tech, and it's already running at scale.

This loop doesn't get out of the way like search did. It takes friction out of producing whatever the optimizer rewards. Right now that's engagement, so the system gets better at engagement. Nothing malicious has to happen for that to land badly; it's doing exactly what it was asked.

The objective is a choice

I'm not fully pessimistic about this, though.

The objective is a choice. Engagement isn't a law of physics. Somebody picked clicks or watch time because it was easy to measure and correlated with revenue. People also reach for banning AI-generated content here. That isn't it either: "the machine wrote it" isn't a stable category once the machines are this good. The thing to push on is the loss function itself (what the system is told to optimize for), and the loss function is written by people.

The original loss function.

The irony's not lost on me that if you're reading this, it probably reached you through one of these feeds. As engineers we
like to act like the loss function is handed down on stone tablets.

It isn't. Somebody wrote it, and on the products I work on that somebody is me.

There is research on what "different" could look like: ranking for informational diversity, or ranking on whether users still endorse a piece of content a week later instead of whether they reacted in the first three seconds. None of it is mature, none of it has a business model behind it the way engagement does, and that's the real obstacle, not the technical side. The systems are perfectly capable of optimizing for something else. The question is whether anyone with the keys wants to. I'd rather sort it out before the next, much more capable generator gets wired into the
same loop.

No zebras were harmed in the making of this post.

KEncode: Packing Data for Strict Limits

Rasmus Ros — Thu, 30 Apr 2026 07:21:53 +0000

Over the past few years, I found myself occasionally writing the same boilerplate: manually packing bits of application state into tight, heavily character-limited strings. It ended up with me creating a library for it called kencode. But first it's story time... and then a little explanation of the underlying tech of why kotlinx.serialization is so cool and THEN I'll go over kencode.

It all started with URL callback links on an integrated Search Engine Results Page (SERP). In a previous project at Theca, we had built a search engine embedded directly into a client's website. When users clicked a search result, the link first redirected to our servers so we could register telemetry for the click before finally sending them to the actual target page.

This is standard tracking infrastructure stuff. But if enough state can be encoded directly into the URL, the tracking server can bypass an expensive database lookup entirely. In this particular case, we needed to pass the query ID, the user ID, the document ID, and the exact position in the SERP (the redirection target itself is appended as well, but does not benefit from compression). One database call is not much, but latency does matter for initial impressions.

Having a short URL here is nice, they look more professional, and there is a limit to how long URLs can be (browser specific). We also want there to be no special characters in the encoded result. That includes hyphens and underscore, since that would otherwise break the word selecting logic. Try to select the entire path by double-clicking in this URL and you'll see: https://example.com/hyphen-path. But here it works just fine to select dQw...: https://www.youtube.com/watch?v=dQw4w9WgXcQ since it's a single word.

Anyway...

Then the same encoding problem happened again with Kubernetes pod names. I was dynamically spinning up short-lived jobs and wanted to embed trace IDs somehow. Naturally, this metadata should also be stored in Kubernetes labels so it remains queryable with kubectl. But since you need a unique name for a pod regardless you might as well use something more informative than the default random suffix, so I put it in the name.

Besides, relying on labels to pass execution state creates tons of error-prone boilerplate. To read that state back, you typically have to fetch the labels by name and manually parse strings, something like:

val clientId = pod.labels["clientId"]?.toIntOrNull()
    ?: throw Exception("Missing clientId")
val batchId = pod.labels["batchId"]?.toIntOrNull()
    ?: throw Exception("Missing batchId")
val retryCount = pod.labels["retryCount"]?.toIntOrNull() ?: 0
val isPriority = pod.labels["isPriority"]?.toBooleanStrictOrNull() ?: false

Kubernetes also imposes a strict 63-character limit on names and only allows alphanumeric characters and hyphens. Encoding efficiency becomes a limiting factor here.

Later, I ran into this encoding problem a third time while implementing stateless pagination links for that SERP. We had built a complex hybrid search system merging traditional keyword matching with semantic vector search. Paginating correctly through these blended results meant we had to carry internal ranking state from page to page. This state lived entirely inside a ?next=xxx query parameter, meaning the payload had to be compact, URL-safe, and opaque to the user.

And now, I find myself needing it a fourth time for my current project Eignex. It's an optimization engine for doing structured optimization in production to automatically tune things like model parameters or ranking weights. Think of it like an advanced multi-variate A/B test. It requires tracking chosen values for the optimization problems until we have a result, at which point we update the optimization algorithm. By potentially passing that state in a token to the front-end and back we can avoid storing it in a massive dict of user ID to settings on the back-end.

I realize this is not an everyday problem, but I have now encountered it four separate times. I think the ability to pack complex state into a tiny string is a useful architectural trick. Doing it manually each time is error-prone.

This is where kencode shines. You define a data class and get strong typing directly from the decoded payload:

@Serializable
data class JobState(
    val clientId: Int,
    val batchId: Int,
    val retryCount: Int?,
    val isPriority: Boolean
)

val state = JobState(119, 210, null, true)

val encodedState = EncodedFormat.encodeToString(state)
// This encodes the object into the string:
// 03W8mJ

val decodedState = EncodedFormat.decodeFromString<JobState>(encodedState)

For comparison, the same object in other encodings:

Encoding	Length	Output
JSON	66 chars	`{"clientId":119,"batchId":210,"retryCount":null,"isPriority":true}`
Protobuf + Base64	10 chars	`CHcQ0gEgAQ`
kencode (Base62)	6 chars	`03W8mJ`

kencode is implemented as a custom format on top of the kotlinx.serialization library, which has quite a different approach to serialization compared to other JVM libraries. Why that is the case requires some context.

Why kotlinx.serialization?

Before libraries like modern Jackson became the standard, serializing Java objects usually involved writing manual boilerplate. If you need to support multiple formats like Protobuf in addition to JSON you will suffer. Manually crafting custom serializers for every single combination of data type and output format (the classic NxM problem) is simply not the way.

To reduce this boilerplate, runtime reflection libraries like Gson and Jackson became popular. Under the hood, when an object is serialized, these libraries inspect the class at runtime to find its fields, their types, and their values. They map these fields to sequential tokens on the fly. This makes standard JSON-focused libraries easy to use, but not necessarily easy to extend.

The sequential model of serializing makes it difficult to create formats that perform aggregate operations on the entire class. kencode relies on exactly this kind of optimization to compact the payload, like grouping all boolean fields and nullability flags into a single bitmask header.

There is also a hard performance ceiling on the reflection, and here is some sage advice: never ignore the cost of serialization. Reflection libraries do usually cache the reflection steps, but the issue is not the reflection itself. It's that interpreting these cached steps at runtime is inherently slower than executing statically compiled code. When a reflection library loops over the fields of your class, it essentially calls a method like serializer.write(fieldValue) over and over. Since your fields are all different types, that is a megamorphic call site which the compiler can't inline or optimize well.

This is why kotlinx.serialization takes another approach completely. Instead of relying on reflection at runtime, it generates static serializers at compile time. The approach is similar to Rust's serde framework, allowing for highly optimized serialization without resorting to manual boilerplate.

"This all sounds good but where is the evidence?" It's probably what I would think at this point. Well, there is actually a recent study comparing kotlinx.serialization to Gson and Jackson (full disclosure: the journal it's published in is a bit dubious, but the actual benchmark methodology looks good). They found that the static compiled approach outperforms Gson and Jackson in most cases in both CPU and memory. kotlinx.serialization was especially good with small payloads with many repetitions. For very large payloads, Jackson was slightly faster. These results are also backed up by this benchmark for CPU only.

In kotlinx.serialization, when a Kotlin data class is annotated with @Serializable, a compiler plugin hooks directly into the build process. It inspects the exact "shape" of the data class and synthetically generates a custom KSerializer implementation for it. Because this happens at compile time, there are no expensive runtime reflection loops or type-guessing. The generated code is strictly typed. This makes JIT happy, which is why kotlinx.serialization is good in high-repetition benchmarks.

The plugin handles what you'd expect from a serialization library:

Primitives: Mapped directly to basic, unboxed encoder instructions.
Generics: The generated serializers simply accept child serializers as constructor arguments, so something like a Response<T> knows exactly how to serialize its generic payload.
Polymorphism: annotating a sealed class automatically generates a serializer that injects a class discriminator (like a "@type": "MyClass" string) so the decoder knows which specific subclass to instantiate later.

The generated serializer for JobState (from above) will look like this:

// Generated automatically by the @Serializable compiler plugin
object JobStateSerializer : KSerializer<JobState> {

    override val descriptor: SerialDescriptor =
        buildClassSerialDescriptor("JobState") {
            element<Int>("clientId")
            element<Int>("batchId")
            element<Int?>("retryCount")
            element<Boolean>("isPriority")
        }

    override fun serialize(encoder: Encoder, value: JobState) {
        val composite = encoder.beginStructure(descriptor)
        composite.encodeIntElement(descriptor, 0, value.clientId)
        composite.encodeIntElement(descriptor, 1, value.batchId)
        composite.encodeNullableSerializableElement(
            descriptor, 2, Int.serializer(), value.retryCount
        )
        composite.encodeBooleanElement(descriptor, 3, value.isPriority)
        composite.endStructure(descriptor)
    }

    override fun deserialize(decoder: Decoder): JobState {
        // This method is analogous to serialize and a bit longer, due to formats with arbitrary ordering like JSON.
    }
}

The benefit here is that there are no generic loops and the call sites are strictly typed (monomorphic), which is a massive speed advantage!

If you're more curious about the details of how the code generation works I really recommend this post. For example, what about which constructor to call (and how) in deserialize?

Notice how serialize just calls methods on an Encoder. The KSerializer provides the data shape while the Encoder writes it. This separation is why it's so convenient to do custom formats in kotlinx.serialization.

So to wrap up so far, kotlinx.serialization has three layers:

Format (StringFormat or BinaryFormat): The entrypoint of the library, like Json.encodeToString() or ProtoBuf.encodeToByteArray(). This is also where you configure and create the underlying encoder/decoders.
Encoder and Decoder: The actual format implementation. They map the shape from the serializer into the logical structure of the output format.
Serializer: Generated at compile time for classes annotated with @Serializable or manually constructed.

How It Works

Let's dive into kencode.

I ended up splitting it into three separate pieces: a compact binary format, a general byte-to-text encoder, and a small composition layer that turns the whole thing into a normal string format. The binary format and text encoders can be used separately.

1. PackedFormat

PackedFormat is the biggest part of the library. It contains the logic to serialize Kotlin objects into small byte arrays.

The format assumes both sides already agree on the schema. This is quite a strong assumption and definitely not what you want for persistence or cross-language communication. But when the assumption holds, we can save a lot of space not encoding structural information that both sides already know.

Its other core optimizations are:

Bitmask headers: boolean fields and nullability markers are packed into a compact bitset header, costing 1 bit per field instead of the usual 1 byte.
Merged nested headers: bitmask bits from nested class fields are collected into a single root-level header, eliminating the per-class byte-alignment padding that would otherwise be wasted at each nesting boundary.
Variable-length integers: Standard integer fields waste space because they always consume 4 or 8 bytes, even for small numbers. We shrink them using varint (LEB128) and ZigZag encodings.
- Varint works by using the most significant bit (MSB) of each byte as a "continuation flag." If the bit is 1, more bytes follow; if 0, it's the final byte. This allows small positive numbers to squeeze into a single byte.
- ZigZag maps small negative numbers to small positive numbers (0 → 0, -1 → 1, 1 → 2, -2 → 3, etc.), keeping the encoded size small.
Collection bitmaps: boolean lists and nullable element lists pack their flags into a leading bitmap rather than storing one byte per element.

Together these optimizations explain how the JobState example was compacted.

The header for a flat class is straightforward: one bit per boolean field, one bit per nullable field (0 = null, 1 = present), packed into a bitset with the smallest number of bytes. For JobState, that is two bits total, which is just a single byte. The field data follows immediately after.

Nesting complicates this. If JobState had a nested class, the naïve approach would write a separate header for each class in the tree. But class boundaries force byte alignment, wasting space. Instead, all bits are merged into a single shared header at the root.

Collections work differently due to their dynamic size. The element count comes first as a varint and then each value is packed after.

PackedFormat is the layer that actually reduces the payload. Everything after this is about transport.

2. The Text Layer: ASCII-Safe Codecs

Transporting byte data as text is a common operation and usually handled by Base64 encoding it. In kencode, we support multiple encodings like Base62, Base64, and Base85.

Base62 is the default because it stays alphanumeric while still being dense.

The encoder uses chunking to avoid O(n^2) BigInteger costs, keeping it effectively O(n).

Codec	chars / byte	Alphabet
Base36	1.55	`0-9 a-z`
Base62	1.34	`0-9 a-z A-Z`
Base64	1.33	`0-9 a-z A-Z` + 2 symbols
Base85	1.25	85 printable ASCII

3. EncodedFormat

Finally there is EncodedFormat, which combines everything into a StringFormat.

val format = EncodedFormat {
    binaryFormat = PackedFormat { defaultEncoding = IntPacking.SIGNED }
    transform = encryptingTransform
    codec = Base62
}

val token = format.encodeToString(payload)

This allows layering encryption, checksums, or compression.

Anyway, that's kencode. Source is at https://github.com/Eignex/kencode.

Building Eignex in the Open

Rasmus Ros — Mon, 27 Apr 2026 11:21:57 +0000

I've always been fascinated by applying optimization to solve real-world problems.

It is often an inherently multidisciplinary activity, and there is something deeply satisfying about taking distinct, often siloed ideas and jamming them together to create something that is fundamentally better than the sum of its parts. In my PhD thesis it was search-based optimization, multi-armed bandit algorithms, combinatorial optimization, probabilistic machine learning, and of course, software engineering.

I wrapped up my PhD thesis back in 2022. I loved the work itself, digging deep into continuous optimization and A/B testing, but I realized pretty quickly that I didn't want to stay in academia.

The environment felt incredibly results-driven, but often in the wrong way. It felt like to be successful you have to play the academic game of marketing your work, rather than the pure engineering challenge of solving a hard problem and making it robust.

I wasn't ready to stop working on optimization just because I left the university, though. I actually find this stuff fun. I wanted to keep building, but I wanted to build tools that actually work in the real world, not just in a paper.

That's basically why I started the Eignex project.

Why Open Source?

To me, open sourcing the work felt like a no-brainer. It wasn't a strategic decision I thought twice over.

First, I enjoy writing high-performance code, and it's simply more fun when other people can use it. But more importantly, there is a trust factor.

If you are building infrastructure that is going to automatically tweak parameters on a live production system, you shouldn't be doing it inside a black box. If a piece of software is going to turn knobs on my server, I want to see the code. I want to know exactly how it makes decisions and how safety constraints are enforced.

That's why all the building blocks of the core engines are public. You can audit the math yourself and contribute if you want.

The End Goal

Let's be real: making money on open source is notoriously difficult. I'm not under any illusions about that, and I'm not trying to build something to make a living out of.

The plan, though, is to eventually build a managed SaaS.

It doesn't exist yet. Right now, I'm just focusing on building the core engine from the bottom-up, one library at a time. But the long-term goal is to build a platform that handles the messy parts of running these optimization loops in production. Things like dashboards, persistent state management, and k8s setup.

If I can eventually get that managed service to a point where it covers the server bills, I'll call that a win.

For now, I'm just building.