Adopting an AI-Native SDLC: Egnyte Search Team Case Study

By Bhumika Sharma | Manager, Engineering at Egnyte 

We ran an AI-native SDLC—here's what it changed about how we lead engineering.

Egnyte's Search team serves 22,000+ enterprise customers across petabytes of content, and like every engineering org right now, we're figuring out how deeply AI tools should reshape how teams actually build software.

Earlier this year, we kicked off a new project: Agent Skills Registry, a microservice for managing agent skill definitions (a registry service with full CRUD, storage on GCS, and MySQL-backed metadata), paired with a skills agent that can discover available capabilities and route user queries to the right tools. 

While the Skills Registry was new, the agent side demanded deep integration into our existing agentic workflows service to enhance the ReAct agent loop with skill discovery, dynamic tool loading through an internal MCP (Model Context Protocol) server, and a routing layer that      coexists with existing connectors and tools without causing disruptions. We decided to run the entire SDLC using Claude Code, not just as a coding assistant but as a genuine development partner at every stage.

What followed compressed what would typically be a multi-month effort into roughly two       weeks, from first alignment to a service running in QA. But the speed isn’t the most interesting part of the story. The bigger takeaway is what this project revealed about how engineering management needs to evolve. If you want the takeaways first, skip to the final section. Otherwise, here's how the workflow played out end-to-end, and note that we moved through several of these stages more than once as requirements evolved:

• MVP scoping: Claude Code synthesized PM discussions into a structured Jira Epic while the EM aligned stakeholders and approved outcomes.
• Technical design: Claude Code drafted architecture and API contracts from codebase context while the EM and TL injected org context and risk judgment.
• Project planning: Claude Code broke the Epic into estimated, linked stories while the EM validated complexity, sprint fit, and team capacity.
• Service scaffolding: Claude Code scaffolded the full microservice from existing patterns while the team reviewed code quality and test coverage.
• CI/CD and deployment: Claude Code generated container and pipeline configs while the EM coordinated infrastructure review and approved all MRs.

Each stage followed the same rhythm: Claude Code generates quickly, humans review carefully. The sections that follow unpack what that looked like in practice and where human judgment filled the gaps Claude left.

1. Cheap Iteration Changed How the Team Made Decisions

Here’s the thing: No project plan survives reality. On the Agent Skills project, we went through multiple design changes and scope adjustments mid-stream. As expected, software requirements evolved as we learned more. That’s not a planning failure, it's how good products get discovered.

But in a traditional workflow, change is expensive. Revisiting a technical design document after a design pivot is a day’s work. Replanning a project after a scope shift means another planning session, more calendar coordination, more momentum lost. Reworking scaffolded code means time your team didn’t budget for. That rework tax is what makes engineers instinctively resist change, and when engineers resist change, teams make worse architectural decisions to protect sunk costs.

With Claude Code, that tax got slashed. Updating a design document after a pivot took minutes. Rescoping a project plan was a prompt. Revising a service scaffold meant a fresh planning session and a new execution pass, measured in hours. We cycled through design and scope changes that would have caused serious schedule pressure in a traditional project, and the team barely broke stride.

The downstream effect was something we didn’t anticipate: The team became genuinely open to reconsidering decisions. When iteration is cheap, you evaluate ideas on their merits. We landed on a better final architecture specifically because we were willing to throw away an earlier one.

2. Turning Alignment Into Artifacts, Instantly

Every project begins in ambiguity. Ours started with a PM sync where we aligned on what the Agent Skills service needed to do, what the skill registry had to support, what the agent’s responsibilities were, and what was explicitly out of scope for the first release.

In the past, that alignment lived in someone’s notes and took hours to distill into a clean MVP scope document. This time, we shared the discussion points with Claude and had a structured Jira Epic within minutes.

That document then went through PM, EM, and TL review before anything else moved. Claude generated the artifact; the humans validated it. That sequence—generate quickly, then review carefully—became the operating pattern for every stage that followed. Speed of generation never means bypassing governance.

⚠️ Caveat: Although the MVP scope was discussed with the PM and documented with Claude Code, the leadership review surfaced gaps that neither the initial discussion nor Claude's synthesis had captured. Specifically, leadership identified the need for an admin tool: a PM-facing interface to create, manage, and feed skills into the system, which wasn’t part of the original scope. We also discovered during this review that the skill agent couldn’t exist in isolation—it had to be integrated with the existing ReAct Agent flow, ensuring that all other tools (MCP connectors, search, filesystem, KB Q&A) remained fully available alongside skill discovery. This is a useful pattern to internalize: Claude Code can synthesize what was discussed, but it can’t anticipate what leadership will add when they see the full picture. The generate-then-review cycle isn’t just a quality gate—it’ where scope actually gets completed.

