Development, Digital Accessibility and AI for Ecommerce Agencies

Niels:
I am Niels de Blaauw, and I’m a WordPress enthusiast with a development background. I work as the Technical Director at a Dutch WordPress agency called Level Level. And with me today is Marius Vetrici.

Marius:
Hi everyone, and thanks for the intro, Niels.

Niels:
So to get started, I’ve been in web development for over 13 years now and got started with WordPress eight years ago at Level Level. There, we make bespoke WordPress websites for e-commerce, Dutch government, banks, NGOs, and more. We do that with a focus on digital accessibility. Other than that, we have an e-learning platform for accessibility called The Collective and maintain open-source software such as the WooCommerce testing automation library. And Marius, you are the founder of WordPress Riders, right?

Marius:
Oh yeah, actually I’m the founder of WordPress Riders Agency and e-Commerce Tools plugins. We have a child business, which is building and selling WooCommerce-based plugins. In terms of background, we are a software development company. We started with WordPress about nine and a half years ago, currently serving customers in Switzerland and in the US. We help build and maintain large web portals, e-commerce platforms with WooCommerce, but also with Shopify. We also work with LMSs. Besides web development, I have an interest in AI, do more and more research on this, and build AI-based solutions and provide advisory on how to meet with AI. With WordPress, I jumped on the WordPress boat, I think, 15 years ago when I started blogging. And 10 years ago, as a freelancer, I started serving customers, and then slowly that freelancing one-man show converted into an agency.

Niels:
So there’s a lot of different things that you’ve done to grow into all of these roles, right? Was it natural for you to grow into this?

Marius:
Yeah, it was organic indeed. It started as a one-man show; currently, we’re 22 people. But somehow, I was lucky to build on prior experience. I had another software company for 10 years, building products using .NET technologies, document management, and inventory management. So I kind of leveraged all of that into this conversion from being a freelancer to running the agency.

Niels:
One thing we have in common is that we both come from non-WordPress development backgrounds and then moved into working with WordPress. I think having prior work knowledge of WordPress helped me hit the ground running, and with quality documentation, the risk for beginners was quite low. It was easy to get into, even though the documentation has improved quite a bit over the years. So how was that for you? Were there any big hurdles getting into WordPress?

Marius:
I don’t think there were any hurdles because the learning curve for WordPress was so much lower before JavaScript and Gutenberg. It used to be much lower than with other technologies. So I don’t think there was any hurdle. I was pretty lucky to ride a couple of waves. I had the technical background, and it took me one month to get up to speed with WordPress and actually start serving clients as a freelancer, thanks to my prior 10-plus years of experience in coding. Then, I was lucky to join the early stages of the Codeable freelancer platform, which gave me a steady flow of customers. It also educated me on customer communication and setting expectations. So yeah, that was a very fortunate combination of factors.

Niels:
Getting into WordPress, at first, I was amazed at how much it did out of the box, mainly around data management. Before WordPress, I must have written the same “Is this an email address?” and “Is this input field actually a valid URL?” validators hundreds of times. WordPress just makes these repetitive things so easy. It frees up so much time.

Marius:
Again and again.

Niels:
Yeah, so you can make WordPress as difficult as you want yourself. A lot of best practices from the rest of the PHP world have been adopted now by WordPress developers like our agency as well. So things like object-oriented programming, static analyzers, dependency injection, design patterns, unit and integration testing, code reviews, dependency management with Composer—all these things are part of our current workflow now. But there are a lot of moving parts, and the community is providing a lot of go-to plugins that might not be up to our standard. So how do you manage this?

Marius:
That’s a very interesting perspective, and thanks for sharing. I was actually talking to scores, dozens of hardcore developers, non-WordPress developers, and I keep hearing them say the same thing again and again: “Oh, WordPress, it’s not even object-oriented, no design patterns. This is below my current level.” I was like, okay, that seems like an opportunity for us. So that’s why I’m very happy to meet a like-minded fellow like yourself.

Niels:
Yeah, it gets messy fast.

