Home›Blog›What Claude Code changed about developers' work, and what it hasn't
Ferramentas de IAClaude CodeDesenvolvimentoAgentic AI

What Claude Code changed about developers' work, and what it hasn't

Rudinei GehmMarch 29, 20266 min read

Claude Code changed a developer's unit of work. The question is no longer "how do I write this function" but "how do I describe this change, and how do I verify it's right." The first part got much cheaper. The second is as expensive as it has always been, and it's where good teams and average teams part ways.

What it is, in practice

Claude Code is Anthropic's coding agent that runs in the terminal. It launched as a research preview in February 2025 (Anthropic, 2025) and became generally available that May (Anthropic, 2025). It reads the repository, edits files, runs commands and tests, makes commits, and uses the command-line tools the developer already uses.

The difference from a chat assistant is where it sits. In a chat, you copy a snippet, paste it, get another snippet back, and adapt it. In the terminal, the agent reads your tsconfig, understands the folder structure, notices the project aliases src, and writes code that fits what's already there. Then it runs the build to see whether anything broke.

Two features change how teams use it. A CLAUDE.md file holds persistent project instructions (conventions, commands, what not to do) and is loaded at the start of every session. And the documentation itself warns that those instructions are context, not enforcement: to block an action regardless of what the model decides, you use hooks, scripts that run before or after each tool call (Claude Code Docs). Every CTO should understand that distinction before rolling the tool out.

What the research shows, and what it doesn't

Adoption is already the norm. In Stack Overflow's 2025 survey, with more than 49,000 respondents, 84% of developers said they use or plan to use AI tools, up from 76% the year before. In the same survey, 46% said they don't trust the accuracy of those tools' output, up from 31% in 2024 (Stack Overflow, 2025). Usage rising while trust falls is an accurate picture of the moment.

The most cited productivity study cuts against the enthusiasm. In July 2025, METR published a randomized controlled trial with 16 experienced open-source developers working on 246 real tasks in their own repositories. With AI tools, they took 19% longer. Beforehand, they expected a 24% speedup. Afterward, they still believed they'd been 20% faster (METR, 2025).

METR returned to the question in February 2026. A new experiment pointed to a speedup, but METR itself called the result unreliable: many developers declined to take part if it meant working without AI, and some avoided submitting tasks they expected AI to finish quickly (METR, 2026). The honest reading is that the gain probably exists, is hard to measure, and users' own perception is not a reliable yardstick.

Google's 2025 DORA report, based on nearly 5,000 technology professionals, offers the most useful frame for managers: AI works as an amplifier. It magnifies the strengths of teams with good internal platforms and clear workflows, and magnifies the problems of teams that were already disorganized (DORA, 2025).

Where the gains show up

In our experience, in three kinds of work.

Broad, mechanical changes. Renaming a pattern across dozens of files, migrating from one library to another, updating an interface in every component that uses it. The kind of task people do badly out of boredom.

Repetitive code with context. Not generic boilerplate, but code that follows the project's type system, conventions, and components. Generating a component is trivial. Generating the right component for this project is what saves time.

Wide reading for debugging. The agent reads many files, follows the call chain, and finds inconsistencies nobody was looking for.

A real case, on this site

This section was added in September 2026. This site's repository includes commits made in Claude Code sessions, and two episodes show clearly where the agent helps and where a person is still required.

In the first, after a language bug had already been fixed on the blog, a session working on a different task found the same pattern in four other pages: offers, the case study list and detail pages, and the RÜNARA page were stuck on Portuguese content whatever the URL's locale. Nobody had asked for that search. Months later, while adding new pages, it found an outdated copy of the route tree in the prerendering code that made those pages return 404 precisely to crawlers, even though they worked fine in the browser.

In the second, while fixing Google Analytics tracking, the agent validated what it could (script loading only after consent, correct measurement ID, an event firing on every page change) and wrote down what it couldn't: the final request to Google wasn't observable in the test environment, and real confirmation depended on GA4's realtime report after deployment. A person checked it. That is the behavior you want from an agent: stating where its own verification ends.

What hasn't changed

Architecture is still human. The agent executes well inside a defined structure. Choosing abstractions, accepting trade-offs, and saying no to a dependency is still the job of whoever will answer for it two years from now. A fast agent on top of a bad architecture just produces technical debt faster.

Review is still mandatory. Working is not the same as right. Subtle business rules, edge cases, and side effects elsewhere in the system pass the build and the tests without warning.

Instructing well is a skill. Asking for "do this" gets average results. Asking for "do this, following this pattern, without touching that module, and run these tests at the end" gets a different level. It's a new competency, and it isn't trivial.

Data, privacy, and client code

For companies handling client code or personal data, the security question comes before the productivity one. According to Anthropic's documentation, on commercial plans (Team, Enterprise, and API) Anthropic does not train models on code or prompts sent through Claude Code, and standard retention is 30 days. On individual plans, training use depends on a setting the user controls (Claude Code Docs). The tool can also run through Amazon Bedrock or Google Cloud, which helps companies that already have contracts and controls with those providers.

The practical consequence is simple: client code, personal data, and trade secrets should not go through a developer's personal account. And if the repository holds real personal data in test files, that data falls under privacy law, such as Brazil's LGPD, like any other processing.

How to roll it out to a team

  1. Start with company accounts and a one-page policy on what can and can't go into a session.
  2. Write a CLAUDE.md for each repository, with build and test commands, conventions, and areas the agent should not touch.
  3. Use hooks and permissions for anything that truly needs to be blocked, such as destructive commands or reading credential files.
  4. Keep code review mandatory for everything the agent produces, held to the same bar as a human pull request.
  5. Measure before and after with delivery metrics, such as cycle time and change failure rate, not with how the team feels.
  6. Pick one type of task to start with, such as migrations or tests, and expand from what works.

What's being automated isn't being a developer. It's the part of the job that least needed one: turning a clear specification into predictable code. What gains value is the opposite: asking the right questions before the first line and judging quality, not just whether it runs.

If your company wants to adopt coding agents without giving up control, Advisor As a Service is the format in which we work with technical teams on these decisions week by week. To upskill the team, see our training programs.

Send us a WhatsApp message about it. In that conversation we'll show whether AI solves it, what it costs to validate and how soon you'd see results.

Talk to us on WhatsApp