Coder Legion - Recent posts tagged ai-coding

What evidence should an AI coding assistant provide before saying a bug is fixed?

Sun, 18 Oct 2026 10:06:10 +0000

An AI coding assistant can produce a plausible patch and a confident explanation in the same response. What evidence should accompany that explanation before a team treats the issue as resolved?

A useful baseline might include:

A reproduction that fails before the change and passes afterward
The exact tests or commands run, with their outcomes
An explanation connecting the change to the reported failure
A clear statement of anything that could not be checked

The difficult part is deciding how much evidence is enough. A typo in a static label and a change to payment processing deserve different levels of verification. Passing tests also leave an important question: do those tests cover the behavior the user actually reported?

For a timing bug, a happy-path test seems especially weak. A stronger check would deliberately reverse the order of events, delay a response, or force a failure at the point where the bug appears.

Would you require a regression test for every AI-generated bug fix, or allow a documented manual check for smaller changes? And should assistants distinguish between “patch prepared,” “automated checks passed,” and “verified in the target environment” instead of compressing all three into “fixed”?

Curious where you would set the minimum bar, especially when the assistant cannot access the production environment.

Beyond the Pull Request: Why Delta Could Reframe AI Code Review

Tue, 22 Sep 2026 12:09:49 +0000

Let’s be honest: the traditional pull request (PR) was designed for a different era of software development. It worked well when people wrote relatively small, self-contained changes and review could focus on a neat diff. But as AI coding agents generate larger changes faster, a diff alone can leave reviewers reconstructing why a solution was chosen.

Nathan Sobo—Zed’s CEO and co-founder, who led GitHub’s Atom team—argues that development is moving toward a richer unit of work: the conversation that produced the code. In September 2026, Zed launched Delta in public beta, a separate multiplayer environment for working with coding agents and reviewing their output. Delta is not a finished GitHub replacement, but it is a serious attempt to rethink one core GitHub workflow: the pull request.

“It seems like everyone is in a race to replace GitHub right now.” — Nathan Sobo

The PR problem in the age of AI

A pull request is excellent at presenting a proposed change, but it usually does not retain the chain of reasoning behind it. That gap is more noticeable with agents: the important context may include the initial task, alternative approaches, failed experiments, review feedback, and the prompts that produced the final implementation.

This does not make PRs obsolete for every team or repository. They remain a familiar, durable coordination layer—especially for open-source communities. Delta’s point is narrower and more interesting: a review should not force a teammate or their agent to reverse-engineer decisions that the original conversation already contains.

Delta’s central idea: the thread

Delta makes the thread—the connected conversation, worktree, review, and landing process—the primary unit of collaboration. A developer can work with an agent, invite teammates into that thread, and let them inspect the context as well as the code.

Reviewers can create a dedicated review subthread. Each review receives an isolated copy of the parent thread’s worktrees, so a reviewer can ask an agent to investigate a concern or try a fix without disrupting the original work. Accepted fixes can then be incorporated before the change is landed.

What DeltaDB actually changes

Underneath Delta is DeltaDB, which Zed describes as extending Git’s content-based versioning with incremental versions based on deltas. It records edits and human/agent messages between commits, preserving how the code evolved during a thread.

That distinction matters. DeltaDB does not eliminate Git commits: commits remain the checkpoints teams can push, pull, and build from. Instead, DeltaDB retains the context and intermediate work that normally disappears between those checkpoints. Participants get synchronized local copies of the worktree, while the conversation and code stay connected in real time.

Dogfooding the model

Zed has turned off pull requests for Delta’s own repository and says the team now builds Delta entirely within Delta. At the time of the public-beta announcement, Sobo reported that 33 people had landed 570 changes to main since that switch.

It is an encouraging operational data point, not proof that every organization should abandon PRs. Still, it shows that the workflow can support real product development rather than only a polished demo.

GitHub is still part of the picture

Zed is keeping its public Zed repository on GitHub for now. The reason is practical: the repository is where the wider community files issues and contributes changes. Zed is encouraging contributors to share Delta threads alongside normal pull requests during this transition.

Sobo told The New Stack that Zed is moving more cautiously with the public repository because hundreds of monthly contributors depend on the existing workflow. GitHub’s community and social layer are not incidental features, and Zed has not claimed to have replaced them.

The bottom line

The provocative claim is not that commits or Git vanish. It is that the thread may become the richer record of software work: a place where the idea, implementation, review, and revision remain connected.

