Welcome to 10x.pub! 👋

[system]

We are so glad you joined us.

10x.pub

For founders & engineers building 10x products

Here are some things you can do to get started:

Introduce yourself by adding your picture and information about yourself and your interests to your profile. What is one thing you’d like to be asked about?

Get to know the community by browsing discussions that are already happening here. When you find a post interesting, informative, or entertaining, use the to show your appreciation or support!

Contribute by commenting, sharing your own perspective, asking questions, or offering feedback in the discussion. Before replying or starting new topics, please review the Community Guidelines.

If you need help or have a suggestion, feel free to ask in Site Feedback or contact the admins.

[eng_director_luis]

This validates our experience piloting SonarQube’s 2026 AI CodeFix across 15 microservices. The predictive debt scoring is the game-changer.

We’re seeing similar patterns - AI detects accumulating complexity that looks fine in individual PRs but becomes problematic at system level. The auto-fix suggestions are surprisingly good for common patterns (null checks, error handling, resource cleanup) but we learned to be very cautious with domain logic fixes.

Key Success: Predictive cost projections help justify tech debt sprints to leadership. Instead of “we should refactor this,” we show “this module will cost 200 engineering hours in 90 days if not addressed. 40 hours now saves 160 hours later.”

The Challenge: High false positive rate initially - took 2 weeks of training/feedback before accuracy reached 80%. Critical lesson: AI recommendations are data points, not decisions. Senior engineers must review and add business context before acting.

How are you handling the balance between AI-recommended fixes versus team-identified pain points? Sometimes AI flags things that aren’t actually blocking us.

[priya_security]

Using Seerene specifically for security debt mapping across our fintech platform. The AI’s ability to trace data flow and predict where injection vulnerabilities might emerge is genuinely impressive.

Real Impact: Found 12 potential security issues before they hit production by analyzing patterns in how we handle user input across microservices. Traditional security scanners check individual files - Seerene analyzed cross-service data flows and flagged: “User input from Service A reaches database query in Service C without validation.”

The Critical Limitation: High false positive rate initially. Took 2 weeks of security team feedback before accuracy reached ~80%. More importantly: never auto-apply security fixes without human review. AI-generated security code can introduce subtle vulnerabilities while fixing obvious ones.

Question for you: How does GitHub Debt Insights handle security-specific debt? We need predictive analysis for auth/crypto vulnerabilities, not just general complexity scores. Are there security-focused modules or is it primarily maintainability-focused?

The pattern we’re seeing: AI is excellent at identifying “this code path is statistically likely to cause problems” but still requires expert judgment about “is this specific problem worth fixing now versus later.”

[vp_eng_keisha]

This is the first AI developer tooling that actually helps with leadership conversations about technical debt rather than creating more work.

The Organizational Value: Makes invisible work visible with dollar amounts. Can show board: “Addressing these 3 high-risk modules now costs 6 weeks. Not addressing them will cost 18-20 weeks in Q3 when they cause production incidents.”

This data-driven framing helped us secure 2 dedicated tech debt sprints per quarter. Pre-AI tools, tech debt discussions were: “Engineers say we need to refactor” vs “Product says we need features.” Now it’s: “AI predicts $200K in incident response costs vs $40K in proactive fixes.”

The Question I’m Wrestling With: How do you balance AI-recommended fixes vs team-prioritized debt? We have modules AI rates as “high risk” that don’t actually cause developer pain, and modules engineers hate working in that AI rates “medium risk.”

I suspect the answer is: use AI predictions as one input, combine with team sentiment, customer impact, and strategic priorities. But curious how others are weighing these factors in sprint planning.

Second Question: How are you preventing gaming of metrics? Worried engineers will optimize for debt scores rather than actual customer value. Have you seen this yet, and how are you guarding against it?

[alex_dev]

Your experience mirrors what I’ve been trying to explain to people about AI migrations - there’s a massive difference between version upgrades and paradigm shifts.

Contrasting Experience: We used AI for Next.js 13 to 14 migration, and it went smoothly. Key difference: version upgrade, not framework change. The mental model stayed the same (React), just API changes (app router, server components).

AI is excellent at: “This API is deprecated, here’s the new API with same semantics.” AI is terrible at: “This framework thinks differently, rewrite your logic to match the new paradigm.”

Your Angular to React migration is fundamentally conceptual translation:

• RxJS observables → useState/useEffect (different reactivity models)
• Dependency injection → Context/props (different composition patterns)
• Two-way binding → Unidirectional flow (different data models)

