.png)
A customer asked for OIDC login hints. Simple feature: when a user has more than one passkey on a device, show them which account they're signing into instead of making them guess. Better UX, straightforward spec.
It sat in the backlog for months.
Not because it was hard. Because shipping it required changes across every layer: all five platform authenticators (Android, iOS, macOS, Linux, Windows), backend service endpoints I'd never touched, and an admin console flow for configuration. The developers who owned those services were allocated to higher-priority work. Nobody was available to pair with, and the project wasn't urgent enough to justify pulling someone off something else.
That's the tax you pay in a cross-platform codebase. The work isn't blocked by complexity. It's blocked by availability.
The Real Bottleneck Is Coordination, Not Code
I was hired as an Android developer at Beyond Identity. Our authenticator is a cross-platform app: Android, iOS, macOS, Linux, Windows. The client is Rust at the core with platform-specific shells in Kotlin, Swift, and web technologies. The backend is a mix of Go and Rust services. The build system spans Gradle, Cargo, Bazel, and Docker. CI/CD pipelines are their own dialect.
I've always worked beyond Android. Go services, Rust libraries, web frontends, CI configuration. I'm not new to any of these domains. But each one has a ramp-up cost. Before Claude Code, jumping into an unfamiliar part of the codebase meant reading through it for a day or two, tracing request flows, understanding the data model, and figuring out where my change needed to land. Then I'd write a ticket for the project owner. If they had availability, they'd pick it up. If they didn't, it would bounce back and wait until they did.
The bottleneck was never "can Will write Go?" It was the handoff: writing up the feature plan, filing tickets, waiting for a project owner to pick them up, and iterating through review cycles before any code got written. Multiply that across every unfamiliar service, and a feature that should take a week takes three.
What Claude Code Changed
I'd used ChatGPT, Google Gemini, and Cursor before Claude Code. They were useful for isolated questions, but Claude Code was different. It operates inside the codebase. It reads the actual code, understands the project structure, and works with me in context rather than in a separate chat window where I'm copy-pasting snippets.
The shift was specific: ramp-up time in unfamiliar domains dropped from weeks to days.
When I pointed Claude Code at a Go service I'd never worked in, the first thing I did was ask it to analyze the codebase. How are endpoints structured? Where does configuration live? What's the testing pattern? Instead of spending a day reading code to build a mental model, I had a working understanding in an hour. From there I could plan the implementation, talk through the approach with Claude, and start writing code with confidence that I wasn't missing something structural.
The dependency shifted. I used to need project owners to review my plan, prioritize tickets, and either do the work themselves or wait until they could. Now I ship the implementation and they review the MR. That's a fundamentally different ask. Reviewing a complete, tested implementation takes a fraction of the time it takes to context-switch into someone else's project, understand the requirements, and write the code from scratch.
Login Hints: One Developer, One Week
Back to the customer request. With Claude Code, I picked up the login hints project in my spare time between higher-priority work. Here's what the end-to-end implementation required:
- All five platform authenticators (Android, iOS, macOS, Linux, Windows) surfacing login hints during authentication
- New service endpoints in Go and Rust to store and retrieve login hint configuration (services I'd never touched)
- Admin console flow so tenant administrators could enable and configure the feature for their users
The old way: I'd write up the feature plan, file tickets for the endpoint and admin work, and wait for a project owner to pick them up. If they were busy with higher-priority work (and they were), the tickets would sit. Realistic timeline: two to three weeks, with most of that time spent in queues.
What happened: I wired the entire flow myself in about a week of spare-time work. Claude Code helped me navigate the unfamiliar services, understand the existing patterns, and make sure I closed every gap between the layers. The project owners didn't need to review a plan or prioritize tickets. They could read the finished MR and evaluate a complete implementation.
Where Claude Code Gets It Wrong
This is not a story about AI replacing engineering judgment. Claude Code gets things wrong, and the failure modes are specific enough to be worth naming.
Bug investigation loops. I've had sessions where I'm debugging an issue, Claude proposes a fix, the fix doesn't work, we investigate further, and Claude proposes the original implementation as the solution. Full circle, no progress. When you see this happening, you have to step back and drive the investigation yourself rather than letting the tool lead.
Test-first shortcuts. Claude Code sometimes writes tests, writes the implementation, runs the tests, and when a test fails, makes a quick decision to fix or delete the test rather than evaluating whether the logic or the test is wrong. This is the most dangerous failure mode because the tests pass and everything looks green. You have to watch for it. A deleted test isn't a passing test.
Skipped steps. We agree on a plan, Claude implements it, and I realize it dropped a step somewhere. The code looks complete, it runs, but a requirement from our own plan is missing. Sometimes it takes a few cycles of implement, test, discover the gap, and go back before the plan is fully realized.
All three failure modes share a root cause: Claude Code optimizes for forward progress. That's what makes it fast. It's also what makes it dangerous when the right move is to stop and verify against the plan. The engineer in the room still needs to be the engineer.
The Whole Team Adopted It
This pattern wasn't unique to me. The entire Endpoint team at Beyond Identity adopted Claude Code. We're a group of platform specialists: one person owns Android, another owns iOS, others own the Rust core, the web layer, the backend services. Before Claude Code, domain boundaries were soft walls. You could cross them, but it cost time and coordination.
Now those walls are lower. The iOS developer can investigate a Rust issue without waiting for the Rust developer to free up. The backend developer can trace a bug into the Android client without needing a guided tour. Each person is still the domain expert on their platform, but everyone can contribute meaningfully across the stack.
The result isn't that we need fewer specialists. It's that specialists aren't bottlenecks anymore. When the person who knows the most about a service is heads-down on a critical project, someone else can pick up the adjacent work and ship it with enough confidence that the expert only needs to review.
What This Means for Backlogs
Every engineering team has a backlog of reasonable customer requests that aren't urgent enough to staff. Login hints was one of those. The feature made sense, the customer wanted it, and it sat for months because the staffing math didn't work out.
Claude Code changes the staffing math. When one developer can cover the full stack of a feature instead of requiring three, more work becomes viable. The threshold for "worth staffing" drops. Features that would have waited a quarter ship in a sprint.
This isn't about replacing developers. It's about removing the coordination overhead that prevents existing developers from using the skills they already have. I could always write Go. I just couldn't justify the ramp-up time when someone else could do it faster. Claude Code closed that gap.
Moving Fast Without Letting Go of Security
Everything I've described so far is about velocity. Shipping across domains, compressing ramp-up time, clearing backlogs. But velocity with Claude Code means Claude Code has access to your codebase, your services, your credentials.
I work across Go services, Rust services, CI pipelines, and five platform authenticators in a single week. Claude Code is in all of it. That means API keys, service credentials, and signing configs are in play every session. On a team where everyone is now working across domains they don't own, the credential exposure surface grows with every person who adopts the tool.
Full disclosure: I work at Beyond Identity, and our product Ceros is built for this problem.
When I launch Claude Code through Ceros, my credentials never touch my machine. They're injected at runtime by the cloud proxy. Claude Code sees a local endpoint on localhost. It has no idea where the real keys are. My device credentials (the signing keys that authenticate my requests to the cloud) live inside the device's secure hardware and can't be extracted, even with root access. If my laptop were compromised tomorrow, there are no API keys to steal because they were never there.
The whole Endpoint team runs Claude Code through Ceros, but none of us had to change how we work. The security is in the infrastructure, not in a checklist we're supposed to remember while we're focused on shipping code.
If you're interested in trying Ceros, you can start for free: https://ceros.beyondidentity.ai/
Where This Goes
I still think of myself as an Android developer. That's my deepest expertise, and it's where I contribute the most nuanced work. But the scope of what I ship in a given month has expanded well beyond a single platform. Go services, Rust libraries, CI pipelines, web frontends. All informed by the same approach: point Claude Code at the codebase, build understanding fast, plan the work, execute, test, and get it reviewed.
The pattern scales. Any team with domain specialists who occasionally need to cross boundaries (which is every team) benefits from tools that compress ramp-up time without sacrificing quality. The knowledge is in the codebase. The judgment is in the developer. Claude Code is what connects them faster.