Modern coding agents can generate a lot of code very quickly.What once consumed days or weeks of a person’s time is now a simple matter of a prompt and a coffee break.The question is whether this changes any of the fundamental principles ofsoftware development.

A significant portion of software engineering (beyond pure algorithms and data structure work) is not about the code itself, but about managing the social aspects of building and evolving the software over time.

Our system's architecture inherently mirrors the structure of the organization that builds it, as stated by Conway's Law.Therefore, software engineering deals a lot with how a software project is structured to ensure that a (human) team can deliver, make changes, and maintain it over time.

That is why maintainability is such a high-value target: an unmaintainable project quickly becomes one no one can safely change. A good example is OpenSSL circa Heartbleed, or your bank’s COBOL-based core systems.

Does this still apply in the era of coding agents?If a new feature is needed, and I can simply ask a model to regenerate the whole thing from scratch, bypassing technical debt and re-incorporating all constraints, do I still need to worry about maintainability?

My answer in this regard is emphatically yes.There is immense value in ensuring the maintainability of projects, even in the age of AI agents.

One of the most obvious answers is that a maintainable project minimizes the amount of code you must review and touch to make a change.Translating this into the language of Large Language Models, this means you are fundamentally reducing the required context needed to execute a change.

It isn’t just about saving our token budget. Even assuming an essentially unlimited budget, the true value extends beyond mere computation cost.

The maintainability of a software project remains critical because you cannot trust a model to act with absolute competence.You do not have the option of simply telling a model, "Make this application secure," and blindly expecting a perfect outcome. It will give you a thumbs-up and place your product API key in the client-side code.

Furthermore, in a mature software project, even one built entirely with AI, making substantial changes using an AI agent is incredibly risky.Consider the scenario where you spend a week with an agent, carefully tweaking the system's behavior, reviewing the code, and directing its output into the exact shape required.

Six months later, you return to the same area for a change.If the model rewrites everything from scratch, because it can, the entire context and history of those days and weeks of careful guidancewill be lost.This lost context is far more valuable than the code itself.

Remember Hyrum’s Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract:all observable behaviors of your system will be depended on by somebody."

The "sufficient number of users" is surprisingly low, and observable behaviors include non-obvious factors like performance characteristics, the order of elements in a JSON document, the packet merging algorithm in a router you weren’t even aware existed, etc.

The key is this: if a coding agent routinely rewrites large swaths of code, you are not performing an equivalent exchange.

Even if the old code had been AI-generated, it was subsequently subjected to human review, clarification, testing, and verification by users, then deployed - and it survived the production environment and production loads.

The entirely new code has no validated quality yet.You must still expend time and effort to verify its correctness.That is the difference between the existing code and the new one.

Over 25 years ago, Joel Spolsky wrote Things You Should Never Do about the Netscape rewrite. That particular article has withstood the test of time very well. And it is entirely relevant in the age of coding agents as well.

Part of my job involves reviewing code on a project that is over fifteen years old with over a million lines of code. The past week,I've reviewed pull requests ranging from changes of a few hundred lines to one that changed over 10,000 lines of code.

The complexity involved in code review scales exponentially with the amount of code changed, because you must understand not just the changed code, but all its interactions with the rest of the system.

That 10,000+ lines of code pull request is something that is applicable for major features, worth the time and effort that it takes to properly understand and evaluate the change.

Thinking that you can just have a coding agent throw big changes on a project fundamentally misunderstands how projects thrive. And assuming you can have one agent write the code and another review it is a short trip to madness.

In summary, maintainability in the age of coding agents looks remarkably like it did before.The essential requirements remain: clear boundaries, a consistent architecture, and the ability to go into a piece of code and understand exactly what it's doing.

Funnily enough, the same aspects of good software engineering discipline also translate well into best practices for AI usage: limiting the scope of change, reducing the amount of required context, etc.

You should aim to modify a single piece of code, or better yet, create new code instead of modifying existing, validated code (Open/Closed Principle).

Even with AI, the human act of reviewing code is still crucial.And if your proposed solution is to have one AI agent review another, you have simply pushed the problem one layer up, as you are still faced with the necessity of specifying exactly what the system is supposed to be doing in a way that is unambiguous and clear.