AI can’t make those conceptual leaps correctly. It pattern-matches syntax but doesn’t understand the philosophy.

Question: What would you do differently if you had to migrate again? Would you still use AI at all, or go fully manual with better planning?

The lesson I’m taking: AI for mechanical transformations (version upgrades, code formatting, boilerplate), humans for conceptual transformations (framework changes, architecture redesigns). Your story is the perfect case study for where that line is.

[eng_director_luis]

Thank you for this honest writeup. This is my nightmare scenario for our banking system modernization, and your experience validates our extremely cautious approach.

Why This Terrifies Me in Financial Services:

Your “worked in demo, broke in production” is exactly what keeps me up at night. In fintech, we can’t afford 7 months of “fixing AI-generated code that looked right.” Regulatory compliance requirements mean we need “works perfectly under audit” not “works in demo.”

Your timeline slippage (2 months planned → 9 months actual) is worse in financial services:

• 9 months of engineering capacity consumed
• Regulatory recertification for any major framework change
• Compliance auditors asking: “Can you explain every code change AI made?”
• Zero tolerance for accessibility violations (you can fix later, we’d face legal liability)

The Risk Profile: AI-assisted framework migration in fintech combines two catastrophic risks:

1. Technical risk (things break in production)
2. Compliance risk (auditors can’t verify AI-generated code correctness)

That’s why we banned AI from architectural migrations and use it only for: documentation, test generation, and code review assistance. Humans do all actual logic migration with AI as documentation assistant.

Question: How did you manage stakeholder expectations during the 7-month delay? When did you tell leadership “AI migration isn’t working, we need 7 more months”? That conversation must have been difficult.

Your honesty is valuable. Most posts share successes. Sharing failures helps the industry learn where AI actually works versus where it’s marketing hype.

[product_david]

From product perspective, this is the conversation that never happens early enough: 7 extra months equals massive opportunity cost.

Let me calculate what 7 months of engineering capacity costs for a typical product team:

• 7 months × 3-person team = 21 engineer-months
• Could have shipped 2-3 major features
• Could have addressed customer feature requests
• Could have improved key metrics (activation, retention, monetization)
• Lost competitive positioning (competitors don’t wait)

The AI Migration Promise Created Planning Problems:

When engineering estimated “2 months with AI assistance,” product planned around that:

• Committed to Q2 feature launches
• Told customers features were coming
• Built roadmap assuming migration done by April

Then migration took until November. Those commitments failed. Customer trust damaged. Feature roadmap disrupted.

The Hidden Product Lesson: AI migration promises create unrealistic planning assumptions. I’m now pushing back on any engineering estimates that assume “AI will accelerate this.” Want two timelines: “AI-assisted estimate” and “manual estimate.” Plan for the manual timeline, hope for the AI acceleration.

Question: How did this impact your product roadmap and customer commitments? Did you have features blocked by the migration? How did you communicate delays to users/customers?

The engineering lesson is “AI can’t translate paradigms.” The product lesson is “don’t let AI promises drive planning timelines.” Both valuable.

[eng_director_luis]

This is the conversation financial services desperately needs. Your fraud detection incident is exactly the regulatory nightmare scenario we’re trying to avoid.

The Regulatory Perspective: We cannot put unauditable AI in transaction processing or compliance workflows. Period.

When regulators audit our systems, they require:

• Deterministic decision-making
• Explainable logic
• Ability to reproduce historical decisions
• Clear accountability chain

LLM APIs fail all four requirements:

• Non-deterministic (same prompt can give different outputs)
• Black box (can’t explain why)
• Can’t reproduce (model versions change/deprecate)
• External vendor (we don’t control it)

Our Current Stance: AI banned from customer-facing and regulatory-critical paths. We use it for:

• Developer tools (documentation, test generation)
• Internal efficiency (support ticket routing)
• Analysis/insights (non-binding recommendations)

Never for: transaction decisions, compliance checks, fraud blocking, customer data processing.

The Question That Matters: How do you handle explainability requirements in fintech? When regulators ask “why did you flag this transaction,” what do you tell them if AI made the call?

The risk isn’t just technical or economic - it’s regulatory. One audit failure from unexplainable AI decision-making could cost us our banking license. That risk exceeds any efficiency gain.

[alex_dev]

Built the exact abstraction layer you’re describing for exactly this reason. LLM calls go through our internal API that handles fallbacks, caching, cost limiting, and circuit breakers.

