Stop trying to make git happen

In the past few years, engineers have really come to embrace “as code” or GitOps workflows. And what’s not to love: you can stay in an editor you’re familiar with, and preview, test, and deploy changes automatically. This has been popularized for many things developers need to manage — we’ve seen infrastructure as code, config as code, and policy as code. Security teams have gravitated toward these workflows too.

It’s no surprise security teams love these workflows too: you get version control, reviews, rollbacks, and audit logs… for free! If the only user of your tool is the security team, this might be reasonable. But if your internal tool needs to be used by anyone who isn't an engineer, it needs to be usable for everyone — and as code workflows aren’t for everyone.

Not everyone can use git

As code workflows become a barrier as soon as someone outside the engineering org needs to use an as code tool as a part of their job. Do you think everyone outside of engineering — in sales, marketing, support, product, HR, or ops…

• … has a GitHub account?
• … knows Markdown?
• … can open a PR?
• … can set up a dev environment, even if it’s a devcontainer or codespace?

No.

I worked at GitHub, and I still don’t feel comfortable using git most of the time, even by referencing excellent documentation. I refuse to use the git CLI. And I would rather throw my computer out the window than figure out how to rebase my branch. (I shouldn’t litter my neighbor’s yard, so what I often do is just start a new PR.) I’m a more technical user — and if I can’t use git, it’s just not reasonable to ask your employees to.

Forcing managers to update permissions in git, or HR to create new accounts in a YAML template can’t be solved with extensive training — realistically, you’re looking at constant support requests. They’ll come to you every time they need help with that task, because you haven’t given them the tools they need to do it themselves.

You might even try to build a UI on top of your as code system, which means keeping context in sync between code and a user interface. Now you’re juggling UI changes and git branches, generating PRs through bots for basic edits, and still don’t have a good flow when a reviewer wants to tweak the generated code. Congrats! You’re now using git as a bad relational database.

Low-code tools exist for a reason

We have lots of internal tools that less technical users need to use — or build. We’ve seen an explosion in popularity in low-code or no-code portals for these tools (and now, LLM-enabled workflows). People who want workflow automation don’t necessarily code, and people who need to use those workflows also don’t necessarily code.

AI has certainly made this easier, but not necessarily better. Claude means that I can now generate a PR against an as code system for an access request, but is a critical everyday workflow really what you want me to be vibing?

So why do we keep building internal tools that require git? Often, because as code provides properties we want, like version control and review workflows. But optimizing only for what you need as a builder — and ignoring what your user (which could be anyone else in the organization) needs — is how you end up with a tool that no one uses.

When you’re building internal tools for everyone in the org, they need to work for everyone in the org. User experience matters more than developer convenience.

"As code" doesn't literally have to mean as code

When we started building Oblique, we started with as code definitions for access controls. That’s what IT and security teams were asking for, and what so many of them have built internally. But the more we talked to these teams, the more we realized what they wanted were the tools to preview access changes and ensure the right review requirements are met, in order to be able to safely make access changes. They wanted the benefits of as code workflows.

“As code” doesn’t literally have to mean as code. You can get the same benefits by building a thoughtful system that takes your change management requirements into account, without making someone learn git.

As code workflows make sense for systems that engineering owns, like infrastructure. But for systems that everyone in an org needs to use, like managing corporate access, requesting policy exceptions, or reviewing vendors? Build those tools with the people who actually use them in mind.