Coder Legion - Recent posts tagged gitlab

Developer Weekly Briefing — October 16, 2026

Fri, 16 Oct 2026 12:28:25 +0000

A week defined by two big ideas running in parallel: AI agents are breaking the infrastructure underneath them, and the security surface around developer workflows keeps growing. Both threads showed up in force. Here's what mattered.

Anthropic hit 30,000 merges a day, and Git couldn't keep up — so it built Scion

By September 2026, Anthropic was averaging 30,000 merged changes a day, up from 2,500 in May. Its main branch history had grown close to 100 GB. CI alone required 25 million checkouts a day, and at peak the team ran several hundred Git mirrors just to keep up. Standard workarounds stopped working. So a seven-person team built a replacement from scratch.

Scion is Anthropic's internal version control system. The design is built for always-online, agent-heavy workloads rather than Git's original model of offline, occasional human pushes. Servers handle commits, merges, rebases, and diffs. Clients keep a small local cache. Commits are stored as changesets that scale with the size of the change, not the size of the repo. Cache hit rates are above 99% at each of the three tiers. The result: checkouts take seconds instead of minutes, use about 200 times less CPU and memory than the old mirror fleet, and recover 25% of CI capacity.

Anthropic says Scion only makes sense for very large monorepos and has no plans to release it — but it wants to share the ideas with GitHub, GitLab, and the open source community. Last week's briefing covered GitHub's infrastructure rebuild to handle agent-scale load. This week, Anthropic said: we got there first, and we had to build something new to do it.

GitLab patches a CVSS 10 — update now

A critical vulnerability in GitLab's CI/CD regex engine, CVE-2026-97229, got a perfect CVSS score of 10.0. An unauthenticated attacker could send a crafted regex in a CI/CD configuration and execute arbitrary code on the server — which typically holds source code, pipeline definitions, and production secrets. GitLab shipped fixes in versions 19.4.2, 19.3.5, and 19.2.8 on October 12. GitLab.com is already patched. Dedicated customers need no action. Self-managed instances need to upgrade now. The release also covers 23 other vulnerabilities, including an 8.7-rated prompt injection in GitLab Duo Agent Platform.

GitHub now records who pushed every commit

Git has always let developers set their own name and email in commits — metadata that's trivially spoofed. GitHub's new push attribution feature records the authenticated account that actually pushed each commit, separate from the author and committer fields. A new repository ruleset, "Committer must match pusher," can block pushes where the committer's email doesn't match the pusher's verified addresses. The practical benefit: bots and agents often push commits under a human's name. This makes that visible. It's in limited public preview for GitHub Enterprise. Before enabling the enforcement rule, audit your release bots, shared tokens, and any workflow that pushes on behalf of someone else — the rule will break those if you don't.

GitHub is pushing teams off classic PATs — here's the new permission model

GitHub announced narrowed app permissions aimed at getting teams off classic personal access tokens. Classic PATs have been a persistent weak spot: long-lived, often over-scoped, and easy to forget once they're embedded in a workflow. The new fine-grained permissions limit what any given token or GitHub App can access. If your team still uses classic PATs in automation, this is a push to move. The transition won't happen overnight, but the direction is clear.

npm gives unused trusted publishing configurations 48 hours to prove themselves

npm's trusted publishing feature ties release authority to a repository or project name. That's useful until the name changes hands — an abandoned or reorganized repo that still has a trusted configuration is exactly where supply chain attacks start. npm's fix: any configuration that doesn't complete a successful publish within 48 hours of creation expires. Once it publishes successfully, the expiration goes away. The practical change: create your trusted publishing configuration when you're ready to publish, not during setup. If it expires, recreate it.

Claude Platform now sends agent traces to your observability stack

Anthropic added native OpenTelemetry trace export to the Claude Platform, in public beta. It works with the Messages API, Claude Managed Agents, and the Claude SDKs. Each trace includes duration, status, token counts, the model used, tool names, and request IDs. Teams can also enable full content export, which adds prompts, responses, and tool inputs and outputs. Setup for the Messages API and Managed Agents requires no application code changes — just configure an export destination in the Claude Console. The feature supports any OTLP-compatible backend; Anthropic has published guides for 12 partners, including Datadog, Grafana, Honeycomb, Langfuse, New Relic, and Splunk. The practical value: agents make several model calls, tool calls, and retries per request, and failures in that chain are hard to trace without instrumentation. This is the instrumentation.

