GenAI Adoption, Challenges & Anti-Patterns

Host Intro (Gene Kim)

So the next speaker, Dr. Tapabrata Pal — I met him in 2014, and holy cow, did he make an impression on me. He was the first distinguished engineer at Capital One, and many point to him as the person who led the DevOps movement there.

This was shortly after an era where Capital One had outsourced 80% of their software engineers, and this is something that he wanted to change. Rumor had it that he was one of the first enterprise architects with an IDE still installed on his laptop.

He then became VP of architecture at Fidelity Investments, and today he's now SVP and head of developer platforms at M&T Bank. Rumor has it that he might be the first person to have uninstalled his IDE, and he might be on a mission to have IDEs extinguished from his engineering organization. But that came from me, not him. Here's Topo.

Tapabrata "Topo" Pal

You've got to know when to hold them. Know when to fold them. Know when to walk away.

Year 2014 — and Gene just now talked about that. I met Gene. He actually invited me to the first conference, DevOps Enterprise Summit, at a hotel near San Francisco Airport. There were about 300 people there, and I was very scared, because that was the first time I'd be talking about something IT-oriented on a stage in front of people that may think that I'm from a place that is not so cool — Capital One.

Because I had been attending DevOps conferences since 2012 to figure out what's going on and where we should be, and every conference I went to, I came back depressed, thinking that I cannot do this at Capital One, ever. Ten deploys per day? Oh my God. Developers shipping code to production? Oh my God, it's not going to happen.

So in 2014, when I went to the conference, I saw people like me — actual enterprises that have real IT problems — and I was one of them. And I felt safe in talking about the struggles that we do at large enterprises in IT. And I presented, and I felt happy. So I felt that that DevOps Enterprise Summit was a safe place for large enterprises, regulated enterprises, to come and openly talk about the struggles, and some solutions, and some wins and some losses. So I felt that Gene Kim and IT Revolution had created a safe environment for large enterprises to talk about DevOps transformation.

And it actually grew so big that it kind of was talked about as the place to go to, to talk about these problems and meet your peers. And this is for me like déjà vu times 100.

So I want to say thank you to IT Revolution and Gene Kim for creating this safe environment for enterprises to come and openly talk about their struggles, their complexities, their problems, and learn from each other.

So I think I can do better than that. What if, on the count of three, we all say it together? Thank you, IT Revolution. One, two, three. Thank you, IT Revolution. Thank you, IT Revolution.

---

With that — I'm Topo Pal, and before I start my talk, just want to make sure that you all know: the things that I'm going to talk about today may or may not be M&T Bank's view. It could be my view. It may be something that I'm experiencing at M&T. So I just want to make that clear.

M&T Bank is a public bank. I joined two and a half months ago. It's a community bank. It's a nice setup in Buffalo, New York. I really enjoy that place, the surroundings. And the funny thing is that every building is kind of an M&T Bank building. Everywhere you go and you have your badge, they know you. So it's a pure community feeling, and I love that. I enter the office and I feel like everybody's smiling at me, welcoming me — "How are you?" So it's a huge change from me coming from Fidelity Investments, which is more than 10 times larger.

So that's my feeling about M&T Bank — just since I joined recently, that's my initial feeling.

Currently, I'm SVP, head of developer platforms. Under me, I'm accountable for what tools developers can use on their laptop, what things they can install, all the way to the whole CI/CD platform, quality engineering, performance engineering, performance tests, test data management, SRE practices, and also the open source program office. So that's a huge task. For me, it's hectic but very, very satisfying so far.

Before this, I was with Fidelity Investments for five years, and as Gene mentioned, I was at Capital One for 10 years. My background is essentially as a developer — that's why I love my IDE on my laptop. The first thing I do getting a laptop is install the IDEs, all IDEs. Who knows which one I need when? I just wanted to have them there. It felt safe for me.

I'm a DevOps enthusiast, open source contributor. I had my open source project called Hygieia. I don't maintain it anymore — it's archived, it's 10 years old. I can talk about that a little later. Author of the book Investments Unlimited. But essentially I'm from a science background. I have a PhD in semiconductor physics, so everything that I do, I still have that thing in my mind: I need numbers, I need graphs, I need charts to make any conclusion about anything. So I tend to challenge everything that I read, and I can talk about some of that today, too.

---

So there are two things that I'm going to talk about: GenAI adoption at M&T Bank, and some of the challenges and anti-patterns that I see across the industry.

Number one: at M&T Bank — and I think this aligns with everyone in the industry — there is wide adoption of general productivity tools. By that I mean creating decks, creating documents, taking meeting notes, getting summaries, writing emails, asking a question and getting an AI-generated answer. That is fun. However, there's another side to that, which is all the decks look exactly the same, all the summaries look exactly the same, all the documents have the exact same formatting. And the most interesting thing is: AI generates those things, and then when they land in my email or my Teams message, I use AI to summarize them. It's essentially going in as X, coming out as Y, getting transformed back into X. Net work done: zero, in my mind.

So that's one side of this. But on the positive side, there is a lot of productivity gain in terms of getting ideas set up, getting meeting note summaries — nobody manually summarizes meetings anymore. The recording is there, the transcript is there, they're searchable, and you can post it and everybody can see it. So that's one.

