Why the Trust Layer Is the Next Thing Developers Will Commodify

Hey guys, thanks for the throw. We're here with Michael Hedayo, who's the vice president of software engineering for TinyMCE, and we're having a little chat about, well, the challenges that developers are encountering in the age of AI as they go to build all these interesting new capabilities. But the environment itself is getting more complex.

Michael, welcome to the show. Thank you very much. Nice to meet you, and happy to be here.

So, if you would explain what's happening here. It seems like the developers are getting all kinds of new tools, and usually that leads to a lot of excitement because everybody likes a new shiny object. But these shiny objects come with weight.

So what's going on here and what are the challenges? Well, what we're hearing from our customers is that they're looking at their product roadmaps, and where they used to focus on their core business, they're seeing a lot of AI in there. They're seeing that their actual roadmaps are drowning in AI engineering, and that's really not their core function.

So what they're looking for are people that can provide the componentry that they need to wire up their application, so that they don't have to dedicate their engineering teams to focus on something they may not necessarily be good at. It really comes down to like, what's your business really about? Is it about AI, or is it about healthcare or banking or some other industry?

So to your point, is it your sense that developers might be spending more time maintaining their application development environments than they are actually writing code or doing the things that they actually get paid for? Well, yeah. That's the great temptation is working on the shiny new things.

And then that turns into a maintenance and technical debt over time. But we all know this. When you're in the plumbing, we know this.

But in the age of AI, because things are moving so rapidly, you're finding these engineering teams having to create accessibility and UI components that they've never really done before, and then they have to maintain them. And then it's this infinite maintenance of how are we going to surface the UI? And then you look at everything that's happening underneath in terms of the models that are changing pretty much every day.

And how do you swap out to the new model? What functions exist to make this easier to use? And then you find yourself working on all these AI streams in your roadmap that you didn't anticipate, and it's not really your core business.

And you have to learn a lot. So what's the alternative? What can be done about all this?

Because I think some folks just assume that this is the new cost of business. Well, you're going to see a large commodification of the AI control layer, sort of the trust layer that we'll commodify. So you'll be able to purchase it and drop it into your application and wire it up through all the surface APIs that that component provides.

And that gives you the ability to sort of outsource all of your risk and all of your UI, your complexity, your maintenance, allows you to outsource that to a company that can specialize in that. So does that mean that, I guess back in the day, a lot of people didn't want to do complex applications using, I don't know, things like containers because they were working with a simplified web framework that they got somewhere in the cloud and they just wrote with that. Are you saying that the same thing needs to occur in the age of AI, essentially, because developers ultimately don't want to get too deep into the weeds?

Yeah. So it will change in that fashion. But also, these applications these days live on the web, and that means lots of QA testing, lots of browsers, right?

The browser being the new operating system is also rapidly changing and trying to keep up. So you can build your application, but then you have to make sure that it can work on a browser on Macs and on Windows and on Linux. You have to run all these new test frameworks that your QA team didn't know they had to do, and that's certainly a surprise for them and just adds another burden, another layer of complexity.

And again, when we start to commoditize that trust layer, you're outsourcing all that browser testing into an organization that is a master at browsers and can understand where the browser roadmaps are going, and they can keep pace your core application with what's happening out there in browser land. In theory, we're supposed to be building more software faster than ever, and I think we're generating more code than ever, but that may not actually be creating more software that winds up in a production environment. So as part of this exercise, do people need to kind of maybe find a more simplified approach so that they can distinguish between the work that they are doing to maintain their environment and what the actual code is that's being actually produced that winds up in that production environment?

That's right. So that's happening in two spaces right now. In the developer space, being able to create a PR, right?

And you will see code generated, and having to review that PR that was AI-generated is a burden. And you have positive parts of it, you have negative parts of that. It's almost emerging into a whole new role in terms of how developers are working in AI-generated code.

