--- title: Developer Productivity in an AI-First Startup description: "a single typed language across the stack everywhere, automated testing, feature flags for AI experiments, and ruthless scope discipline. How a small team ships fast on a complex product." canonical: https://nowah.xyz/blog/developer-productivity-ai-first-startup lastModified: "2026-08-07T03:47:32.944Z" --- # Developer Productivity in an AI-First Startup a single typed language across the stack everywhere, automated testing, feature flags for AI experiments, and ruthless scope discipline. How a small team ships fast on a complex product. We ship production features to an AI travel booking platform with a team that would make most enterprise engineering managers nervous. Not because the team is bad. Because it is small. The reason we can do this comes down to a handful of decisions we made early and have doubled down on since. This is not a post about productivity hacks or morning routines. It is about the structural decisions, from language choice to testing strategy to feature flag architecture, that let a small team move at a pace that feels unreasonable. ## a single typed language across the stack everywhere ![Illustration for this section](https://pics.nowah.xyz/website-media/engineering-052-img-1.webp) I know. Everyone says this. But most teams that say "a single typed language across the stack everywhere" mean "a single typed language across the stack on the frontend and some of the backend." We mean everywhere. Frontend. Backend. AI agent orchestration. Database schema definitions. Test suites. Background job workers. Build scripts. The productivity gain is not about a single typed language across the stack being a better language than alternatives. It is about eliminating context switching. When an engineer moves from fixing a bug in the chat interface to updating the booking API to adjusting how the AI agent formats tool results, they are in the same language, the same type system, the same mental model. Full-stack a single typed language across the stack teams report 20-40% productivity gains, and in our experience that number is conservative when you factor in the compounding effects over months. Shared types between frontend and backend are the specific force multiplier. When we add a new field to a trip object, the type definition propagates everywhere. The backend route handler knows about it. The API client knows about it. The React component rendering it knows about it. Type errors show up at compile time, not at runtime in production. This matters more for AI products because the data structures are complex and evolving. A travel agent's tool call results, search parameters, booking states, and conversation contexts involve deeply nested objects that change frequently. In a polyglot stack, keeping those structures synchronized across languages would be a full-time job. ## Automated testing as the safety net A small team cannot afford manual QA cycles. Every hour spent manually testing is an hour not spent building features. Our approach is simple: automate everything that can be automated, and make the automation fast enough that it does not slow down deployment. Our CI pipeline runs unit tests, integration tests, and AI eval suites on every pull request. Unit and integration tests finish in under two minutes. Eval suites take longer because they involve actual AI inference, but we run them in parallel and have optimized the suite to focus on the highest-risk areas. Automated testing reduces regression incidents by 60-80%. For an AI product, this number is even more impactful because AI regressions are harder to detect manually. A small degradation in search result quality might take days to surface through user complaints. An automated eval catches it before the code merges. We also run tests on a schedule against live third-party APIs. Travel APIs change their behavior without notice. A weekly smoke test against production endpoints catches breaking changes before they affect users. ## Code review for AI system changes ![Supporting diagram](https://pics.nowah.xyz/website-media/engineering-052-img-2.webp) Reviewing a prompt change is nothing like reviewing a code change. Code changes have deterministic effects. You can read the diff and reason about what will happen. Prompt changes have probabilistic effects. The same prompt tweak might improve 80% of conversations and break 20%. We developed a review process for AI changes that treats them differently. Every prompt change comes with eval results showing the before and after scores. Reviewers do not just read the diff. They look at how the change affected real conversation samples. If the eval scores improved overall but degraded on specific categories, we discuss the trade-off explicitly. [Feature flags](/blog/feature-flags-high-stakes) play a big role here. We can merge a prompt change behind a flag, enable it for a percentage of traffic, and monitor the results before rolling it out fully. This is not novel, but applying it to AI behavior rather than UI features changes the monitoring requirements. We are watching conversation quality metrics, not click-through rates. ## Feature flags for AI experiments Feature flagging for AI experiments is one of the most underrated productivity tools we have. It lets us test different agent behaviors without deploying new code, which means experiments run faster and rollbacks are instant. Our flag system supports several types of AI experiments. Different model instructions for different user segments. Different tool configurations for different conversation types. Different ranking algorithms for different markets. Each experiment runs independently, and we collect metrics on conversation quality, booking completion rates, and user satisfaction for each variant. The alternative to feature flags is branch-based development where each experiment lives in a separate code branch, gets deployed to a separate environment, and requires manual traffic routing. That approach works fine when you are running one or two experiments at a time. When you are running ten, it falls apart. Feature flags let us run many experiments concurrently without the operational overhead. ## AI-assisted development building the AI product There is something satisfyingly recursive about using AI development tools to build an AI product. We use AI-assisted coding extensively, and the productivity impact is real. For experienced engineers, AI code assistance increases output by 30-50%. Not by writing code for us, but by handling the boilerplate so we can focus on the hard parts. The pattern that works best for us is using AI assistance for the structural and repetitive work. Generating a single typed language across the stack types from API responses. Writing test scaffolding. Creating boilerplate for new API endpoints. Drafting database migration files. These tasks used to take an engineer 30-60 minutes of tedious work. Now they take 5 minutes of reviewing and adjusting AI-generated output. Where AI assistance does not help much is the genuinely hard engineering work. Designing the agent's tool orchestration logic. Debugging non-deterministic test failures. Optimizing streaming performance. Architecting the booking [saga pattern](/blog/saga-pattern-ai-booking-distributed-transactions). Those tasks require deep context and creative problem-solving that current AI tools cannot provide. The productivity gain is concentrated in the 60% of engineering work that is mechanical, which frees up time for the 40% that is creative. ## How this compares to large OTA engineering teams I do not want to be unfair to big companies. They face challenges we do not. Compliance requirements. Legacy system maintenance. Organizational coordination across hundreds of engineers. Those are real burdens. But the speed difference is stark. We ship AI agent improvements in days. A comparable change at a large OTA takes weeks to months. Not because their engineers are slower, but because the organizational machinery around each change, the approval processes, the cross-team coordination, the deployment windows, adds latency that dwarfs the actual engineering time. Small AI-native teams iterate in days where legacy platforms iterate in months. That speed gap is our competitive advantage. We are not smarter. We are faster. And in a market where the technology is evolving as quickly as AI is right now, speed wins. The decisions that enable this speed are not glamorous. a single typed language across the stack everywhere. Automated tests. Feature flags. AI-assisted development. Ruthless scope discipline. None of these are revolutionary ideas. The leverage comes from applying all of them consistently, over time, with a team that is small enough to stay aligned without process overhead. That is the real productivity secret. It is not any single tool or practice. It is the compounding effect of many good decisions executed by a team that trusts each other enough to move fast. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).