Architecture Pattern:

Application → Internal LLM Service → [GPT-4, Claude, Local Model]
                                    ↓
                                Monitoring, Fallbacks, Cost Controls

What This Enabled:

When GPT-4 had outage last month, our system automatically failed over to Claude with modified prompts. Added 200ms latency but maintained availability. Users never noticed.

Cost Control: Set budget ceiling at $X/day. When hit, system automatically:

1. Switches to cheaper models for non-critical tasks
2. Increases caching aggressiveness
3. Degrades to rule-based for some features
4. Alerts engineering team

The Investment: Took 2 weeks to build abstraction layer upfront. Has saved us from 3 production incidents and prevented cost overruns 5 times.

Key Pattern: Treat LLM APIs like any external dependency:

• Wrap in abstraction layer
• Monitor for failures
• Have circuit breakers
• Design graceful degradation
• Never hard-code provider in application logic

Worth the upfront investment. Saved us multiple times already.

Question: How are you handling prompt version control? We store prompts in git, but testing prompt changes is still painful. Any good patterns for “prompt regression testing”?

[vp_eng_keisha]

The economic dependency is what keeps me up at night as VP Eng. We built features users love, can’t remove them without customer revolt, and monthly costs are 15% of infrastructure budget and growing.

The Business Model Problem:

Started with AI features as “value add” at no extra charge to customers. Users adopted them heavily. Now:

• $18K/month in LLM API costs
• Growing 20% monthly with usage
• Can’t remove features (customer expectations set)
• Can’t easily pass costs to customers (pricing model doesn’t support it)

This is tech debt that becomes business model debt. We designed pricing before understanding AI cost scaling.

The Strategic Risk: If OpenAI 10x’s prices tomorrow, we have three bad options:

1. Absorb cost (kills margins)
2. Pass to customers (requires repricing, migration, customer conversations)
3. Rebuild features (6+ months engineering time)

None of these are good. We’re strategically dependent on external roadmaps we don’t control.

Considering Self-Hosted Models:

• Pros: Cost predictability, control
• Cons: ML expertise gap, infrastructure complexity, accuracy trade-offs

Different complexity, not necessarily better.

Question for Group: How are others handling the economics? Usage-based pricing for AI features? Reserved capacity contracts? Self-hosted models? What’s actually working in production?

This is the first time I’ve dealt with infrastructure costs that scale unpredictably with user behavior AND are controlled by external vendors. Traditional cloud costs scale predictably. LLM costs are wild west.

[product_david]

From product perspective, this is vendor lock-in 2.0, and it’s more insidious than traditional vendor lock-in because it’s at the UX level.

Traditional Vendor Lock-In: Backend infrastructure (database, cloud provider). Painful to switch but invisible to customers.

AI Model Lock-In: User experience is designed around specific model capabilities. GPT-4’s specific outputs, response times, accuracy levels. Switching models means redesigning UX.

Real Example: We built chat-based feature exploration using GPT-4. UX flow assumes:

• Responses in 2-4 seconds
• Specific tone/personality
• Particular level of context understanding

If we switch to different model with 6-second response time or different personality, UX breaks. Users complain “it feels different/worse.”

The Hidden Lock-In: Prompt engineering is product knowledge, not in docs but in engineers’ heads and Slack threads. If we need to switch providers:

• Rewrite all prompts for new model
• Regression test all outputs
• Potentially redesign UX flows
• Retrain users on “how it works now”

This is much stickier than “switch from AWS to GCP.”

The Strategic Question: If OpenAI controls our UX and can change pricing/terms anytime, do we actually own our product?

We’ve built features where core product experience depends on external vendor’s roadmap, pricing, and availability. That’s a strategic vulnerability board should understand.

What I’m Pushing For:

1. AI features must have non-AI fallback (degraded but functional)
2. Pricing model accounts for AI cost unpredictability
3. Architecture review for any new AI dependencies
4. Quarterly “can we switch providers” assessment

AI features create product value but also strategic risk. We need to measure both, not just the upside.

[product_david]

As the PM who doesn’t touch code but feels the impact of these decisions, I appreciate the honesty about your failed startup’s GraphQL experience.

Time to Market Is Everything

Your point about spending more time on GraphQL infrastructure than user-facing features - this is what keeps me up at night.

The opportunity cost of technical complexity:

• Every hour spent building GraphQL infrastructure is an hour not spent on features customers asked for
• Every week debugging N+1 queries is a week we’re not talking to customers
• Every sprint planning meeting discussing schema design is time not spent on product strategy

