Hey there,

In this part of the series, I will discuss the challenges an AI engineer faces in the current “AI era” with company leadership. Of course, as always, this mainly applies to mid- to large-size companies.

Leadership and AI: fear and obsession

The day after November 30, 2022

It’s the 30th of November 2022, and most companies are already in end-of-year pre-holiday mode. This is when ChatGPT was released and took the world by storm.

By the time the year ended, the company’s C-suite executives and directors had already seen enough demos and heard enough interviews and podcasts to know that 2023 should be the year of AI at their company; The year they transition their companies to “AI native”; It’s the year they needed to start answering the following questions:

• How can we benefit from this technology to improve our products?
• What does this mean to the continuity of our business?
• How can we be ahead of the curve?
• How can our employees make the most of this technology?

And this is when most companies’ leadership relationships with AI started in what follows I will cover real life scenarios I faced in the past three years dealing with leadership and AI.

”We saw from your Windsurf usage that you didn’t use AI in coding in the past month, why?”

No one can deny that AI is helping us do a lot of tasks faster and easier now, be it writing code, debugging, researching, writing an email, and even brainstorming ideas. The problem here is the obsession of leadership with AI and how much it is being used by the employees to later report it to the board with some metric that required procurement of a special software to report. It says a lot that in my case there was apparently an issue in the report that included my name as someone not using AI in the company where it was completely ignoring developers using Windsurf from inside IntelliJ like me…

Leadership should instead be more focused on enabling us with the tools we need to do our job better, not micromanaging us with metrics and reports and mandatory surveys about how many times do we use ChatGPT a day.

”Evals can wait, MCP support when?”

In addition to the panic of trying to be ahead of the curve and rushing any type of AI integration (be it useful or not, secure and private or not, profitable or not) into production is the sudden focus on trendy technical protocols that shouldn’t be YOLO-tested in a company with hundreds of microservices and thousands of B2B customers. Suddenly the top leadership is very keen on adding MCP support for all the company products with initiatives involving multiple teams and months of work.

But why? Why should we jump into adding a protocol that still has not been battle tested in a company at this scale and doesn’t support auth natively? And more importantly, why should leadership be this involved in a very technical conversation?

Countless times, I have been in demo meetings or conversations with stakeholders (none of whom have written a line of code in years, and whose knowledge is based on podcasts they listen to) where they are willing to discuss MCP or computer-use for hours, but the moment you mention the need for evaluation or anonymization of the data, they get bored and want to move on to the next topic. If leadership is now willing to be that involved in engineering decisions and priorities, they should also be willing to cover the “boring” parts of evaluation and anonymization and looking at the data.

”We have a bolt example, just integrate it and use AI for that”

AI has reduced the time to prototype to a minimum. Tools like Bolt, Lovable, and Replit made it so easy to go from idea to prototype in minutes. However, productionizing these prototypes is another story. The engineer has to worry about edge-case scenarios, add tests, follow the design system, add observability, review, and deploy the changes.

Unfortunately, leadership is not very keen on this and expects it to be just small polishing accelerated by “AI.” Writing code was never the bottleneck, reviewing the code and handling the other productionizing duties are. And unless we are willing to start merging PRs without reviewing them (horrible idea today), the impact of AI on the velocity of shipping production code will never match its impact on prototyping.

In summary, the past three years witnessed a lot of change in leaderships’ approaches and engagement with AI and engineering teams. Hopefully, this over-engagement will stop so that engineering teams can focus on the real challenges of integrating AI in production!

Stay tuned for the third (and last) part of the series! And as always feel free to reach out and share any frustration of yours!