Published a DBLog implementation, 100% vibe coded. Literally didn’t touch a single file. It is pretty clear that infra/platform/backend coders are cooked (if they don’t lean really hard into LLMs).
Repo: github.com/aandreakis/dblog-impl
DBLog is the watermark-based CDC algorithm that I created and implemented while I was at Netflix. If you are not familiar: DBLog allows copying table rows in chunks and interleaving them with live CDC events without locking the source tables. The following TUI screenshot illustrates this (part of the repo and generated with the snap of a finger):
I thought it was worth having an implementation from someone close to the original work, especially after the DBLog concept had already been adopted by Debezium, Apache Flink CDC, and other projects.
For this repo I only used the public paper and blog post as source material. There is no feature roadmap and no support commitment. This repo only exists to promote the DBLog idea, to verify, study, and experiment with it.
The AI part though, is what I wanted to test the most. Could I take something I know deeply, point coding agents to public material, and get them to produce code I would be comfortable releasing ?
The answer is yes and Im honestly stoked by the result. Lets say it this way: I have more confidence in this implementation than I had in early iterations of the code that I deployed at Netflix. The coding agents rigorously self-tested the code, identified and fixed several corner cases one would typically only encounter in the wild. Such as MySQL/PostgreSQL replication quirks, datatype boundaries, cross-version compatibility issues, and small memory leaks that compound over time.
It was a bit harder however than a simple “build DBLog from this blog post and paper” and I iterated a few times until I found a structure that worked well. I learned a lot during this process and it would take me much less time if I repeated this now.
The workflow that ended up working well looks like this:
- Use ChatGPT Pro to extract a high-level algorithm spec from the public material
- Turn that into a detailed implementation spec
- Ask for a module-by-module implementation plan with goals and success criteria
- Use Codex with GPT Extra High and Claude Opus Max to implement
- Execute several self-review and deploy-and-test runs: make the agents deploy it, run it under a variety of scenarios, and try to break things
LLMs are now pretty good at coding, especially compared to anything before GPT-5.4. Yet, the defaults are still not great. If you care about clean, idiomatic code, you have to say exactly what that means. Generally, you have to define what you want and what you DONT want. Im surprised that neither Codex nor Claude does a better job here. I found it useful to point the models at principles from Effective Java and Clean Code. Instructing the agents to write TDD-style failing tests first also worked well, and high test coverage seems to be a good strategy to prevent drift.
Before this project, I used LLMs only for very specific local tasks (like reviews etc) and I was unsure how it would feel if I stopped coding. I was worried that it would feel less stimulating.
After working with Claude and Codex every day now, basically every moment Im awake, I can confidently say that it is unlike anything I imagined. Im extremely satisfied and happy.
The bigger realization was that once you accept handing implementation to coding agents, the next instinct is to carefully review everything they generate. But with the throughput that coding agents offer, line-by-line reviews kill most of the possible velocity gain. The new review surface increasingly feels like “let me define the contract, tests, invariants, failure modes, and convergence criteria.” Plus asking the AI to showcase some snippets of important code, just to make sure it looks ok. I’m still working through this hurdle myself, and trying to find the right balance between inspecting generated code and trusting the higher-level contracts, tests, and review loops.
We vibe code maxing now and there is no going back from this.
Working pretty hard on multiple fronts and something related to DBLog too :))
Disclaimer: The repo is not Netflix’s production DBLog. No Netflix production code was used. No private material was used. This repo is not affiliated with, endorsed by, or maintained by Netflix.
Also: The repo is not recommended for production use. Use a well maintained and active CDC project like Debezium instead.
Top comments (0)