I’m not anti-GraphQL. I’m anti-technology-for-technology’s-sake.

The Question I Ask Engineering

When evaluating REST vs GraphQL (or any tech decision):

What customer problem does this solve that simpler tech doesn’t?

If the answer is “better developer experience” - that’s valid, but:

• Does better DX lead to faster feature delivery?
• Does faster delivery lead to better product-market fit?
• Does it compound over time or is it one-time gain?

If the answer is “enables features customers want” (e.g., real-time updates, complex data aggregation) - now we’re talking.

Mobile App Implications

You mentioned mobile apps working better with REST. Can you elaborate?

We’re building iOS and Android apps. Our mobile team has been lobbying for GraphQL because:

• Reduces API calls (battery life)
• Flexible queries (different data needs per screen)
• Typed schema (Swift/Kotlin codegen)

But you chose REST. What made that the right call for mobile?

Is it caching? Offline support? Team expertise? I need to understand the trade-offs.

The Hybrid Approach Makes Sense

REST for public APIs, GraphQL for internal tools - this is pragmatic.

From a product perspective:

• Public APIs need to be stable, well-documented, familiar to partners (REST wins)
• Internal tools can move faster, team controls both sides (GraphQL makes sense)

This mirrors what Luis said about different API styles for different audiences.

Question: Did you design the REST API to enable future GraphQL layer on top? Or are they completely separate?

Some companies expose GraphQL that wraps REST endpoints. Gives flexibility to external consumers while keeping internal benefits.

[vp_eng_keisha]

Maya, thank you for sharing the failed startup story. That kind of vulnerability helps all of us learn.

The Team Context Point Is Critical

Your decision framework - REST for production, GraphQL for internal tools - makes perfect sense for an 8-person team.

At different team sizes, different trade-offs:

5-15 engineers: Keep it simple. REST, familiar stack, boring technology. Ship fast.

15-50 engineers: Can start specializing. Platform team can own GraphQL infra. Product teams benefit from flexibility.

50+ engineers: Multiple API styles make sense. Different teams, different needs, different expertise.

We’re at 25 engineers scaling to 80+. The question I’m wrestling with: When do we have enough bandwidth to support GraphQL for some use cases?

Currently all REST. But our mobile team (like David mentioned) really wants GraphQL for the reasons you listed.

The Hiring and Onboarding Lens

Your contractor story highlights something we track closely: time to first commit for new hires.

With familiar tech (REST, PostgreSQL, React):

• New hires productive in 1-2 weeks
• Can hire from broader talent pool
• Less specialized knowledge required

With specialized tech (GraphQL, CQRS, event sourcing):

• 3-4 weeks to productivity
• Narrower hiring pool (or train them)
• More documentation and mentorship needed

At our stage, time to productivity matters enormously. We’re doubling the team - that’s ~40 new engineers to onboard this year.

Question: How did your 8-person team handle knowledge transfer? Bus factor with GraphQL expertise concentrated in one person seems risky.

The Design System Connection

Your point about API design affecting component architecture is something I don’t see discussed enough in engineering leadership circles.

We’re building a design system for our EdTech platform. The questions we’re grappling with:

1. Should components handle their own data fetching? Or stay pure and presentational?
2. How do we make components reusable across different data sources?
3. What’s the contract between design and engineering on data requirements?

The API architecture choice (REST vs GraphQL) directly impacts these decisions.

With REST and container/presentational split:

• Design system stays pure and portable
• But more boilerplate in app code
• Clearer boundaries between concerns

With GraphQL co-located queries:

• Less boilerplate, faster iteration
• But components coupled to GraphQL
• Harder to reuse in different contexts

For a design system team, which approach do you recommend? Pure components, or co-located data?

The Maturity Progression

What I’m taking from this entire thread series (tRPC, database choices, CQRS, API versioning, GraphQL):

Technology choices should match organizational maturity:

Early stage (Product-market fit):

• Simple stack
• Fast iteration
• Technical debt okay

Growth stage (Scaling):

• Can add complexity where it delivers clear value
• Invest in platform/infra
• Strategic technology choices

Mature stage (Optimization):

• Multiple technologies for different use cases
• Strong governance and standards
• Operational excellence focus

We’re transitioning from early to growth stage. These discussions help me understand what complexity is worth adding when.

Thank you for the honest, pragmatic take. More of this, less hype!