[ulber]

Driving is qualitatively different from coding: an AI that's pretty good but messes up sometimes is vastly more useful for coding than for driving. In neither case can you let the AI "drive", but that's ok in coding as software engineering is already set up for that. Testing, pair programming and code reviews are popular ways to productively collaborate with junior developers.

You're not replacing the engineer, but you're giving every engineer a tireless companion typing suggestions faster than you ever could, to be filled in when you feel it's going to add value. My experience with the alpha was eye opening: this was the first time I've interacted with an AI and felt like its not just a toy, but actually contributing.

[qqqwerty]

Writing code is by far the easiest part of my job. I certainly welcome any tools that will increase my productivity in that domain, but until an AI can figure out how to fix obscure, intermittent, and/or silent bugs that occur somewhere in a series of daisy-chained pipelines running on a stack of a half-dozen services/applications, I am not going to get too worked up about it.

[worldsayshi]

I agree. It kind of amazes me though there is so much room for obscurity. I would expect standardisation to have dealt with this a long time ago. Why are problems not more isolated and manageable in general?

[jude-]

It's extremely hard to reason about the global emergent behavior of a complex system than the isolated behavior of a small component.

[Jeff_Brown]

I don't think it's a function of complexity per se, but determinism. This is why Haskellers love the IO monad. Used well, it lets you quarantine IO to a thin top-level layer, below which all functions are pure and easy to unit test.

[jude-]

Distributed systems are anything but deterministic.