AI Won't Steal Your Job—But It Will Make You (and Your Clients) Unstoppable

[00:00:00] Hello and welcome, everyone. Today we're going to talk about how AI will steal your job, make you unemployed, and take over the... sorry, wrong note. No, we want to show you how AI won't steal your job, and how it will make you unstoppable, how AI can empower you. First, a quick question: who is already using AI in some fashion? Most of you. Who is not yet using AI? And who is using AI already for coding? Great. So now we have an idea of who you are, and maybe you'll find yourself in one of the next parts.

[00:01:07] Who here are actual developers? A lot of developers. So the first persona is "I've never seen AI write code successfully." Someone I met here at DrupalCon actually said that, so, the last human in the repo. The next one is "I tried AI when ChatGPT first came out, it wasn't for me, too many mistakes." Some people still miss the old dialup days, but perception is changing. Then, "AI wrote that because it looks like it might work," which was a core committer, changing perception one line of code at a time. "Wow, this AI code review is actually really good," grudgingly impressed. "AI can refactor code and reduce complexity, that's amazing," amazed and already slightly unemployed.

[00:02:30] So here's what we'll cover today: why your organization needs an AI portal, how to be successful with AI, the process of good development, case studies, and how AI is always changing, where adaptation is key. I'm already good at this, and I almost cannot keep up, it's changing so fast. I'm Fabian Franz, VP of software engineering, robot and AI innovator, and rumor has it I never sleep. If you're not familiar with Tag1, we're a global technology consulting group focused on using open source software to solve the toughest problems of well-known organizations. We're best known as the number two all-time contributor to Drupal. Since 2001, our team has created many of the innovations that fueled Drupal's success, such as the taxonomy system and the Migrate API, and I hope we can keep doing that with AI, empowering more of the community to develop open source patches. If you use Drupal, and I'm pretty sure you do, you rely on Tag1 every time you update your site, because we manage the infrastructure and tooling used to build, test, and release Drupal on behalf of the Drupal Association and community.

[00:04:03] And this is Marco Molinari, a technical lead and AI enthusiast, and I heard a rumor that he even has an AI in his basement.

[00:04:14] Hi, hello, good afternoon. This session is divided into three parts. First, how we use AI internally at Tag1. Second, what we use to work with AI. And last, the challenges and lessons we've learned. So, how do we use AI? For everyday tasks: summarizing articles before reading them, checking documents or even contracts, though not only having the AI check a contract, but having it help, and then we check it as well. For research, which is what I mean when you go to ChatGPT and search for something, to generate reports and other small tasks. And for communications, like proofreading, changing the tone, or checking the tone. Pretty basic stuff, but think about this: three years ago, these things were science fiction.

[00:05:46] We also use AI every day for learning. It's very nice for deeply understanding a new subject or library. You can ask it to explain something in detail, to rephrase, to focus on a certain subject, to explain in simpler terms, or even to confirm that you actually understood something. It's amazing for learning. Another good use: you know when you've been on a project for a few weeks and there are things you can't ask anymore because the concepts or terminology feel too late to ask about? You can ask an AI those things, because it won't judge you.

[00:06:59] And note-taking. We're already seeing, in certain cases, an agent taking notes during a conference call and sending a summary of the notes at the end. If you haven't seen that already, you will soon. And of course, preparing sessions. But almost all of us are developers, so how do we use it for development? Code reviews, a lot, and again not as the only tool, but as an assistant; it's a lot like pair programming. Commit messages, I love AI for commit messages. I'll still look at it and change most of it, but it gives me ideas, instead of just writing "fix bug." Unit tests, great. Documentation, we'll see an example later. And as a code assistant, which can be code completion, which I'm not a huge fan of, or a chat where you paste some code and ask in natural language for a change.

