Five Core Working Principles of the Claude Code Team Worth Learning
In the wee hours, AIHOT published an official blog covering Claude Code.
It's fairly uncommon. Few genuine AI firms like Claude open up to share their organizational insights and reflections. What makes this write-up extra special is its author: Fiona Fung, the Director of Engineering leading the hugely popular Claude Code team.
The discussion centers on shifts to the team's workflows and operating practices as an AI-native organization. I've finished reading the full blog and also watched the accompanying half-hour presentation video, and many points really resonated with me. A great number of their philosophies align with what our own team has been practicing and implementing.
One recurring habit she emphasized particularly struck a chord: whenever the team runs into a problem, they always ask one follow-up question — can we automate this work? This mirrors a core principle I've long advocated: any task repeated three or more times ought to be automated with AI by every feasible means. I was genuinely excited to discover the Claude Code engineering organization operates around nearly this exact mindset, which is why I'd like to distill the most valuable takeaways from the blog to share.
She opens with an intriguing observation. For decades, every established software development framework — from Waterfall to Agile and all associated standards and methodologies — has fundamentally revolved around one core cost driver: the high expense of writing code. Engineering manpower comes at a premium, forcing teams to sink extensive hours into upfront planning, requirement documentation, and endless reviews — all designed to manage this most costly resource.
Anyone who has worked in the internet industry can surely relate to this. Yet the premise has shifted entirely in the AI era — or more precisely, the Agent era. At the Claude Code team, coding is no longer the bottleneck holding back development speed.
This raises a critical question: if coding itself is no longer the bottleneck, all upstream and downstream workflows built around it need to be reimagined from scratch. Fiona brought up a pivotal term that underpins her entire sharing: shift. Bottlenecks do not vanish; they merely shift elsewhere — toward validation, code review, and security.
With code being generated at unprecedented speeds, fresh challenges emerge: verifying code correctness, ensuring long-term maintainability, and enabling engineers to keep pace with reviewing such large volumes of auto-generated code.
The grey section on the left stands for the old bottleneck: productivity around coding and deployment. The black section on the right represents new bottlenecks: validation, code review, cross-functional collaboration, and security.
This observation about bottleneck shifting becomes increasingly tangible as AI gets more deeply embedded into organizational structures. Our organizational frameworks and workflows must be redesigned to adapt to this massive transformation. It mirrors the transition from horse-drawn carriages to automobiles: swapping horses for engines alone was never enough — entire road networks, traffic regulations, and urban planning all had to be rebuilt from the ground up.
Fiona included a diagram outlining exactly which components require overhauling.
She outlined five traditional process areas gradually becoming obsolete:
- Planning methodologies: Project delivery speed and output volume have been completely transformed.
- Code ownership: Tracking who authored specific code has turned into an awkward conundrum.
- Code review: Disrupted by altered scale, new code formats, and emerging tooling.
- Team composition: Job roles are blurring, making it unclear which skill sets are essential for staffing.
- Knowledge sharing: Documentation is no longer the single source of truth.
Following this breakdown, she introduced five revised internal standards they have built from scratch as alternatives.
These new norms cover five core shifts: keeping human judgment focused on high-value work where it is truly indispensable; drastically cutting onboarding costs such that new hires can deliver production code within just one week; shifting away from heavy upfront planning toward rapid prototyping; prioritizing creativity and critical reasoning over raw coding speed in recruitment; and adopting a flatter organizational structure where all managers start out working on frontline development tasks.
I. Changes to Planning
Back when coding incurred high labor costs, teams were forced to invest excessive hours in upfront planning. Fiona recalled drafting an elaborate six-month product roadmap shortly after joining the Claude Code team. However, the extremely fast iteration pace of Claude Code rendered the roadmap obsolete in roughly three months.
The team now adopts JIT (Just-In-Time) planning, modeled after just-in-time compilation: they complete only the minimum necessary planning at the right moment. Lengthy formal design documents have been scrapped; discussions now unfold directly within pull requests or prototype implementations. Cumbersome pre-launch product reviews are also eliminated. Instead, the team builds prototypes for internal user testing and iterates rapidly based on real-world feedback.
Items on the left mark practices they've eliminated: the ritual of drafting full design documents prior to any coding work. In Fiona's view, such formal documentation is nothing but theater for most tasks — empty performative work with little practical value.
Their updated approach prioritizes prototyping first; formal requirement documents are only added post-development once the code proves viable.
Items on the right represent processes they've doubled down on: validation. In an AI-native workflow, bugs emerge in fundamentally different ways compared with traditional development. Pushing validation earlier into the development pipeline is the only reliable way to safeguard product quality.
She also put forward an insightful viewpoint that resonated deeply with me.
In technical discussions, code wins arguments.
When two people disagree on a solution, the fastest way to resolve it isn't to keep arguing — it's to let Claude build prototypes for both approaches and judge based on real working results.
Building is cheap. Arguing is expensive.
It reminds me of the old days: people would debate solutions, create competing PPTs, and hold two rounds of meetings just to decide. Now, two prototypes are ready in 10 minutes. Discussing from real products is 10,000 times more efficient than arguing over slides.
I follow the exact same approach. Back when I was building AIHOT, I used to write detailed PRDs. Later I realized writing the PRD took longer than just building the product directly with Claude Code.
So I changed my workflow: whenever I have an idea, I build a prototype first. If it works, we move forward. Many features get adjusted on the spot when we find issues during usage — extremely fast iteration.
Frankly speaking, in the AI era, over-planning is just waste.
II. Changes in Automation
As Fiona said: at the Claude Code team, every time they encounter a problem, they ask one follow-up question: Can we automate this?
She shared a personal example. Every morning, she used to sit with her coffee and manually summarize feedback from all customer channels — a daily routine. Later, she turned it into an automated background task. She still drinks her coffee, but no longer has to scroll through reports while doing so.
This example sounds small, right? Just summarizing customer feedback — how much work could that be? But the point isn't this one task. The point is the habit.
Everyone at Claude Code, whenever they face repetitive work, instinctively asks themselves: Can I automate this? She said it has almost become muscle memory.
This is exactly what I've been saying all along: if you have to do something more than 3 times, automate it with AI by any means necessary.
In my company, I tell my team again and again: this isn't even a suggestion — it's a requirement.
But honestly, turning this into team-wide muscle memory is way harder than it sounds. Most people still understand automation at a superficial level: they think it's just writing a script or setting a cron job. But AI-era automation is on a completely different level.
Today, with Claude Code, you can automate many things in 10 minutes — sometimes even less. For example, to sync my home and work computers, I just told Claude:
"Write me a hook that pulls the latest code from GitHub before I open my XX project."
It was up and running in minutes.
In the past, automation was expensive, so only high-frequency, highly repetitive, high-value tasks were worth automating. Now automation costs nearly zero — so the logic flips completely: almost everything repeated more than 3 times should be automated.
Beyond workflows, hooks are incredibly powerful. I think I'll write a separate post later about small automation tricks with Agent + hook — they're really fun.
When you accumulate small automations one by one, you'll eventually realize they've grown into a giant tree before you even notice.
So if you're still hesitating to start, my advice is: don't think big. Don't start by trying to build a full automation system — that's intimidating and unnecessary.
Start today. Pick one thing you repeated today, spend 10 minutes, and let Claude Code automate it. Do another one tomorrow, then another the day after. A month later, you'll look back and realize your entire way of working has completely changed.
III. Changes in Code Review
On code review, Fiona said that over the past six months, when talking to other engineering leaders, the most common question she gets is: How do you keep up with the speed of code review?
Their guiding principle here is Trust but Verify. The Claude Code team relies heavily on code review workflows powered by AI. Claude takes care of style compliance, lint checks, PR feedback, bug detection and remediation, plus supplementary test creation — tasks that once made up 60%–70% of traditional review workload are now fully handled by the model.
Human reviewers remain irreplaceable, however, for work requiring genuine expert judgment. Fiona noted legal compliance matters always demand input from legal teammates for risk assessment. Boundary-setting for trust rules and security-sensitive code calls for subject-matter specialists, while judgments around product positioning and user experience taste fall to product managers and designers.
She specifically stresses that the balance between trust and verification is dynamic. Tasks requiring human oversight today may well be fully automated by future model iterations, which means teams must continually reassess where to draw the dividing line. It is much like playing video games: optimal strategies shift with every game update. Sticking to outdated tactics from old patches for a new version only leads to poor outcomes.
IV. Evolving Team Roles
According to Fiona, role boundaries have blurred extensively across the Claude Code team. Product managers write substantial volumes of code, while engineers regularly take on content and design work; formerly rigid dividing lines between job functions are fading away.
For instance, in the old workflow, after an engineer fixed a bug, they had to wait for content designers to free up their schedules to draft user-facing copy. Anyone in the industry knows how problematic scheduling bottlenecks can be — teams either wait multiple days or rush out hastily written subpar copy to meet deadlines. Under the revised process, Claude drafts the initial copy right after bug fixes, and humans finalize revisions, enabling same-day release.
Gaps across different functional roles are no longer bottlenecks; cross-functional teammates now operate as collaborators. Humans retain ownership of final decisions yet no longer need to produce first drafts from scratch.
She shared a viewpoint I wholeheartedly endorse: her team prioritizes two core traits when hiring new staff.
One type is creative builders with sharp product sense: people who can pinpoint what needs to be built and rapidly spin up prototypes. She underscored a key line explicitly: Taste is scarce, typing is not.
The other type consists of engineers with deep systems expertise, tasked with handling the high-stakes human-led portion of the trust-but-verify workflow, guided by the mantra: subtly wrong is still wrong — even subtle flaws count as errors. She cares nothing for how many lines of code a candidate can churn out per hour. What matters instead is the problems they choose to tackle and how they validate correctness of their work.
When AI boosts execution speed tenfold, the critical differentiator shifts to knowing what to build and what constitutes genuinely high-quality outcomes. That is exactly what taste means in this context.
V. Driving Organizational Change
Fiona's team abides by a set of distinctive core operating principles.
She splits the team principles into two categories. Items shaded grey on the left represent mandatory ground rules, while entries in black on the right leave room for autonomous exploration by individual teams. Essentially, she has built an operational harness for the organization: alignment on top-level strategic direction, yet full autonomy for each group to decide on implementation details.
Fiona highlights three priorities she values most:
- Keep the organization as flat as possible. Managers exist to back team initiatives while enabling flexible talent movement to where work demands manpower.
- Delegate any work doable by Claude to the AI, freeing up engineers for higher-complexity assignments.
- Teams tend to pile new processes atop outdated ones rather than scrapping redundant workflows voluntarily, so leaders must proactively identify and eliminate obsolete procedures by name.
These three rules sound straightforward on paper yet prove tough to implement, especially the third one. Fiona recalled a recurring weekly review meeting from a past role: dozens of attendees sat in the conference room glued to their screens, only lifting their heads to briefly report progress when their turn came before dropping back to their devices. I suspect countless meetings across our industry follow this exact pattern.
She posed a simple question: Why are we still holding this meeting? It dawned on everyone the session served no practical purpose, and it was canceled immediately afterward.
This scenario is commonplace across domestic enterprises. Countless meetings and processes were justified at their inception, yet shifts in business context and tooling have stripped them of all utility; they persist solely out of institutional inertia. Few staff derive real value from them, yet very few dare to call out wasteful, pointless gatherings and propose scrapping them entirely.
The deeper AI integrates into organizational operations, the more legacy steps become eligible for automation. Without regular proactive audits, redundant procedures linger and devolve into empty formalism.
Closing Thoughts
To wrap up, Fiona shared three open-ended questions she is still pondering with no definitive answers — all thought-provoking.
First, do dedicated standalone iOS and Android teams still make sense, given engineers can now work across platforms with far greater flexibility?
Second, how far can fully automated code review realistically scale? Where lies the fine line between "fast enough" and "we've overlooked critical risks"?
Third, as job boundaries keep blurring, how can organizations ensure every team member retains confidence in their deliverables?
I find the mere act of putting forward these three questions incredibly valuable. Even the core Claude Code team behind the product hasn't figured out all the answers and remains in ongoing exploration — there is rarely a universal correct solution to such matters.
Every major wave of transformative technology is never merely an upgrade of tools; it often demands a full overhaul of the organization's entire operating model. Being AI-native is never as simple as purchasing Claude subscriptions or procuring API keys for team usage to check off an AI transformation box. From my perspective, a genuine AI-native enterprise requires full redesign across every layer: planning methodologies, knowledge management, review workflows, and talent architecture alike.
Our team hasn't fully accomplished this transformation yet, but we keep moving steadily toward the goal. Several newly onboarded teammates bring innate curiosity and self-motivation, unburdened by outdated legacy working practices, and their presence has already helped us build early prototypes of our ideal organizational model.
Underpinning all these shifts is the down-to-earth mindset mentioned at the very beginning: automate repetitive tasks, eliminate useless processes, and hand over non-human-dependent judgment work to AI. Take things step by step without rushing, yet never halt progress entirely.
We'll close this piece with Fiona's concluding remarks.
