Effective Vibe Coding Shatters Decades-Old Developer and Recruiter Certainties
For the past few years, we've used clockify.me to generate the time reports some of our service invoices are based on. Clockify drastically changed its offering, and we ended up only relying on its CSV exports as the source for generating those invoices.
We looked for Open Source alternatives but none of them really convinced us: some were basically glorified pomodoro timers, others came with a stack whose footprint was too heavy for our taste. Among the best known, Kimai or Solidtime for instance are written in PHP, which means running Apache or php-fpm.
Between that disappointment and the fact that we didn't want to rewrite our entire billing pipeline, built around GitLab CI/CD cronjobs, in one go, we decided to build an application with the exact same export interface contract as Clockify, while also being able to reingest Clockify's own exports so we wouldn't lose years of history.
Then we went further and, staying fully Open Source, built everything Clockify was missing:
- Better-scoped RBAC, separating people who can access financial data (daily rates, etc.) from those who only see time records
- Export jobs that let you automate sending invoices or time sheets, with dynamic expressions (cron for scheduling,
now()-1dfor time ranges) - An agentic CLI with an embedded MCP server we can invoke from our low-code serverless functions through the CWAI API
- A user-friendly mobile app
- A calendar view compatible with Google Calendar and Microsoft Outlook
- Daily or half-day time sheet entries for services that aren't billed by the hour
- A decision matrix to configure which data fields are mandatory depending on the country
- Etc.
And that's how cwclock.me1 came to be, built with:
- Go for the API (api.cwclock.me), the CLI and the MCP server
- Flutter for the mobile app
- React for the web version
- PostgreSQL for the database
All of it grew out of about a hundred prompts, which are themselves fully part of the source code, available here:
This experience led us to question some principles we'd been convinced of for years, and that's what I wanted to share here.
Choosing a simple, market-consensual script language like PHP, Python, TypeScript or JavaScript to make hiring easier
That's clearly no longer where the real battle is. Between Kubernetes, Docker and pretty much every CNCF tool written in Go, plus every platform now written in Rust, models like Claude Opus & co. are extremely well trained to write clean, readable Go and Rust code.
Hiring difficulty for these languages just isn't the blocker it used to be. It's now better to favor technologies with a light footprint, backed by enough large-scale Open Source projects to guarantee their long-term viability, with plenty of source code available for LLMs optimized for code generation to train on.
Mono-repo vs. multi-repo
There used to be plenty of arguments, mostly coming from highly specialized developers, in favor of separate repos with strict separation of concerns: a frontend dev only needs the OpenAPI spec, not the whole backend codebase they don't understand, and vice versa.
With vibe coding, it's exactly the opposite: the more context a model gets as input, the fewer tokens it burns reasoning through the task at hand, and the fewer back-and-forths you'll need with it. And frankly, there's no better spec than the code itself. So when a change impacts the API and all its clients (frontend, mobile, CLI, Terraform provider, Helm chart, etc.), it's much better to have everything in the same repo. After years of advocating for multi-repo, I'm personally reversing that opinion entirely.
Don't multiply the technologies in your codebase
For decades, most companies refused to follow the obvious common sense that "each technology has domains where it's more or less efficient," and told themselves "better to stick to a single programming language" instead, which gave us "all-Python" or "all-TypeScript" shops, even though we all know perfectly well those technologies aren't efficient for a large number of use cases.
React Native is a good example: reusing the same codebase between the web frontend and the mobile app. Look closely at this technology and you'll quickly see it demands a lot of maintenance.
Same story here, it's no longer really a valid argument. Try the experiment yourself and you'll notice Claude struggles a lot more to generate working React Native code on the first try, failing roughly one time out of two because of Node package incompatibilities with Kotlin, whereas with Flutter it's very efficient and almost never breaks. You might think having two separate codebases, React for web and Flutter for mobile, is a shame, but in reality it's quite the opposite: for agents, it only reinforces the context available to know exactly how to implement the same feature in yet another technology, like the CLI in Go, or why not another mobile app better optimized for iOS, written in Swift for instance.
The ROI of a big-bang rewrite is rarely positive
When a codebase caused maintainability issues, you used to have to weigh the ROI of a full rewrite against the time sunk into keeping it on life support. More often than not, the conclusion was that it was better to keep stretching its lifespan somehow.
Nowadays, an old legacy codebase is the best possible context you can hand a model for a full rewrite, fixing along the way defects that have been known for years. It's the perfect time to finally tackle all those refactoring projects you'd written off as too costly.
Conclusion
At the latest DevoxxFR 2026 conference, I was talking with one of Copilot's developer advocates, who claimed that TypeScript is the only programming language that will be left standing, backed by arguments that make sense from an "old-school HR management" point of view. But I honestly think he's off the mark, for all the reasons laid out here.
With vibe coding, it's way better to pick technologies models are well trained on, not because they're massively adopted, but because there are quality Open Source projects that served as training material and that are more optimized and closer to their execution platform. Maintainability and running costs will also end up much cheaper for companies.
The value of "high-level" and "simple" scripting languages collapses entirely once you're able to interact with the machine directly in human language.
Moreover, we're not the only ones to have had this idea, by the way:
Today, building custom applications is becoming a commodity accessible to everyone. We don't know how long that will last, or what will eventually restrict access again (a drastic price increase from providers like Anthropic or OpenAI as they push for profitability, geopolitics, the end of capitalism, whatever). But our position is that we should make the most of it now to enrich Open Source, so we keep benefiting from it even if it all stops one day.