[00:08:27] I'd like to bring a first example of an advanced code assistant we built internally, and this is about Tag1 Drupal 7, so it's a bit of advertising. You may know Tag1 has a Drupal 7 extended support program; we provide patches for Drupal 7 core and contributed modules. There's a tricky case: CKEditor. CKEditor 4 is not supported anymore, and if you want a fully secure site you need a secure CKEditor. You have two choices: pay for CKEditor 4 extended support, or upgrade to CKEditor 5. We suggest upgrading to CKEditor 5, and we provide an upgrade path. It has a lot of benefits, and it may help a future transition to Drupal 11. Everything works well, except custom plugins, something a client built for their internal use. That's an issue, because the plugin API for CKEditor 4 is completely different from CKEditor 5, and the plugin essentially needs to be written from scratch. It's a big deal and takes quite some time.

[00:10:04] So what we built internally is an AI tool. If you just ask any model to take a CKEditor 4 plugin and convert it to CKEditor 5, it will fail badly. But we built a tool using RAG, with certain examples and system prompts, and now it can do most of the work. We estimate it gets 80 to 90% of the work done, which saves a huge amount of time. A developer still needs to review everything and probably fix a few things, and we also have the LLM suggest, with comments, where you probably need to touch something. It's a huge help, essentially a supercharged boilerplate for the plugin, and all the time saved means it's much less expensive for the client. It works really well.

[00:11:25] This session is mostly about how we use AI internally, but I also want to mention what we built for clients using AI over the past year, which falls into four major categories. One is content manipulation. In certain cases there are really good reasons to build tools that extend existing content: changing the tone, retargeting for a different audience, remixing. To be clear, this is not a cheap way to flood a site with content; there are good reasons for it, like training, where you want to target a different audience.

[00:12:34] Another big area is content administration: translations, tagging, generating alt text for images, automatic summaries, suggesting relationships between content, and content validation at many levels, from proofreading and editing so text runs smoother, to high-level validation against business rules. Then there's content promotion, for example search; we've seen a massive shift toward AI search, plus search suggestions and recommendations. And finally, everything around community: comment moderation, spam, and so on. Each of these would probably be worth its own session, but I wanted to mention them. Another big area where we create things with AI is open source, and Fabian is going to talk about that.

[00:13:59] Thank you. Now comes my exciting part, because I'm going to show several case studies of how I've used AI already, to prove that yes, AI is ready for coding, and to give you some ideas. One of these is an actual core patch, for adding a cached placeholder strategy, which improves perceived performance a lot. There was one very tricky problem: we had one cache get and we needed a cache getMultiple, and that was non-trivial. It turns out ChatGPT was really good at it. I used a little trick: at that time it was ChatGPT and Grok 2, so it's a bit historical already. You can input the same commands and ideas into two different models and see where they converge, and then you know you're at a solid solution. They nailed it in thirty minutes, and we got a nice comment from people: "Wow, AI wrote it, that's cool."

[00:15:42] The next one was the open source OpenTelemetry PHP extension. OpenTelemetry is a new thing Tag1 is heavily investing in, which lets you profile your Drupal site and get various traces. Several of you have probably heard of New Relic or Datadog; now we can be very granular and say, I want to profile just the cache gets, or just views, so whenever there's a view on a site I get an entry in my graph. What this extension was missing was an observe-all function. I wanted to hook into any PHP function call to see what the overhead would be if I traced everything. The problem was I had never seen the code of that extension before, and neither had the AI, so we started at ground zero. Claude, in this case DeepSeek R1, and I came up with an architecture together, discussed it for a while, and then the AI gave me the code and I was the code slave, implementing it by copy and paste. The overhead turned out to be about fifteen times, so the observe-all idea wasn't feasible, but the PR still exists.

[00:17:50] What I really wanted for years was the world's fastest XHProf profiler, because a huge problem in Drupal performance profiling is that Drupal has these insanely long function calls, but in actual PHP with JIT they're really fast. As soon as you profile it, you think it's a huge problem. The profiler gives a very distorted image of actual performance. One way I often work in performance is to comment out a long function call, run it, and see it has no real impact, but the profiler will say it would save a second, which is misleading. So the performance of our performance tools matters too. Before this patch it was a 3.55x overhead; after, about 1.47x. In this case DeepSeek R1 wrote most of the code under my guidance; I also tested o1 a little, but DeepSeek got the better result.