Figma gives AI agents a spec sheet and code layers land on the canvas

Figma shipped two features worth tracking. Specs is a Markdown editor — on canvas or as a standalone file — where teams write requirements, design rules, and agent instructions. It can reference canvas elements, pull context from a connected GitHub repo, and embed diagrams and code. On the development side, Code Layers lets teams place running, code-backed prototypes directly in a Figma file. Code can come from a GitHub repo, a local folder, a live website, or an AI coding tool. Claude Code gets a round-trip: work from Claude Code can land in Figma, and design changes can be pulled back into the codebase through MCP. Both features are in open beta.

Cloudflare acquires Deno's team to build self-hosted Workers. Cloudflare is hiring Ryan Dahl and the Deno team to make workerd, the open-source Workers runtime, production-viable for self-hosted deployments. Deno Deploy shuts down in six months. Deno runtime gets one more year of maintenance releases. JSR keeps running. If you're on Deno Deploy, start planning the move now. Read more
Microsoft launches Decision-1, a fast, cheap decision-scoring model. Built on post-trained Qwen3.5-9B, Decision-1 takes a fixed set of answers and returns calibrated probabilities in a single API call. It's aimed at routing, classification, and workflow control — the "System One" decisions in an agent pipeline. Available in Microsoft Foundry and through OpenRouter at $0.042 per million input tokens. Read more
Nvidia hands Run:ai to the open source community. The GPU orchestration platform Nvidia acquired in 2024 is going open source. For teams managing GPU workloads for AI training and inference, this matters. Read more
SpaceX bundles Grok, Cursor, and X Premium into one subscription. The $30/month Premium tier combines Grok, Cursor Pro, and X Premium+ — tools that would cost about $90 separately. The catch: Grok and Cursor share a usage pool, so AI chat and coding work against the same weekly limit. Dev teams should audit that tradeoff before committing. Read more
AI doesn't replace your thinking — it raises the bar for it. My latest for Insights From Analytics: the patterns I keep seeing when professionals struggle to get real value from AI, and what changes when they fix them. Read more

Developer Spotlights this week

Bryan MacLee drives an oil and gas truck in Vernal, Utah, and builds his own programming language on the side. SCRML is a full-stack language for the browser — the compiler handles the wiring between frontend and backend that developers normally manage by hand. Version 0.8 is out. Adoption is near zero, by his own description on the project site. He's building it anyway. A good conversation about what it takes to build something nobody's using yet.

Watch the conversation

Jonathan Gordon spent decades building developer tools at Google, Apple, Microsoft, Oracle, and SAP. His warning: AI-generated code often has error handling that "puts nothing in the catch block." Users find out when buttons stop working. His rule: "We can't just let AI build the software by itself." The full conversation is a useful counterweight to the vibe coding conversation.

Watch the conversation

The through-line this week: agents are breaking things at the infrastructure layer, and security controls designed for human developers don't hold up at agent scale. Anthropic had to build a new VCS. GitHub is adding authentication that was never needed when a human was always at the keyboard. The same pressure is showing up everywhere.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Overengineering Doesn't Always Win Hackathons — I Learned This the Hard Way

Sat, 11 Jul 2026 02:24:01 +0000

I recently participated in the GitLab Transcend Hackathon with a project
I spent weeks designing, refining, testing, and polishing. It grew into
a complete developer intelligence platform with onboarding, architecture
analysis, impact analysis, repository health, executive reports, and
more.

It didn't win.

After reading the judges' feedback and studying the winning projects, I
realized an important lesson:

Hackathons reward clarity more than complexity.

Most winning projects solved one memorable problem with one clear
workflow. My project solved many real problems---but that made its
story harder to communicate in just a few minutes.

What I Learned

