Chris Bryce: Things are processing here and we will just update our channel. Okay, click to join here. Having trouble streaming. That is fine. And let's go here.

Chris Bryce: Okay. Hello and welcome to episode 31 of Beyond the CMS. I'm just clicking through some windows here to make sure everything is operational. Thanks for joining. The show is all about everything to do, sorry, I have an overlay with LinkedIn going on here. The format is to essentially ask us anything.

Chris Bryce: We just wanna thank folks for taking some time out of their Thursday lunch to join us and chat about all things CMS related. Today we've got a really great and special guest here with us, Tom Cranstoun, also known as the AEM Guy, and I'm sure there's a lot of stories to share around that.

Chris Bryce: Thank you for making some time. I believe you're calling in from Europe. It's a little bit later in your day, so thank you. Maybe do you want to just tell everyone about yourself?

Tom Cranstoun: Yeah. Hi. Colloquially known as the AEM Guy, a name I gave myself at the CMS Experts Conference, because I was the only guy that knew AEM at that time. CMS Experts has moved on and we've got an awful lot more people in the AEM community joining in, but I've kept the name.

Tom Cranstoun: I worked with AEM for 13 years. I started with one of Britain's giant telecom companies, EE, and we migrated T-Mobile, Orange and EE websites into one big uber website. I won an award for my performance on that task. Following on from EE, I moved to Digitas where I worked with Nissan and Renault in the world's largest AEM implementation at the time.

Tom Cranstoun: It was a global AEM implementation which had 500 people from Digitas working on the project and 500 people from the client working on the project. So you can imagine that if you took two weeks leave, three years worth of effort happened in the background. You came back, you had a lot of catching up to do. I was architecture director looking after the global implementation for 30 different markets in just as many languages.

Tom Cranstoun: Having left them, I then worked for Media Monks, and I worked for a company called Twitter. We built microsites for Twitter using AEM. They use their own proprietary software for X, of course, but they used the microsites to teach creators how to make good use of Twitter, now X. So we did two microsites for them, and after we were finished, they told us that we were the best agency that they had ever worked with. So that was a good feather in the cap. We've also worked for Land Rover, Jaguar, Ford, quite a few automotive companies. So my background is deep in AEM.

Chris Bryce: Amazing. I know you have a lot to talk about today and we have a short amount of time. The folks that watch the show, either live or mostly with the artifacts on YouTube and in our podcast, are kind of CMOs and have a slight marketing bias. And the conversations I have with Dotfusion, they're curious about AEM and the larger enterprise platforms, let's say. Do you have any insights on where things are going with AEM these days, or can you share a little bit about what's happening over at Adobe?

Tom Cranstoun: No secret insider knowledge, just what I've observed. I've worked closely with Adobe. I've got some friends, some colleagues that used to work with me, now work with Adobe. The big movement that they're making is to turn what was a monolith into a composable architecture. They're doing this while the thing flies. In the olden days, AEM on premises was one great big chunk of software that you ran on your local machine. It used OSGi to brick software into parts, but it was one piece of code that worked on your servers.

Tom Cranstoun: That has now been split up into about six different pieces with the same APIs, the same calls. The users don't see the difference, but the backend is completely different and is being restructured to use open standards. There's a thing called OpenWhisk, which is a serverless backend, and it emulates the old AEM pieces, like the DAM, etc., which have been entirely disconnected from the AEM instance and turned into a cloud-native, interactable piece using OpenWhisk.

Tom Cranstoun: And Adobe I/O, which is what Adobe call their version of OpenWhisk, allows you to connect all of the different pieces of Adobe together, like Photoshop, AEM, Lightroom, and you can create interfaces and actions that look like and work as part of the Adobe software. So they've been on this route for quite a few years.

Tom Cranstoun: The Adobe Experience League website, which is their support website, has recently made the transition to a thing called Franklin, or Edge Delivery Services, which is a frontend-built, frontend-driven version of AEM, which uses the content hub and pieces in the background. Something like a quarter of a million pages, so it's been tested at scale by Adobe before being unleashed to the public. It's now been out for one year, and Adobe are moving it into the backend of AEM and creating a new product called Document Authoring, DA. This completely transforms AEM from being a Java-based environment into a composable, choose-your-own-frontend-tools type environment. So the future is to completely decompose parts of AEM that were in the monolith and turn them into more modern, cloud-friendly implementations.