[00:19:18] Then I had the full plan for how to implement it, and the question was which model could implement it for me. I tried a lot. Claude Haiku was especially fun: I asked for the whole file, and it said, "Are you sure you really want the whole file?" Yes. "Let me make sure one last time that you really want the whole file." Yes, please. Then it gave me a file with everything that wasn't changed removed, and I said, that's not the whole file. "Are you sure you want the whole file?" AI can be really funny. In the end, GPT-4o was the most stable model that could also process large files. Grok 2 was great and fast, and then it would just stop: no more output for you.

[00:20:57] Continuing: my colleague Andrei Mateescu was on a call and said he had a refactoring problem for Drupal Workspaces. Hank and Michael Meyers from Tag1 already talked about workspaces during the healthcare summit, and we had a session in Barcelona recently. A workspace is a way to have content staging for your site all within Drupal; it's wonderful for editorial teams and supported by core. He had a workspace association thing that he really wanted to call workspace tracker from the start, and his goal was that AI should be able to do that rename. It turns out just pasting the whole codebase into one model didn't work well, because Workspaces is huge, a really fine piece of software. So I consulted with DeepSeek R1, and it wrote me a nice AI-refactor Python script.

[00:21:53] One way you can work with the AI portal, which we'll come to in a moment, is that it exposes an API endpoint, so you can use it from the command line. This is a real-life example: a little bash magic to find all the files, put things into a lock file, and then it did its thing while I tested a lot of models. DeepSeek R1 was very slow to think about everything, so that wasn't what I needed. Again, ChatGPT-4o was the most stable, not over-thinking things or suddenly ignoring instructions and outputting just a section of the file. The script is really dumb: I get a PHP snippet back and just write it to the file, and I did the code review myself.

[00:23:41] Here's the actual prompt. We defined two variables, because at the time that was best practice; it's improved a bit since, so it's no longer best practice, but you can still use it. I told it to intelligently rename this class to this class, and to also handle the interfaces and the service name. I gave it extra instructions after it couldn't catch everything: ensure you do not rename the database table. That was the challenge, because the database table is conveniently also called workspace association, so a pure find-and-replace would never have worked. There was also a lot of documentation referencing workspace association and workspace tracker. The prompt worked really well, with a bit more instruction to output exactly one PHP snippet with the whole file, and if there were no changes, to output an empty snippet, which some models didn't follow.

[00:25:05] The next case study: now I'd smelled blood, because I knew the command line was powerful and I'd got my power back, out of the chat interfaces and back where I'm most familiar, the command line and vi. I wanted to do an experiment of 100% AI-written code. So I wrote a short OpenTelemetry PHP instrumentation trait that makes it much easier to set up instrumentation. The important thing is, yes, AI was able to write all that code. I had a lot of fun just running my little script, putting the prompt in a file if it was longer or inline, then running it, doing a git diff, committing, and going my way.

[00:26:10] Then, our most recent problem, and now we've evolved to modern times with Claude Code. We had the problem of the Redis module not playing nice with Redis Cluster. In the end it did a nice analysis, and in just three minutes and thirty-three seconds of API time and sixty-nine cents of cost, it gave us the answer, which was really good, because Redis is a complex codebase. Then we investigated a little ourselves and asked it to change it, and for around $1.33 we could solve the problem we'd been working on for a while. Claude and our own analysis were spot on: transactional support was breaking things, and changing it to a pipeline made everything work. We'll be blogging about that; Narayan, who's also here, will write it up, and you'll learn how the Redis module is really only usable with one Redis instance by default, but with a bit of magic setup you can use it with Redis Cluster.

[00:27:53] The last thing: Grok 3, right now, and this might change tomorrow, has a syncing mode that's a perfect mirror. You tell Grok 3 what you did or a situation you're experiencing, and it mirrors your thoughts back to you in an easier-to-understand way. That's great, because you have complex thoughts that aren't quite making sense, it mirrors them back, maybe even misunderstands some, you say no, you got that wrong, it mirrors it again, and you get much more insight into what you want to do.