There is already a proper way to do that, we call it coding 🙂.

I was reviewing some code, and I ran into the following snippet. Take a look at it:

public void AddAttachment(string fileName, Stream stream)
   {
       ValidationMethods.AssertNotNullOrEmpty(fileName, nameof(fileName));
       if (stream == null)
           throw new ArgumentNullException(nameof(stream));


       string type = GetContentType(fileName);


       _attachments.Add(new PutAttachmentCommandData("__this__", fileName, stream, type, changeVector: string.Empty));
   }


   private static string GetContentType(string fileName)
   {
       var extension = Path.GetExtension(fileName);
       if (string.IsNullOrEmpty(extension))
           return "image/jpeg"; // Default fallback


       return extension.ToLowerInvariant() switch
       {
           ".jpg" or ".jpeg" => "image/jpeg",
           ".png" => "image/png",
           ".webp" => "image/webp",
           ".gif" => "image/gif",
           ".pdf" => "application/pdf",
           ".txt" => "text/plain",
           _ => "application/octet-stream"
       };
   }

I don’t like this code because the API is trying to guess the intent of the caller. We are making some reasonable inferences here, for sure, but we are also ensuring that any future progress will require us to change our code, instead of letting the caller do that.

In fact, the caller probably knows a lot more than we do about what is going on. They know if they are uploading an image, and probably in what format too. They know that they just uploaded a CSV file (and that we need to classify it as plain text, etc.).

This is one of those cases where the best option is not to try to be smart. I recommended that we write the function to let the caller deal with it.

It is important to note that this is meant to be a public API in a library that is shipped to external customers, so changing something in the library is not easy (change, release, deploy, update - that can take a while). We need to make sure that we aren’t blocking the caller from doing things they may want to.

This is a case of trying to help the user, but instead ending up crippling what they can do with the API.

RavenDB has recently introduced its dedicated Kubernetes Operator, a big improvement over the Helm charts that teams have been using. This is meant to streamline database orchestration and management, essentially giving you an automated "SRE-in-a-box."

You can read the full announcement here. And the actual operator is available here.

The Operator shifts the management paradigm from manual configuration to a declarative model. Simply applying a RavenDBCluster custom resource definition (CRD) allows developers to automate the heavy lifting of cluster formation, storage binding, and external networking, removing the operational friction typically associated with running stateful distributed systems on K8s.

Most importantly, it isn’t a one-time thing. The RavenDB Kubernetes Operator is all about "Day 2" operational intelligence. It handles complex lifecycle tasks with high precision, such as executing safe rolling upgrades with built-in validation gates to prevent breaking changes.

From dealing with the intricacies of certificate rotation—supporting both Let’s Encrypt and private PKI—to providing real-time health insights directly via kubectl, the automation of these critical maintenance tasks lets the Operator ensure that your RavenDB clusters remain resilient, secure, and performant with minimal manual intervention.

For example, you can push an upgrade from RavenDB 7.0 to RavenDB 7.2, and the Operator will automatically handle performing a rolling upgrade for you, ensuring there is no downtime during deployment. There is no need for complex orchestration playbooks, you just push the update, and it happens for you.

This is part of the same DevOps push we are making. If you are partial to Ansible, on the other hand, we have recently published great support there as well.

I’m looking for a key technical voice to join the team: a Sales Engineer who will be based in a GMT to GMT+3 time zone to best support our growing European and international customer base.

We want someone who is passionate about solving complex technical challenges who can have fun talking to people and building relationships.You’ll bridge the gap between our technology and our customers' business needs.

The Technical Chops:We need a technical champion for the sales process.That means diving deep into solution architecture, designing and executing proof-of-concepts, and helping customers architect reliable, scalable, and ridiculously fast systems using RavenDB.You need to understand databases (SQL, NoSQL, and the cloud), and be ready to learn RavenDB's powerful features inside and out.If you have a background in development (C#, Java, Python—it all helps!) and enjoy thinking about things like indexing strategies, data modeling, and performance tuning, you’ll love this.