Chris Bryce: Okay, thanks for sharing that. I know we've got a lot to talk about outside of Adobe, but thanks for the update because I think this is really important to know. So you have some thoughts on AI and how it's impacting software architecture and development, and I think this is really the core of what I'd love to have you share with the audience here. I find what you have to say about this really fascinating. Maybe I'll hand it over to you, but I know the number one priority is the phrasing around the runtime debugging trap. Do you wanna explain that?

Tom Cranstoun: Yeah. Well, it all fits into what's happening with the modern AEM, as I spent the last year working with the modern AEM and working with AI because they're both contemporary and of the moment. You begin by asking AI to eat the repository that you have in hand and see if it can understand it. AI struggles with things that aren't in the public domain and widely known. So things like React, everybody knows how React works. There's a million webpages out there about React and how it works. So it's quite easy for an AI to go, oh, this is what you do with React, this is what you do with Vue, this is what you do with plain JavaScript, etc. You give it a new tool, a new CMS one that hasn't existed before, and its knowledge is limited. It's limited because you've only got the manufacturer's instructions, which are new. You haven't got a big buildup of history behind you.

Tom Cranstoun: Now, I am a bit worried about that for the future. AI will only teach you what it knows. So unless you've got a big enough collection of webpages that describe your product with lots of independent sources, the AI will struggle. So I created a training course. The training course was for me, for my AI, to show it how Edge Delivery Services worked. It's a 13-parter, which I constructed over a year, one a month. It's actually a 12-parter. I then took that 12-parter and fed it back into my AI and said, this is how EDS works, and it still didn't get it. It was nearly right, but missing something. So I wrote a part zero to introduce the topic so that AI knew what we were gonna talk about, and I did that. Then I blended it with the manufacturer's webpages, and I took the example repo from the manufacturer and turned that into one large document, which told an AI how to work with EDS. That was a great step forward for me and my development processes. It was then easy to get AI to build new things for me.

Tom Cranstoun: It wasn't very hard in the first place, humans can do it quite nicely, but working with AI, I was a solutions architect, I was an architecture director, and talking to people and explaining what I want and how things should be built was my bread and butter. So telling an AI what I wanted became an interesting ask.

Chris Bryce: Interesting.

Tom Cranstoun: So literal, so, so literal, right? And so literal that when you ask it to debug things, it started going into my core files, my JS files, which came from Adobe, and started changing the code. And I thought, this is not right, this is not what I want. The debug process has got to be simpler than this.

Tom Cranstoun: So you begin to think about the boundaries that you're working with. The way the new AEM works is that you create a document in Word or Google Docs, and you share it either on Google Drive or SharePoint, your choice, you choose your backend of choice. So the backend is a document or a spreadsheet. These things are then published through publishing points, and Adobe's backend takes those artifacts and turns them into HTML, very, very simple HTML. It also turns it into markdown. It doesn't, well, it surfaces the markdown but doesn't use it as part of its generation. So you've got simple HTML produced in Google Drive and fed to Edge Delivery Services, Franklin, which then takes that simple HTML and redecorates it, turning it into the artifact that you want at the end of the day.

Tom Cranstoun: There was no chance that an AI could understand that that is what I was trying to do. I wrestled with it and wrestled with it until in the end I decided that I've got to write documentation for AI that explains what this platform actually is and each of the steps that it must go through, which things it could debug and which things it couldn't. So it's going back to the manufacturer's original intent. They wrote it for a human to follow. For an AI to follow, it's a different kettle of fish, and you have to start changing your terminology and language to get the AI to cooperate with you.

Tom Cranstoun: So I did that, and I was very, very careful, and I eventually ended up with six or seven documents. One about the architecture of EDS, one about how the code was created for EDS, how to debug it. And when you're debugging, don't change core files. However, you could proxy the core files, or if you do change the core files, take a backup and restore it after the session. So documentation at that level, which I call the docs folder slash for-AI, and I now write that for every project I'm working on, whether it be our React project or an EDS project or a Node.js project. The rules for AI, this is different from the project rules that you might create in a PRD.md or a rules file, which tells the machine what you want to build. This is a bunch of files that tells the machine what not to build, where the boundaries are, which things should not be changed, which things could be changed. Give AI half a chance and it'll rewrite everything you've got. Unless it's constrained, it goes a little bit crazy.

Chris Bryce: So when you have this AI document folder, are you basically telling it to look nowhere else but in there? Or how are you architecting that folder structure?