The second side is GenAI adoption by technology teams — engineering teams, developers, operations teams. In terms of coding, code analysis, platform engineering, testing, everything: even cloud migration, converting a CI/CD pipeline from one tool to another, or even enhancing them, and in general just modernization. And also vulnerability management.

As I said, there's another side to that. The other side is: all this code — I don't know who's reviewing it. Is it good or bad? I looked at some of it. Pure disclaimer: other than my own code, I hate everybody else's code. So you can imagine, looking at the code, it pains me. But does it matter? It works. Maybe.

And then testing — unit testing. I see this pattern everywhere: "Hey, you have all these code analysis bugs showing up on dashboards. You can point your AI agent to these repositories and it can fix them." And I go: are you letting the AI generate test cases for bad code and making your code look good? I have seen instances where a buggy piece of code has a test case that passes the bug — which means you have now ingrained that buggy code in your software, and nobody notices, because you have 100% test coverage on a beautiful dashboard. That's one side of it.

Similarly, vulnerability management — are you sure? I have seen instances where it actually created more vulnerabilities than it fixed. So those are the two stories, two sides. Yes, huge adoption of GenAI across the board. It doesn't matter whether you're an engineer or a product owner, everybody's using it. So that's the good news.

---

The other thing is a few observations in terms of token usage. I'm seeing that 20% of the high hitters are using 80% of the tokens budgeted for your organization. If I look closely, 5% of the top hitters are using 75% of the tokens for the whole organization.

The other thing is efficiency increase. It's not numbers — it's pure experience from developers — but they are now solving some problems in days, maybe in hours, instead of weeks or months. And I have seen evidence: they have shown me, and it is believable, and it is real.

Innovation. Some of the things I'm seeing across the industry — and of course at M&T Bank — things are happening that would not have happened without AI. Give you an example: enterprise dashboards. There's no dashboard, no visibility, and boom, it shows up tomorrow. Something like that. I actually presented one of these cases one year ago at the Enterprise AI Summit in Las Vegas. And I actually live-coded an SBOM dashboard — a software bill of materials dashboard — with lots of features in five days, nights included. That took five days and then took three weeks to get to production. I have done the same thing last month in one day.

Now, back in those days, one year ago, it was GPT-4 and Sonnet, and we were struggling even to make that work — but it was still better than nothing. The same thing that took five days is now doable in one day. And I have experienced that myself. I cannot lie to myself.

Those kinds of results are happening in every corner of every large enterprise. How do I know? I have seen it, and I know — speaking with you — it's the same feeling.

The other thing that is coming to the forefront is governance risks. How do you know X, Y, Z — whatever it is — is true? How do you know the models are saying the right thing? How do you know who's using the model, and in which way? Is it good practice, bad practice? What are the controls — security controls, cost controls, operational controls? How do you know who is using which harnesses? Unlimited questions that are unanswered at this point. We are figuring things out. As was shown earlier, we don't know. All the questions that we have in our minds — we don't know the answers yet. Isn't it crazy? And it is beautiful. We are here to figure it out.

---

So with that, I'll talk about some of the challenges and anti-patterns. These are purely my observations.

One: we are looking at 100X throughput, but our pipeline — our supply line — is 1X. I do not know if today's SDLC tools that we dearly love — everybody loves their pipelines, have you noticed that? "That's the greatest pipeline ever." — will developers be willing to give those up? I'm seeing pressure on every point in the pipeline. That tells me that maybe five years down the line, we need to have a different kind of SDLC.

Now, I'm not calling that "AI SDLC," because AI SDLC means putting agents doing the same things that the current setup does — and by the way, it doesn't scale. Because whatever source control you are using, do you know if it can handle the volume of code that will go through it five years later? Some of the tools we use for scanning our code charge you line by line. Do you tell the agent to reduce the number of lines of code so that you can maintain your cost for scanning or testing or whatever? How many pipelines can you run in a given time on your current system? Can you extrapolate and prove that if throughput increases 100 times, your system can hold it up?

Maybe there is a new thing. Maybe agents will figure out what's the best way to send it to production. Who knows? Maybe we don't see any pipelines. Maybe there's no SDLC anymore — it's just idea to production, with all the controls managed by an agent. That's not going to be "AI SDLC" either. It will be something else. I don't know.

Enterprise processes are one of the main bottlenecks that DevOps experienced, that Agile experienced — and this is just 100 times more. In DevOps, I could not code up and send something to production without going through all the approvals, all the gates, in a planned manner. I could have 10 sprints in one day or whatever, but that code was not going anywhere until the next release, which was one quarter away. We have seen all these challenges. Those challenges are not going to go away. Will they need to be revamped? Absolutely yes. How? I don't know.

Are customers ready to consume 100 changes? I'll tell you — I have seen iOS releases where the release notes say "five new emojis." Now imagine waking up every day to a new iOS release with one more emoji. How would you feel about that? I'm not installing any of those. In fact, I would hate that. So are customers actually ready to consume 100 changes? I don't know. I'm sure I'm not.

