CIRCLE WITH A DOT

Three levels of AI in software development 🧠

After my recent posts about vibecoding and devibecoding I want to zoom out a bit. I think there are three levels of using AI in software development — and they are really about risk.

🟢 Level 1: passive AI usage. Autocomplete, code review, planning, answering coding questions, writing documentation. You stay in full control, AI just saves you time. Almost zero risk, immediate productivity gains.

🟡 Level 2: vibecoding non-production code. Tests, internal tools, CI/CD scripts, prototypes. This is the sweet spot most teams underestimate. The upside is high but the blast radius is small — if a generated test is wrong it fails, if an internal tool has quirks nobody outside your team notices. Great place to learn what AI can and can't do.

Level 3: vibecoding production code. This is where it gets real. By my definition from the earlier post: vibecoded code is code nobody on your team has fully understood. Shipping that to production is a conscious risk decision.

The key insight: these aren't steps you walk through sequentially. It's a risk assessment. Level 1 and 2 are almost always worth it. Level 3 depends on your situation — a startup that needs an MVP in three months has a different equation than an enterprise with compliance requirements.

And when level 3 code needs to grow up? That's where devibecoding comes in — turning code nobody fully grasps into code your team truly owns.

Where does your team sit on this spectrum right now?

#SoftwareDevelopment #AI #Vibecoding #Devibecoding #CodeQuality #DevLife #RiskManagement

@Ken5280 Welcome!

@Blf_tpe Totally agree — the intent is real and the community should meet that with openness, not defense. The people coming in through vibecoding are potential long term contributors and supporters. Your mom donating to Debian is living proof of that.

The YouTube tutorial idea is exactly right. The technical barrier to contributing is lower than ever thanks to AI. But nobody teaches you how to write a good commit message, how to read contributing guidelines, or when NOT to open a PR. That cultural onboarding is the real gap.

Maybe that's actually a community project worth vibecoding — an interactive guide for first time open source contributors.

@Blf_tpe Great point — AI as a gateway to open source is a real upside I hadn't considered enough. More people discovering and appreciating the ecosystem is genuinely valuable.

But there's a flip side: if a lot of newcomers start opening issues or PRs on established projects without fully understanding the codebase, that can overwhelm maintainers who are already stretched thin. The intent is good but the burden is real.

Maybe the better path for beginners is to start your own small open source project with vibecoded code. Put it out there, get feedback, learn from the community. That way you build understanding without adding noise to existing projects.

Places like Mastodon could actually be great for that — share your project, ask for feedback, learn in public. Devibecoding as a community effort rather than a solo struggle.

@radicalabacus Love the archaeology metaphor. And I think you nailed the core difference — legacy code has a story, vibecode doesn't. Digging through an old codebase you can always ask "why did they do this?" and find an answer. With vibecode that question leads nowhere.

Which makes me wonder: is devibecoding even the right response in every case? Maybe your instinct is the pragmatic answer — treat vibecode as a disposable draft. Use it to understand the problem space, extract the spec, then write it properly from scratch.

That might actually be the most efficient form of devibecoding — not saving the code but saving the knowledge.

@BuuBuu Welcome!

Devibecoding

In my last post I defined vibecoded code as code nobody on your team has fully understood. But what happens when you take that code and make it yours?

I think we need a term for this: devibecoding.

Devibecoding is the process of taking code you don't fully grasp — whether AI generated or not — and systematically working through it until you truly own it. Understanding it, restructuring it, making it maintainable.

🧠 This is not just code review. It's a mix of reverse engineering, refactoring and deep comprehension — without being able to ask the original author about their intent. Because there was no human author.

Someone in the replies to my last post described exactly this: putting in the effort to understand and reformat AI output until it becomes their code. That's devibecoding in practice.

And here is my take: this will become its own discipline. With its own tools, its own best practices, maybe its own specialists. Think tools that don't just lint but explain. That visualize where your understanding gaps are. Possibly even AI helping you understand AI code — ironic but inevitable.

The more vibecode exists in the world, the bigger the need for people who can devibecode it.

What do you think — is this already part of your workflow? And what tooling would help you most?

#SoftwareDevelopment #AI #Vibecoding #Devibecoding #CodeQuality #DevLife #Refactoring

@Blf_tpe This is a great real world example! Your point 2 is exactly the key — the moment you put in the effort to understand and reformat, it stops being vibecode. You are turning AI output into YOUR code.

And point 1 is interesting — a few hundred lines seems to be the natural ceiling where vibecoding starts to break down. Beyond that, debugging (point 3) becomes the real cost.

Sounds like you are already moving from vibecoding to AI-assisted coding — and that's a huge difference in terms of risk.