That's a challenge. The other challenge is in the content space, and how do you govern content that has been AI-generated? How do you track that, and how do you audit that?

You look at Article 50 in the EU, you look at new changes that will be coming ininto the US, which will be coming up probably next year, where they're going to be putting a lot of compliance and governance frameworks similar to GDPR on content that was generated by AI. And you're going to have to prove it. And that governance is a challenge.

That audit trail will be a challenge. You have to prove provenance, and that's where I think everything will be going is proving provenance of a concept or an idea. Mm-hmm.

And that's a huge challenge for businesses in the future. And to your point about that, the developer who used the AI coding tool didn't write the code, so they don't really understand it all that deeply. So it makes it hard to debug, and we wind up in this infinite loop where I spend more time reading code I don't understand than writing code that I at least nominally understood.

Yeah. Well, that's why architecture are important and that's why the actual craft of coding and understanding code is extremely important. So, we make sure that anything that we use to assist us in generating code is governed by our architects who can review it and can bop you on the head if you're not doing it right or if you're not reusing a component or if AI is reinventing something that's already been done and is producing readable code that you can follow along and continue to maintain.

It is about maintainability. That's one of them. That's one of our core non-functional requirements.

You have to be able to maintain it. I don't know if you remember back in the old days, Macromedia, that company had a product called Dreamweaver, and all of a sudden everyone can just cut and paste code from Dreamweaver. And they can create JavaScript.

And they were doing all of this fancy drag and drop componentry in their applications. " I don't know if you've ever seen that before, but it's what we like to call in Australia a dog's breakfast of code. To your point about that, it seems like the code being generated by the AI coding tools is a lot more verbose than what the human would create.

So is the cost of deploying this stuff starting to rise because I am running more or consuming more infrastructure to run this AI-generated code? That's certainly possible, but I think any smart engineering manager certainly wouldn't let it get to that state where the cost of the AI that you're using to assist you in your development process is becoming prohibitive to actually getting the actual work done in a maintainable fashion. We have to maintain products for decades.

TinyMCE has been around for over 25 years. So you have a lineage that you need to maintain, and any decent engineering manager isn't going to just take the quick fix. They're going to want to make sure it's maintainable.

So it's a tough balance. But anyone that's taking those kinds of shortcuts just for the quick win introduces a lot of risk into their business, and risk is something that customers really don't like to wear. Well, to that end, though, we also hear tales that developers are chewing through tokens like crazy and that they're running out of tokens in a given month.

And so now they've got a project that's kind of half done by AI, and they're waiting for the token refresh at the end of the month to keep going, or they got to go ask the boss for more money, and then suddenly the cost of these things is a lot higher than people realize. So do we need to put some sort of dashboard in front of people that says, "This is the number of tokens you have left for this project," and maybe they'll be smarter about using them? Yeah.

They'll have those sorts of management layers that can control that. I think what you'll see is in the ISIMs, those Information Security Management systems that are inside lots of enterprises, I think you'll start to see those in the future start to monitor that AI usage space because that manages corporate risk. So you're going to see a lot of the ISIMs in the future start to help manage and have that dashboard.

So it's not just monitoring token usage and how much code is AI-generated, but it will be monitoring that along with the other risks that are native inside any software business. Right. It'll start to unify into one view.

" I think people trying to custom code and wire AI natively with their own engineering teams into their application, and that work absorbing a lot of the roadmap. It defocuses you from what your business is really all about. We have customers from all over the world and none of them are natively AI customers.

Or they don't build AI products. They're absolutely building something completely different. And then they come to that challenge where, okay, I can use AI, anyone can use it, but now I need to inject that into my application, and I need to inject it into a structured format.

And now your engineers are working on how do I get this structure right, how do I render it inside of a table? How do I do that so I can preserve it for the future? And why am I doing this?

Because I'm in healthcare. Do I really need a huge engineering team to maintain this? And then what happens if you want to switch LLM providers, right?