Marius:
And I actually see a bit of a challenge here. As you mentioned automated testing, from my perspective, I keep seeing this challenge. Again, comparing other technologies with WordPress, with Java Enterprise Edition, or maybe with .NET, all the updates and changes are mostly being managed by somebody, a centralized entity, which is obviously good and bad. But here, when you own a website—I’m not even talking about building a website at an agency—when you are a client and you have at least 20 plugins, let’s say at least 20 plugins, each of them having their own version, you are basically responsible for the integration testing of those plugins. You are responsible for making sure that they work. And of course, at the end of the day, you hire an agency to do that for you. But when you have so many moving parts, each of them being built by a third party, each of them releasing new versions randomly, I mean, this is an amount of work that probably not many website owners are really aware of. How do you deal with that?

Niels:
So one thing we do is we rely heavily on integration testing within our projects. We test critical parts of a website both through automation and manual testing. We mention to a lot of clients that issues that pop up for one customer or lessons learned from the next project benefit all our clients because we manage more sites like them. So you’re on both sides of the equation, right? On one hand, you are managing an agency with these issues related to plugins, updating, and compatibility. On the other hand, you’re building plugins yourself and can only test so much. So how do you balance this?

Marius:
Actually, that’s a very good question. Before we decide to build a feature for our plugins—by the way, the plugins are related to subscriptions; one of them is called “Buy One or Subscribe,” and the other one is called “Self-Service Commerce Subscriptions”—before deciding to launch a new feature, we always think about the total cost of ownership of that feature, including the future maintenance and updates to that feature. When you look at a feature through that lens, if it requires some integration with third-party plugins, let’s say with Woo Bundles or Woo Composite Products, we know that’s going to factor in an exponential amount of work and updates and maintenance because those plugins will randomly change. So to answer your question, we try to build our features as self-contained as possible, with as few dependencies as possible.

Niels:
And with the plugins that you mentioned, they’re mostly plugins built by Woo with the Automattic team behind them. So these are somewhat stable, reliable products, even though they’re moving fast and changing things. There’s a bigger picture, and there’s also, of course, a single-entity builders that create a product and then abandon it after two or three months, which you have to take care of.

Marius:
I’m not even talking about those who abandon it. And that’s a very good example with Automattic. Even with Automattic, you get certain updates inside the code that just come, they just hit you. It is what it is. I’m not saying it’s good or bad; it’s a fact of life. But someone needs to take care of all of that. And you mentioned before our talk that you rely heavily on automated testing, the shopping carts, and making sure everything actually works. How are you doing that? Maybe you can elaborate on that a bit.

Niels:
So we’re talking about total cost of ownership for our customers. It’s almost always more expensive to have a failing critical process. People can’t buy the products on the website because they’re spending on advertising. These people are reaching the website trying to buy a product, and if things don’t work, it’s not only missed revenue, but also they’re incurring costs to get these customers. So keeping the business-critical processes alive is the number one priority for us. When we’re talking about having 20-plus plugins that integrate with each other and then having the bespoke layer on top of it, like we do for most of our customers, we really need to make sure that everything keeps working. One of the things we do is we have an open-sourced testing library called WordPress Browser WooCommerce, and it’s an extension on top of WordPress Browser, which allows WooCommerce developers to write tests in the same way that you would for WordPress core.

So the factories from WordPress core unit tests, like this->factory->user->create or this->post->create, we also make the WooCommerce functions available in the same manner. So now suddenly there’s this->factory->order->create, or product->create, or coupon->create, or shipping_zone->create. All these sometimes difficult-to

-test things, like “We’re shipping to 20 different countries, but they all have their own business rules,” are automatable through this library. We create scenarios for every single feature that we build to keep them tested through integration so that we make sure that every single part of the chain of plugins is working as we expect. So when there’s an update to a Cost of Goods plugin, we can update it, see if the test fails, and then fix either the way we integrate with it. Another thing that guards us from these unexpected updates—and this is mostly related to changes in the programming interface—is that we’re heavy users of PHPStan, like the static analyzer, which shows us “This function is deprecated,” or “This function has a different parameter signature after the latest release.” So there are a lot of safeguards to capture issues early. That’s one of the most important things that we’re working on. And I think one of the things we mentioned in our pre-talk is that you don’t, or you have fewer of these issues when comparing Woo to other platforms like Shopify. Do you have any experience with Shopify and the direction it’s going as opposed to Woo and the direction Woo is going?

