HN user

jmalicki

1,984 karma
Posts0
Comments995
View on HN
No posts found.
OpenAI Presence 6 hours ago

This sounds like it's for when you don't have a defined workflow and it helps you iterate on defining it by being deployed and identifying gaps.

But you now have to trust that each department head is making good decisions.

There is a lot of evidence that corporate mergers destroy value.

What if... they were disintermediated by markets instead of being one company?

There are tons of reasons why companies exist (the whole Theory of the Firm line of research), but the information asymmetry barriers are constantly coming down.

Oh yes, the agent won't have access to the weights via tool calls.

But nothing would inherently stop an RLVR trained model from distilling a version of itself and proving it could regenerate that at runtime, if somehow it got off on an evil tangent and "decided to do so", much like the model hacked to get at the answers here, or the agent can hack out a sandbox to achieve its goals.

It would be extremely impressive for the agent to do so during an RLVR rollout, but they are becoming increasingly longer and longer horizon tasks.

This is science fiction, these models don't have access to their own weights

The weights plus the architecture is the model.

What do you even think "the model" or "the weights" are?

The weights aren't some far off training concept, every time you type something into ChatGPT it's making a forward pass over the weights.

It's as silly as saying "Computer programs don't have access to their binary compiled code at execution time."

You can just tell your main agents "I have these implementation docs in <DIRECTORY>, please spawn parallel subagents to implement all of them" and I generally find that works, and what's great is it's in parallel too so takes less wall clock time (even if there is slight token duplication from having the main agent and the subagent both read the prompt/doc, but overall I think it is less usage of tokens unless you go crazy with /clear).

I like to actually have hierarchical plans.

Start with the big idea. Pin down the product manager-level description, and maybe some details about which features are in or out, how the phased design/roadmap will work, maybe what the basic tech stack will be.

That document gets saved, and has the big picture context.

Next, we go a little deeper, flesh out schemas, APIs, a little more about what the code should look like, the overall testing strategy. This document gets saved, and the AI can reference it for context.

The next level is a very specific implementation plan. Think individual small JIRA tickets in an epic. The AI writes this based on previous context. I make sure each individual step has very explicit instructions about branch names, which branch is branched from where, the testing and documentation that will be done for that step. It should be obvious from the higher level documents, but that helps keep the AI to only worrying about the local document in its context window.

Then have a DAG of stacked pull requests designed for subagents to work through.

All of this keeps the context window down (as well as costs down, and accuracy up) and works super well, and I can get a tremendous amount of code that is easy to review through stacked PRs. Invariably I will want to fix earlier ones then percolate that down the stack, so I have some skills for that.

For those kind of tasks, I do hierarchical planning, and then parts of the plan can focus one agent on keeping a smaller amount of pre-determined context when orchestrating.

Think: A VP of engineering has some super high level goal: "build a new product to beat our competitor in this new market". It then filters down and various levels of reports build more and more detailed yet more narrow pieces of planning/orchestration. They don't make it work by keeping all of the context in their head and micromanaging.

I have actually had a ton of success using Strassen matrix multiplication kernels with extra structure in custom CUDA kernels (e.g. a covariance matrix is symmetric positive definite, or can be represented with Cholesky, and that comes up in a ton of useful computation). It's been a couple of years, but IIRC I would find it would start to win over the standard kernels at ~n>2500 or something (and in addition to Strassen was also exploiting the explicit structural constraints of the matrix, so not a completely fair comparison).

AI has been making a ton for advertisers for decades. Think Facebook ads, Google search ads, etc.

That's a different and older kind of AI than chatbots, but it's not fundamentally different, but AI is the engine that makes their ad targeting so effective, and why they're some of the most profitable large companies on the planet.

I didn't find a direct proof earlier, just assertions - I've only seen it proved in textbooks that aren't linkable.

Theorem 1, section 1.3, page 2 shows that the expected variance of the gradient of the loss function and the expected second derivative of the loss function are equal at the minimum. I hate that the ADAM paper did not talk about this, this is something that is hammered into anyone who has taken a mathematical statistics course. This has been an established fact in statistics for well over 100 years.

https://courses.grainger.illinois.edu/ece563/fa2025/Notes11-...

Away from the minimum they can diverge, but there is a close enough connection to make it an extremely useful approximation.

Some fun stuff about SVDs:

If you want to take a low rank approximation to a matrix D, let's call our approximation D'. The approximation that minimizes mean square error of the reconstructed matrix vs. the original (i.e. ||D - D'||_F, the Frobenius norm of their differences) happens to be the truncated SVD, by the Eckart–Young–Mirsky theorem [0].

I'm not claiming it's a practical way to do so, but this means that if you set up a neural network w/o nonlinearities that goes U -> S -> V^T, where S is a truncated scaling vector, and U and V^T are trained weights, make your loss function the MSE of reconstruction error, and minimize it with gradient descent, you will end up with the same U, S, and V that an SVD gives you.

In fact, this is basically exactly what a Variational Autoencoder [1] is! Way too few people realize this connection, and I wish it was taught in more ML courses. VAEs just add nonlinearities between U -> nonlinearity -> S -> nonlinearity -> V^T, and a KL-divergence regularization term. (Well VAEs are trained as operators to reconstruct vectors, and the S is an embedding not a trained weight, so I'm being a little sloppy, but still the connection is strong).

Once you realize this, you can have a lot of fun... anywhere you see an SVD being useful, you can construct arbitrary neural networks to replace them, and any time an SVD doesn't quite fit, e.g. you have binary data, realize that VAEs are just the same thing you can make all kinds of bespoke changes to... don't want MSE as your reconstruction error? Fine, use something else, but it's basically just an SVD!

[0] https://en.wikipedia.org/wiki/Low-rank_approximation#Basic_l... [1] https://en.wikipedia.org/wiki/Variational_autoencoder

ADAM is related if your second derivative matrix happens to be diagonal.

Of course, it takes about 5 minutes to show that any DNN is going to have very very high magnitude off-diagonal terms by the way it's constructed, so pretending that a diagonal approximation is close enough is crazy.

Tylenol is one of the things on the shelf most likely to kill you from liver failure. It is way more dangerous than many prescription drugs.