Isn't the whole point of <abstraction> that we don't need to worry about the inner details?

A friend currently has an AI workflow that pits two AIs against each other. They start with an issues database. AI 1 pulls issues, and fixes them, and commits them. AI 2 reviews the work and makes new issues. And the cycle repeats.

After a bunch of work is complete and issues are flagged as done, the tests run green, he grabs all of the commits, walks through them, cleans them up if necessary, and crunches them into one big commit to the main branch.

He loves waking up in the morning to a screen filled with completed things.

He has, essentially, self-promoted to management over some potentially untrustworthy junior developers with occasional flashes of brilliance.

And I was pondering that, and it just reminded me of something I've been feeling for sometime.

A lot of modern development is wiring together large, specialized libraries. Our job is to take these things (along with their cascade of dependencies) and put our own little bits of glue and logic around them.

And, heck, if I wanted to glue badly documented black boxes together, I would have gone into Electrical Engineering.

But here's the thing.

While the layers are getting thicker, the abstractions more opaque, in the end, much like a CEO is responsible for that ONE PERSON down in the factory behaving badly, we, as users of this stuff, are responsible for ALL OF IT. Down to bugs in the microprocessor.

When push comes to shove, it's all on us.

We can whine and complain and delegate. "I didn't write the compiler, not my fault." "Not my library..." "The Manager assured the VP who assured me that..."

But doesn't really matter when you have a smoking crater of a system, does it?

Because we're the ones delivering services and such, putting our names on it.

So, yea, no, you don't have to be "as skilled", perhaps, when using something.

But you're still responsible for it.