LLMs Changed the Rules: Git for Everyone, SQL for Everyone, Rust for Almost Everyone

The Old World: High Barriers, Gatekept Tools

Every developer remembers the first week with Git. Not the concepts, the concepts are fine. Branches, commits, merges make sense on a whiteboard. The barrier was the CLI. rebase --interactive, cherry-pick, a merge conflict in a file you didn't touch. One wrong command and your afternoon is gone.

SQL had a different kind of wall. The logic is intuitive: "show me users who signed up last month and bought something three times." Any analyst can say this sentence. But translating it into JOINs, subqueries, GROUP BY with HAVING? That required a developer. So analysts filed tickets and waited.

Regex was its own circle of hell. The running joke ("I had a problem, I used regex, now I have two problems") existed because regex was write-only code. You could Google a pattern, paste it, pray it works. Writing one from scratch meant opening a cheat sheet and spending twenty minutes on something that should take two.

These tools had something in common: the barrier was not intelligence or logic. It was syntax, CLI complexity, and the cost of the first mistake. The gap between knowing what you want and being able to express it was wide enough to keep people out.

What Changed

GUI tools for Git have existed for a decade. SQL query builders too. Regex testers with visual explanations. None of them solved the problem.

Even modern tools like GitButler, which genuinely innovates with virtual branches and drag-and-drop commit management, still require you to think in Git's language. You still need to understand what a branch is, what a commit does, why a rebase differs from a merge. GitButler makes Git better for people who already know Git. It doesn't make Git accessible to people who don't.

The same applies everywhere. A SQL builder still expects you to understand JOINs. A regex tester still expects you to read the pattern. These tools reduced friction, but they didn't change the input paradigm.

LLMs changed the input. You describe what you want in plain language, and you get a working artifact back: the actual command, query, or config, ready to run.

The tools themselves didn't get simpler. git rebase still does the same thing, a SQL window function still works the same way. But now people who couldn't use them before can.

Git for Everyone

A product manager on my team maintained his knowledge base in Cursor. Before Git, his version control was plan-old.md, plan-old-2.md, plan-final.md. You know the type. I showed him Git once. Now when something breaks, he resolves it himself by talking to Cursor. No more backup files.

The people who benefit most are not developers. Developers already knew Git. The shift is for everyone else in a tech team who used to depend on developers for version control.

The mental model of "save my changes, make them available to others, don't break what's already there" is intuitive. The CLI was the only barrier. LLMs removed it.

What hasn't changed: understanding why a merge conflict happened still requires context. But resolving it ("take my changes for this file, keep theirs for that file") is now a sentence, not a manual edit in a diff viewer.

SQL for Everyone

Getting data used to require a developer in the middle. You know what you need, but you can't get it yourself. With the ClickHouse setup I described above, we skipped the dashboard entirely. The PM asks questions, gets queries, runs them. More useful than anything we could have pre-built, because the person with domain knowledge is the one querying.

Any analyst who can say "monthly revenue by product category, excluding refunds, for the last quarter" can now get a working SQL query in seconds. One that actually runs, not a rough draft to hand off to a developer for fixing.

Window functions, CTEs, self-joins, stuff that took developers real time to learn, are now available to anyone who can describe the result they want. The LLM handles syntax, the person handles domain knowledge.

In practice, this means analysts stop filing tickets for queries and developers stop being the bottleneck for data access. The loop from question to answer goes from days to minutes.

Regex, Shell Scripts, and the Rest of the Unlocked Toolkit

The same thing is happening with other tools that share the same problem: useful, but painful to learn.

Regex. "Match email addresses but not the ones from internal domains" is now a prompt, not a puzzle. The LLM generates the pattern, you test it, done. The regex itself is still unreadable, but you don't need to read it. You need it to work.

Shell scripting. "Find all log files older than 30 days and compress them" is a one-liner that most people would spend fifteen minutes Googling and stitching together. An LLM writes it in seconds, including edge cases you wouldn't think of.

Docker and Compose configs. "Set up a Postgres database with Redis cache and expose port 3000 for my Node app." Declarative configuration is a sweet spot for LLMs. The syntax is rigid and well-documented, which means the LLM output is reliable.

I've used most of these tools for years. It's not that I couldn't before, it's that every time I needed a cron expression, an FFmpeg command, or an nginx rewrite rule, I'd go through the same cycle: look up the syntax, debug it, get it working, forget everything by next time. Now I just describe what I need and it takes a minute. I still don't remember the cron syntax. I just don't have to.

And the list keeps going:

• Cron expressions: the same write-only format as regex; everyone used to Google "crontab guru"
• jq: JSON parsing in the terminal, syntax no less cryptic than regex
• FFmpeg: legendary 200-character one-liners; "convert this video to 720p and trim the first 10 seconds" is now just a prompt
• Nginx configs: reverse proxy, SSL, rewrite rules; used to be copy-paste from StackOverflow, now it's a description of intent
• iptables / firewall rules: critical to get right, terrifying to touch by hand. I still ask the LLM for sources before applying anything and double-check manually. Some fears are healthy
• GitHub Actions / CI/CD: YAML with specific syntax and dozens of magic keys
• Kubernetes manifests / Helm: YAML hell, fields you need to know but never remember
• Terraform / IaC: declarative, but the API surface is enormous
• Excel formulas: VLOOKUP, ARRAYFORMULA, nested IFs; analysts and managers struggled with these for years
• LaTeX: researchers know what they want to format, hate the syntax to get there
• pandas / data wrangling: .groupby().agg().pivot_table() chains; analysts know the transformation, not the API

You know what you want, you just can't express it in the tool's language.

Another project manager on my team showed me how far this goes. A non-critical server went down. I showed him how to give Cursor SSH access via keys. He took it from there: connected, read the logs, figured out what happened, applied a fix. Talked to Cursor the whole time. A year ago, that would have been a ticket to the ops team and a day of waiting.

And then there's Rust, the "almost" in the title. A backend developer on PHP, Python, or Ruby can now write production Rust with LLM assistance, because the strict compiler disciplines the model the same way it disciplines a human. Rust deserves its own article, and I'll write one. For now: the barrier that kept most developers away from it has compressed from months to days.

What This Means

SQL, regex, shell scripts, Git are no longer "developer tools." If you're an analyst or a PM, they work for you now. The question is whether you'll start using them.

For developers, the dynamic is shifting too. "Ask the backend team to write you a query" is turning into "write the query yourself and ask the backend team to review it." Fewer tickets, faster iterations. And if you're hiring, "must know SQL" starts to mean something different. The syntax is free. What matters is knowing what to ask for: domain knowledge, data modeling, understanding what the numbers mean.

One more thing. Tools with strict compilers and clear error messages have an advantage now. LLMs iterate well on precise feedback. Permissive runtimes where bugs hide until production are actually harder to use safely with LLMs.

Pedantic mode on. Understanding what's happening under the hood still matters. I'm lucky: I learned most of these tools by hand, broke things, debugged things, built the intuition for when something is wrong even if I can't immediately say why. That knowledge doesn't go away just because an LLM writes the code now. But where does the next generation get it, if the LLM handles everything from day one? I don't know. I'm not going to pretend I do. The need for deep understanding isn't going anywhere, but the path to acquiring it is changing in ways nobody has figured out yet. Pedantic mode off.

Your Turn

I listed everything I could think of, and Claude Opus reminded me of a few more from my own usage history. Between us we got to about twenty tools. But I'm sure we're both missing things.

What tool became accessible to you or to people around you because of LLMs?

Kubernetes manifests? Data pipelines? Figma-to-code? A language you never expected to write in?

Drop your examples in the comments.