For teams reviewing agent-generated code, that is a compelling direction. Delta’s real test will be whether this context-rich model improves review quality without creating new overhead or fragmenting the collaboration ecosystems developers already rely on. For now, it is best understood as a promising public-beta experiment in continuous, agent-native engineering—not GitHub’s obituary.

Sources

About the Author

Jarno S. AEOvara is a technology professional specializing in software development, AI integration, and modern engineering workflows. He helps teams navigate the rapidly evolving landscape of software engineering.

Connect with Jarno: aeovara.fi/asiantuntija

The Pendulum: How to Use AI Without Losing Your Edge

Thu, 30 Jul 2026 23:04:47 +0000

I used AI more last year than in any year of my career. And I got quietly worse at my job.

Not slower at everything. Slower exactly where it counted: reading unfamiliar code, catching an answer that was almost right, holding a system in my head during an incident when it’s down right now and no chat window moves fast enough.

That’s the thing about skill atrophy. It’s quiet. The AI fills the gap, the code ships, the PR merges, and you feel productive. You only notice when something breaks.

Last year something broke. I reached for the mental model I’d spent years building, the one that used to tell me where to look first, and found mist.

The pendulum

So here’s the strange place I’ve landed. I use AI more than ever, and I write code by hand more than ever. Both at once, on purpose.

That’s not a contradiction, it’s the method. A pendulum only works if it swings both ways. Let it stick to one side and it stops being a pendulum. It’s just a weight on a string.

Swinging to AI is the baseline now, not the question. The part people skip is swinging back.

It isn’t just me

Stack Overflow’s 2025 Developer Survey found trust in AI accuracy fell to 29%, down eleven points in a single year, while usage kept climbing past 80%. Sit with that shape for a second: the people using these tools the most are trusting them the least.

And the top frustration wasn’t AI being wrong. It was AI being almost right. That’s the hardest kind of wrong to catch. It compiles, it looks fine, it survives the shallow read. Catching it is exactly the muscle that goes soft first when you stop reading carefully.

The three habits

Write the first implementation by hand. Not the whole thing, just the first one in any new domain. You can’t review what you’ve never built.
One hour a week with the autocomplete off. It’s not about what you build in that hour. It’s about what the hour keeps working.
Read before you ask. Read the code yourself before a model explains it, especially when that’s slower. The friction is the rep.

Flat ground

The person who finally made me understand this isn’t an engineer at all. He’s a pro skater, and his channel is almost entirely him landing the plainest tricks there are, the ones you learn in your first month, over and over, on camera. Flat ground isn’t where you go backward. It’s where you keep the feel that makes the hard stuff possible.

Writing code by hand is flat ground for engineers. You’re not going back. You’re protecting what carries you forward.

The engineers who’ll matter in five years aren’t the ones who used AI the most. They’re the ones who used it while staying sharp.

Swing to AI. Swing back. Keep the pendulum moving, both directions.

This is part three of a trilogy. Part one, AI Didn’t Take Your Job – It Revealed It, on what your job actually is. Part two, I Delegated My Thinking to AI. Now I’m Taking It Back., on flipping who leads.

The post The Pendulum: How to Use AI Without Losing Your Edge appeared first on sudoish.

Checklist of Common mistakes coding AI Agents make

Tue, 26 May 2026 05:08:37 +0000

Invented Functions or APIs

pandas.read_excel_fast()

Looks real.

Does not exist.

Security Vulnerabilities

AI often ignores security unless explicitly asked.

query = "SELECT * FROM users WHERE name = '" + username + "'"

Very dangerous.

Code that looks correct but is wrong

supposed to return even numbers

if num % 2 == 1:

return True

Looks clean.

Completely wrong.

Inefficient Code

AI usually optimises for readability, not scalability

So it may generate nested loops, repeated database calls

Works for: 10 records

Breaks for: 10 lakh records

Outdated Syntax or Deprecated Methods

Training data may contain older code.

So AI may generate code that:

gives warnings
is no longer recommended

Inconsistent Codebase Style

Example:

camelCase

snake_case

PascalCase

all in same file.

Broken Multi-File Integration

AI may generate files independently that:

don’t connect properly
mismatch interfaces

Frontend expects:

{ "username": "Nik" }

Backend returns:

{ "user_name": "Nik" }

What other common mistakes have you experienced?

Microsoft Just Officially Called "10x AI Coding Productivity" a Myth. Real: 26%

Mon, 27 Apr 2026 22:17:16 +0000

