Exploring the Depths of Vibe Coding: Reflections on Building Journal Systems

"Vibe coding" has been alive as an idea since Andrey Karpov from OpenAI coined the term on February 25 of this year. The practice, of course, predates the name, and I've been doing it for a few months. It really started to get better with the evolution of agent implementations and increasing utility of Anthropic's LLMs for code development. Before this, I was using AI as an assistant and experimenting with development, which was great, but now I'm more "going with the vibe."
This is an experiment, but I've decided to push it harder and see how far I could go, so I developed an entire multitenancy end-to-end journal platform comparable to established systems like OJS (Open Journal Systems) or Janeway—all without the traditional support of a dedicated engineering team.

Most folks would think any disheartening aspects of this experience would stem from limitations of vibe coding itself. That's definitely not true. You can achieve a lot with vibe coding, more than is really being acknowledged in current discussions, and I'll write about this more extensively in the future. What actually disheartened me was how the process reinforced just how bad legacy workflows for journals truly are.

I've always known this intellectually, but building a legacy system really brings it home: journal management systems are fundamentally linear and industrial in their design—essentially digital conveyor belts for academic content. While straightforward to implement, this simplicity reveals a rigidity that's completely out of step with today's technological possibilities.
These traditional systems resemble horse-drawn carriages of the publishing world—reliable and recognizable, but hardly suited to the innovative aspirations of our digital era. They optimize workflow by metaphorically "accelerating the conveyor belt" they operate on—a frustratingly outdated approach that barely scratches the surface of what's possible with today's technology.

EasyJournal, the platform I "vibe coded," perfectly demonstrates both the strengths and limitations of these traditional approaches. It offers robust workflow management options with customizable stages and role-based permissions. Its reporting functionality provides valuable insights into submission volumes and reviewer performance. The production interface streamlines manuscript preparation, while customizable forms collect precisely the information journals need.
The system even includes a SaaS admin interface for hosting multiple journals on a single platform—each with its own branding, workflows, and user communities. Screenshots reveal a clean, functional interface that prioritizes clarity and familiarity over innovation.

But here's the problem: EasyJournal is just a bad way of doing things. It might be the popular approach, but it's fundamentally dumb.
In contrast, Kotahi, the system I co-developed, challenges the notion that we must adhere to traditional workflows. It offers everything expected from conventional journal systems while emphasizing smart, communicative collaboration that enables concurrent processes. Kotahi doesn't follow the legacy approach—it can perform all the same functions, but in a better and more interesting way.
By building both types of systems, I've reaffirmed for myself the importance of questioning not just what we produce, but why we produce it in certain ways. When comparing these approaches, I keep pondering: is this truly what users want? Do familiar structures simply feel more accessible despite their limitations? Is coming closer to where users are actually a good idea, or should we be challenging them to adapt to more effective approaches?
The real challenge lies in bridging the gap between current practices and future possibilities. Systems like Kotahi offer a vision where collaboration isn't an afterthought but a core design component. They address the evolving needs of scholarly landscapes by pushing beyond legacy limitations while embracing new opportunities for innovation.
This raises further questions: How can we encourage broader adoption of advanced, collaborative platforms without alienating users accustomed to traditional systems? As I continue exploring the possibilities in the digital publishing space, it's clear that the most effective solutions will combine intuitive simplicity with powerful collaborative features.
The interfaces I've included here for EasyJournal I'll push next week to the EasyJournal site. I'm still figuring out what to do with the system. If you have ideas please reach out.
Member discussion