u/GitKraken — reddlx

The talk that finally said what most senior devs actually believe about AI coding

We shared a talk at GitKon recently from Chris Kelly at Augment Code, and it's been sitting with us since.

His core argument: generating code was never the job. The job is building a system, safely, on top of something already running in production. AI can write the code. It cannot make the architectural trade-offs, understand your specific system's constraints, or decide when a microservice is the wrong call for your team.

A few things he said that we think are worth talking about here:

"The best code is no code at all. Every line is a liability." If that's true, then optimizing for how much code AI can generate might be optimizing for the wrong thing entirely. He also made the case that code review is becoming the highest-leverage skill in an AI-assisted workflow. Not prompting, not context management, but the judgment to look at a diff and know whether it's actually right.

And one that stuck: LLMs apologize and say things like "let me read that more carefully" because they were trained on email threads where someone got yelled at. They're text generation machines. The anthropomorphic language is a pattern, not intent. Knowing that changes how you work with them.

Are you finding that the engineers leaning hardest into AI agents are doing more code review, or less? And does the "you need to know what the code should look like before you write it" bar feel realistic when the whole pitch of agents is moving faster?

youtu.be

u/GitKraken — 16 days ago

▲ 1 r/GitKraken

AI made our devs faster at writing code. Our deployment frequency didn't move. Here's what we found.

We've been digging into a pattern we keep hearing from engineering teams: PR volume is way up since AI tools got adopted, but DORA metrics aren't budging. Deployment frequency stays flat. Lead time doesn't improve. The code is being written faster, the PRs aren't getting shipped faster.

The reason, at least from what we've seen in our own data and in the 2025 DORA report from Google, is that AI accelerated code generation without accelerating review capacity. 90% of developers are using AI. Over half report little to no trust in AI-generated code. Those two things are landing directly on your reviewers.

Some metrics worth looking at if you're seeing this in your team:

First response time (pickup time). Are PRs sitting in queue longer on average? Is the number of PRs with zero activity going up?

Cycle time distribution. Not just your average, but the spread. One 30-day PR can tank your whole average. Look at the distribution to find where things actually stall.

Code churn / post-PR rework. If merged code is getting changed again within 7 days at a pattern, that's a signal that review quality may be slipping, not just speed.

Code duplication rate. AI without the right context generates a lot of assumptions. Duplicate code blocks and unfamiliar patterns are a sign the code generation isn't working with the right context.

PR size vs. merge time correlation. Large, complex PRs getting merged very quickly is a flag worth investigating.

We think of DORA as the lagging indicator and PR metrics as the leading indicator. If your DORA is off, the answer is probably sitting in one of those five PR signals. And if your PR signals are off, the culprit is often the AI adoption pattern itself, not the devs.

Curious if others are seeing the same thing. Did your team hit a point where AI tooling actually slowed review throughput even while speeding up authorship?

youtu.be

u/GitKraken — 23 days ago

▲ 3 r/GitKraken

There's a pattern we've been watching play out across engineering orgs and honestly

it's concerning.

When leadership mandates AI adoption without building culture around it first,

teams tend to fracture into three groups:

The resistant ones. They've seen hype cycles before (crypto, Web3, the whole lot).

They're not being irrational. They're protecting themselves from another "this will

change everything" that quietly doesn't.

The reckless adopters. They ship fast. They vibe code. And six months later

someone's debugging spaghetti with a security hole in it.

The jaded ones. They've reviewed enough AI slop in PRs that they've written off

the whole thing. Also not irrational. They're reading what's actually coming out.

The real question isn't "how do we get engineers to use AI." It's "how do we build

a culture where engineers actually want to use it and have the judgment to use it well."

We featured a GitKon talk from Rizel Scarlett (Block/Goose) that digs into exactly

this. The two-phase model she describes, earn interest first, then build judgment,

maps to what we're seeing work in developer communities too. Fun low-stakes

experimentation before production pressure. Flexibility on tooling (Cursor, Claude Code,

Amp, whatever fits the team). And leadership that actually builds in public instead

of just pushing a tool they've never touched.

The line that stuck with us: "Inspiration spreads faster than mandates."

Full talk is up on the GitKraken YouTube channel if anyone wants to dig in. Curious

whether others have seen this compliance vs culture split happen on their teams.

u/GitKraken — 30 days ago

▲ 1 r/GitKraken

We tracked the overhead: manual worktrees, individual terminal tabs, zero consolidated status.

The context-switching cost is what makes most devs avoid parallel sessions entirely. How are others handling this?

u/GitKraken — 1 month ago

▲ 1 r/GitKraken

We partnered with GitClear and spent the last year talking to hundreds of engineering teams about AI adoption.

The common thread: everyone knows AI is changing things, but nobody is sure if it's helping or hurting. The data surprised us. Code duplication has increased tenfold since 2022.

Refactoring dropped below duplication rates for the first time. And developers feel more productive than ever, even as the codebase gets harder to maintain.

That gap between perceived productivity and actual code health is the thing nobody is measuring, and it's the thing that will bite you in 6 months when velocity tanks for reasons nobody can explain. We put together a framework built around 4 measurement layers: direct AI usage, code health indicators, developer experience signals, and business outcomes. None of them tell the whole story alone. Together they act like a dashboard, because you wouldn't ignore the fuel gauge just because the speedometer looks good.

A few things from the research that stuck with us:

• 79% of code changes now touch code written less than a month ago (up from 70% in 2020). Fast iteration or fast rework? You need to know which.

• Developer experience metrics are leading indicators, typically months ahead of delivery impact. By the time velocity drops, the warning signs were already there.

• One engineering manager put it well: "My developers are flying through tickets, but they can't explain how their code works."

That's a developer experience problem that becomes a velocity problem fast. We wrote up the full frameworks and playbooks in a free guide: "Quantifying the Impact of AI." If your org is trying to justify AI spend or figure out where it's actually creating value (vs. just feeling like it is), it might be worth a read.

u/GitKraken — 1 month ago