Y Combinator informa de que o 25% do seu proxecto W25 ten bases de código que son 95% xeradas por IA. Este artigo discute os verdadeiros compromisos: velocidade vs. débeda técnica, prototipo vs. produción, e por que os enxeñeiros seniores reportan desenvolvemento inferno. Hai unha nova forma de construír software que está tomando Silicon Valley por tempestade, e honestamente, estiven observando con unha mestura de fascinación e horror. En febreiro de 2025, Andrej Karpathy acuñou o termo "codificación de vibe", e dentro de semanas, tornouse a palabra máis quente na tecnoloxía. En marzo, Y Combinator informou que 25% do seu lote de inverno 2025 tiña bases de código que eran 90% xeradas por IA. Vinte e cinco por cento das startups máis prometedoras do mundo están enviando produtos onde Como alguén que construíu software de nivel de infraestrutura como Sayna, podo dicirlle que esta estatística manténme á noite, pero probablemente non polas razóns que esperaría. ¿Que é exactamente Vibe Coding? Déixeme citar o tweet orixinal de Karpathy porque capta perfectamente a esencia do que estamos a tratar: É un novo tipo de codificación que chamo "codificación de vibe" na que se cede completamente ás vibracións, abraza os exponenciais e esquece que o código existe. "acepto todo" en, xa non leo os difos, cando recibo mensaxes de erro só os copio con ningún comentario, normalmente que o fixa. " É un novo tipo de codificación que chamo "codificación de vibe" na que se cede completamente ás vibracións, abraza os exponenciais e esquece que o código existe. "acepto todo" en, xa non leo os difos, cando recibo mensaxes de erro só os copio con ningún comentario, normalmente que o fixa. " Isto vén dun ex-investigador de OpenAI e director de IA de Tesla que axudou a construír algúns dos sistemas de IA máis avanzados do planeta está dicíndonos que só ... buzz con iso. E aquí está a cousa: para botar fóra proxectos de fin de semana como foi descrito orixinalmente por Karpathy, iso realmente ten moito sentido; o problema é que as startups tomaron esta filosofía e lanzárona directamente á produción. A verificación de realidade do combinador Y Cando o socio xestor de YC, Jared Friedman, anunciou estas estatísticas, foi rápido para aclarar algo importante: estes non eran os fundadores non técnicos que loitaban con ChatGPT, senón enxeñeiros altamente cualificados que, hai un ano, terían construído todo desde cero - elixiron non, porque a IA foi o suficientemente boa. Garry Tan, CEO de YC, o dixo abertamente: "Isto non é unha moda.Isto non vai desaparecer.Isto é o xeito dominante de codificar, e se non o está a facer, só pode quedar atrás." Pero aquí está o que chamou a miña atención nesta conversación: Tan advertiu o que acontece cando unha startup con 95% de código xerado por IA atinxe a 100 millóns de usuarios: "Cai ou non?" Esa é a historia da que ninguén quere falar. O hangover é real Nos últimos meses, estiven vendo as discusións de enxeñeiros e CTOs e as historias comezan a derramarse: un director de enxeñería senior de Navan levantou un punto crucial que a maioría das discusións de codificación de vibe perden por completo: "A IA está estendendo ou refactorizando características ou son todos proxectos de campo verde?" A resposta importa máis do que a maioría da xente entende: Construír algo desde cero é fundamentalmente diferente de manter sistemas que acumularon anos de coñecemento tribal, patróns e, si, débeda técnica. Aquí está o que está a suceder na produción: Un desenvolvedor desilusionado compartiu: "Estou intentando crear o meu pequeno proxecto pero cada vez hai máis e máis erros... Estou traballando nel durante uns 3 meses pero cada vez que quero cambiar unha cousa menor, eu matei 4 días debugando outras cousas que van ao sur" The Debugging Nightmare : Un arquitecto de software describiu o que el chama "débeda de confianza" despois de que un desenvolvedor junior maltratou un sistema de permisos de usuario que pasou as probas, sobreviviu á QA e lanzou con éxito. Dúas semanas máis tarde, descubriron que as contas desactivadas aínda podían acceder ás ferramentas de backend debido a unha verificación de verdade invertida que "parecía funcionar no momento". The trust debt problem Estamos vendo unha división na industria: hai "construtores nativos de IA" que poden entregar funcións rapidamente, pero que loitan co desmantelamento, a arquitectura e o mantemento a longo prazo; e entón hai "arquitectos de sistemas" que entenden as implicacións das decisións técnicas e poden navegar pola complexidade xerada por IA. Adiviña que grupo se está facendo máis valioso? Problema: dous enxeñeiros creando a débeda de cincuenta Hai unha broma facendo roldas en círculos de enxeñería: "Dous enxeñeiros agora poden crear a débeda tecnolóxica de cincuenta." O código xerado por IA sen verificación amplifica a débeda técnica de maneiras que nunca vimos antes.A queixa de broma contén un gran de realidade que está esnaquizando os equipos de enxeñaría.O código parece perfecto na superficie, pero debaixo é o que algúns chaman "código de casa de tarxetas" - parece completo pero colapsa baixo presión do mundo real. Isto maniféstase de varias formas distintas: En primeiro lugar, emerxen patróns de codificación inconsistentes cando a IA xera solucións baseadas en diferentes prompts sen unha visión arquitectónica unificada e acaba cunha base de código de patchwork onde se resolven problemas similares de xeitos completamente diferentes. En segundo lugar, a documentación vólvese escasa ou unha inexistencia porque o foco cambia para a enxeñaría de prompt en vez de explicar a funcionalidade do código.O desenvolvedor que escribiu os prompts pode entender o que pediron, pero a lóxica real da implementación permanece un misterio. Terceiro, e este é o temible, as vulnerabilidades de seguridade crepan a taxas alarmantes: un estudo descubriu que os modelos de IA introducen vulnerabilidades de seguridade coñecidas no código 45% do tempo. Onde a codificación Vibe realmente ten sentido Vou ser honesto, non estou aquí para dicirche que a codificación de vibe é malo e debería ser prohibida. Iso sería hipócrita porque uso a asistencia de IA todo o tempo no meu fluxo de traballo de desenvolvemento. Vibe Coding funciona moi ben para: Prototipos e probas de conceptos onde necesitas validar rapidamente unha idea Proxectos de fin de semana e experimentos onde o custo do fracaso é baixo Aprender novos idiomas e marcos onde a IA serve como un tutorial acelerado Código de boilerplate que segue patróns ben establecidos Compoñentes de UI e operacións simples CRUD Onde cae é calquera cousa que require: Comprensión profunda do comportamento do sistema baixo carga Compoñentes críticos de seguridade que manexan datos de usuario ou autenticación Código de infraestrutura onde a fiabilidade e a latencia importan máis que a velocidade de desenvolvemento Lóxica empresarial complexa que necesita evolucionar ao longo do tempo Sistemas de procesamento en tempo real onde os milisegundos importan Excepcións de infraestruturas Aquí é onde teño que falar do que estamos construíndo: cando traballas con software de infraestrutura, a tolerancia para "funciona principalmente" cae a cero; cando estás a manexar procesamento de voz en tempo real, conexións WebSocket ou streaming de audio, non hai "Aceptar todo" En Sayna estamos a construír unha capa de voz unificada para os axentes de IA, o que significa xestionar voz a texto, texto a voz e transmisión de audio en tempo real con requisitos de latencia subsecundaria. Podería codificar algo disto? Quizais as partes máis sinxelas, pero a arquitectura principal? Os tubos de filtración de ruído? A capa de abstracción do provedor que necesita cambiar entre Deepgram, ElevenLabs, Google Cloud e Azure sen caer cadros? Absolutamente non. A razón é simple: o código de infraestrutura é a base que depende dos produtos doutras persoas.Cando esta base está construída sobre vibracións en vez de comprensión, todo enriba se fai fráxil. O que realmente fan os enxeñeiros Aquí está o paradoxo interesante: os enxeñeiros seniores están a obter máis valor das ferramentas de codificación de IA que os juniors - a razón é clara se o pensas: os anciáns teñen o coñecemento para dirixir a IA correctamente e reparar os seus erros - tratan a saída de IA como o código dunha nova contratación, inspeccionando cada liña, asegurándose de que a entenden antes de que a envíe. Un CTO describiu a nova realidade perfectamente: a codificación de vibe é un excelente método para avanzar unha idea de 0 a 0,7, pero que o último 0,3, a parte que fai que o software realmente funcione na produción, aínda require enxeñaría humana. Os equipos máis exitosos que vin tratan a axuda de IA como ter un desenvolvedor super-rápido pero máis novo no equipo - a IA podería arrancar o primeiro proxecto, pero un enxeñeiro senior aínda o revisa cun ollo crítico, refinando e asegurando que cumpra cos estándares de calidade. É por iso que "a codificación da vibe está morrendo" non é moi correcta; o que está morrendo é a fantasía de que podes enviar software de produción sen entender o que estás enviando. O último proxecto de The Irony of Karpathy En outubro de 2025, Karpathy lanzou un novo proxecto chamado Nanochat.Alguén lle preguntou canto era xerado por IA e a súa resposta foi: "Tentou usar axentes Claude / Codex algunhas veces, pero non funcionaron o suficiente e fixeron a rede inútil". O pai da codificación de vibe non confía na técnica para os seus propios proxectos serios, deixe que se afunde por un momento. Construción a longo prazo Se está comezando hoxe unha empresa ou proxecto, aquí está o que eu suxeriría: Use o soporte de IA agresivamente para prototipos e MVPs, pero teña un plan para a transición de "código vibrado" a "código de produción". Know Your Boundaries As startups que sobrevivirán ao hangover de codificación de vibe serán as que investiron desde o principio na arquitectura adecuada: a IA pode axudarche a escribir código máis rápido, pero non pode axudarche a deseñar sistemas que escalen. Invest in Architecture : Para todo o que xestiona os datos do usuario, procesa o pagamento, xestiona a autenticación ou necesita ser executado 24/7, tome o tempo para construílo correctamente. Build critical infrastructure correctly Se estás a usar a IA para xerar código, asegúrate de que o teu equipo estea aprendendo diso, non só aceptándoo. Create learning loops Para nós en Sayna, isto significa construír en Rust para garantías de rendemento, implementar probas axeitadas, manter documentación clara e deseñar sistemas que evolucionen a medida que cambian os requisitos - non é tan rápido como vloggar o noso camiño a través do desenvolvemento, pero é o único enfoque que ten sentido para a infraestrutura na que outras persoas dependen. O futuro é híbrido O futuro do desenvolvemento de software non é pura codificación de vibe máis que pura codificación manual, está nalgún lugar no medio, onde a IA acelera o desenvolvemento e os humanos proporcionan calidade. As empresas que saiban este balance gañarán: enviarán máis rápido que as tendas de desenvolvemento tradicionais evitando o tsunami de débedas técnicas que a codificación de vibe puro causa; terán enxeñeiros que poidan debutar problemas porque entenden o que enviaron; construirán sistemas que escalen porque alguén realmente pensou na arquitectura. A angustia é real, pero tamén é evitable: só tes que saber cando deixar de beber a AI Kool-Aid e comezar a enxeñaría. Se está construíndo a seguinte gran cousa e o 95% do seu código vén de prompts de IA, teño unha pregunta: ¿entendes realmente o que estás enviando? porque se non, este hangover está chegando. Non esqueza e compartir se o atopa útil! e se está a tratar co seu equipo con débeda técnica de codificación de Vue, gustaríame escoitar as súas historias nos comentarios.