Marius:
The experience is, as with anything else, it’s about changing the problems you deal with. When you move from one country to another, you actually change the problems you’re dealing with. Same with changing platforms.

Niels:
I think you’re not actually solving the issues; you’re just moving to different issues.

Marius:
And sometimes you’re choosing to solve some unknown issues you weren’t even aware you were going to have to solve. But getting specific about Shopify, I kept watching the Google Trends, WooCommerce versus Shopify, for quite a while. For the last one or two years, I was writing some articles on that and performing some analysis myself. The difference is like five to one, five times more searches for Shopify than for WooCommerce as reported not by individual keyword searches but by Google Trends. And this eventually translated into almost a change of market share. It depends on the source you’re looking at, but they’re both on average around each at 25%. Some would report 20 to 30 WooCommerce versus Shopify, some would say 30 to 20. And in terms of problems, I think Shopify has created an excellent user experience team, great product managers. Basically, they have built an excellent wizard. If you remember the old-time wizards like a step-by-step wizard, they will just ask some questions and then they’ll point you in the right direction later. WooCommerce picked up as well. They came with their own wizard that pops up and helps you.

Niels:
For the first setup experience.

Marius:
For the first setup, but yeah, they came in after Shopify, as per my knowledge. But still, I think the Shopify experience is better. So with WooCommerce, those who are in the WooCommerce community, I think we still have some things to learn from the other guys.

Niels:
One of the things that impressed me about Shopify is the last two steps in the checkout experience, the way you check out. A lot of forms are pre-filled based on things you might have entered on other platforms. For WooCommerce, you’re really dependent on the payment gateway you’re using to fill in stuff automatically. And the Shopify platform makes this a cleaner experience in my eyes for the end user. So I think there’s a big opportunity for payment gateway providers to look at how Shopify is doing these last two steps from selecting the payment method and paying itself and copy it, just steal it. It’s better.

Marius:
I would guess that they got, I won’t say they stole it, but they got inspired by Stripe, which was the first in the market that actually built an excellent payment experience. And let’s face it, that checkout process is the reason to exist for the shop, for our work, for our agencies when we build e-commerce. And that little chain at the end is not perfect.

Niels:
We’re actually talking with a couple of payment providers because we also have an accessibility consultancy business. We have three certified accessibility professionals on our team, and we’re now talking with several payment providers, payment gateways, to get their checkouts accessible for people with keyboard accessibility issues or people using screen readers. Every year, we do research on the biggest e-commerce platforms in the Netherlands and how accessible they are. For eight out of 15, you are not able to reach the final steps of the checkout with just the keyboard. So there’s a big opportunity for a lot of WooCommerce shops or WooCommerce shop owners to get a bit of a competitive edge because if you are the one doing accessibility or getting your checkout accessible, you’re blowing away the competition on other WooCommerce shops or on other platforms.

Marius:
And besides the competition, there’s the legal compliance in most of the countries.

Niels:
And especially next year, there’s the European Accessibility Act coming through, which forces European countries to have legislation for the accessibility of web shops that make more than 2 million in revenue a year or have more than 10 employees. So next year in June, there’s going to be pressure on everyone to make sure that their web shop is accessible. And I’m expecting a lot of shops to handle this the same way that they did with the privacy legislation—look the other way for as long as possible until it’s too late and then start implementing it. Our experience teaches us that the process of getting your organization up to speed with accessibility, making the changes needed, and making sure that it’s legally compliant is a process of several months. So if it’s going to be next June that you have to be compliant, you’d better start now, or you’re going to be too late.

