andrewshawcare

The Klarna guy:

>The misconceptions about Klarna and AI adoption baffle me sometimes.

>Yes, we removed close to 1,500 micro SaaS services and some large. Not to save on licenses, but to give AI the cleanest possible context.

If you remove all your services...

That sounds like a horrible way to flirt.

> The game has changed. The system is cracking.

Just say what your thing does. Or, better yet, show it to me in under 60 seconds.

Web sites are the new banner ads and headings like that are the new `<blink>`.

It used the best tests it could find for existing compilers. This is effectively steering Claude to a well-defined solution.

Hard to find fully specified problems like this in the wild.

I think this is more a testament to small, well-written tests than it is agent teams. I imagine you could do the same thing with any frontier model and a single agent in a linear flow.

I don’t know why people use parallel agents and increase accidental complexity. Isn’t one agent fast enough? Why lose accuracy over +- one week to write a compiler?

> Write extremely high-quality tests

> Claude will work autonomously to solve whatever problem I give it. So it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem. Improving the testing harness required finding high-quality compiler test suites, writing verifiers and build scripts for open-source software packages, and watching for mistakes Claude was making, then designing new tests as I identified those failure modes.

> For example, near the end of the project, Claude started to frequently break existing functionality each time it implemented a new feature. To address this, I built a continuous integration pipeline and implemented stricter enforcement that allowed Claude to better test its work so that new commits can’t break existing code.

How is using a function not sweeping domain complexity under a rug?

A complaint was that the data-driven development approach created a _poor_ DSL and then a non-DDD solution didn’t use a DSL at all…

What would a solution using a good DSL look like, and how would it differ from the DDD-based approach?

Impossible. Schrodinger’s envelope, then. You can’t reflect the probability to be 2A AND 1/2A if A represents the value of an envelope.

The value of the other envelope must include the probability that it is the original A (not some sleight of hand new A’ that, itself, is based on an expected value).

Once you pick an envelope, you no longer stand to only gain money.

You can lose money and that has to be reflected in the potential value of each envelope.

After the first selection, you must express the envelope value as the potential of what each envelope holds (the probabilities from the initial selection) which makes selecting again a wash.

Let A = 50 Envelope 1 is 100 Envelope 2 is 25

First selection 1/2(100) + 1/2(25) = 62.5

Great! Do it! 62.5 is bigger than 0, which is the expected value of not playing at all.

After that, it makes no difference to switch (the envelope value is recursive):

1/2(62.5) + 1/2(62.5) = 62.5

or

1/2(1/2(2A) + 1/2(A/2)) + 1/2(1/2(2A) + 1/2(A/2)) = 1/2(2A) + 1/2(A/2) = 5/4A

and the trick is that’s now the potential expected value you have (you now have 5/4A in your envelope), so switching is a wash. You never really “had” A as a value to compare against (by evaluating that 5/4A is bigger than A), we just get tripped up with the doubling and halving at the outset.

Said another way, the fact that 5/4A is bigger than A is irrelevant, no envelope contains A, they both contain the expected value of 5/4A.