> The claim you should know everything about everything you work on is an intensely naive one.

I disagree with this take. Personally, I pride myself in learning the code bases I work on in detail, sometimes better than the leads for those code bases. I’m not saying that everyone should do so, but it’s achievable and not naive at all.

Knowing it better than the leads isn’t that hard - they spend most their life in meetings and teaching people how to think. Knowing the code base in detail is important - but I’m certain unless you wrote it all, there are parts you don’t know. I’m sure what you do is build enough scaffold understanding and depth in the core parts you can visit any part and understand it. But I’m also certain there are parts that based on pure recall you care unaware of the details. Someone else wrote it, you haven’t had to read it yet, and thus it’s a black box. Either that or your code base is quite small relative to the team size, or the team is very unproductive. The supposition one person is fully aware of any growing code base built by a team or organization - or a monorepo being built by 10,000 developers over 15 years - is prideful. A lot of it works because it works and you accept that unless you need to inspect a part because it’s not working. Whether a machine wrote it or an intern 10 years ago did, it’s a black box until it has to not be.

The question is one of is it easier to untangle llm code or human?

The answer is similar to: whose code is easier to untangle: human-A or human-B?

"Depends".

Even if you did write it all, unless you are regularly in all of it (which sounds like a horrible job to me), or it is rather small, in my experience you will be at some point trying to git blame some section of code you don’t understand only to find the finger pointed at your ghost.

> why should that prevent them from sponsoring someone to work on nanoelectronics?

Because companies should be held accountable when they make mistakes in hiring. The employees shouldn’t have to bear the burden of their employers mistakes.

If the penalty for hiring too many people for the wrong job role is being barred from hiring people ever again even for a different job role, then companies are just not going to hire people in the first place.

Would you say the vast majority are back seat drivers?

Do you run an optimization pass on the AST between parsing and evaluation?

For an interpreter / AST executor, I think a big win would be efficient parsing in the first place, in particular using a precedence parser for expressions vs recursive descent, which would avoid the need to optimize the AST to remove the 1:1 "unit productions" in the grammar.

I run a “resolve” pass.

That’s where for example getter inference happens.

That’s peaceful. What do you expect, politeness?

Why does a language model have to be monolithic? I think retraining a model is expensive (relatively speaking). Is there some way to bolt on specialization?

That's exactly the issue. Retraining is too expensive & needs too much iteration to work efficiently I think.

> Everything changed in the past 6 months and coding LLMs went from being OK-ish to insanely good. People also got better at using them.

I hear this literally every 6 months :)

It hasn't been true forever, but it has been true over the last 18 months or so.

Can’t you just use Anthropic models through bedrock?