The Quiet AI Revolution Coming for Your Publishing Tools

Written for the EDRLab conference I'm presenting at tomorrow in Dublin.

As AI ripples through publishing, much of the discussion—especially at industry events—focuses on what AI can do: summarization, copyediting, multimedia generation, recommendations, metadata enhancement, and so on. These use cases are undeniably important. But it's not the full story.

What’s coming isn’t just AI functions. It’s a full reset on the economics and structure of how publishing software is made. And that’s going to change everything.

Not Just What AI Does—But What It Changes

We’re entering a new era not just because AI can help you write a better book blurb, but because it can help you build the entire system that produces, processes, and distributes that blurb. Faster. Cheaper. With fewer technical specialists. That’s a profound shift.

Until recently, building software was a specialized, high-friction process. Whether you were building in-house or adopting existing platforms, your choices fell into three basic models (I'm not covering the open source itch-to-scratch model, which I've discussed here):

1. Build in-house – Slow and expensive, but tailored. Requires dedicated technical teams.
2. Rent existing platforms – Fast and cheap, but you compromise: your workflow bends to their logic.
3. Collaborate on shared infrastructure – Open source or shared services. More cost-effective than building by yourself but inherently consensus-driven and (generally) slower to evolve.

These three models—building in-house, renting platforms, and collaborating on shared infrastructure—have all been widely adopted across the publishing sector. Each offers trade-offs between cost, speed, and control. But whether the tool is built internally or licensed externally, most publishing systems today share a common trait: they are built by other people for you (true also if you have an internal development team). The 'developer folks' work hard to meet your needs, but seldom, if ever, exactly match them. This is not a criticism of developers, its an acknowledgement of a problem intrinisc to a model where the user with the problem is different to the folks that have the expertise to develop a technical solution.

As a result, working with software has generally become an exercise in compromise—bending workflows to fit existing logic, hiring consultants to bridge the gaps, and navigating dense configuration layers just to get close to what you actually need.

The Shift Begins

This is now starting to change.

When GPT 3.5 was first released, I began experimenting to see how well AI could interpret software patterns, interact with APIs, and follow structured standards like file formats. I also tried building out various 'GPTs' when the product bcame available, to further test the possibiltiies and to report out what I found.

In that initial moment—and for some time afterward—the potential was clear, but the technology wasn’t production-ready. And we weren’t ready either.

We didn’t fully understand what these models were capable of, how they worked, or how to distinguish between what a large language model could generate and what it could do within the real-world systems we use every day. We didn’t have a clear conceptual model. In many ways, we still don’t. We’ve made progress, but like many others, we’re figuring it out as we go. There’s still a lag.

In the meantime, though, things have progressed quickly.

Two moments stand out. In September 2024, Replit released what I consider the first truly viable AI coding agent for non-developers. Then, in February 2025, Andrej Karpathy introduced the term vibe coding - coding by describing what you want to an AI agent, not writing code yourself.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists
https://x.com/karpathy/status/1886192184808149383?lang=en

Since then, the economics of software development have begun to shift dramatically.

In January 2025, I revisited in earnest what AI could do for software development. Over the next four months, I worked intensively—developing over 40 platforms and products using AI agents. Some were production-ready, others were experiments or prototypes.

As part of this exploration, I gave myself what felt like a deliberately unreasonable goal: to build an entire end-to-end journal submission, review, and publishing platform. I dedicated two months to this, working around 80 hours a week—sometimes more. I wanted to take it as far as I could.

I also chose to do it entirely on my own, without writing or reading a single line of code. (As a non-developer, this part was easy.) I know this space very well—it's one of the areas where I’m a domain expert—so I was able to clearly articulate requirements and workflows. The result was EasyJournal.org, which you can try out online.