3. Technical Design in Hours, Not Days

Drafting a technical design document (TDD) has always been one of the highest-effort pre-development activities. It demands deep familiarity with existing architecture, careful thinking about API contracts and data models, and anticipation of edge cases that won’t be obvious until someone actually tries to build the thing.

We used Claude Code in Plan Mode, providing it with context about our existing services as architectural references. Claude Code drafted the TDD structure: service architecture, API contracts, data models, integration points, and non-functional requirements. We iterated together, adding context about skill discovery logic, routing behavior, and edge cases that required domain knowledge Claude Code couldn’t infer from code alone.

When design requirements changed mid-project (and they did), we updated the TDD the same way: revised inputs, iterated on the affected sections with Claude Code, and had the updated design reviewed before execution resumed. What used to mean a full day of rewriting took an afternoon.

⚠️Caveat: Claude's technical designs were strong on structure and API contracts but consistently underestimated integration complexity with our existing systems. For example, the initial design proposed standard REST APIs for the Skill Registry service. During review, our tech lead identified a better approach: exposing the registry as internal MCP tools directly available to the agent. Not only did this simplify the integration but it also enabled other services to discover and consume skills through the same protocol. Claude Code wouldn’t have arrived at this on its own because it required understanding how our MCP-based agent ecosystem worked end to end. These are the kinds of architectural pivots that require engineers who have maintained the system in production. The lesson: Use Claude Code to accelerate the 80% of a TDD that is structural, but expect your senior engineers to supply the 20% that comes from operational experience and system-wide thinking.

4. Project Planning at the Speed of Thought

Breaking an approved design into a well-scoped project plan with stories, effort estimates, and ticket dependencies is important work that too often consumes a disproportionate share of sprint capacity. It’s also the most painful stage when scope shifts require replanning mid-execution.

Using Claude’s integration with Jira via MCP, we fed in both the MVP scope and the approved technical design. Claude Code generated a complete plan, broke the Epic into stories with effort estimates, and created the tickets with proper linking. When scope changed later in the project, replanning followed the same pattern: updated inputs, regenerated plan, team review, and back to execution.

Claude’s estimates were a solid foundation. The team calibrated several based on domain knowledge that no AI could have, familiarity with specific systems, known complexity in certain integration areas, and realistic assessment of team bandwidth. That calibration is precisely where engineering judgment adds value.

⚠️ Caveat: Claude's effort estimates skewed optimistic on integration-heavy tickets and slightly conservative on straightforward CRUD work. It also couldn’t factor in team-specific context like concurrent commitments, on-call rotations, or the fact that one engineer was ramping up on a new area. We found that Claude Code-generated estimates were a useful starting point: Roughly 70% matched our final numbers, but the remaining 30% required calibration from engineers who understood the human side of delivery. Treat AI estimates as a draft, not a commitment.

5. From Empty Repository to Running Service

With the plan approved, we scaffolded the Agent Skills microservice. The workflow was deliberate and built to be repeatable across the scope changes we anticipated. Here’s that process:     

1. We created a new repository and set up the project structure.     
2. Then we entered Plan Mode and gave Claude Code architectural context from our existing services as templates.
3. We reviewed the generated implementation plan as a team, then iterated until it covered all critical paths without over-engineering.
4. Our next step was to start a fresh Claude Code session to execute a clean context window, using our finalized plan as the sole input.
5. Claude Code scaffolded the full Java microservice: CRUD APIs, data models, and integration stubs.
6. Finally, we ran /init inside a Claude Code session to generate CLAUDE.md, capturing build commands, project conventions, and architecture notes.

CLAUDE.md deserves special emphasis. It’s the project’s persistent memory across every Claude Code session shared with the whole team—everyone gets consistent behavior      and keeps current via a Git hook that prompts for updates whenever source files change, but the doc doesn’t. As the service evolved through multiple scope changes, so did CLAUDE.md. Think of it as the AI onboarding document for your codebase. We keep it current with a Claude Code "Stop" hook, a shell script that diffs staged and modified files against CLAUDE.md at the end of every session, and if source files changed but CLAUDE.md didn't, reminds the developer to review it for updates.

⚠️Caveat: Scaffolding was where Claude Code was most impressive and also where the risk of false confidence was highest. The generated code compiled, followed our patterns, and passed basic tests. But it contained subtle issues: The tech stack was inherited from older services used as architectural references, resulting in Claude Code creating the new service with an older Java and deprecated MySQL version that had to be explicitly updated. Test fixtures mocked away the exact integration points we needed to validate. Each of these was caught in code review, but they wouldn’t have been obvious to a reviewer unfamiliar with the codebase. The trick is to review AI-generated code with the same rigor you’d apply to code from a talented new team member who doesn’t understand your production environment yet.