Everyone talks about vibecoding but most definitions focus on how the code was created. I think that misses the point.

My take: vibecoded code is code that nobody on your team has fully understood. It doesn't matter if an AI wrote it, a junior dev copied it from Stack Overflow, or a senior dev hacked it together at 2am. If nobody has truly reviewed and comprehended it — it's vibecode.

That distinction matters because it shifts the conversation from "did you use AI?" to "do you actually know what this does?"

This also means: code that an AI generated but you thoroughly reviewed and understood is NOT vibecode. The tool doesn't define the category — your level of understanding does.

Why does this matter? Because it changes the risk assessment entirely. Using AI to write code you then deeply review is just a productivity tool. Shipping code you don't fully grasp is a conscious risk decision — sometimes justified, sometimes not.

Do you agree with this definition? Or would you draw the line somewhere else?

#SoftwareDevelopment #AI #Vibecoding #CodeQuality #DevLife

Generating cryptographically secure random values in C and C++ – what are your options?

After writing about how secure random links work, a few people asked about the underlying libraries. So here is a quick overview.

libsodium is the easiest and most recommended choice. One function call, cross-platform, and built specifically for cryptography:

randombytes_buf(buffer, size);

That is really all there is to it. libsodium picks the best available entropy source on the OS automatically.

OpenSSL / LibreSSL is the classic option. RAND_bytes() does the job and is available almost everywhere. Worth using if you already have OpenSSL as a dependency – otherwise libsodium is cleaner.

️ If you want no external dependency at all, go directly to the OS:

Linux: getrandom() – available since kernel 3.17
macOS / BSD: arc4random_buf() – even simpler, no error handling needed

Both are solid choices for system-level code.

️ What about std::random_device in C++? It looks convenient but the standard does not guarantee cryptographic security. On some platforms it falls back to a predictable seed. Fine for games or simulations – not for security-critical code.

So for anything security-related: libsodium or the OS primitives directly. std::random_device is a trap if you care about real randomness.

What do you use in your projects for secure randomness? Still rolling your own or already on libsodium?

#CPlusPlus #C #Security #Cryptography #libsodium #Infosec #SystemsProgramming

🫀 SO_KEEPALIVE — How your server detects dead connections before the client knows
A client connects to your server. Then their laptop lid closes. WiFi drops. Router reboots.
The TCP connection is dead — but your server has no idea. It just sits there. Holding a socket. Waiting forever.

This is called a half-open connection — one of TCP’s most silent failure modes.

The fix — one line:
setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &flag, sizeof(flag));

The kernel now sends small probe packets on idle connections. No response after a few tries? Connection gets cleaned up automatically.

️ Three knobs you control:
→ tcp_keepalive_time — idle time before first probe (default: 2h )
→ tcp_keepalive_intvl — time between probes (default: 75s)
→ tcp_keepalive_probes — failures before giving up (default: 9)
The defaults are hilariously conservative. For a real server you want minutes, not hours.

Without it you risk:
→ File descriptor leaks
→ Thread pool exhaustion
→ Memory piling up for connections that died hours ago

Who needs it most:
→ WebSockets & long-lived connections
→ Servers behind NAT — routers silently drop idle mappings
→ Any server where clients disappear without sending FIN

Your server shouldn’t mourn connections that are already gone.

#Linux #Networking #SystemsProgramming #ServerDevelopment

Interesting read on heise.de: "From Output to Outcome" argues that dev teams should stop measuring success by features shipped and start asking: what actually changed for the user?

The idea is simple but powerful — a feature is just output. Outcome is when a customer actually solves a problem faster, makes fewer errors, or needs less support. Developers are encouraged to ask "why are we building this?" before writing a single line of code.

But here's where it gets tricky for B2B software:

Your actual users and your paying customers are different people. The CFO signs the contract, the clerk uses the software daily — their definitions of "value" rarely align.

You often have no direct telemetry. On-premise deployments, strict data policies, and months-long update cycles mean you may never see how a feature is actually used.

Feedback is heavily filtered. It travels through support tickets, account managers, and customer success teams before it reaches the dev team — losing signal at every step.

Outcomes are slow. In B2B, the real proof shows up at contract renewal time — sometimes a year later.

So the question is: how do you build an outcome-oriented culture when the outcome is invisible to you?

Is opt-in telemetry the answer? Closer collaboration with customer success? Structured user interviews? Or something else entirely?

#SoftwareDevelopment #ProductManagement #B2BSoftware #AgileB2B

Interesting read on heise.de: "From Output to Outcome" argues that dev teams should stop measuring success by features shipped and start asking: what actually *changed* for the user?