Marius:
I actually have positive examples on this end. One of our customers invented and patented a device, a gear, they’re manufacturing it for professional tennis players and they’re selling it all over the world. A few months ago, we had this talk with them, and we got a couple of people on our team certified in accessibility, and we had to implement quite a few changes there just so they are prepared. But they have done it not because of the European Act—they are based in Europe, but outside of the EU—they have done it literally for business reasons.

Niels:
That’s what I always say. The stick is the European Accessibility Act—you have to do it because it’s the law—but there’s a huge carrot. I don’t understand how every marketer is focused on performance. Everyone likes a fast website, right? Faster is better. Google rewards fast websites. This is the mentality. But for accessibility, it’s exactly the same. An accessible website is a benefit for everyone. If you break your arm, you’re temporarily disabled, and you have to find another way to use a website that you like to shop on. People who can use accessibility features spend longer on your website. User engagement goes up, and a lot of the changes that you’re making are not even visible to the end user. They’re just good UX, good user experience that you’re building. Not having to press tab 120 times to put something in your cart or having the autocomplete for your address actually make sense. So it’s a process that benefits everyone, and there’s a very large segment of people that actually benefit directly from a better accessible experience.

Marius:
And I was recently talking to somebody here in Switzerland, and they were so frustrated with a website from a pretty big company here called Manor because they had a really hard time checking out. They said, “Hey Marius, why won’t you reach out to them and tell them this and tell them that?” And that was someone who wouldn’t normally need accessibility features.

Niels:
We work with the biggest retailers in the Netherlands. These are companies making hundreds of millions in revenue every year. We’re testing, like A/B testing, the accessible variants as opposed to the non-accessible variants to gather data on how much more effective it actually is to have an accessible “Add to Cart” button or an accessible search function.

Marius:
And on the accessibility and automated testing, we played a lot with some legacy frameworks. Years ago, we started with Codeception, and after writing quite a few thousands of lines of code, we eventually realized that it was a waste of time—it wasn’t reliable. You would execute the same script two times in the same browser, and you would get different results and errors. So we eventually switched over to Cypress, which is client-side JavaScript, and that worked pretty well for us. So now, for certain clients, we do run batteries of tests as well just to make sure this integration problem doesn’t fall on their shoulders and that we can give them peace of mind that their checkout still works. You also mentioned in the beginning that you work for some government websites and large e-commerce websites. Maybe you can share a few notable projects?

Niels:
So for e-commerce, we’re doing a large project, which is a web shop in 10 European countries that makes plastic sheets to measure. You can order online different shapes of plastic sheets, and we’ve integrated the WooCommerce store from these 10 different shops into a back office where they’re actually on the factory floor, seeing the orders come in live on the table saws and on lasers. We’ve made an interface where all these orders are combined and then produced from the tablets in the factory. So it’s really a full-service, full-flow web shop. And for governments, yeah, we’re working for our local governments in the Netherlands, state government, and the national government on a couple of projects. What’s interesting is that we’re learning lessons from e-commerce that we can then apply to the government because needing a new passport is much like the same checkout flow that you would see in the awareness and decision stages, but there’s no competitor on the other side.

But you still need to guide people through this funnel, and you need to get them to the next step because if they’re not

entering the next step, the intent is really high. So if they’re not going from starting the application form to finishing the application form, there’s obviously something confusing about the form. So there are a lot of lessons that we can take from these different types of projects in our portfolio that we can move to other industries, businesses, and verticals in the same way. There are really high security and privacy rules and expectations for governments, banks, and insurers. We’re taking the lessons we’re learning there and applying them back to e-commerce to make sure the processes are done in a way that updates are safe, and we have data reliability—all these types of lessons learned from this vertical that really appreciates the security aspects of WordPress development, and we’re moving it into the “move fast, break things” part of WooCommerce development.

Marius:
WordPress development done right.

Niels:
Agree with you, right. Yeah, yeah, yeah. That’s basically it. That should be the tagline of the agency—WordPress development done right. So how is this experience for you? Because obviously, with the very broad spectrum of customers that you have with the WooCommerce plugins, you must have a lot of different experiences between types of customers.

