About this talk
In this talk, Marco discusses his long journey of managing and migrating a personal website built on Drupal, initially created 24 years ago. He started with a custom PHP solution but transitioned to using Drupal 3, contributing to its development by creating the 'taxonomy' module. As his site grew to over 100,000 nodes, the challenges of maintaining it increased, especially when Drupal 7 reached its end of life. Faced with the complexities and costs of migrating to Drupal 8 or 9, Marco turned to an AI-driven development methodology called BMAD, which facilitated the migration process. He elaborates on the phases involved in BMAD, such as analysis, planning, and implementation, showcasing how AI helped identify and overcome issues during the migration. Marco emphasizes that while using AI can accelerate development, careful planning and human oversight remain crucial to ensure quality and thoroughness.
Full transcript
Thank you for being here. Uh I'm Marco. I work for Tagwan. But today I'm going to talk about something more personal. I'm going to talk about my personal website. So um 24 years ago, I had this work uh this website. It's an Italian website and uh uh it's mostly about uh uh you know, humor content. Uh uh nothing serious really, but it it was working. uh and
I soon realized that uh I needed a way to manage it. Uh it was running with some uh custom uh PHP code but I needed something better. So at the time I don't even think uh we were talking about CMS. Uh I I'm not sure it was actually a term but there was something called PHP Nuke uh which was probably the most famous option but it it
wasn't great. I was looking for something uh with a better foundation and I found Drupal. It was Drupal 3 at the time. Uh and I thought okay uh it's a good foundation. It's missing missing a few things but I can probably join and help. And so I did and I started contributing and uh uh one day I I needed something I realized I needed something to categorize
things. Okay. Could be like uh pages uh or uh images, sections, forums. It's all about categories. Okay. And so I I created a module and I called it category. Okay. And Dre said in the developer mainly said, "Okay, that's a good idea, but let's not let's call it something different. Let's call it taxonomy." [laughter] And I I was like, "Huh? I I search on the dictionary was
oh okay if you merge it I'm I'm okay with taxonomy so in a way you can blame me for the API but you should blame trees for the name okay so uh I used this module and all my customization uh for several years uh and uh this was really my my testing ground okay so a new version of Drupal uh came out and so I tested it
and decided whether to uh use it or not. And I kept on using my Drupal 4 uh and something code for a while uh until uh Drupal 7 when uh uh when Drupal 7 uh came out, I thought it was a good idea to migrate and uh so I did. And so uh jump forward 15 years and now I have this uh uh website uh with a
lot of nodes more than 100,000 nodes not every node is published just about 40,000 and there are several types there are articles jokes uh uh there is a newsletter with 100,000 subscribers uh and several uh integrations like uh the integration to the newsletter provider uh a lot of Uh so is is it large site is it small it's a lot of content uh there are not not
a lot of custom code but still there is some custom code can you say it's a medium size probably it has its issues for example with performance uh if I'm not careful but it was working it worked for me for a long time and then of course Drupal 7 uh reached the end of life which is a problem so uh I actually uh had an estimate. Uh
I asked someone because u uh you know I I realized that migrating uh to Drupal 8 or [snorts] may maybe probably when I asked for the estimate it was more like Drupal 9 it was going to take some effort and I was told uh this going to be two to three developers uh several month and a significant budget uh and quite frankly the economics just uh didn't
work. Maybe maybe I'm a decent developer, but I assure you I'm not a great entrepreneur at all. So it wasn't going to happen. So what I did was what every responsible uh project product owner does. I I swept the problem under the rug and prayed for a magic bullet. And of course that was the right strategy because then AI arrived. So it worked. >> Thanks. [clears throat]
And then uh I I'm going to spoil you what happened. It worked. It worked. Uh after seven epics and more than uh 50 uh stories uh every entity was migrated uh across the epics and uh no there were no there was no blocker. Uh I will just discuss what this means later. Uh so yes, story competition rate 100%. Uh uh I already did the the integrations. Uh
that's that's a great success. No. So yeah, maybe you may wonder is it online? Of course [clears throat] not because uh well I mean it's in UT. Okay. I'm still testing tweaking a few things. Uh most mostly it's not online yet because I need let's say a couple of weeks where really I'm I'm not stressed and I don't have any deadline. So I I if there's an
issue I can jump and fix the issue because at the end of the day this is still a side project for me. Uh but in my opinion this is a success. I have no uh doubt that I will go online. I I may even go online uh with and switch say for example if like a a horrible security bug came out for Drupal 7 I could just
say okay I I will just switch the code. Uh so yes in my opinion uh it was a success. Uh I'm sorry if it's not online yet but uh yeah that's how it is. Now I'm going to tell you how this happened though because I I think it's interesting. I use u uh methodology and uh you of course I used the eye but uh I'm I agree
I I I hope you agree that uh something like this cannot be done just uh with a single chat even with with code and planning mode. It needs much much more. Uh the framework I used is called BMAT which stands for breakthrough method for agile AIdriven development. It's open source. It's available on GitHub and it's a specdriven development. Uh the core idea uh is to have uh
is to have agents as code. So instead of having having one AI that does everything, you have some specialized personas that you will meet in a second. uh has markdown files uh each with its own uh identity, communication style, principle and in particular responsibilities. They are versionable. Uh they leave and you you commit them in your repository. Uh but I I want to make this very clear.
This is not just a prompt engineering. Okay, this is a a a full life cycle methodology uh with four phases that I will I will show shortly and uh also just as importantly each phase produces an explicit uh artifact uh which is also uh committed uh to your repo and uh those artifacts are used in the other phases uh of of the project and so as cringey
as it is. But please meet my uh v virtual team. We have John the product manager, Sally the UX designer, Mary the analyst, Winston the architect, Bob uh the scrum master, and Amelia who was doing both the developer as the work as developer and also doing the adversarial uh reviews. We will we will talk about what this means and if it makes sense if the same persona
does both. I think it does. uh each one as I said has its own identity, communication style, uh operating principles. What's very very important is that uh each of these uh in a certain workflow runs in its in its own session in its own AI session it's running within uh cloud code. It also BMAD also supports uh like other other uh open code and other um software
like code but I work with clo code and it's uh each session uh starts of course with a fresh context. Uh so for example Bob creates a story then a separate session validates it. Amelia implements it then uh another uh fresh session runs the adversalia code review and so on and so on. And uh really this separation of concerns is what uh makes everything work. Uh the
human me u is partially the product owner. Uh so I I drive the direction uh I review the output. I also make uh architectural decisions and I review the code and I also test a lot. Uh and yeah, I just executes. Uh this one is probably very very small for you. I will try to uh zoom in but it's probably still almost unreadable. Uh these are the
four phases. Uh you you can find this diagram uh on the BMAD uh page. [clears throat] But let's skip to the next one where I actually show you for each phase uh what I actually did. So in the first phase is the analysis phase. Uh and I started with a product brief essentially what I was going to do and why. Then uh the analyst made two researches.
One was the Drupal 7 site audit. So uh it cataloged every module, every content type, every integration and so on. There was a separate research uh session uh mapping the D7 modules to their D11 equivalents. Uh so identifying what could be replaced, what needed to be uh rewritten, what could be dropped and so on. The next phase was the planning phase uh where in a very long
session uh I wrote the product requirements document which at the end contained more than 70 functional requirements. I also had a UX specification uh session where essentially I was talking to the UX agent about uh I was showing the UX agent some screenshots. I was talking about what I wanted to do with the teaming and so on. Then the solutioning phase uh where the architecture document was
written and then where the seven epics with uh the skeleton of the 50 stories was decided each with the its own acceptance criteria criteria and uh then the implementation phase. So in the implementation phase uh it's divided essentially in four uh workflows which is to fully develop uh actually fully write the story review the story finally write the code to implement the story and then review uh
the code and then uh it's repeated for the next story and so on and so on and uh at the end of each epic I also did a retrospective with uh the with my team. Yeah. Yeah. Who's was laughing? I know it's a just as cringy as retrospectives in real life, [laughter] but just as useful. Okay. I I I will show some examples. Big fan of retrospectives.
Okay. So, why why are we doing this? Because of the context window uh problem. You know, I hope you know what I mean. Every uh AI agent has a certain context window. It's more or less like its reasoning memory. It's short-term memory, but it's uh uh very limited. Uh we just had this huge increase of code of oppus 4.6 to 1 million from 200,000 uh tokens. But
still uh after you are run out of uh the the the context window you [snorts] have to start essentially a new session. Um BMAD uh and also other uh frameworks like that solves this problem through artifacts. Uh as I said each phase produces documents that the next phase the next phases read. Uh so for example when Amelia starts implementing a certain story she reads the architecture document
she reads the story document she reads the dev notes and everything uh well everything that she needs. She does not need to know what happened in a certain session. Uh she just needs the decision from uh from that session. So in in every session uh with an agent you go through a workflow uh and step by step the the agent guides you and discusses the details related
to the current process. For for example in the UX workflow with Sally I was showing her the screenshots then step by step we're talking what to do uh accessibility and so on and so on. uh it guides you and meanwhile the agent takes notes and at the end these notes become the artifact of that session and they are committed to the repository. Then uh though uh after
each workflow step uh you're also uh given a choice. You can continue to the next step in the same workflow or you can do uh the advanced elicitation or party mode. So advanced elicitation is really interesting. So if you think that the the the the current step has something that doesn't sound right, uh you can use this advanced elicitation and try to go uh deeper and try
to find out what's your feeling. Uh the AI analyzes the the context and recommends some uh techniques. Uh so maybe it will uh recommend the premortem analysis. I use that a lot. Essentially the idea is uh uh saying okay if in six months from now this didn't work why uh why didn't it work and try to imagine why it didn't work um or or other good cop
bad cop there there are many techniques you may you may recognize some of them from agile uh they are um divided in in several uh categories [snorts] um or you can also also do uh oh yes and at the end uh so what happens is that you say okay let's do a good cop bad cop then uh the AI uh does uh this bad cop uh bad
cop good cop and suggest some uh changes and then you decide to accept these changes or to just drop them or maybe you want to discuss the changes and take something and not something else. There's also party mode. A party mode essentially uh it brings uh a few two or three relevant agents into a live discussion and then they discuss uh with each other about the current
decision and maybe you can imagine the architect uh and the PM debating whether to use a JSON API or a custom rest endpoint. It does this kind of thing and then of course at the end you you you watch the debate and the end you decide or you just continue if you if you're sure. Um, something that I I should note especially if you're a little OCD
like me, you you uh probably tend to to uh want to do a lot of these uh elicitations and and just to be sure you didn't miss anything. Uh it's useful but to a certain point as we will see this process very long takes a lot of time. So it requires some balance also in in this but I've used this a lot uh and they surfaced things
that uh honestly I wouldn't have considered. Uh the premortan analysis for example um flagged a certain issue in a migration that would have been a problem later. Uh and this should also show why uh BMAD is a methodology not just a prompt collection. Uh it's interactive. It's very collaborative and the human is in the middle of everything and also uh in control. So it it wasn't simple
to see uh from from that small diagram I was showing uh with every uh section every phase of BMAD. But BMAD has also in the first phase a brainstorming uh mode a brainstorming workflow. uh I didn't use it for this project but I used it for other projects and I decided to talk briefly about it because it's very very powerful um so essentially uh it allows you
to use these uh existing techniques they were invented by BMAT um and uh they uh they could be scamper which is from uh research in 1971 uh it could be the five wise from Toyota you may have heard about some of these yes and is from impro is first principles is from Aristotle uh they are uh these methods uh they work really well u they are different
from the advanced elicitation because it's more back and forth uh the uh AI asks you often a provocative question and then you start discussing with it and you really see ideas that uh emerge. It also has an antibbias protocol. It tries consciously to pivot uh the domains uh once in a while uh to avoid clustering around similar ideas. Uh the zombie apocalypse planning is very fun. You
should try quite frankly uh if you take home like two things from this session. Try this thing. Even even if you don't do anything else with BMAT, try this. It's very powerful. The the other thing is the very last thing I will say but yeah this one is very very cool. So I want to talk about some field stories. So some examples uh of uh things that
happened during uh this development and I will start with by far the worst bug I had in the whole migration. uh without going into much details because really what happened technically is not super interesting. But essentially for some reason the revision ID uh in in uh a table for a certain uh content type was not matching the revision ID in the field revision tables. Okay, I have
no idea why. Probably something m some query I did. I have no idea why but it was matching. it wasn't causing causing any issue uh on the side but uh essentially it was uh losing during the migration it was losing some very important uh data uh which is essentially the it was assigning the wrong taxonomy. Um so it was a big deal. Uh what's really interesting is
that even with such a a weird bug uh likely caused by a human error, who knows when, the AI was able to find a solution by itself. And uh the way it was able to do that uh and this is the interesting part is that during all the planning phases one of the things that we said was that we really needed to test the migrations uh with
a limited subset okay 100 items. Uh once we said that and once the started the development then of course it ran this limited migration during the development to test and almost immediately it realized there was a problem and even without telling me it told me at the end it started searching for a solution which was nothing complicated. It was uh doing a custom source plug-in uh acquirering
the the correct data essentially and uh this resulted in at the end the of the process of uh resulted in a full migration a working migration of every joke because we we have a lot of jokes because we are Italian I guess and uh yes but uh what what's really interesting in my opinion is this proper planning that allow the the AI to catch and fix this
tricky bug. Um this is a a a different example. So uh during the very first epic um and during the development phase uh the AI and I were start we were starting to notice uh um uh configuration drift. So essentially uh the YAML fixes uh were not were committed but they were not imported in the database. So the next exporter were was overwriting the fixes and uh
this caused a regression and it kept on fixing the same things and wondering why this was happening. And uh I think I think you have seen if you have worked with clo code with these codes with with these models you you probably have seen some something like that like this circular uh things where the AI does something and then it goes back and then it keeps on
doing a loop trying to fix this. Um, so we we eventually uh I noticed this uh and I I I I asked uh during the the retrospective of the first epic uh and and I I had to I had to ask because the AI uh was flagging a few issues but not this one. And I was like okay yeah we're good but what about this loop thing
that kept on happening? So we investigated the we we we found the root cause which is what I described and the the fix was just uh fixing the workflow. So as you can see there formalizing the protocol we implemented export commit and review then fixed then import verify and commit. Okay. So we decided to make this uh for formal and from that point forward the issue didn't
happen. Okay. So uh again this is more about fixing the process uh rather than the the bug uh the bug itself. Uh another issue uh was was this is typical very very classical very classic problem with the uh AI training. um we decided to do a Bootstrap 5 uh theme, but of course due to the uh training of the models, the the model kept on using uh
Bootstrap 4 um uh patterns. Okay. Uh at the end of the day, I I saw this this kept on happening. So we I I stopped the process. I talked about it. We decided just to add some documentation and underline that uh it was it it had to use uh Bootstrap 5 and and once again the issue was uh was fixed. Uh this also completely different a completely
different issue I had. Um so uh after the first epic uh during the retrospective we uh found four actual action items. Uh two of these items were embedded in the workflow of uh the next uh epic but two were just uh kept there and we said okay then we will fix that uh those two somehow. Uh and of course they got dropped and we forgot about them.
Uh so at the end just like in real life you uh so at the end uh of the second epic we realized that and we decided that no uh no more standalone uh tasks uh we we had to include every task in the next every every action item in the next uh workflows. Uh and once again once we fixed this uh uh process uh this didn't happen
again. it it essentially this process selforrect u and also this is uh also a generic lesson I think which can be learned here if if you tell the AI uh what what to fix and make sure that it takes notes the will will will often uh follow and avoid make that mistake again uh this is the last uh issue that I wanted to report um the way
I organized the code because I had a root repo uh with all the BMAD artifacts and then uh two folders subfolders, one with the Drupal 7 repository, one with with the Drupal 11 repository. Uh and what I noticed that the um the coding agent kept on uh committing uh the files in the wrong uh repositories. Okay. Uh yes the the the g ignore was set correctly but
still uh it was getting confused. It was committing the files of uh the Drupal uh 11 uh repository into the root repository and so on. But once again uh I I told uh during a retrospective so see big fan retrospective I told the guy uh to take care of this to take a note to avoid this and I really saw immediately that uh at the end when
it was time to commit uh it was very uh explicit uh explicitly saying okay now I'm going to commit for the root repo now I'm going to commit for the Drupal 11 repo and so on. Okay. So, let's look at some numbers. Um, this is uh the codebase uh the comparison between the Drupal 7 Drupal 11 um sites. I'm sure it's something that you've seen before. So,
the custom modules, the number of custom modules decreased significantly. The contract modules uh are now managed by composer. The config uh config management now is through YAML. The theme is now very clean and bootstrap 5. The package management through composer uh the field system plug-in based and typed and of course the migration using the core migration. But my point here is is that uh something that matters
for AI assistant development is that with a clean architecture with with a very clear patterns uh this is something that AI can reason uh about reliably with D7 and and the hook soup so to say. Um yes the eye can reason and can work on that but it struggles much more. Uh Drupal 11 structure um and all the design pattern patterns that it uses. Uh these are
things that the AI has seen uh several times in in its uh uh training and so it it works uh uh really well. about the process. Uh more than 10 uh planning documents were produced and as I said there were more than 70 functional requirements. The seven epics and 50 stories. No blockers. Um no blockers means that during the development no uh no story was blocked because
we forgot something. Uh you can imagine uh dependencies you cannot do certain migration without an another migration and so on. Everything was very clearly uh documented and planned before and uh the development phase flew uh flowed very very smoothly. Um we also did something that I think was very interesting once again probably for [snorts] the uh for for the for being trained with uh you know it
has a certain uh endpoint with training certain uh date. Um it was finding surprises with Drupal 11. Um so during the first uh um retrospective we decided to start uh documenting these uh surprises that it was finding and at the end all these uh if the documented patterns line uh we we found more more than 50 uh patterns that were surprising the eye and then I I
I saw that the more we were documenting these surprises the more the later phases were using these patterns and these pattern document to avoid these surprises. uh um a use case uh a case a case study um about this uh food inside project. It was a green field IoT uh application. Greenfield meaning that it was made from scratch uh from from from zero. While of course what
I worked on was a migration. So maybe it was more complicated. Um you can see there uh the stories uh at the end were 29. The line of code were about 50,000. Uh food inside uh clocked about 20 hours 20 human hours while the traditional estimate was 400. You can see that I didn't put any number there. Why? uh because as I said it's it's a side
project. So I I I have trouble saying how many hours uh I actually put into this. I worked during my uh evenings during the weekend and so on. Sometimes I was just letting the eye work and then once in a while I was checking where it was and so on. uh so I can tell you that uh the core of the the uh project the core of
the process was done in about three weeks three four weeks uh so but it's not really like three uh three four weeks of full-time work uh more you know here and there um and of course uh I mean this is my example and and another example Um this this process is based on proven techniques uh agile techniques and other uh but uh of course it's very young
methodology. Uh there is no there's very limited uh critical analysis of BMAD. There are no published failure cases. So yeah and quite frankly there's there are also some criticisms uh about BMAD. uh and they probably also make sense and that's what I'm going to talk about next. So what the numbers don't show uh yeah they don't show for example the time that I spent uh uh reading
AI output a lot of out I output and essentially mostly approving but sometimes pushing back so I I couldn't just click okay okay I I had to read they don't show that the three review passes um that that were done before the config drift issue was found. Uh they don't show every time uh the eye was uh running uh you know the test migration uh and it
was just working um and so on and and maybe most importantly they don't show the time I used uh for the more than 10 document planning documents that preceded any code. Okay. And it's real time that that's a very uh time consuming and and also stressful uh process. Uh it's not something that you can do lightly. You you stay there, you talk to the eye, you do
these uh elicitations, you do party mode. It's fun. It's interesting, but it's like real work. And also of course the retrospectives uh the the patterns documentation, the the process refinements. this this meta work so to say they does doesn't doesn't show up in the lines of code per hour thing and so I believe this is important for uh the next session so a honest assessment if you
want to follow this uh if you think this uh methodology is right for your project which may be or may may not be uh you should be aware that you need First of all, domain expertise. You must understand Drupal module system, config API, migration framework, how entities At the end of the day, the hardest task uh that uh um I had during this process, people who work
with me probably can imagine what the hardest task was. Was theming, of course. Why? Because I'm not a themur. Okay. So when I was doing the teaming there, I was really feeling, you know, the vibe coding thing and and just saying, "No, no, no, that's not what I want. No, look at the screenshot. Why don't you look at the screen? No, I want that." But I wasn't
able to provide anything useful for the AI. Okay, I was just crossing my fingers and and I was getting frustrated and quite frankly I'm even now I'm not really happy about the but yeah it's not that bad so probably it will be fine. You also need uh discipline and especially code review discipline. I really reviewed every single commit, every change and I never gave AI the uh
auto merge uh permission. yes, it takes time and yes, it stops the process but uh I believe that the few minutes that you you take to review really help uh at the end. uh the AI accelerated my execution but uh uh I made or at least I approved the and you need a lot of patience reading AI output is slower uh than writing the code itself for
simple task tasks uh really the leverage with such a process comes with complex uh multi-step tasks like a migration uh otherwise Yeah. Uh I I have tried using uh BMAD for other tasks. For example, I was working uh with we with I was playing with an idea uh and I use the uh brainstorming thing. Uh so I was getting really excited and then thought okay now I
want to do a prototype and I fall into the the the trap of initiating the BMAT process. No, that's not a good idea. uh prototype probably just clo code planning and then uh uh executing and and that's it. Uh and and that's what I did. I I I I I stopped doing using BMAD for for that prototype and I went back to just clothes code with planning
and so on. And I believe for complex task uh complex tasks you really need a framework. Uh maybe not be mad like for example this spec kit uh GSD. I haven't used them. I've read great things about them. Um the the the main uh the main con of BMAD is probably time. If you if you uh search online, you will find criticism criticism about uh the time
that BMAD takes because it it still requires effort. Uh something that I I kept on telling myself is that is to take take your time okay because if um I wasn't putting any effort I felt that something was wrong uh so maybe the completed a complex migration too quickly and so yeah let me investigate that or maybe uh a code review came back saying okay it's all
it's all good then Yeah, in that case I I felt something was wrong. Um, so yes, uh Oops. Uh, in my opinion really uh it's better to slow down, read every line uh and verify. This is not uh this this methodology is not a press a button and get website thing. Okay. And also when when you uh if you read online about the comparison saying oh I
I I I asked cloud code create uh this uh this this tool then I did the same with BMAD. BMAD took two days. Clo took two minutes. Yes. Yes. That's true. That's what I was saying about the prototype. Uh BMAD works in certain cases and not other cases. So, uh, the bigger picture. Oh, no. Uh, oh, yes. Yes. Sorry. Uh, I'm also running out of time. Yeah,
I already said this. Um, takes time. Uh, and, uh, is there a faster way? Maybe, maybe you could skip a few things. I decided not to. Uh, and I I believe at the end of the day, it was the right decision. So, bigger picture. I I I I be very honest here when when these tools work when even just cloud code writes a migration plug-in that passes
on the first try or BMAD generates a story which mirrors perfectly what you have in mind you feel invincible. I felt invincible and I really wanted to run like say five agents in parallel. I want to be 10 times faster. Quite frankly, when I when I starting doing this, I get I was getting so excited that I decided, okay, you know what? I am going to do
this migration in one week, which is delusional. And not only that, uh a study published uh just a couple weeks ago talks about uh uh what they call brain f brain fry. It's really mental fatigue. It's a very interesting uh study. I I have the the resources at the end. Um it talks about it found out that 14% of AI using workers experience this mental fatigue this
AI brain fry. Uh and workers made when they were stressed by this uh mental fatigue caused by AI uh they made more uh mistakes uh and they reported of course more fatigue. Uh apparently according to this study, productivity peaks when it's when you're using three AI tools concurrently and then declines. And the worst part is that people don't realize they have this feeling and I had that
that if you run five six concurrent processes uh everything is is working fine. And the most taxing form of AI engagement was oversight, which is exactly uh what I saw like over oversight uh having to look at what AI was doing, having to approve and so on. Um and uh there there was also they also found a positive side the uh when AI replaces routine or repetitive
tasks, burnout scores was were actually lower. So it's clear that uh uh you can use AI in a good way or in a bad way. It can stresses you or it can make you uh happier. And really I found myself completely drawn into this. Uh I wanted to do like one last session and 1:00 a.m. you know or using Git work 3 which is amazing and I
never heard about that to run concurrent sessions. uh telling myself that I was going to uh migrate everything and and complete migration in one week. Uh I don't know if any of you have done this but uh I have used tail scale and t-max sessions so that I could connect on my phone while I was away so I could check what I was doing and I I
really did that in very inappropriate uh events and I couldn't stop. Okay, I I'm 51. I should be wiser than that. And I'm saying this and and when when uh clothed remote control uh came out, I was so excited because I didn't have to do the tail scan T-Max anymore. So very clearly this is not healthy. Uh so once I finally realized what was happening, I settled
on a principle that I set the pace. Okay. uh and that AI can wait and it's okay if I don't you know uh use all my code usage you know you the bar the usage bar I wanted to see go to the end okay no it's okay if it doesn't happen [snorts] and so now I aim for say like a 2x speed up but with higher quality
where I understand everything where I approved everything where I have uh excellent uh test coverage where I have good documentation, up-to-date documentation, uh where I have a good architecture where I can do a refactoring uh without uh any fear. I I I prefer to aim for that instead of just a chaotic 10x speed up where where I barely understand what's going on. So um this is uh
this is some some practices published as a companions tip tips article uh to the uh the first So the is talking about uh five five ideas. The the first one is to set clear expectations because uh no sorry the first one is to redesign the work for human and AI collaboration. So the idea is that you cannot just layer AI uh oversight on top of existing work.
Uh you need to define clear limits even either if you work by yourself or if you're in a team and probably just set a couple of um m at most two active AI tasks at a time. The second one is to set clear expectations. The idea is that when organizations celebrate productivity gains without clarifying what changes often the employees interpret it as uh work as more work
and this alone causes stress. Uh the third one is to measure impact and not activity. So according to this article uh there is a very famous company meta which [snorts] includes the number of lines of code generated by AI has a performance metrics for engineers >> like in the 70s okay no this clearly is not good uh it's volume over quality and uh it's really what uh
leads to fatigue number four uh is building uh problem framing skills and this is very interesting because BMAD methodology or the analysis planning and solutioning phases they are problem framing you don't don't just uh jump straight to uh so I thought it was very interesting it's it's very clearly what BMAT does and number five is to protect the human attention to treat it as a finite uh
which is always important But there is also uh good use. Um in my things like BMAT and AI make D1 uh economically viable. Again in a way we we have told oursel that Drupal 11 is enterprise only. In my opinion that's not only that's no longer the case. the the traditional cost of D7 to D11 migration uh has changed significantly with with something like this um a
process like BMAD uh changes the equation. It does not eliminate the cost but it changes the equation and one person uh can deliver what previously required a small team and Drupal 11 architecture is a huge advantage here. As I said, all the excellent design patterns of Drupal 11 um are are very well known by AI and it means that AI can work very well with Drupal 11.
Um it is said that uh the uh Drupal 11 is a perfect uh uh platform for uh AI, but it's also the contrary. AI is perfect for uh Drupal 11. Yes. And and the final point is in my opinion now Drupal 11 is also very much um usable for medium-sized uh sites. So very quickly uh five things that you can do uh tomorrow. First of all never
approve never auto approve commits. Uh always read the changes and always remember uh see offency. the II will tell you everything looks great. Uh they will tell you that this session is fantastic. It will do that. Number two is to document and commit your decisions. Even if you don't use BMAT, you can have like a decisions markdown file and you commit it. Number three, retrospectives in real
life or with your AI agents. Number four, regardless of the tool, tell AI about its mistakes. every every tool every coding tool now has a sort of memory h and make sure that it actually takes notes. And number five is the takeaway. So set the pace and let AI wait. It's all right. Aim for 2x speed uh with quality rather than 10x with with chaos. This is
frankly all just common sense. Uh it's important if you use AI. Uh if you don't use AI, probably more important if you if you use it. And so yeah uh with this uh this is the last slide. Uh I hope you you you will use these tools because they are amazing. Uh they are very very exciting if used uh in a healthy way. I migrated this website
and I could make it and quite frankly two years ago even just one year ago this wouldn't have been possible at all. And enjoy them because they can be fun. Uh I yesterday at the gala I heard someone saying that uh they haven't had this much fun in 20 years and I agree. I agree. So [snorts] yes, build something amazing with them because now we can do
things where uh which were sci-fi just a few years ago and then uh then close your laptop. Okay. Okay, that's it. Thank you. These are some resources if you want to take a look. >> [applause] >> We have one full minute for question. Oh, there's actually two questions. Okay. Uh there first. >> So, yeah, I'm curious. Uh hey, great guy. Um >> thank you. I'm curious how
much of your success was due to Drupal to Drupal versus some obscure CMS like WordPress >> or you know that joke obviously but AI presumably knows WordPress as well as it knows Drupal 11 probably way more than it knows Drupal 7. So I'm curious what you think that might have looked like >> in a different >> um last year I I I had another related session was
where I was talking about a website I did >> repeat the question. >> Oh yes I repeat the question. So uh the question is uh did this work uh because uh uh it was Drupal to Drupal uh did this work better because it was Drupal to Drupal or uh would it work as well for uh I if coming from for example WordPress or uh some other um
tool. Uh last last year I did another AI session where I was talking about um a website a small website I did for a friend of mine uh based on WordPress which I really have no experience with uh and it work really well. So yes if if it's WordPress I'm sure it it it will work. If it's some custom thing will it work? Yes, in my opinion
it will because I'm thinking for example uh some projects that we did with Tagwan uh it was about taking uh a lot of uh very custom and very large uh code uh with a lot of uh uh business logic uh embedded into it and something that we did we we had first of all to understand what this thing was was doing. uh and uh I I I
have to say that AI was able to analyze what was going on very well uh and yes of course uh as we didn't just trust what the eye was telling us we were very fine so in my opinion yes my opinion even uh some completely custom code will will work fine on the other hand you have the huge advantage uh of uh having Drupal 11 on the
other end that that's a huge huge advantage So yes, in a in a way you the large custom code will just be read and understood. If it had to write that then then it would probably it may miss some pattern something but then you port it to Drupal 11 and it will be fine. There was a question there. >> Yeah. Uh so a question about the uh
outdated or old indexed information in uh the AI uh kind of index for example you showed that it tried to use bootstrap 4 instead of bootstrap 5. >> And if two months before uh the bootrap six will be released and I want to use >> Yes. how to add this actual information to the LLM to start to use it because I I can't add all the thousands
of documentation of the new bootation to the context window. >> How to handle this? >> Yes. Yes. Yes. That's a good question. So the question is uh yeah but uh as we know um AI models have um their training is limited in time. So what happens if you want to use bootstrap 6 which was just released or will be released soon uh instead of dup of bootstrap
5 bootstrap 4 because if you put all the documentation in the context window it will take a lot of uh space. Yes that is very true. Uh first of all context windows right now are quite large. So 1 million tokens is quite large as a context will do and I've seen more and more projects which are actually uh providing a a single file with all the documentation
okay uh right for to be included into uh a project uh into a context window and so on. I don't think uh bootstrap 6 documentation will fill the 1 million context window. I I I I I don't know because I said I'm not a teamer, but I don't think the documentation will will fill the 1 million context window of obus 4.6 and a process like this where
uh you have these sessions and every session loads just the artifacts that it needs is exactly what you need. So you go to theming and then it will load the architect architecture and then the story and so on and so on and also the documentation. I think it will work then of course if it doesn't work there there are options for example the context 7 MCP uh
is something that can be used to instead of having the whole documentation to just query the documentation just pick the right things. Maybe you can uh you can ask yourself, do I actually need the whole documentation or do I just need uh in the context window just the main concepts? Okay. And then the details can be fetched with with an MCP server like context 7. So like
a hybrid approach. >> So the will automatically fetch the missing parts if I just put the link. Okay. If you want to uh read more, use this link. >> Yes, I would do that. I would probably if if I if I thought that uh I I was going to end to to to run out of the context window, I would probably select a part of the documentation
like uh say the tutorials uh the introductions, the concepts and so on >> with references to >> and then tell the when you need more. This is e either you you you say just look at the the API uh online or use the context 7 MCP server to get more information. Yes, I I I think that will work well >> because I my approach is to ask
AI about okay what the last version of the Drupal and it says >> uh uh for 2024 it's Drupal 10. I don't I don't know I know nothing about Drupal >> And I afraid to ask it to produce migration to Drupal 11. They have no idea about what is Drupal 11. >> Yes. Yes. And and I saw that. Uh so now now the the the followup is
um I I've asked uh the the AI about the latest version of Drupal and it said of course Drupal 10 but as we know it's Drupal 11. How can we solve that? And yes, there are differences and yes, there will be surprises for the eye, but uh for example, something that I suggest the eye is I I know I know you don't know about Drupal 11, but
you actually have the source code >> there. So have a look if you need to check for a method and so on. >> Okay. >> Yeah, thank you. >> Anything is a question there. >> So actually I have my my reading glasses which I cannot see anything. So you said that uh sometimes the agent would mess up uh the base working in the Drupal 7 instead of
the Drupal 11 and all of that. So I'm assuming that you had two code bases close to each other. But I wonder how do you organize all this documentation the agents and everything along with project in a way that you can persist that in the code base or was separated or how do did you organize it? >> Yes. uh I organized it like this. I had a
uh root repository and inside that I had all the BMAD folders. BMAD works with two folders. One with BMAD itself which is uh all the prompts and all the data from BMAD and the other is BMAD output with all the artifacts about your project. So I had this repo with these two folders. Then I had two more folders with the Drupal 7 and Drupal 11 uh repositories.
Sorry, I didn't I didn't I didn't u uh repeat the question. The question is how to organize the the the folder structure. >> You can control the structure if you >> Yeah, I'm running out of time really. But yeah, I really imagine uh the the root the uh root repo was the tobad folders then Drupal 7 Drupal 11. Okay. And then with with uh the g ignore
I was saying but these two are also repositories Drupal 7 Drupal 11 and so and after I I underline yeah look where we are committing okay then we started working well >> by the way if you have a lot of documentation maybe it's a good idea to put it into vector database instead of files because uh AI you you you can't add everything to the context you
can add but it will not be very effective. So maybe just index all the generated ND files and provide it as a ragu for the >> mhm this approach or not. >> Yeah. So the followup is uh you can also use a database or rag or something for AI instead of having the everything is markdown files or as static files. In my experience these statics files work
really well. uh yes uh they take u uh context uh but uh it didn't cause any trouble. Uh if you have like a huge documentation then yes you should probably look at if it's public documentation you can use the context 7 or other MCPS otherwise you should probably use uh some kind of rack. >> Okay, anything else. Okay, that's it. Thank you. [applause]