Solve one pain point exceptionally well.
Make your value obvious in a single sentence.
Let supporting features strengthen the story, not replace it.
Great engineering alone doesn't guarantee a winning project.

I'll still build ambitious software, but next time I'll spend as much
time refining the story as I do refining the code.

Sometimes the best hackathon project isn't the one with the most
features---it's the one everyone remembers.

🚀 Try It Yourself & Contribute

GitLab Knowledge Navigator is open source, and I'd love to hear your feedback.

Whether you're interested in AI developer tools, GitLab Orbit, or repository intelligence, feel free to explore the project, try it on your own repositories, and share your ideas.

Ways you can contribute:

⭐ Star the repository if you find it useful.
🐞 Report bugs or unexpected behavior.
💡 Suggest new features or workflows.
🔧 Submit pull requests for improvements.
📝 Improve documentation or examples.

Every contribution—big or small—is appreciated. If you're interested in building better AI-powered developer tooling, I'd be happy to collaborate.

Repository: https://gitlab.com/gitlab-ai-hackathon/transcend/38699100

Happy exploring! 🚀

Branching Strategies

Wed, 08 Jul 2026 09:00:00 +0000

Tony Kelly hosts our latest episode of Continuous Delivery Office Hours, with Bob Walker and Steve Fenton.

Your branching strategy can support Continuous Delivery, or make it an impossible goal. Teams should assess the impact of how they branch on their ability to deliver software at all times, and that means there are some branching techniques that make software delivery more like walking in the dark through a field of rakes.

Listen now to discover:

The best branching strategies
The worst possible branching strategy
How branching fits into Continuous Delivery
Confessions from our worst merges

What If Your Repository Could Explain Itself?

Mon, 22 Jun 2026 13:02:34 +0000

🚀 Built: GitLab Knowledge Navigator

Over the last week, I've been building GitLab Knowledge Navigator for the GitLab AI Hackathon 2026.

The idea started from a common developer problem:

You join a project, open an issue, and suddenly need to understand years of architecture decisions, merge requests, dependencies, ownership history, and code relationships.

The information exists, but it's scattered everywhere.

GitLab Knowledge Navigator transforms GitLab Orbit's knowledge graph into actionable repository intelligence.

Demo Video:- https://youtu.be/xLBaZ2sFMEI

🔍 What it can do:

• New Contributor Onboarding
• Architecture Memory
• Decision Intelligence
• Change Impact Analysis
• Architecture Drift Detection
• Repository Risk Alerts
• Executive Engineering Reports
• Knowledge Graph Visualization
• Repository Intelligence Scoring

One of the most interesting capabilities is the ability to answer questions such as:

"Why does this dependency exist?"

Instead of giving a generic AI answer, Navigator traces real repository history through GitLab Orbit and explains when a technology was introduced, why it was added, and which merge request introduced it.

🏗 Technical Highlights

• GitLab Orbit API
• Orbit Local Graph (DuckDB)
• Gemini 2.5 Flash
• Python
• Knowledge Graph Traversal
• Multi-Repository Analysis
• Interactive HTML Dashboards

The project was validated not only on its own codebase but also on a fork of GitLab Runner containing:

✅ 1,366 files
✅ 9,314 definitions
✅ 58,340 indexed relationships

One of the biggest lessons from this project was that repository intelligence requires more than an LLM. The real value comes from combining AI with structured repository knowledge and software development lifecycle context.

From Code → Context → Decisions.

GitLab #GitLabOrbit #GitLabAIHackathon #DeveloperTools #SoftwareEngineering #AI #KnowledgeGraph #Python #OpenSource #DevTools #GenerativeAI

Confessions of a Git Beginner: Why the Terminal Stopped Scaring Me

Mon, 22 Jun 2026 06:49:46 +0000

When I started my coding journey, I thought writing code was the hard part. Then I met Git and the command line. At first, it felt like a series of incantations I had to type perfectly into the terminal, or my entire project would vanish. But after breaking a few things and pushing through the confusion, I realized Git isn't just a tool only, it's also a mindset shift.

