menaerus

Yes, I can reckon. Have a good one my sad internet friend.

I liked the commentary and the metaphor with the Nyquist theorem. Mathematically speaking it's invalid but the problem being discussed is real - when the velocity of code generation (accelerated by LLMs) outpaces human cognitive capacity to review, test, and mentally model the system, structural coherence collapses.

And we're already there, it's beyond our cognitive capacity to fully understand the (AI) produced volume of work for given unit of time.

In order to really mitigate the human bottleneck, we will either have to reach the AGI, which might not come in the next 10 years or so, or change the form of how we're doing work, review included.

I wonder how is it to live with that amount of toxicity and frustration? Keep it loose man, you're gonna get yourself a cancer.

Keep coping. And next time find some decency in your replies.

I thought so too. I understand the TLA+ part but Lean not as much.

Bad news for you is then, no, it does not and I have a case in point at hand. Complex many-fold cascading incident(s) investigation that spans multiple data centers. I am not making these things up. As much as AI has been shown to be very good in complementing the SWEs work, the same goes for SREs and other similar roles in the field.

Yes, my point was that one does not need "all kinds of information".

Yes, "entire" company codebase is a stretch as is design docs, status pages etc Helpful yes but not a hard requirement per se. In many places you won't find such level of details available and yet the incidents are still being solved

Yes but IME it is never possible to collect everything. It's part of the job to deduce the missing parts from what we have available.

Not sure how that relates to incident debugging?

What contexts would the AI model need for analyzing, let's say, cluster-wide incident other than the observability data that such systems anyway collect already?

> AlphaFold didn't solve a decades old protein folding problem. They substantially improved protein structure prediction but with important limits.

That is a bit of a semantic stretch and calling it substantial improvement for a 50-year (?) old computational bottleneck in structural biology is a bit of an understatement too. It has been a true breakthrough solving a problem humanity as of then thought it was impossible to tackle.

I personally find it much better than Claude in day to day tasks. Easier to understand and to the point without getting overly verbose like Claude always does. I solved some pretty difficult engineering problems with it, and most of the time I run Claude in parallel, and more often than not I found Claude to be less precise actually.

Well, we have seen AlphaFold solving a decades old protein folding problem. There's no reason for me to believe, with all the AI advancements I've seen in the meanwhile, that we will not solve other problems in this field too.

I appreciate the details, very interesting. So from a quick glance my understanding is that exacycle is a task partitioning and dispatching system built on top of existing google infra runtime (borg). Tasks are units that are massively parallel and distributed across the compute, and have no or almost no shared data. Problem space seems to be built around self contained tasks which have well defined input and output, and main engineering challenge in the exacycle itself would be the optimizing the system for maximum resource utilization? It's complex but not as complex as open problem space engineering problems dealing with highly concurrent and distributed workloads with shared state and that are unknown at the time you're designing the algorithm.

Anyway, my point was not in that I would equate software complexity with the complexity found in biology but that I see the same trend and similar type of challenges that can be found in both fields and therefore I see both fields amenable to the AI advancements whereas many people from the thread do not, and I disagree with that.

I'm not sure what you mean by "running a job that ran a worker". Running the system is vastly different than building and maintaining one. I work on highly available and distributed systems spanning multiple data centers, and single node scalability of database kernels, so I guess I could also say that I've done and still doing work at the highest level but in my case it is the core development. Which one is yours?

I made a parallel with similar complexity and ambiguity that can be found in SWE discipline too. I tried not to make any hard claims but I did present my opinion on the topic - I don't see a reason why drug discovery field wouldn't benefit from the AI when there're proportionally difficult fields (math, comp.sci, mechanics, medicine) where AI is already making a significant difference. Maybe you think comp biology is of a very different kind in which case you would turn out as ignorant here. lastly, my comment is there to spark the discussion and have some food for thought because not so long ago this type of reaction has been seen in comp.sci circles and math just few days ago.

Did I say anything wrong?

I'd take your overly dismissive words as credible (but still wrong) only if you did the career in both disciplines which I assume you didn't. You're wrong, and your view of SWE discipline is a great example of DK effect. Not something one would expect from a PhD in computational biology, yes?

You largely explained a day in life of a SWE working in a complex codebase spanning (tens of) millions lines of code. In complex products we always deal with a great degree of uncertainty and due to the ambiguity and high complexity we usually have no simple way of proving that the thing (TM) we designed is going to be working as advertised in all cases. Because the problem space is in-exhaustive, and to increase the likeliness of the solution we designed, we run the experiments, and not on a sole machine but clusters at data-center scale. Even then you get "bug reports" and that's not because engineers were lazy but because the domain is genuinely complicated, and ever changing.

So, I'd say it's a pretty similar process, and yet we have the AI models now almost completely integrated into the SWE domain remediating significant parts of its complexity.

Few years back many SWE people would say, including me, that the bottleneck is not in coding. We were all very wrong.

Yes, I do. My comment was a general sentiment saying that sole inexistence of something is not a proof that that something has to be very complex. Pharma is no different when it comes to people relationships and/or fear of somebody else stealing your chunk of expertise and/or fear of some other company taking a significant part of your revenue. Gatekeeping is one form of "preventing" or slowing down the process, and we see it in various domains regardless of their complexity.

We see it happening in SWE as we speak - people from and outside the tech who had no or very little experience with programming are now starting to deliver their ideas into products without devs or very few of them. We also see this within the SWE where strong domain experts are now able to deliver ideas into code easier than ever, and by themselves, and for which they would previously need a handful of programming experts. We also see it in other way too, strong programming experts are now able to pick up other domain easier than ever.

This process is something that I believe it will (and hope so) inevitably be picked up by the pharma too so the myth about the complexity will become broken.

> And if it was simple, it would already exist.

Not necessarily. Many things are simply gatekept behind the door.

Where all of this people have come from? Fresh from University? Other jobs? Out of nowhere?

> and avoid even the appearance of the idea that Claude came up with it de novo.

If we s/Claude/Few Meta engineers/, would de novo still hold?

> it neatly compiles into a single portable executable.

Not quite the advantage in the AI era. Quite the contrary. Dynamic linking is something Rust will have to solve.

Dropping human-in-the-loop reviews is inevitable - it's just a matter of time. You cannot design a Ferrari and then let the driver crawl its speed by manually pushing it down the road. And all the "real" companies I have worked with are not 100% but 1000% into the AI - the incentive is huge.

That is not the quote parent comment was about wasn't it or am I missing something?

In case of your comment, I could have agreed to some degree but what you say is also not necessarily true since we don't actually know if the new source control is the result of human creative input or if it was also suggested by the model. Having worked with these models extensively I am inclined to believe that both can be true.

Well, Anthropic used model A to output the version 1, and then used model B to rewrite the version 1 into version 2, so the handoff was machine to machine and not human to machine. I read that part of an article as if it was their internal assessment test of their new model B (Fable) capabilities so that they can see if the new model can find interesting things but by intentionally being vague and without implementing the bias into your prompt. I use this technique very often as well for two major reasons: (1) I don't know what I might be missing so I let the model do the unbiased exploration of problem space, (2) I am curious how far the given model has come with its capabilities. What Antrophic did in this case is an example of (1) and I wouldn't really call it creative since anyone could prompt the model with "rewrite this code".

While companies are heavily incentivized to speeding up, cutting costs, etc. I expect that friction imposed by the humans is not going to go away that quickly.