Productivity measurement. Questions are asked in every meeting: we are spending so much on tokens, what are we getting out of it? How do you justify GenAI cost? What can you measure?

And that last one — "what can you measure" — it's nothing new. In DevOps times, when we brought in a new CI tool, $3 million, our CIOs asked: "What is the ROI of this? Going from a manual build process to this $3 million tool that you're going to install — how much are you going to make out of it?" It's the same question in a different way.

Every time I ask somebody, "What is the benefit you are seeing?" — including myself — I see the value, I feel the value, I just don't have a number. And what that number is supposed to be, we don't know. We may have some ideas that we can talk about this afternoon.

Governance. What use cases are approved for GenAI usage? Reuse and duplication are everywhere. Everybody's building the same dashboard five times over. Everybody is doing the same architecture analysis on the same product 10 times over. There are many prompt libraries, skills, harness setups, all of that being rediscovered across the enterprise many times over. What are the controls? What risks are you exposing? Answers to all of that — we don't know. We are figuring things out.

---

This next one is very near and dear to me. For the last six months, I have been benchmarking many harnesses, many ways of doing things, with real open source repositories. What I noticed is that your compiler can tell if the code is good or bad, your test cases can tell which code passes or fails, you may have Javadocs and all that around the code. But one thing that you don't see — but your agents do — is the comments in the code, the other documents in the code. And it can fool itself and it can fool you. You think that code is doing one thing, but the coding agents are reading the comments and concluding something totally different. And I have proof for that. I'll publish it in the next few months.

Conflicting requirements. There's a UI, there's a button — red on day one, purple on day two, yellow on day three. By day five, you ask the same question and the agent will get confused. Now, this is a simplistic, very linear flow. But when you have conflicting requirements that none of your systems can catch other than a human being, you know for sure that the agent is confused too.

From human instruction to system execution — that is what I'm talking about. The comments in the code that the agents write, and you write, or whoever wrote 10 years ago, are now pieces that will be executed in production if you're not careful enough.

Predictability. I have noticed agents behave differently at night versus day. This is a real story. The same problem, the same task from a given open source repository, may take 100,000 tokens in the morning during the daytime and may take 500,000 or more at night. I have seen that kind of variation in solving the same problem. The predictability issue is very real. And for the same problem, the solutions may be a little different — but both are correct.

---

Anti-patterns.

I think we are prematurely standardizing. I have seen a lot of use cases among my friends across companies. People are building platforms, frameworks, structures, controls, that will be used as an AI platform to build the framework that will build the thing. And I am struggling with that, saying: why not just build the thing?

Because all the standardizations we are doing — around specs, skills, prompt libraries — for me, they didn't last more than six months. I'm not sure if whatever you standardize now will last more than six months from this point forward. I had to change my skills, my specs, my prompts, everything, on every new generation of AI model. First of all, some of them may not work. Some of them may actually confuse the agent. Some of them are not needed anymore because of how the new models work. Building in-house agentic SDLC flows is the same thing. I think we are all trying to build something for a future that is unknown — and by "future" I mean six months from now. So standardizing way ahead is, I think, premature.

Anti-pattern: speed of code is not equal to speed of delivery. We talked about that already so I'm not going to spend much time on it. There are demos everywhere — localhost:3000. Some are actually on internal servers, but still internal. My question, and what all the product owners are asking: "Who ships it? Who supports it? Who funds it? Do customers need it?" In many cases some of those answers are known, some are not — and "do customers need it?" I still have my doubt.

Anti-pattern: token-saving tools. I have done a lot of benchmarking over the last six months that tells me all the popular token-saving tools actually don't work. They filter input and output in ways that actually hamper your agent. They obstruct your agent. I think we should be looking for correctness, not token savings. Correctness is the first choice. If token savings happen, you can achieve them by reducing your turns, not each individual token. Try to see how you can reduce the number of turns, because in every turn you are carrying the whole context for the whole session forward — that is multiplicative. The other token savings are additive. Multiplicative will win hands down over additive any day.

---

Final thoughts.

Strong engineers are not yet replaced. I know there's talk about junior engineers — I know Steve Yegge talks about this — but junior engineers with agents do not suddenly become senior engineers. You need to have coding, prompting, text generation, and all those constraints internalized in your system, so that even if it is science, it becomes an art form. Nothing can replace that ingrained scientific understanding coming out as art form.

One of the things I observe is that a novice or junior engineer asks: "Can you make this work? Can you fix all the bugs? Can you fix all the test cases?" Instead of that, an experienced engineer will always ask: "What assumptions are you making? What behavior did you preserve? What could fail? What are the risks? What is the documentation supporting that risk or change, and how will you operate it?" That will make the agent think much deeper, instead of just saying "fix the thing."

And I think I'm going to keep it at that.

One thing I've learned: the agent made me faster when I use it — but if I don't know the underlying principles of coding, one thing it does not give me is the expertise to ask the right questions of the agent. What I mean by that is: if I'm using some technology that I don't know and cannot question, then I just accept it — and the problem is, all that acceptance can become technical debt going forward.

So I'll leave it at that. Thank you so very much. Appreciate it.