To be completely honest, the terminal terrified me. It felt like a cold, unforgiving void where typing a single wrong character could accidentally delete my entire project or break my machine. For the first few weeks, running commands felt like shouting magic incantations into the dark and praying everything didn't blow up. But a funny thing happens when you use Git every day: the fear fades, and the mindset changes.

I’m still very much a beginner, but Git has completely changed how I think about building software. Here are the four biggest lessons version control has taught me so far.

1. Making Mistakes is Part of the Process (The Safety Net)
Before I started using Git, writing code felt incredibly high-stakes.

Git completely flipped that script. It taught me that software development, it’s about having a safety net that allows you to fail safely.

Realizing that I can ruthlessly experiment, completely mess up a file, and then simply run a command to discard those changes and reset back to safety was a massive breakthrough. Git didn't just save my code; it gave me the psychological freedom to break things on purpose just to see how they work.

2. The Art of Breaking Things Down
Git forced me to stop, breathe, and think modularly. It taught me to break big problems into micro-steps:

Isolate the feature:
Instead of working on everything in the main branch, I learned to spin up a dedicated feature branch for a single specific task.
Work in tiny increments:
Fix a small bug? Commit it. Format a file? Commit it.
Write meaningful histories:
Wrapping my head around why git commit -m "fixed stuff" is a bad idea made me a better critical thinker. Writing a clear, structured commit message forces you to explain what you changed and why.

It made me look at projects differently. I now view coding as a series of small, manageable stepping stones.

3. Communication & Collaboration
Even if you are working on a solo project, you are never truly coding alone. At the very least, you are collaborating with Future You.

There is nothing quite like looking back at a project you wrote three weeks ago and trying to figure out what your past self was thinking. Git taught me that code isn't just written for computers to execute; it's written for humans to read.

Maintaining a clean Git history, naming branches logically, and writing a solid, detailed README.md file aren't just administrative chores. They are essential communication tools. Git taught me that being a good developer means being a good teammate to whoever reads my repository next—even if that person is just me in a month.

4. Navigating the "oops" Moments

Git will throw errors at you that look like complete gibberish at first. You'll run into an unexpected merge conflict, a permission issue, or a 403 Forbidden error when trying to push to a remote repository.

In my first week, those errors made my stomach drop. I assumed I had broken everything beyond repair.

But navigating those "uh-oh" moments taught me the most valuable lesson of all: senior developers don't have fewer errors; they just have more practice solving them.

I learned to slow down, read the terminal logs closely, check my remote configurations, and realize that every single error is fixable. The terminal isn't an enemy looking to punish your mistakes; it’s just a tool waiting for clear instructions.

Repetition Builds Muscle Memory
If you're a beginner reading this and you still have to look up how to update your branch from main, delete a local branch, or fix a detached HEAD state—that is completely normal.

I still keep a cheatsheet open on my second monitor. The commands don't stick overnight, but the confidence does. Git stopped being a scary obstacle and became the ultimate developer tool. It keeps me organized, gives me permission to make mistakes, and reminds me that every big problem is just a collection of tiny, committable pieces.

If you’re hiding from the terminal, take the leap. Type git init, embrace the errors, and let yourself break things. It's the only way to learn!

️ What was the most terrifying Git error you ran into as a beginner, and how did you fix it? Let's swap horror stories in the comments!

I Stopped Fixing Bugs Myself and Built an AI to Do It Instead

Sun, 03 May 2026 10:48:06 +0000

Every developer knows this pain. A bug gets filed and suddenly someone has to drop everything, read the issue, search through the codebase, figure out what broke, write a fix, add tests, open a PR and report back. It’s all manual work that takes time away from things that actually need a human brain. I kept asking myself one simple question, how much of this work can an agent handle on its own? That’s how BugFixer came about.

BugFixer is an AI agent that works inside GitLab using Claude. You file a bug report, assign BugFixer to the issue and walk away. The agent reads the issue, looks through the codebase, finds the problem, writes a fix with tests, opens a merge request and comments back explaining what it did. Nothing gets merged automatically, you still review and approve. BugFixer does the work, you make the final call.