Tom Cranstoun: It depends what task I'm about to do. If I'm gonna write a simple component, I just tell it to look at the how-to-build-blocks document, the simple how-to-build-a-simple-component document. If I'm going in for a debugging session, I tell it to read the debug information architecture before we begin. If I'm adding background services for a composable system, for instance, within the Edge Delivery Services field, where people are discouraged from using Vue and React, you can use them with it, and sometimes your client says, I've got these components, I want to reuse them, I must reuse them, I've invested a lot of time and effort in building them, so ship them into the EDS place. So I have a set of rules, architectural rules, that tell the AI how to do this so it knows not to touch the EDS stuff while it's working on React stuff, and to build React stuff that will port into the EDS stuff.

Tom Cranstoun: And it would make all sorts of mistakes in the beginning. Like it would try and modify the compiled files, I've done a build-create file, and it would go in and start changing things inside the compiled files. You go, no, no, no, everything in the build folder is read only. So you go through the mistakes that you must make working with anybody, human or AI. You give them instructions, they do what they think is right, and you come back and go, oh, I didn't delegate that properly. And then you go through the process of redirecting and moving the learner into the new world, and you tell it never to touch these files, never to touch those files. Don't debug those, those templates get put through a build process and turn into code, you cannot touch the code, you must start with a template. So those labels and hierarchies are put into the AI.

Tom Cranstoun: Obviously there's quick wins, like you have a folder called build, so you tell AI, you can create in there, you can't debug in there. So when it comes to dist, that's where the built component goes, you can't use it in EDS in the dist folder, you must move it out of the dist folder and put it into the blocks folder where it must have the same name as the component so the CMS can find it through auto-discovery. So you build up the rules slowly, and depending on which job you're doing, you pluck from the docs-for-AI folder the piece that you want to work with and feed that to the AI, because AI has terrible memory, you just keep reminding them.

Tom Cranstoun: I employ an AI-first design principle, and I build my code and my scripts such that I can attach an AI to the output and it knows how to build tests, it knows how to build pre-rendered scripts and rendered scripts. It doesn't need to know about the existence of Google Drive, but it does need to know what transform is done by Google Drive and what the files should look like. So I force my AIs, when they provide new components, to build new pages which look like they've been served by EDS, and then pages that look like they've been decorated by EDS. And then you ask the AI to build and run tests against those, allowing it to use its own browser tools to inspect, because in the first place we had Google Docs, we had GitHub, we had local files, and we have the live website sending JSON and data elements down. So you have to tie all of those up in such a way that the AI can reach what it needs. So I did that by building a proxy server which emulates a web server. If it can't find anything local, it'll go to your production and find it there, or your staging, or a test environment, you tell it where you'd like it to go, so that you can get live data for the components that you're building, whether they be in React or whether they be in Edge Delivery Services native. It all works, and the AI has one place to go and one place to ask, and it doesn't get confused and it doesn't say, I can't read your Google Doc, I don't know what's been transformed. We've given it everything that it needs to know.

Chris Bryce: Interesting. Can you share some advice to a CMO that is just tasked with a modernization project, a full rewrite and migration, regardless of the content platform? What is it that they should be thinking philosophically about, empowering their developer teams to be AI ready within the architecture of the new build?

Tom Cranstoun: Yeah, the first thing is that everybody talks about vibe coding. Vibe coding is when you sit down and you say to the AI, make me a to-do list, and off it goes and you get a to-do list. What language is it written in? I don't care. How performant is it? I don't care. What you've got to do is sit down and plan the task before you begin the work, and that is the most important thing. The planning and the documentation takes a lot longer than you think, getting your ideas clear, the design stage, and it's always been that way. AI doesn't take this out of the equation, AI is a different kind of beast that you've got to train.

Tom Cranstoun: You could say you were an automobile company and you're trying to build a new website, but you could take staff from somebody that's already done an automobile website and get them to adjust to your website quite quickly. If you're gonna get an AI to do it, it's never done one before, it doesn't know what an automobile is, it's lost. So you have to spend the time upfront working with the technology and the AI, creating the correct environment, the correct instructions, even if it's content that you're generating using AI, you still have to put the work up front. And you have to train your own AI, you cannot use AI off the shelf. Off-the-shelf AI is an entertainment tool, I've said this many times. Companies like OpenAI have built an attention grabber, they will provide, if you pay them the correct amount of money, something that works, and it works only for you. That's what people should be looking for, not using entertainment machines to create your next product, but something that's been trained in your way of working, your way of developing, so that in itself takes perhaps an architect's look at the project before development begins, and I would say a seasoned architect, this is the thing that AI is, I think, missing, and the vibe coding is what people are jumping on.