Marius:
Yeah, it’s pretty broad, and it ranges from shops selling dog food, pet food on a subscription, or even toothbrushes on a subscription, and so on, to some very, very high-profile customers such as Panasonic. We actually built their e-commerce platforms for a couple of countries, and that was an extremely challenging project to be built with WooCommerce because they wanted tons of features that you would normally get for a ton of money on other platforms—more expensive platforms like Magento, the Adobe experience, or maybe a platform from SAP. But here they wanted to get all of that on WooCommerce. Basically, all the learnings and the knowledge gathered from more than a thousand projects had to be condensed into the Panasonic website and reviewed for the code of some of the plugins because they actually wanted us to use some plugins in order to “move fast, break things.” Now, the Czech Republic and Poland are running on WooCommerce, which is something our team is very proud of.

Niels:
Can you share something about what your review process looks like for onboarding plugins made by third parties?

Marius:
Yeah, sure. We have a list of preferred plugins, which we have reviewed the code for, and we do monitor the code quality of the plugins using PHP CodeSniffer with a WordPress set of rules for security and code formatting and compliance. We also use a couple of tools to check the security of the code besides manually reviewing it, but it’s always good to use things such as Snyk to go through the code and other tools. Actually, building on this need of our customers—the need being, “Hey, is this a good or bad plugin?”—we’re about to launch WPPluginReview.com, which will be a website that will automatically review the quality of the code using DevOps approaches, like automated approaches, and assign certain color codes just like with fridges—the energy label for the fridge, A, B, C, D, or for buildings. We’re building this for plugins so that a non-technical person will immediately be able to grasp whether this is a trustworthy or not trustworthy plugin.

Niels:
So you’re making the process of selecting a plugin and comparing different plugins in the same space easier by showing that this has a “D” score on your automated tests for plugin quality.

Marius:
Yeah, and going beyond just comparing features because features are already being compared all over the internet, but comparing the quality of the code for now requires developers’ time to actually go through the code and review it. So yeah, we’re trying to automate this part.

Niels:
Yeah, so one thing we’re also taking into consideration is that we internally have a point system that we give to plugins, and it’s partially based on the hard factors that you’re sharing. Does it comply with PHP coding standards for the WordPress standard? Does it have any known security issues—these kinds of things? But also the…

Marius:
Number of database queries is also an important factor.

Niels:
And if they have filters and actions available to hook into how they’re doing things, right? Because it’s easy to do things the wrong way in WooCommerce. So seeing these positive signals on plugins, and we also take into account some soft factors. Are they continually updating WooCommerce plugins? You have this README.txt property called “compatible with” or “tested up to.” Are these up to date with the current version or maybe the previous? Because if it’s not, it’s going to be like a score penalty for us, deducting points from the plugin. Or do they have a clear revenue or monetization component? If they don’t, it’s going to be a liability for us because the creator might abandon the project if they don’t have a financial motive to continue working on the project. So we have these couple of soft factors that we also take into account when grading plugins. From this, it gets to a score where we say, like, 75 points or above, we’re like, okay, we don’t have any serious concerns, let’s do this. And then 75 to 50 points, we go to the customer and advise them: “These are our concerns. Do you want to push on and bet on this, or do you want to reconsider or compare other products in the space?” And then below 50, we highly discourage our customers from using these kinds of plugins because it’s going to be a business risk.

Marius:
Yeah, that’s a clever way to do it, to rank the plugins. Changing topics a bit, before we wrap up today—you are on the very technical side of things, and currently, I run the commercial side of the business—I would be curious from your perspective if you were to… two things I have to ask you. If you were to give advice for other agency owners who don’t have a CTO by their side, when should they consider getting a CTO by their side? At what point, at what size of the agency, when is this a good time? And the second thing is, what would you expect, or ideally, what would a CTO of an agency expect from the CEO to be or to have in order to foster the best possible collaboration that is the goal?