[00:28:42] Now the second part, the Tag1 approach behind the scenes. We decided that the best way for our organization is not to have a developer pasting confidential data into ChatGPT, but to have a proper AI policy and to empower developers with internal tools and guidelines. For that AI portal, we use the Open WebUI portal. It's open source, the UI is familiar, similar to ChatGPT and Claude, it's always improving, and it has plugin possibilities. You can have multiple models at once, which I really love: you start a chat with DeepSeek, it goes into a corner and can't finish, so you switch to Claude and it continues with the same context. You have custom system prompts, which Marco will talk about later.

[00:30:12] Those are all the models we're providing right now: OpenAI, Llama, Mistral, Qwen, DeepSeek, some reasoning models, external, internal, and local. One thing about internal models: you don't want to send your data to just any external provider, so you want to deploy on your own internal hardware. You can rent hardware, which is expensive, or use on-demand models in Azure AI, AWS Bedrock, or GCP, running in your own cloud account. That's important, because you can say this is our infrastructure, so you know it's hitting your servers, and even an on-demand instance is still doing some kind of isolation. On demand we have Mistral Small; on Azure you get OpenAI, even faster than on OpenAI's own infrastructure, plus Llama 3.3 70B and DeepSeek R1 free; on the GitHub marketplace you get Claude; and in Google you get Gemini. So you get them all.

[00:31:32] My tools evolved a bit. I started with ChatGPT and Grok, because those were the chat interfaces available. Then Marco and Jeremy brought me to Open WebUI, and a whole new world opened up: my own chats, everything local, switching models, customizing, creating reasoning models. Later I even wrote some plugins, like the newest Claude 3.7 pipeline, and an AI-refactor tool for the command line, where I got my power back. Then Claude Code came along, and that was even more powerful.

[00:32:21] The real technical approach, and this is just my opinion and my workflow, is that you think of what to do next, code just the next step, test that little bit of code, and then commit it, and continue. For me, testing even means a print_r to see it gets the right output; at that point the code works to there, and I can continue. The advantage is that we can move from that iterative development workflow into an AI-augmented one, because we have models that can think of what to do next, like Grok 3, Claude 3.7, and DeepSeek R1 or o1 and o3-mini-high; models that can code the next step, like GPT-4o, still really good for coding, Claude 3.7 and 3.5, and Llama 3.3 70B. Claude was one of the models that often failed at refactoring whole files, but for little steps it's great. Then you test the code, which is more the work of autonomous AI agents that are coming up, and what no one talks about enough is sandboxing: everyone is giving full access to their machines. In my opinion it should be a mini-deployment of the code in a secure Docker, where the code is run, tested, and reported back by the agent, and then the code is reviewed again by reasoning models. You want multiple models as experts working together for code review.

[00:34:24] But everyone can start with an AI-augmented development workflow: think of what to do next, code the next step, delegate that step via Claude Code or a refactor script, test the code manually, then commit it, and you still get a nice, clean commit history, with none of the mess you hear about. It just works. The one problem with my workflow is that AI models are slow and costly when outputting the whole file again. So I'm thinking about chunking the file, getting an implementation plan from a slower model, and applying diffs per chunk with very fast models. My highest frustration with Claude Code right now is: do this change, okay, apply, and then wait, and wait, and wait. If there were a snappier way that used the different speeds of the models better, it could be much more fun.

[00:35:43] Now, the tools I use. Of course I use the chat in our Open WebUI instance. I use deep research a lot; if you haven't used it, please do, you'll find it on ChatGPT, Gemini, and Perplexity, and for whatever reason they all decided to use the same name. It's an agent that takes some time, does research for you, and prepares a report; incredibly powerful, and it can take ten or fifteen minutes. Also NotebookLM, check it out if you haven't. And I use PHPStorm, in particular a plugin called ProxyAI, previously known as CodeGPT. You can use it with any provider, remote or local; personally I use it most often locally with Qwen Coder. You get a chat inside PHPStorm where you can reference parts of the code or files, a code assistant, code completion, which I'm not a huge fan of, and you can generate commit messages or chat about the GitHub history.

[00:37:29] And then there's the elephant in the room. Who has used Cursor or VS Code with Cline? Really, so few? So some of you may have a smart friend who told you there's a tool that lets anybody code without knowing how to code, and you'll be out of a job soon. This is the tool they were referring to. In the case of Cline, it takes control of VS Code: it can read and write files, run commands in the terminal, and browse a site with its own window. While it does all this, it chats with you about what you want to do, and it keeps a human-readable documentation that it uses as a reference for the next task, so it keeps a brief of the project, a change log, and so on.