Tom Cranstoun: I did a bit of vibe coding a year ago, I learned by my mistakes, and I've documented my documentation, and it's now easy for me to spin up a new environment and ask AI to create new things, and it'll create the documentation for the content authors, it'll create the test pages for the testers, it will create the code, it will create the manual, the user manual, all of it, because I've spent the time training it and telling it what I want. So that is my first thing, don't jump in unless you're trying to test the water and see what a simple component can do. But that will not help you in the long run, it will open the door, you'll creep in, and there's a ten-ton truck coming down that corridor.

Chris Bryce: Right. And how do you see the state of vibe coding right now? Although in my conversations I get a lot of folks kind of bagging on vibe coding because that last maybe 30% is not complete or requires a team, but would you say it's not also a bit indicative of the progress made? Like a year ago, we couldn't enter a few prompts and get a to-do list, let's say.

Tom Cranstoun: Yeah, yeah, yeah, that's very, very true, that's very, very true. But you couldn't release the to-do list, vibe coding gives it to the public. But you couldn't do it a year ago, and people thought that they were doing it, and people still think that they are doing it. You see, when you're coding with AI, small piece at a time, keep your eye on the plan, keep your eye on the product, and make sure that the AI understands what you're doing, and be prepared to press the cancel button and go back again. Sometimes that's necessary. The more often you do that, the less rigorous the original instructions were. So it's not just the prompting, it's the guidance that you give it in the background. I've spent about a year building up my guidance skills rather than my prompting skills.

Chris Bryce: Right. And kind of just setting that architecture for you to have humans and robots playing in with some predictability, I guess.

Tom Cranstoun: Correct, correct. Yes, yes.

Chris Bryce: You talk about the business case as well for kind of setting yourself up properly for now and the capabilities of AI in the future. Do you wanna talk a little bit about that, as businesses try to figure out how to manage this and what to do next?

Tom Cranstoun: Yeah, it's amazing how quickly these things are changing, it really is. Every week the Chinese bring out a new model, and every week OpenAI responds with an upgrade. It's happening so fast that one of the memes going around at the moment is just build it, the future version of AI will fix it for you. Now there's an element of truth there, but I still wouldn't trust it. I still think a human in the loop is always necessary, or more than one human in the loop. Even with good instructions, AI still needs the occasional prod and no, you misunderstood, kind of guidance during its work. So I think setting off one of these super agents to go off and run by itself for five hours and come back with the solution would never work, and I don't think that'll work in the future either.

Tom Cranstoun: One of the interesting things that I found in my career is just recently I went to Hamburg, or Frankfurt, with Jan's CMS Experts Group, and I met a lot of Germans there who were complaining that AI wasn't very good in German. Because German, unlike English, has the du and Sie, you know, three different forms, not just you like in English. English is such a simple language, and English has got something like 67% of AI's content, German is in there for about 6% of the content. So these machines are being trained with a Western bias, an Anglo-Saxon bias, and probably with a San Francisco bias. So there is a huge disconnect between the world and AI. That's one of the things that's troubling me at the moment, I've written a few blog posts about that. I know I've gone off topic, but you talked about the future, that's great.

Tom Cranstoun: In Iceland, the children no longer speak Icelandic unless they're speaking to their grandparents. It's English everywhere, and I'm afraid that AI is gonna force that even further in the world, and that the Germans will find it easier to talk English than German, because these great big long German words that they have do not work well as tokens for AI.

Tom Cranstoun: These things worry me about the future, and content and moving content through CMS using AI to help translate and shift it, you end up with stilted German or stilted Icelandic because they don't have the understanding of colloquial or the voice that the end user wants, which once again comes back to my point, you must train your own AI, you must train it in your voice, you must train it in how to speak for you and your company. These things take quite a bit of work, which aren't technical in nature, but they inform the technology about what you want.

Tom Cranstoun: We are moving away from the days of, well, the web was print in an electronic form, and it's moving into the web becoming less important, and it's the culture of AI and the negotiations that AI make to AI that's going to inform us in the future. We may not even have a screen to work from, and this looks like that's one of the things that OpenAI are working towards, a screenless future, and Meta with their VR glasses. Getting your development teams up to speed means having documentation people there to help with the documentation. Documentation people have to have technical documentation skills, and those are a bit rarer than programmers and developers, I'm afraid.

Chris Bryce: And how are you finding AI for, I guess, preparing documents? Is it doing a decent job? Can you rely on it? Is it a great addendum to your bench?

Tom Cranstoun: I give it extensive instructions as always, I architect my documents, I tell it I want British English, I tell it I don't want any of the things AI does all the time. I have learned AI helps me with my documentation, like a grammar checker helps me with the grammar, but I get it to write the initial version, I review it, I change it, I point it in the right direction, and I get it to come up with a polished version which follows my style.