If you want to go from Anthropic to Gemini, then what are you going to do? You got to rebuild the whole thing again. So yeah, it's pretty interesting.

So yeah, I think a lot of people are choking on a lot of possibilities. And developers are smart, right? " Because they know it's going to change.

" And again, these are all decisions that they have to make in their roadmap to deliver their product. " The other thing I hear from folks is that, especially in their workflows, they're running into the same bottlenecks five times faster, and so they hurt more. But do we need to kind of re-engineer some of our workflows in the age of AI and think this through a little bit better?

Absolutely. The entire SDLC needs to be rebuilt around agentic modeling. Everything from product requirements intake, all the way through maintenance and observability.

The entire chain needs to be overhauled. Anyone working on an old SDLC model will be suffering in the future. You need to incorporate that now, even if it's aspirational, and then you can figure out where humans in the loop are inside that model.

But you need to start to rejig your SDLC because sprints are dead in the age of AI. Because things do move faster, and you're ready to ship now, and you have to tell the product team, "Hey, we're ready to go now. What are we waiting for?

" Well, I think one of the things we're waiting for is that there's more concerns about security and compliance because a lot of folks are thinking maybe that there's more vulnerabilities in the code generated by the AI tools than the humans, but that remains to be seen, because you could probably argue it both ways. But as one wag once put it, all it takes is one successful lawsuit to wipe out all the productivity gains from AI. So what do we need to do to kind of batten down these hatches?

Well, I think what I was talking about before on risk management and ISIMs and those management systems, they need to start monitoring AI usage within organizations. They will be doing that, and they need to be mapping those to all the standard compliance frameworks. That's the only way that you're going to be able to get a good read on what's going on inside your organization from a risk perspective, and then you have to figure out what exactly is truly a risk and draw your attention to that part of your product base or that code set that you're working on.

All right. So Michael, you guys are pretty far down this road. What do you know now that you wish you knew six months ago?

What do I know now? Hardly anything. " Especially around compliance and audit on keystroke, right?

So you have people that are going to ChatGPT or whatever, and they're kind of cutting and pasting stuff from ChatGPT into their application and it's unauditable. There's a bridge there. You need to figure out where it came from and how much risk that introduces into my business, because it may not be true.

It may not be mine. We didn't realize that level of compliance that our customers needed until after we were able to speak with them and kind of get their requirements and kind of see how they were going to be using it. So that one's pretty interesting.

Also, the UI there's no standards on the UI on these apps. It reminds me of the old days of Linux, when everyone had their own UI for every component within the operating system, so you couldn't figure out where the OK button, whether it was a check mark or a checkbox, or if it was OK, because everybody had their own way of doing it. So there's a lack of sort of unification in the UI space.

All right. And my friend, for the uninitiated, what exactly does your platform do? Okay.

So what we do is we provide a rich text editor that you can drop into your application. But that rich text editor is actually a series of APIs, and that allows you to modify content going into your application. And it's more than just WordPress.

It's about real structured content, real governed content, medical records, legal records. Our customers are large governments. " Because they have a different focus.

And then what we've done with our TinyMC AI is we've wired that into a series of usability and UI functions that allow you to integrate with all the large models so that you can utilize AI inside your application without having to recode everything. You just point the API to what you need it to do, and it just simplifies it. Lets you make custom prompts that you can build once and your entire organization of thousands can use.

It creates more of a controlled environment for AI usage. So that's basically what we do. We're trying to really take that AI trust control space, try to commodify that so that we can get it into the hands of as many people as possible.

And at our core, we're open source, so we want to make sure that a lot of people have access to our core code base so they can really see what's going on. All right, folks. You heard it here.

Hey, the tech is cool, but at the end of the day, you might want to keep your eye on the business goals and work backwards from there because, well, you'll probably have a better outcome. Hey, Michael, thanks for being on the show. Thank you, Mike.

It's been a pleasure. Cheers. All right, and back to you guys in the studio.