People Person: You need to be able to walk into a room (virtual or physical), quickly identify a customer's pain points, and articulate a clear, compelling vision for how RavenDB solves them.This role requires excellent communication skills—you’ll be giving engaging demos, leading technical presentations, and collaborating directly with high-level technical teams.If you can discuss a multi-region deployment strategy one minute and explain the ROI to a business executive the next, you’ve got the commercial savviness we’re looking for.

You should have 3+ years of experience in a pre-sales or solution architecture role. A strong general database background is required, experience with NoSQL databases is a big plus.

Please ping us either via commenting here or submit your details to jobs@ravendb.net

You may have heard about a recent security vulnerability in MongoDB (MongoBleed). The gist is that you can (as an unauthenticated user) remotely read the contents of MongoDB’s memory (including things like secrets, document data, and PII). You can read the details about the actual technical issue in the link above.

The root cause of the problem is that the authentication process for MongoDB uses MongoDB’s own code. That sounds like a very strange statement, no? Consider the layer at which authentication happens. MongoDB handles authentication at the application level.

Let me skip ahead a bit to talk about how RavenDB handles the problem of authentication. We thought long and hard about that problem when we redesigned RavenDB for the 4.0 release. One of the key design decisions we made was to not handle authentication ourselves.

Authentication in RavenDB is based on X.509 certificates. That is usually the highest level of security you’re asked for by enterprises anyway, so RavenDB’s minimum security level is already at the high end. That decision, however, had a lot of other implications.

RavenDB doesn’t have any code to actually authenticate a user. Instead, authentication happens at the infrastructure layer, before any application-level code runs. That means that at a very fundamental level, we don’t deal with unauthenticated input. That is rejected very early in the process.

It isn’t a theoretical issue, by the way. A recent CVE was released for .NET-based applications (of which RavenDB is one) that could lead to exactly this issue, an authentication bypass problem.RavenDB is not vulnerable as a result of this issue because the authentication mechanism it relies on is much lower in the stack.

By the same token, the code that actually performs the authentication for RavenDB is the same code that validates that your connection to your bank is secure from hackers. On Linux - OpenSSL, on Windows - SChannel. These are already very carefully scrutinized and security-critical infrastructure for pretty much everyone.

This design decision also leads to an interesting division inside RavenDB. There is a very strict separation between authentication-related code (provided by the platform) and RavenDB’s.

The problem for MongoDB is that they reused the same code for reading BSON documents from the network as part of their authentication mechanism.

That means that any aspect of BSON in MongoDB needs to be analyzed with an eye toward unauthenticated user input, as this CVE shows.

An attempt to add compression support to reduce network traffic resulted in size confusion, which then led to this problem. To be clear, that is a very reasonable set of steps that happened. For RavenDB, something similar is plausible, but not for unauthorized users.

What about Heartbleed?        

The name Mongobleed is an intentional reference to a very similar bug in OpenSSL from over a decade ago, with similar disastrous consequences. Wouldn’t RavenDB then be vulnerable in the same manner as MongoDB?

That is where the choice to use the platform infrastructure comes to our aid. Yes, in such a scenario, RavenDB would be vulnerable. But so would pretty much everything else. For example, MongoDB itself, even though it isn’t using OpenSSL for authentication, would also be vulnerable to such a bug in OpenSSL.

The good thing about OpenSSL’s Heartbleed bug is that it shined a huge spotlight on such bugs, and it means that a lot of time, money, and effort has been dedicated to rooting out similar issues, to the point where trust in OpenSSL has been restored.

Summary

One of the key decisions that we made when we built RavenDB was to look at how we could use the underlying (battle-tested) infrastructure to do things for us.

For security purposes, that means we have reduced the risk of vulnerabilities. A bug in RavenDB code isn’t a security vulnerability, you have to target the (much more closely scrutinized) infrastructure to actually get to a vulnerable state. That is part of our Zero Trust policy.

RavenDB has a far simpler security footprint, we use the enterprise-level TLS & X.509 for authentication instead of implementing six different protocols (and carrying the liability of each). This both simplifies the process of setting up RavenDB securely and reduces the effort required to achieve proper security compliance.

You cannot underestimate the power of checking the “X.509 client authentication” box and dropping whole sections of the security audit when deploying a new system.