6. Infrastructure and Deployment: Days, Not Weeks

Standing up deployment infrastructure for a new service—container orchestration, CI pipelines, internal networking, cloud storage, and identity and access management—is notoriously time-consuming. It’s also the stage most likely to involve back and forth with platform and infrastructure teams, creating coordination overhead and compounding delays.

We used Claude Code with structured prompts to generate deployment configurations, CI integration files, networking setup, and cloud storage configuration. The process required manual intervention in a few places. Generated configurations needed refinement for our specific environment, and our platform engineering team reviewed all merge requests before anything was applied to infrastructure. Those review steps were not optional.

💡 Key Learning

The most effective pattern for infrastructure work: Give Claude Code a working example from a similar service and ask it to adapt, rather than generating from scratch. Our CI pipeline generation worked well because we had existing Jenkinsfiles as templates. Networking and permissioning required significant manual correction because those rules live in internal wikis and team knowledge, not in code.

7. What This Changes for Engineering Managers

As the engineering manager on this project, I’ve been thinking carefully about what an AI-native SDLC actually demands from engineering leadership. A few key things became clear to me after project completion.     

Review Quality Is Now the Critical Path

When Claude Code can produce a design document, a project plan, and scaffolded code in hours, review becomes the highest-leverage activity. The team’s judgment architecture, risk, team capacity, and long-term maintainability are what determine whether fast generation leads to good software. If you’re not already investing in your team's review culture, now is the time.

Context Is the New Leverage

Claude Code’s output scales directly with the quality of context it receives. Knowing which architectural patterns your team follows, which edge cases are landmines in your domain, and which tradeoffs are acceptable given your organization’s risk appetite is knowledge that lives with experienced engineers and EMs. Surfacing that context precisely in CLAUDE.md, in prompts, in plan-mode sessions is one of the highest-leverage things a technical leader can do.

Embrace Change Earlier, Not Less

The traditional instinct when requirements shift is to minimize scope to protect the timeline. With Claude Code, the calculus changes: You can absorb scope changes more gracefully because replanning and redesigning are no longer expensive operations. We made a better final architecture on this project specifically because we were willing to revisit decisions that, in a traditional project, we would have locked down to avoid rework.

Product and Engineering Partnership Is the Real Multiplier

None of this works without tight, continuous product-engineering coordination. On Agent Skills, scope wasn’t frozen for MVP until we were well into QA. Requirements shifted multiple times as features were added, reprioritized, and redefined. Claude made those pivots absorbable, but only because every scope change was accompanied by updated product inputs. This matters because Claude code draws inference for scope, design, and code directly from what it receives—a vague PRD produces vague scaffolding, a precise one lands close to where it needs to be. 

In hindsight, if we’d started with a more fully defined PRD, we would have avoided several design pivots that cost us iteration cycles. Claude made those pivots cheap, but the cheapest pivot is the one you never have to make.

Where This Approach Fits and Where It Doesn't

Agent Skills was an ideal candidate for an AI-native SDLC: a new, isolated microservice with a well-defined API surface, reversible deployment behind feature flags, and no direct dependency on core infrastructure. The blast radius of getting something wrong was a rollback, not an outage.

This approach doesn’t transfer wholesale to high blast-radius systems with infrastructure changes—core components of the business where the cost of being confidently wrong is measured in customer impact. For those systems, AI is most valuable in assist mode: drafting proposals, generating test cases, and exploring edge cases in review. The human stays in the driver's seat for every decision, not just the final review gate.

Knowing which projects are ready for an AI-native workflow and which demand a more cautious integration is itself an engineering leadership judgment call and arguably the most important one as these tools mature.

The Bottom Line

Our Agent Skills project went from alignment to QA deployment in roughly two weeks, through multiple rounds of scope and design change, without skipping a single review gate. That compression wasn’t magic. It was the result of treating Claude Code as a serious development partner and reserving human judgment for the decisions that actually require it. But acceleration without ownership is technical debt in disguise:

• Review AI code like you'd review a talented new hire. Analyze it like it was authored bysomeone who writes clean, pattern-consistent code but doesn't yet know your production environment.
• Don't let AI test its own assumptions. Invest in integration tests and manual QA that stress the assumptions behind the code, not just the code itself.
• Use CLAUDE.md as a forcing function. Keeping it current forces engineers to articulate decisions, not just accept them.
• Build evals early. We used DeepEval to measure skill routing quality before we shipped, not after.

This isn’t a sprint tool you pick up for one project and put down. The capability compounds: CLAUDE.md gets richer, the team develops shared fluency, and the patterns that work for your stack get refined over time.