Niels:
Yeah, so one of the things that makes my job as a Technical Director easy is that we have a very clear focus on WordPress and WooCommerce. There are all these new technologies constantly popping up around, for example, headless SaaS that do one thing really well. And then a lot of people get hyped up by the availability of these kinds of technologies, jump on board, and then figure out, like you said before, that you’re not solving issues, you’re just having different issues. If you have a very clear vision of the core technologies that you use and a very stable base of things that you develop on, then you can have some freedom putting things on top of it. So if you’re always working with WordPress and WooCommerce, or if you’re always working with Shopify, then you can move some parts around without endangering your business or having to retrain your whole company. They call it “building” if that stable base is missing.

Marius:
Exactly. It’s a stable base. It’s about building and consolidating probably.

Niels:
Yeah, and also, once you have that stable base, it’s easier to tell the story to customers, to either employees, about why you are choosing X and not Y, why you’re choosing a certain technology and not chasing the other, right? Because it becomes easier to make choices for certain technologies. And then on the opposite side, when you don’t have a clear vision from the get-go about what is the stable base and what are the dynamic, movable parts, then it’s time to get a CTO because then you need someone to figure out what this stable base is going to be. What is going to be the technology that we can build on now that’s still going to be available and relevant in five years? What are the trends going to be in developer experience, and how do we make sure that we don’t fall behind on the developer experience while maintaining the stable base? Right? These are the tasks that, in my eyes, the Technical Director has mostly—keep things predictable but also steadily moving in the right direction regarding developer experience, stability of the platform that you’re building, and customer experience. And then, as the second part of your question, since you have a mostly technical background too, but you’re now more in the CEO position, I would say the hardest thing for CEOs and Technical Directors is balancing innovation with business goals. On one hand, you’re trying to create new things, create a “wow” experience for your customers. At the same time, you have to move into a space where things are known, and not everything is new every single time, which costs a lot of time and reduces predictability. I think the most important thing a CEO can do is be very clear on what the expectations are regarding business goals because this also determines how much room there is for innovation. How is your experience, since you have both experiences, in managing and balancing these two parts?

Marius:
I came to realize that both are very important—balancing both the short- and medium-term profitability but also the long-term ability to stay in the market. So for now, I’m just allocating my personal time with a percentage such as 20 to 80—20% for innovation. Actually, this percentage was valid one year ago. I was doing roughly one day per week for innovation and strategizing and market research, and 80% doing the day-to-day stuff. Ever since I moved this year to Switzerland, we actually have a new CEO. It’s our former CEO. So

I’m not running the company anymore since March. I shifted this percentage. Now I’m more onto 95% looking into the markets, experimenting, talking to various business people at various levels from the C-suite down to the one-person entrepreneurs, not even the local entrepreneurs. Also, because I’m technical, I am experimenting a lot with AI nowadays because there is this wave, and I’m trying to understand—do we want to ride it? Can we ride it? And I’m writing myself some prototypes to understand how it works. Why am I doing this? It’s again, to be able to understand—do we want to be there in one, two, three years? Are we able to? And that gives me the necessary bones for the meat to be put on when we have a conversation with somebody about AI. I don’t just “blah blah” by reading some articles; I actually try the OpenAPI, and I know how it works. I know the limitations firsthand, and that helps a lot in being able to both better understand what customers want and need and what can actually be achieved.

And it also helps with having meaningful conversations with any future person responsible in our company for AI, like a dedicated CTO or Technical Director for AI projects, eventually AI advisory AI projects. So to answer your question, basically it’s about allocating a percentage of the time for the present. Normally, I would say for somebody who is doing day-to-day operations, I would say it’s 90% of the time focused on existing clients. But don’t forget about the future—at least 10% of the time to be spent on just reading newsletters. I know for some people this doesn’t sound like work. It sounds like wasting time. So it’s fine to waste 10% of the time just looking around and reading and trying,

Niels:
Being ready for opportunities.

Marius:
And seeing them—creating the space for you to see the opportunities.

Niels:
Right. So how are you experiencing the volatile space of AI at the moment?