Chris Bryce: Gotcha.

Tom Cranstoun: So for documentation, as it builds components, I get my AI to build the documentation to match the components.

Chris Bryce: Okay. And just for folks listening in, what is your favorite AI these days? Do you have a go-to?

Tom Cranstoun: Claude. It's always Claude. I used to take out subscriptions to everything, but I cancelled everything but Claude. Claude is superb. People say that these Chinese things are as good as Claude. Claude's on it, it's the latest, and it's superb. I try the Chinese things, I put them to the interview and they fail. Claude always comes through. And I use Claude on the web, Claude in Cursor, Claude in Visual Studio Code, and Claude from the command line, so all three different iterations. Sometimes to give it an entire GitHub repo at once is an interesting way to get Claude to work. If you're working in Roo Code, it will break the code up and give the right proportions. So different strokes for different folks, it depends on the task that I'm asking it to do, whether I want a holistic look at my code or a piecemeal attack, but the backend agent has so far always been Claude.

Chris Bryce: Well, thanks for sharing that. Claude is named after Claude Shannon, the inventor. Claude Shannon is the inventor of information theory, way back in the 1950s. He worked for Bell AT&T Labs and basically created the modern world of telecommunications as we know it, digital telecommunications, quantization, all of those things all come from Claude Shannon.

Tom Cranstoun: I had always guessed it was Claude Monet, the painter. I don't know why I defaulted to the art side of things.

Chris Bryce: Well, while we're on naming of names, the thing called Franklin, Edge Delivery Services, isn't named after Benjamin Franklin.

Tom Cranstoun: Okay, who is that?

Chris Bryce: Rosalind Franklin, one of the discoverers of DNA. As Adobe likes to say, AEM is in our DNA, well, their DNA is in the product, it is true.

Tom Cranstoun: Oh, that's wonderful.

Chris Bryce: Time flies during these great conversations, but just before we go, I know something that's important to you is around the idea of ethical AI. Do you wanna just talk a little bit about where your concerns are and your thinking around what we need to be thoughtful towards?

Tom Cranstoun: Oh yeah, guardrails, the architecture, the documents help it to produce, do what I say, don't veer off, because there's so much in these things for it to pick up on. The next step, we can all see it coming, OpenAI etc. are gonna bring out their own browsers, and these browsers are gonna own the interface between the buyer and the seller. And just like the Apple App Store charges 20%, these guys are gonna charge 20% every time you make a purchase, and these guys are gonna surface it. Now, I don't feel that that's ethical, this goes into the ethics, but this is business.

Tom Cranstoun: You know of Cory Doctorow? He's invented the term, forgive my bad language, enshittification. The enshittification of a product is when they give it to you free, you enjoy it, they build a massive audience, and then they start inserting adverts. Then they start making the content acceptable to the advertisers, not the audience, and then they push you to the advertisers, and that is where Facebook becomes enshittified. LinkedIn goes that way, and AI will go that way, it won't be long until you start seeing adverts as you work with AI, it won't be long until AI is the frame that you purchase things from rather than Google being the frame that you purchase things from. And this is an existential risk for Google, and I think Google will manage it, but they will still manage it in the same way, by owning the space and forcing sales pitches and rewards for them, not rewards for you.

Tom Cranstoun: It's not quite unethical, it's what the founders of the internet didn't want to happen to the internet. They wanted the internet to be an academic space, not a commerce space, and yes, it is becoming a commerce space. But I don't really wanna talk about unethical things in AI, because things like Ukraine have got unethical AI, Israel and Gaza, there's a lot of it about.

Chris Bryce: Yeah, well, trying to keep things positive and figuring out ways that AI can make the world, the planet, our lives better, and I'm sure that's also part of what we're hoping for and participating in. Any last comments? It's sad to see you go, we're a little bit over time, but really appreciative of you being here. Parting words?

Tom Cranstoun: Thanks Chris, that's been very interesting, good fun, and great to have a long chat face to face. We've had short ones before, but this is a long one, really wonderful, thanks.

Chris Bryce: Thanks to everyone else who's made some time to listen in over their lunch. Stay tuned, we'll post any links or things that were referenced in the chat, I think there's a blog post to share that we'll put on LinkedIn below afterwards. And follow up on Apple, Spotify, or wherever you get your podcasts, and thanks again. Have a wonderful Thursday.

Tom Cranstoun: Thank you, Chris.

Chris Bryce: All right, thank you, bye bye.