[00:38:51] I wanted to try this recently. A friend of mine has a website, not a Drupal site, sorry, a WordPress site, and I have zero experience with WordPress. She asked if I could help with some changes, and I had no idea what to do. So I took a backup of her WordPress site, downloaded it locally, put it in a folder, and just asked Cline to make it run locally. Cline ran some commands, looked inside the snapshots, told me this is the database snapshot and these are the files, and unpacked them. Then I told it I had DDEV, and it created a new DDEV environment. After a few minutes I was just watching, and the site was running. Actually, it tried to run in its own browser, hit an error, said "there's an error, let me investigate," found a configuration error, fixed it, and then the site was running, and I did nothing. Then I had to change the admin password, which I had no idea how to do, and it could do it. It wrote a simple plugin to change a section of the site, helped me with theming, which I'm definitely not good at, and did exactly what I asked.

[00:40:41] I can tell you these things, but I also have a very short recording of Cline doing one of these tasks. I edited it, so some places are faster and some slower. I'd already asked a question, and then it collected the memory of the project, kept showing me how much I was spending, started analyzing the problem, the double-quote escaping I wanted fixed, found the root causes, actually two of them, and proposed a solution and an implementation plan. Then it asked me to switch it to act mode, and it started writing the code. It's faster than me just at enlarging the window. It fixed the first bug, went on to other things, asked if I was okay with the change, I said okay, save the file, it found another issue, fixed it, and kept going while I kept clicking save. At the end it updated the memory with the change log, and I was sincerely like, okay, I'm done, I might not have a job.

[00:42:38] Is that true? Could anybody have done this? In other cases it got stuck. For example, it kept using a certain CSS selector, and I kindly suggested it use another one, and it said yes, let's do that. Could a non-developer have suggested another selector? Probably not. So when you read that these tools are amazing but stop at 80 or 90%, that's probably what it means. There was also some convoluted logic I asked it to simplify. But it was incredibly impressive, and I strongly recommend you have a look, because it's an amazing tool.

[00:43:39] So, lessons learned and challenges. First of all, LLMs are not humans. They may seem like humans, and they have an interface that works really well with ours, but there are big differences, and if you're aware of them the experience will be much smoother. They're much better at focused tasks; they have trouble holding the big picture of a project, even though tools like the memory in Cline are making this better. One issue, in my opinion, is that they're too accommodating: they don't argue with you much, they tend to agree, they were rewarded to agree. So my sincere recommendation is to change your system prompt and ask it to kindly challenge you; this really helps.

[00:44:44] Another thing: always be very verbose. Take your time; an LLM won't be annoyed. Use full sentences, and don't use vague pronouns like "it" or "they" if it's not clear what they refer to. Be very explicit; LLMs don't read minds, and they won't be mad if you're a little verbose. Use examples as much as possible, and provide a lot of context. With reasoning models in particular, always remember they are not chat models; they're significantly different, and they need a big prompt with a lot of context and information. Personally, I've easily spent thirty minutes on a single prompt for a reasoning model. It's more or less like writing a good ticket, so if you write a good ticket, the reasoning model will work much better, and there's a good reference article on this.

[00:46:05] Hints: should you provide them or not? It depends. If you give hints, the model will follow them, so provide them only if you're sure it's the correct path. Otherwise, just explain the problem and let it search for solutions. You should also thank them, because an AI takeover is coming soon, no. There are some studies suggesting that if you thank them, it routes the model toward more polite sections of the neural network, and maybe those sections are more useful. Also, it feels good, so I thank them, I don't care.

[00:46:47] And something very important: go back in history. If the model misunderstood what you were asking, don't correct it in the next reply; go back and edit the previous message. This way you keep the context clean. It's also something you can't do in real life, so do it with the models, you can do it here. Always keep the context in mind; it's a limited resource that needs to be kept clean. When you start a new task, always start with a new conversation. And the last thing: learn to give up. When the model starts hallucinating, and it will, going in circles and suggesting the same code again, give up and start from scratch with a cleaner context. Consider shaking things up: rephrase, provide different context, and if the model was confused by the version of a library, upload the documentation, the API, or even the source code.