In my demo, I filed a bug about passwords being stored as plain text in an authentication file. After assigning BugFixer, it found three vulnerable functions, replaced the plaintext storage with bcrypt hashing, wrote security tests and opened a merge request. It also spotted a session token vulnerability that I never mentioned. It found that on its own just by reading the code.

Building this wasn’t easy. The first problem was the YAML tool configuration. The documentation wasn’t clear, and small syntax changes caused confusing errors like “tool_name is missing” or “tool_name not expected.” I had to ask in the GitLab Discord community to figure it out. The second issue was permissions. Even with a Developer role, the agent could read files but couldn’t create commits or merge requests. Early runs were triggering but producing nothing, no commits, no MRs, no comments. Fixing that took days and was the biggest challenge.

Learn about Medium’s values
What I’m most proud of is that BugFixer fixed real bugs on its own. It worked on a Python calculator, a geospatial script I was working on at work and an authentication module with multiple security issues. Every run produced real fixes, real tests and real merge requests. But the best part was the session token issue it found on its own. I never asked for that. It just read the code and noticed the problem.

This project taught me how to build an AI agent from scratch on a platform I had never used before, how to write prompts that give an LLM enough context to make decisions, and how to debug using only session logs. It also showed me that building on a beta platform means hitting walls with little or no documentation. You just have to keep testing until something works.

Right now, BugFixer handles one bug at a time, but real teams deal with many issues at once. The next step is to run multiple agents in parallel and prioritize bugs by severity. I also want it to leave inline comments directly in the merge request not just a summary on the issue. Long term, the goal is for BugFixer to run the pipeline after fixing a bug, check if tests pass and only then open a merge request. The tools for that already exist, so it’s close.

BugFixer isn’t about replacing developers. It’s about removing repetitive work so people can focus on what really matters. If an agent can read bugs, fix code, and write tests, then maybe our time is better spent reviewing, designing, and solving harder problems.

Try it out: GitLab
YouTube: BugFixer - AI Agent that fixes bugs automatically in GitLab

GitLab Accidentally Deleted Its Own Database… Live on Camera

Sat, 18 Apr 2026 07:21:55 +0000

Hey guys!
Today’s story is every developer’s worst nightmare… but it actually happened.

Imagine this:

You run a command
And suddenly… your entire production database is gone

Now imagine…

Thousands of people are watching it happen LIVE

What Was Going On?

Back in 2017, GitLab (a platform used by developers worldwide) was facing some database issues.

Engineers were trying to fix replication problems.

Nothing unusual.

Just a normal “let’s fix production” situation.

⚠️ The Moment Everything Broke

During debugging…

An engineer ran a command to clean up some data.

But instead of deleting a small part…

It deleted the primary production database

Yes. The main one.

“No Problem, We Have Backups”… Right?

At this point, everyone thought:

“Relax… just restore backup”

But here’s the twist:

Backups were outdated ❌
Some were corrupted ❌
Recovery was not straightforward ❌

Basically… the backup plan also needed a backup

And Yes… It Was LIVE

Now this is what makes the story legendary.

Instead of hiding the issue…

GitLab started a live stream

They:

Showed the real problem
Tried to fix it in real-time
Explained every step

The entire internet watched engineers panic-debug

The Recovery Struggle

Engineers tried everything:

Restoring partial backups
Rebuilding database state
Recovering lost data manually

It took hours of effort…

Finally:

Most of the data was recovered

But the damage?

Already done.

What Actually Went Wrong?

A combination of issues:

Running risky commands directly in production
Lack of proper safeguards
Weak backup verification

One small mistake + poor preparation = big outage

The Real Lesson

This story is funny… but also painful.

As a developer, remember:

Never trust backups blindly
Always test recovery process
Limit direct access to production
Add confirmations for dangerous actions

Final Thought

In coding, everyone says:

“It won’t happen to me”

But reality says:

“Just wait…”

Even top companies like **GitLab can fail.

The difference is:

How you handle it when things go wrong

Let’s Talk

Be honest

Have you ever:

Run a command you instantly regretted?
Broken something important by mistake?

Drop your story below
Let’s share some real dev pain!