I don’t believe the system is production-ready (and I don't intend it to be unless someone ponies up with some cash to go through and tighten it up!), but it is impressive. From a functional perspective, I believe it compares favorably to existing open-source systems in this space, such as OJS (Open Journal Systems) and Janeway. In fact, I designed EasyJournal to meet or exceed their core functionality, that was the challenge and they (Janeway in particular) was a great benchmark.

The result is a multitenant system with end to end publishing features for journals, SaaS controls, super admin capabilities, and more. It’s not perfect, but it shows what’s possible.

I’ve also since 'vibe coded' platforms in collaboration with professional developers, and I’m happy to share those with anyone interested—just drop me a line. But the main point here is this: OJS, for example, has been around for over 20 years, and I was able to build a system with more functionality in a matter of months, working alone without looking at the code.

Documenting the Shift: What’s Changing in Software Development

This is what I'm seeing, this isn't an exhaustive list, I coudl speak for days about what is possible, how things are working now, where they are going, how to work with AI agents for developing products, but for the main part:

• From shared components to shared descriptions
  Software is moving away from wiring together modular components via code toward describing systems in natural language. Instead of plugging parts together, we’re describing what we want, and AI builds it. This allows for faster iteration and personalization. A software component for me now is not a software library, but a description.
• From large teams to individual creators
  AI-assisted development means complex systems no longer require large developer teams. Individuals with domain expertise can build viable products themselves using AI tools. The barrier to creation is dropping rapidly. 'Real engineers' have no fear of becoming extinct anytime soon however, if you want to go into production you need to at least validate the backend code is doing what it says it is. In many more situations you need developers to do a lot more to make the end products robust, secure etc (more on this below). But you can go to production in certain situations without the help of engineers at all.
• Open source as AI training ground
  Open source isn’t just a community for human developers anymore—it’s becoming a rich, structured training environment and library resource for AI. Repositories and product documentation are readable by AI are currently being used to replicate, customise, or improve upon existing open source tools. What this means for open source software communities and open source economics is anyones guess.
• Product manuals as prompts
  Manuals, specs, and configuration files are transforming into rich instructional material for AI - essentuially the manual is rapidly becoming the product requirements doc. These documents are increasingly useful not just to people to learn how to use a softwre, but as exact inputs for model-guided builds.
• Ubiquitous development, new support needs
  As vibe-coding tools proliferate, a new technical service industry is emerging—not centered on coding, but on maintenance, integration, security, and operationalizing AI-generated systems.
• Taste as a technical skill
  The ability to curate and evaluate well-made systems will become increasingly important. With more tools being built than ever, filtering and designing strong, reliable options is a core competency. For this reason, I think we are going to see the evolution of boutique, bespoke, solutions provision. Why build one big box and offer it to the market when you can build 30 custom ones?
• Changing system architectures
  Software design will increasingly separate solid back-end engineering from dynamic, AI-built or vibe-coded front-end workflows. Domain experts will play a much bigger role in shaping the front end and user-facing logic, while infrastructure remains robust and stable in the background.

What Comes Next: The Lag Before the Leap

How this all plays out is going to be interesting. We’re in an "AI lag" moment right now. Some people don’t yet know what’s possible; others do, but feel that if they say it out loud, they’ll sound crazy. Proof is still in short supply, and so conjecture is running wild.

But I strongly believe that vibe coding is no joke. It’s going to transform software—not just by making senior developers faster, but by changing everything: the economics, the processes, and most importantly, who it is that makes software.

On that last point, I want to say more—because I think it’s the most important point of all.

Showing, Not Telling

After taking stock of the AI lag—seeing firsthand what was and wasn’t possible through my deep dive—I realized that simply talking about what AI can do wasn't going to cut it. People need to see it.

So I started VibeCodingWorkshops.com, a place to teach people how to vibe code. So far, I’ve trained over 60 people, and I’m just getting started. Most participants, though not all, come from publishing—and some are even in this room today (nb: these are notes for my conf presentaiton tomorrow).

One example stands out. Ashlea Shaw, a product manager from the eLife journal in the UK, attended one of my early workshops in April. She’s not a developer, but just last week, eLife put into production a tool that Ash created herself. Here’s what she wrote to me:

“[...] I created a Chrome extension which enables editorial colleagues to recommend a bioRxiv preprint at the single click of a button. We understand colleagues spend a lot of time looking at preprints to find suitable articles eLife would like to publish. These users manually capture the article information and will later reach out to the preprint authors to invite them to submit with eLife.

When the extension is added by a user, our button floats on top of every bioRxiv preprint, without interfering with the reading experience and is available for each user to click when they find a suitable paper. The button confirms when it has captured the details and the metadata is added to a Google spreadsheet ready for review. This allows the Editorial team to not only save time on data capture but also have a single source of truth from which they can more strategically plan communications to authors.”

This is the point. Software has always been created by other people. The entire process of traditional software development has been resource-intensive and expensive. And the biggest problem? You’re usually working with someone else’s idea of what you want. It's a translation issue that is slow, costly, and lossful.

The whole history of systems development is one long attempt to bridge the translation gap between what users want and what software delivers. But there has always been a gap.

Now, that gap is closing. Now you can build your own tools.

This means perfect fidelity between requirements and results. The process is instant. The tools you build can evolve with you. As the domain expert, you can see what’s needed and respond in real time.

That’s the real change. This is bespoke software—software built by you. Shared infrastructure will remain useful where the effort still outweighs the time you have. But even then, the cost is reduced by a steeply evolving gradient.

We’re seeing the end of big-box platforms. We’re seeing the beginning of tools built by users. And this is going to drive workflow innovation across publishing—and every other domain touched by software.

coda...

We are not there yet. There is a road ahead of us but I strongly believe what I have described here is already possible as I have built these systems myself and trained others to do it. This is all going to have a massive effect on the software industry and how existing vendors react to it is going to be very interesting. Regardless, the entire economic rationale for software as it exists today, and the processes around how software is made and by who, has already started to change and the pace of change is not slow. Systems do change, even if they don't change as fast as techncial capabilities. Over time however, the change is going to be enormous.