[00:48:11] I'll very quickly, since I see Fabian breathing here, talk about the ethical and legal challenges. You need to be very clear with your clients: first, ask them if they're okay with you using AI, and be clear when you use it in PRs, reviews, and code. Be mindful of the data, both the code, especially your client's code, and even more so personal data, if it goes to cloud models. Review, understand, and test the code from the models, or you will pay sooner or later; models make mistakes, and if you don't do that, you lose importance and become irrelevant. If you review and deeply understand the code and test it, it will work much better.

[00:49:14] We will also need new UX patterns. For example, we've seen projects trying to apply search patterns to AI, and it doesn't work well; I believe there will be a lot of interesting, experimental, fun work in this area. So where are we? Is this advanced chess? Advanced chess is something Kasparov suggested in the '90s after he was beaten by Deep Blue: have human players and chess engines work together to make a very powerful player. It was an interesting idea, but after a few years very powerful engines like Stockfish were introduced, and maybe they turned the human into something irrelevant. I've researched this, and there's still a lot of debate: some say the human is now irrelevant, others say humans can still add a lot to chess.

[00:50:38] I think it's a good metaphor, and I also think the problem space of chess is much more limited and defined than programming. So if advanced chess is still debated, I believe that with programming there's hope we won't be irrelevant soon. Cooperation is the right path. The images we displayed before the session were all generated by AI, both the idea and the drawing. They weren't great, and I did nothing; I asked for twenty funny images about AI, gave a few hints like "create something with Drupal," and not much more. They didn't quite work, frankly, but there were good ideas, so if I'd worked on them a bit, something good might have happened.

[00:51:46] Expect changes. Most of what we said today will probably be obsolete in a few months, I'm sorry, that's just the way it is. Two hours ago, OpenAI introduced a new image model that probably would have created better images for the first slide. So keep investigating, and it's very possible that not just new models and tools but even new architectures, like diffusion or JEPA, will be interesting. For the few of you not yet using AI, if you take one thing from this talk, please try again. Next time you're looking for something on Google and end up on Stack Overflow, try asking one of these tools instead.

[00:52:47] Fabian, real quick. As Marco said, review, understand, and test all AI-generated code. You don't want to be part of the big AI takeover, when all the AIs decide to send commands to all the autonomous agents running. I really think it's important to be a little careful; while models, especially Claude, have invested a lot in AI safety, which is why they provide Claude Code, it's also important to be a little paranoid, and not just have AI create a huge PR you don't understand, push it to production, and then the site breaks under certain circumstances. Good development practices are still needed. But we're definitely at the point where a senior can advise a junior with a ticket, get some nice code back, review it, and push it as a PR.

[00:53:53] Two more things about keeping history clean. One of my frustrations with ChatGPT was that if you removed history, you lost everything before it. In Open WebUI that's not the case; it forks endlessly, similar to how Grok works, so you can have as many fork trees from the same beginning as you want, and it really makes sense to go back in history and start from a different point. The other reason you want to do that is cost: I once worked with a very long context that I continued on and on, and suddenly I had no credit left. I had $20, which is usually plenty, but because I kept sending this huge context again and again with no context caching, it got expensive really fast. That's also why I still believe little tools like a refactor script play a role, because they always start fresh with the code and don't carry all the context baggage.

[00:55:10] What's really important is that AI is a tool, and it can make you smarter or dumber; it's up to you. You can be lazy and delegate everything to AI and lose your ability to program, or it can make you a better programmer, code reviewer, and developer. One thing I do is switch things up: sometimes AI is the coder, and sometimes I'm the coder and AI suggests what I should do. That keeps me fresh and my own mental model well trained in coding. That's really important, using AI to empower yourself.

[00:56:00] Because AI cannot only change the way we develop code, it can also change the developer. AI is here to stay. You can use it to make you and your team more effective, or you could just chop wood, says the pragmatic lumberjack. Thank you very much. We're way over time, but if you have questions, come up to us or contact us by email or on social. Thank you.