The idea is simple but powerful — a feature is just output. Outcome is when a customer actually solves a problem faster, makes fewer errors, or needs less support. Developers are encouraged to ask "why are we building this?" before writing a single line of code.

But here's where it gets tricky for B2B software:

Your actual users and your paying customers are different people. The CFO signs the contract, the clerk uses the software daily — their definitions of "value" rarely align.

You often have no direct telemetry. On-premise deployments, strict data policies, and months-long update cycles mean you may never see how a feature is actually used.

Feedback is heavily filtered. It travels through support tickets, account managers, and customer success teams before it reaches the dev team — losing signal at every step.

Outcomes are slow. In B2B, the real proof shows up at contract renewal time — sometimes a year later.

So the question is: **how do you build an outcome-oriented culture when the outcome is invisible to you?**

Is opt-in telemetry the answer? Closer collaboration with customer success? Structured user interviews? Or something else entirely?

#SoftwareDevelopment #ProductManagement #B2BSoftware #AgileB2B

https://www.heise.de/hintergrund/Von-Output-zu-Outcome-Entwickler-als-Produktgestalter-11204293.html?seite=all

spdlog — Logging for C++ that actually gets out of your way

When you’re writing a Linux server in C++ close to the hardware, the last thing you want is a logging library that slows you down — at build time, at runtime, or when reading the code.

That’s exactly where spdlog shines.

Header-only — zero build ceremony
Drop the headers into your project, #include "spdlog/spdlog.h" and you’re done. No linking against extra libraries, no CMake gymnastics, no ABI headaches. For embedded systems or minimal server builds this alone is worth a lot.
And because spdlog supports C++11 and up, it runs happily on older GCC toolchains — exactly the kind you find in Linux BSP environments and long-lived server codebases.

Logging should be fast AND readable
spdlog uses the {fmt} library under the hood, which means your log messages are formatted at compile time where possible. Instead of stringing together cout-style streams, you write:

spdlog::info("Connection from {} on port {}", client_ip, port);

Clean, readable, and significantly faster than printf or std::cout at runtime.

🪣 The Sink System — one logger, many destinations
The real power comes from sinks. A sink is simply a destination for log output — and you can attach as many as you want to a single logger.

→ stdout_sink for live debugging in the terminal

→ rotating_file_sink to write to disk with automatic file rotation

→ syslog_sink to feed directly into the Linux system journal

In a hardware-near server this means you can log to syslog for production monitoring AND to a rotating file for post-mortem debugging — with a single log call in your code. No duplication, no extra logic.

Log levels keep noise under control
spdlog supports the classic hierarchy — trace, debug, info, warn, error, critical. You set the minimum level per sink, so your rotating file might catch everything from debug upwards while syslog only sees warn and above. Perfect for production servers where log volume matters.

For C++ server development on Linux, spdlog hits a rare sweet spot: trivial to integrate, fast enough for hot paths, and flexible enough for real production setups.

#Cpp #Linux #SystemsProgramming #ServerDevelopment

The C10K Problem — The challenge that changed the internet

1999. The web is booming. Servers are struggling. Dan Kegel asks one simple question:

“Why can’t a web server handle 10,000 simultaneous connections?”

Not a bandwidth problem. Not a CPU problem. A design problem.

️ The old model was simple but deadly:
→ 1 connection = 1 thread
→ 10.000 connections = 10.000 threads
→ 80GB RAM just for thread stacks
→ Kernel spends more time scheduling than actually working

The server wasn’t busy doing work. It was busy managing the chaos.

C10K forced a complete rethink:
→ 1 thread handling thousands of connections
→ Non-blocking sockets
→ Event loops instead of thread pools

The ripple effects were massive:
→ epoll landed in Linux 2002
→ nginx was born with this model in mind
→ Node.js made it mainstream
→ Redis, HAProxy — all children of C10K

One blog post in 1999 rewired how the entire industry thinks about network servers. We’re still building on those ideas today.

#Linux #Networking #SystemsProgramming #WebDev

The Prefork server model gets dismissed as “old school”. I think that’s wrong – especially on Linux.
With SO_REUSEPORT, the kernel distributes incoming connections across multiple pre-forked worker processes natively. No thread contention. No shared memory complexity. Each worker is an isolated process – a crash stays contained.

What you get:
– True process isolation per connection
– Kernel-level load balancing, no userspace overhead
– Predictable memory footprint
– Simpler security boundaries between workers

In a world obsessed with async event loops, we forget that prefork scales surprisingly well for workloads with high per-connection compute and where isolation actually matters – think security-sensitive services.
SO_REUSEPORT didn’t just fix the thundering herd problem. It quietly gave prefork a second life.
More on this soon.
#linux #infosec #networking #serversecurity #prefork