cweld510

I think the assumption is that there are clearly problems to solve and useful work to do, but that useful work is not always well-defined enough to be ticketed and represented in the backlog as individual parallelizable work items.

Code and architecture (at least the architecture that AI can do) only need to be “good enough” to fulfill the requirements. Today I can write more tasteful and elegant code than AI, but that doesn’t matter very much. But the marginal value of taste in product decisions is much higher comparatively. A product is never good enough, it can always be better.

It's an abstraction layer w.r.t. how you write code, not an abstraction layer in the live system. An IDE is a higher abstraction than e.g. vi but it doesn't mean you don't have to go low-level sometimes.

That’s not a bad thing though — what that means is that the original dev believed this could never happen and probably therefore could not decide exactly what the right way to handle the error is.

Writing is already amenable to many different levels of abstraction, though. If an LLM can expand your outline into writing, then you aren’t writing at the correct level of abstraction in my opinion; you should instead be explaining how you arrived at your chosen outline. You don’t need to explain the details because any party can generate those with an LLM; same as how many PRs today can be auto-generated and no one needs to read implementations; that is no longer the correct level abstraction to work at. This should actually free us to do work at a higher level of abstraction —- more consideration of strategy, objectives, etc and less worry about implementation details.

Obviously yes, how can you design good systems without studying the systems created by others?

Math is based on axioms because you need some a priori axioms to do logical deduction, but the axiom selection is also historically fluid. Mathematicians suggest new axioms or move away from old axioms based on their understanding of which results are intuitive or not, and also which are most useful, and most mathematicians that work close to the axioms have some view on how “correct” or not various axioms are. As evidence of this, I’d point to how many mathematicians find the axiom of choice problematic due to results that seem clearly “wrong”, but nevertheless accept it because they need it to prove other things that seem obviously “right”. So the axioms are not the base truth, there is some platonic ideal of mathematics beneath that.

We try to spread out sandboxes evenly across the cluster (at least, across the workers which are available to take new sandboxes) to minimize conflict. But in general we don't get close to saturation thresholds so high that conflict becomes a problem, except during massive load tests. I suspect we'd see issues around 90% effective utilization.

We make a probabilistic routing decision based on worker load and attributes of the sandbox request. I compare to a load balancer because it's essentially just forwarding an HTTP request.

I'm a huge scheduling nerd, and the container scheduling system in this post is probably the most impactful system I've worked on. It's quite different than existing solutions, and I personally feel it's at an interesting point in the design space -- very distributed, no strong consistency anywhere, and oriented towards massive scales. Would love to hear feedback and thoughts!

The PM’s job in this situation is to articulate some sort of high level strategy generalizable across customers, based on information gathered from customers, which includes feature requests but is more than just that.

The skillset is different. SAs everywhere I’ve worked are solidly salespeople. They can do AE work in a pinch, they use Salesforce, they know how to understand the state of an account, etc. They tend to be more limited technically and as such are generally deployed for the sale of a product which is “finished”, and as such spend most of their time mapping customers onto existing patterns that are already known to work, and identifying those patterns.

FDEs are different in that they’re deployed to sell and integrate products which are unfinished in some way. For example Palantir sold a fairly low-level generalized product which required bespoke technical work to integrate with a customer. This integration work is more like normal engineering work in that lots of code may have to be written and there’s technical creativity required. The reason why FDE is increasingly in vogue now is because AI companies haven’t yet found a high-level product shape which is generalizable across many customers, because the market is immature and customers probably don’t know what they want. So there’s lots of engineering work required to take a lower-level offering (e.g some sort of agent) and figure out how to use it to generate value for one particular customer.

Is the point of math really to prove the statement? Arguably interesting, unproven statements are interesting often specifically because they are hard to prove with existing techniques.

It definitely is at the youth level. I don’t think any football or basketball pros could be soccer stars, but absolutely there are kids who are star point guards on their youth basketball team but top out at 5’8”, or football players who never make it past high school but could have been great at soccer.

Sure, but then the interesting question becomes how people decide whether or not an action is in their self-interest.