Marius:
Different trends, different forces. I’m waiting to see the checks and balances that will come into play, including the regulatory compliances. What I see is a lot of buzz, a lot of HUE effect thanks to the popularization of large language models through ChatGPT. At the same time, while they do lower the costs of their tokens and the usage of ChatGPT, it’s still heavily subsidized. So I’m waiting to see when the real price kicks in, what’s going to happen. It’s interesting to create a new SaaS product and a new plugin just based on ChatGPT, but then you have this huge vendor bargaining power. You just have one single vendor you’re building your business on, and if they cut your trunk, you’re in the air, and it’ll take a while to rewire yourself to Bard or to the Amazon AI and so on.

So these are all of the risks that you need to take into consideration when considering going with AI. But for some processes inside of the company, I am a huge fan of using AI, for example, to sort data, to search through knowledge bases. You can connect ChatGPT to an API, and you can basically start talking, chatting with your HubSpot and get the latest reports. You can talk with your bank statements through ChatGPT nowadays and ask about your spending trends. Or if you’re a CFO, you can talk to your Xero through the API and get financial forecasts, which opens up some interesting avenues.

Niels:
Yeah, it’s interesting to see AI at the moment as a virtual assistant, like assisting in getting data and insights instead of doing the actual work. If you have a Copilot integration when programming, you’re seeing a lot of suggestions, but you also always need the oversight of an experienced developer to evaluate what it’s suggesting to you. Does this contain any security issues, or is this a nightmare for maintainability—these kinds of judgments? You need someone to manage these. But at the same time, I’ve looked up the syntax for the PHP date function a million times in my life, and now I just tell it I want this format and make it for me. Or when writing tests, I’m like, all right, I need 5,000 postcodes from these eight different countries. I don’t have to make up a list of these kinds of repetitive things anymore; I just have to check if it’s right, instead of generating it myself. It’s interesting. It’s also got a long way to go.

Marius:
It is, it is. And there’s a long way to go. There’s a huge reason for which tools like Copilot and the AI assistant, for example, from Cloud AI, which is good with coding, or the AI assistant from JetBrains that lives inside PHPStorm, which is also very good. The reason for which there’s a long way to go before—and I’m not sure that these things will ever be able to replace developers—but they will make developers so much more productive and faster. Here’s a metaphor; it’s like a story I can quickly share with you. Years ago, when I was studying probability, one of our professors in mathematics and statistics said, “Imagine you have a monkey randomly typing on the keyboard. Now, please calculate the probability of the monkey typing in the Three Musketeers novel.”

Niels:
Right.

Marius:
Okay. What we have now is we have a very smart monkey that’s typing on your keyboard, but it’s still typing randomly—kind of randomly with a very well-trained randomness—but it’s actually guessing what the next character should be based on the previous characters.

Niels:
A context-aware monkey.

Marius:
It’s a context-aware monkey. Some call it a very fancy autocomplete that tries to please you—always to please you.

Niels:
Yeah. So my current experience has been it makes good programmers faster, it makes bad programmers worse.

Marius:
Yeah, that makes sense.

Niels:
That’s my current experience. There’s a category of programmers that are still very much going through the learning curve and growing from the junior position. Three or four years ago, they would be the ones copying Stack Overflow answers and putting them into production code, and that’s now shifted from copying from Stack Overflow to auto-completing from Copilot. That’s the shift, but it’s still the same problem. I think that’s the key insight—that you’re not removing issues, you’re just changing them.

Marius:
Yeah, I agree with you on this one. Well, I think it’s time to wrap up for today, Niels.

Niels:
Yeah, thank you for the interesting conversation. I’ve learned a lot.

Marius:
Same here, Niels, and let’s keep in touch offline.

Niels:
Definitely. Yeah.

Marius:
It’s my first time doing this chat, so I would love to be able to keep in touch.

Niels:
Yeah, we’ll definitely do that. I’ll see you at the next WordCamp Europe. Definitely.

Marius:
Sounds good. All right, take care.

Niels:
Alright, have a good day. Take care.