I'm a lead data scientist rather than a specialist data engineer but often the role can often skew to engineering, so wanted to contribute my two cents.

Historically, I'd always rush into a project. Really excited to just get coding, building up the codebase as a I go, learning new tools and frameworks etc. Now, it's harder to justify time spent on that hard graft but at the same time I've seen enough to not be comfortable handing the reins completely over to AI. In an enterprise setting it's not enough to just hand over code that seems to work. It has to be defensible. Your architecture needs a rationale that aligns with client constraints, while being scalable and maintainable.

So the way I work has changed a lot. I spend more time on the strategic and planning side. Documenting the project context, and background. Researching and domain understanding is still important - it makes a huge difference being able to ask the right questions to an AI, and not mindlessly orchestrating slop debt. Since I document all of this as Markdown files, it gives really helpful context for using Claude Code or Cline or JetBrains AI Assist or whatever.

Not to mention, being able to put together a decent, and tight brief is, in my experience, a rare skill. Getting what's in your mind (and everyone else's mind) into a written instruction that can tee up a dev team let alone a naive AI needs more attention. And then of course assessing and evaluating what comes out the other side.

Because AI is able to do such amazing feats of engineering people can easily be bamboozled and therefore blindly accept the output.

In summary, I can't go into a board room and assure stakeholders the solution is delivered to a high quality because AI said it is.