On April 9, 2026, Microsoft Research published the New Future of Work Report. Buried inside is a section titled "myths" — three of them, named directly:

Counting AI-generated lines of code is a meaningful productivity metric
Current tools will instantly turn every developer into a "10× engineer"
Adoption primarily depends on model capability

The company that owns GitHub Copilot just officially called the entire AI coding marketing playbook from the last two years a myth.

The real number

The same report links to a randomized controlled trial published in Management Science (2026):

4,867 developers across Microsoft, Accenture, and an anonymous Fortune 100 company
Random subset got access to an AI coding assistant; the rest didn't
Outcome measured at the developer level on real production work

The result: 26.08% more completed tasks (standard error: 10.3%).

Not 10x. Not 5x. Twenty-six percent.

A note on timing: the experiments themselves ran in 2022–2023, on the GPT-3.5 generation of Copilot. Peer-reviewed final results came out in February 2026. The April 2026 Microsoft Research report cites this study as the best evidence available — meaning when they list "10x" as a myth, this is the number they're pointing at.

The hidden finding

Read the second sentence of the abstract: "Less experienced developers had higher adoption rates and greater productivity gains."

Translation: juniors got more out of the assistant than seniors. The benefit is concentrated where the existing skill is lowest.

The mechanism is obvious to anyone who's watched both kinds of engineer use these tools. A junior asks the assistant to write a function and ships what comes back. A senior asks the assistant to write a function and then spends as long reviewing it as it would have taken to write from scratch.

Reviewing is more cognitively expensive than writing. The senior pays that cost. The junior either doesn't pay it, or doesn't yet know they're supposed to.

Same tool. Two different jobs. Two different productivity numbers.

Stack the second study

The METR randomized trial (2025) measured experienced open-source developers working on their own repositories with Cursor + Claude 3.5/3.7 Sonnet:

Predicted before the trial: +24% speed-up
Felt after the trial: +20% faster
Measured: −19% slower

A 40-point gap between perception and reality.

Stack the two studies:

Microsoft (RCT, 4,867 devs, code completion, GPT-3.5 era): +26%
METR (RCT, 16 experienced devs, agent tools, modern Sonnet): −19%

The honest range is somewhere between +26% up and −19% down, depending on the task, the seniority of the user, and the discipline of the prompt.

How to actually use this

1. Stop using "lines of code" as an AI productivity metric. Microsoft Research just officially flagged it as a myth.

2. Budget against ~25%, not 10x. A quarter is the right size of number to plan around. License renewals, hiring forecasts, quarterly capacity. 26% is the kind of gain you can actually budget against.

3. Expect inverse seniority gains. If your senior devs feel like AI isn't helping them as much as your juniors — they're probably right, and the data confirms it.

If you've been quietly suspecting the hype was off — you now have a citation. Use it the next time someone asks why your AI-assisted output doesn't look like a launch keynote.

The full breakdown is in the video above.

What's your team using as an AI productivity metric right now?

Your Job Isn’t Gone. Relax.

Thu, 26 Feb 2026 06:39:26 +0000

The Anxiety Phase

There has been a feeling of anxiety among developers around the world for a few years now, and it is no different here in India. But it has never been this high as it has been in the last six months.

The reason is obvious to anyone paying attention, AI models are improving faster than our ability to mentally process the change.

Every few weeks there’s a new release claiming better reasoning, autonomous coding, agent workflows, or near-instant software generation. Models that once struggled with small snippets can now refactor projects, design systems, and ship working prototypes in minutes.

What used to feel like assistive tooling suddenly started looking like replacement capability, and that shift is what triggered the collective panic.

Noise vs Reality

Some say the panic is narrative-driven. Others argue companies are quietly correcting the over-hiring done during the COVID boom.

Whatever the explanation, the ground reality is simple: layoffs have been happening for the last couple of years, and uncertainty makes noise louder than facts ever could.

But history shows one pattern, technology rarely removes work entirely; it reshapes who does what.

The New Developer Archetype

Look at the bigger picture. We are in the middle of an AI revolution, much like the industrial revolution. The short term feels chaotic, but the long term usually rewards adaptability.

As developers, there isn’t much value left in memorizing syntax or writing boilerplate line by line, machines are already exceptional at that.

The emerging role of developers may shift toward being:

super reviewers instead of pure writers
precise prompters instead of manual implementers
system thinkers instead of framework specialists
engineers who can tell the difference between vibe coding and code that survives production traffic

AI isn’t removing developers.
It’s quietly raising the bar for what being a developer means.