Interviews · GitHub · Frontend

The 3 A.M. Difference Between Outsourced and Big Tech Frontend Code

By 怕浪猫 · Oct 23, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

As AI makes happy-path code nearly free, teams that pay only for visible features accumulate hidden debt that settles at 3 a.m. as a P0 phone call. The line between cheap and expensive code has moved from writing features to defining correctness and carrying responsibility for the invisible layers.

Summary

Frontend code from outsourced vendors and big tech teams is shaped by the payment model before it is shaped by skill. Outsourcers settle by project and bill by person-day, so the rational target is a feature that passes acceptance on demo day; big tech teams keep iterating for years, and a hidden bug can surface six months later as an incident affecting millions of users. The same feature therefore converges on the happy path and diverges everywhere else.

The divergence lives in five invisible layers: full-chain defense from external input to error reporting, a system-level separation of state, services, and presentation, exception paths such as duplicate submission and setState after unmount, observability through Sentry-style error capture and dashboards, and security defenses like HttpOnly cookies and CSP that no acceptance checklist ever lists. Each layer costs money and shows no visible result on the demo, which is why outsourced code skips them without anyone being negligent.

AI changes the arithmetic. Generated happy-path code is nearly free, so visible functionality stops being a differentiator. The new rule, in the words of a V2EX commenter, is that code that cannot be changed is cheap and code that can be changed is expensive. What still has value is defining what counts as correct, designing the exception paths, and owning responsibility when something breaks at 3 a.m.

Takeaways

— Outsourcing bills by project or person-day, so the optimal move is to make the feature pass acceptance on demo day and treat every other concern as a cost.

— Big tech teams plan for code to be maintained for years by rotating staff, which is why strict ESLint, TypeScript strict mode, and code review are enforced.

— TypeScript validates types at compile time only; HTTP responses still need runtime schema validation before the UI can trust them.

— Five layers separate production code: full-chain defense, system-level component separation, exception paths, observability, and security.

— A common exception-path bug is setState in an async callback after a React component unmounts; a cancelled flag fixes it.

— Outsourced systems typically ship without frontend monitoring, while big tech systems use Sentry, business-step tracing, and response-time and error-rate dashboards.

— Security defenses such as HttpOnly cookies, input escaping, and CSP are absent from acceptance checklists, so outsourced code omits them as a rational response to the payment model.

— A client spent 40,000 RMB on an outsourced submission system and hit problems everywhere after acceptance; another commenter noted the client's testing cost can exceed building it themselves.

— One company's internal review expected 60,000 lines to cover all features, but the outsourcer delivered 180,000 lines, much of it AI-generated.

— The outsourcing model now has two moats: complex business context AI cannot handle, and someone to take responsibility when things break.

— A review checklist should cover HTTP status validation, runtime data validation, loading/empty/error UI states, async cancellation, catch blocks with context, and token storage outside localStorage.

Conclusions

The acceptance demo is the product outsourced development actually sells, so maintainability standards from long-lived teams grade a sprint by marathon rules.

AI removes the only cost advantage outsourcing had: when generating visible code no longer requires paying a vendor, the vendor's remaining value is context and liability, the two things the model never priced.

The “unchangeable code is cheap, changeable code is expensive” distinction applies beyond vendors; teams that refuse to pay for change will eventually pay to be stuck.

The six-question checklist doubles as a career filter: the skills that survive AI are writing acceptance criteria, designing error paths, and building observability, not producing happy-path code.

Concepts & terms

Happy path

The ideal flow where the API returns 200, the data is well-formed, and the user does exactly what is expected. Code that only covers the happy path passes demos and fails in production.

Runtime schema validation

Checking API response data against a defined structure at runtime, independent of compile-time TypeScript types. It treats every HTTP response as untrusted input.

HttpOnly cookie

A cookie flag that prevents JavaScript from reading the cookie, so a successful XSS attack cannot steal the token stored in it.

Content Security Policy (CSP)

A browser security mechanism that restricts which sources scripts can load from, reducing what an injected script can do.

P0 incident

The highest-severity production incident, commonly a large outage or data breach, that requires immediate attention regardless of the time of day.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