Què és Replit
Replit és una plataforma al núvol per crear i executar programari, amb editor de codi, agents d’IA, dades i publicació. Actualment inclou aplicacions web i mòbils, dissenys, visualitzacions i altres materials dins de projectes.
La unitat de treball no és només resposta textual: pot ser un programa que rep entrades, consulta serveis i desa informació. Cal distingir idea, implementació generada i comportament comprovat. Una interfície convincent és part del resultat; també importen regles, resposta als errors i qui la mantindrà quan canviïn necessitats. Aquesta distinció ajuda a decidir quines parts es poden mostrar com a demostració i quines requereixen més treball.
Documentació de referència: Agent overview.
Origen, empresa i nom
JSRepl va aparèixer com a prototip el 2011. Amjad Masad explica la inspiració d’escriure i executar codi al navegador i compartir entorns. L’empresa es va fundar el 2016, amb Amjad Masad i Haya Odeh com a cofundadors i Faris Masad com a enginyer fundador segons perfils oficials.
El nom remet a REPL, cicle de llegir una expressió, avaluar-la i mostrar resultat. El març de 2021 es va anunciar el pas de repl.it a replit.com; el gener de 2025 els projectes Repls van passar a Replit Apps. Això explica terminologia antiga en tutorials i repositoris.
Documentació de referència: Replit origins and name · About Replit · Faris Masad biography · 2026 financing · Replit Apps name.
D’entorn de codi a plataforma amb agents
Replit Agent es va llançar el setembre de 2024. Agent 4 va arribar l’11 de març de 2026 ampliant treball creatiu i paral·lel. El juliol de 2025 es va anunciar col·laboració amb Microsoft per a empreses i distribució amb Azure.
El març de 2026 l’empresa va anunciar 400 milions de dòlars de finançament amb valoració de 9.000 milions i al setembre la primera oficina internacional a Londres. Són fites corporatives datades, no garanties d’una aplicació. L’evolució central és passar de facilitar escriptura de codi a coordinar construcció, configuració i revisió mitjançant llenguatge natural.
Documentació de referència: Agent introduction · Agent 4 · Microsoft partnership · 2026 financing · London office.
Planificació, modes i canvis
Plan Mode permet discutir un enfocament abans de modificar codi o dades. Els modes actuals són Free, Power i Max; Power substitueix Economy. Auto selecciona models per treball de pagament segons configuració i pla.
Un encàrrec útil defineix usuaris, dades, resultat i excepcions. «Cercar documents» exigeix idioma, ordre, camps i resposta sense coincidències. Divideix el treball en canvis comprovables. Si una versió cerca bé però ordena malament, corregeix ordre sense reconstruir-ho tot. Un model més capaç no resol una regla de negoci que ningú ha definit. Conserva exemples del resultat esperat per comprovar les revisions.
Documentació de referència: Agent overview · Agent modes.
Projectes, codi i resultats
Un projecte pot reunir artefactes com aplicació web, mòbil i presentació, compartint dades i serveis. L’editor permet inspeccionar codi i continuar implementació més enllà de la conversa.
Compartir backend evita duplicar informació, però un canvi pot afectar diverses interfícies. Si una llista alimenta web i mòbil, comprova tots dos quan canviï l’estructura. Desa una explicació breu per iniciar el projecte, trobar regles i identificar serveis. Això permet a una altra persona revisar errors sense reconstruir tota la conversa que va generar el programa. La documentació ha de descriure el resultat actual, no únicament la intenció inicial.
Documentació de referència: Agent overview.
Desenvolupament i producció
La documentació separa bases de desenvolupament i producció. Agent modifica desenvolupament i pot consultar producció mitjançant rèplica de lectura; canvis d’estructura es poden aplicar en publicar. Helium actual conviu amb projectes anteriors Neon.
Separar entorns protegeix experimentació, però publicar té efectes. Afegir una columna i eliminar-ne una altra afecten registres de manera diferent. Identifica canvis i conservació de dades abans de publicar. No copiïs exemples ficticis a producció per comoditat. Una rèplica de lectura pot tenir retard i no confirma instantàniament una escriptura. Comprova que dades, codi i entorn corresponen a la mateixa versió prevista.
Documentació de referència: Database environments.
Identitat i permisos
Replit Auth utilitza comptes Replit. Clerk Auth proporciona comptes independents de l’aplicació amb altra configuració de marca. Autenticar identifica usuari; autoritzar decideix què pot consultar o canviar.
Una pantalla d’accés no prova protecció de cada registre. Defineix rols i prova persona autoritzada, sense permís i sessió tancada. Comprova restriccions també en peticions directes al servidor. Un directori públic pot no necessitar compte; afegir-lo augmenta manteniment. Separa administració de continguts i lectura general, i revisa retirada d’accés. Les proves han de demostrar la regla prevista, no només que el formulari de login apareix.
Documentació de referència: Replit Auth.
Integracions i credencials
Els connectors treballen amb serveis externs. Secrets conserva credencials xifrades com variables d’entorn; Configurations és per valors no sensibles. Les claus no s’han d’incloure en codi del navegador.
Connectar un servei introdueix permisos i efectes externs. Consultar documents i enviar missatges requereixen autoritzacions diferents. Defineix operacions necessàries i prova amb compte limitat. Evita secrets en errors o registres. En substituir credencial, comprova desenvolupament i publicació: un canvi no ha de deixar l’altre entorn amb connexió antiga sense advertir-ho. Documenta també com revocar accés si el projecte deixa d’utilitzar el servei.
Documentació de referència: Secrets · Integrations.
Xats i rutines recurrents
Les rutines programen treball des d’un xat i hi retornen resultats. Poden utilitzar connectors i actuar en serveis autoritzats; no programen publicacions. Funcionen en Power o Max en plans compatibles, amb límits i pressupostos segons modalitat.
Un ús proposat és revisar enllaços d’un catàleg públic i informar dels que no responen. Defineix freqüència, criteri de fallada i destinatari. Lentitud no equival a desaparició del recurs. Comença amb informe revisable i comprova falsos positius abans d’automatitzar canvis. Multiplica pressupost per execució per freqüència per estimar consum mensual. Conserva historial de resultats per distingir una incidència puntual d’una ruptura persistent.
Documentació de referència: Chat and routine scheduling.
Proves i revisió de seguretat
App Testing navega amb navegador real; la guia el limita a web Full Stack JavaScript i Streamlit Python en Power o Max. No s’executa després de cada missatge. Security Center diferencia dependències, revisió de codi i prova externa.
Són cobertures diferents. Una biblioteca sense vulnerabilitats conegudes no prova permisos correctes a l’aplicació. Prepara casos amb resultat esperat, entrades buides, connexions fallides i usuaris sense accés. Revisa evidència de què s’ha provat. L’absència d’errors al recorregut automàtic no demostra que funcioni una ruta no visitada. Repeteix els casos afectats quan una modificació canviï dades o permisos.
Documentació de referència: App testing · Security scan levels.
Publicació i operació
Publishing configura adreça, accés, base de producció i allotjament. Permet domini propi i opcions d’accés segons pla. Vista prèvia de desenvolupament i entorn publicat són diferents.
Verifica URL final des d’una sessió independent. Comprova enllaços, serveis i variables de producció, i que un usuari nou completi l’acció prevista. Defineix qui rep avisos d’errors i com retirar una versió problemàtica. Publicar inicia manteniment: dependències, dades i connexions canvien encara que la interfície sembli igual. Inclou aquesta responsabilitat en decidir convertir el prototip en servei estable i registra la versió comprovada després de cada actualització.
Documentació de referència: Publishing.
Codi, portabilitat i recuperació
Git i GitHub conserven historial i permeten traslladar codi. Recuperar producció és separat: la documentació descriu restauració a un moment anterior i còpies programades. Les finestres depenen de pla i configuració.
Exportar codi no exporta tots els comptes, fitxers, dominis i serveis necessaris. Prepara inventari i assaja recuperació amb dades de prova. Per tornar a un estat coherent, codi i estructura de dades han de ser compatibles. Una còpia mai restaurada aporta menys evidència que una recuperació comprovada amb resultats coneguts i temps registrat. Anota també les connexions que s’han de reconfigurar després de restaurar.
Documentació de referència: Version control · Data recovery.
Aplicacions mòbils i plataformes de treball
Replit crea aplicacions mòbils amb Expo i React Native, amb previsualització al telèfon i simuladors al núvol segons pla. Simulador no substitueix proves de càmera, ubicació o altres funcions físiques. L’aplicació d’escriptori està disponible per Windows, macOS i Linux basat en Debian.
Web adaptable i aplicació nativa tenen distribució diferent. Defineix si cal obrir un enllaç o instal·lar aplicació i prova el dispositiu real del públic. Construir paquet no equival a aprovació en botiga. Revisa permisos, funcionament sense connexió i mida del text abans de decidir canal. Mantén coherència entre les versions que comparteixen dades.
Documentació de referència: Mobile apps · Desktop application.
Plans i cost de funcionament
La documentació diferencia Starter, Core, Pro i Enterprise. Els crèdits poden cobrir Agent i recursos d’operació; Pro amplia col·laboració i tasques paral·leles. El panell desglossa consum per projecte i recurs.
Calcula construcció, correcció i disponibilitat per separat. Un web poc visitat i un servei de consultes contínues tenen perfils diferents. Compara plans amb el mateix cas, dades, revisions i trànsit previst. Quota de construcció no és cost total permanent. Revisa consum després de canvis importants i assigna qui atura recursos sense ús. Inclou serveis externs en l’estimació, perquè poden facturar fora del compte Replit.
Documentació de referència: Core plan · Pro plan · Spending controls.
Propietat i responsabilitats
Les condicions mantenen drets de l’usuari sobre contingut i regulen permisos per prestar servei. La responsabilitat compartida assigna al creador revisió de codi generat, permisos d’aplicació, dades i llicències.
No confonguis protecció de plataforma amb correcció de cada programa. Una dependència pot tenir llicència pròpia i una integració afegir obligacions. Mantén inventari i acorda qui aprova canvis. En ús organitzatiu, algú ha de poder explicar quina informació entra, on es desa, qui accedeix i com s’elimina. L’explicació ha de correspondre a implementació, no només al text de l’encàrrec. Revisa-la si canvien dades o serveis.
Documentació de referència: Shared responsibility · Terms of Service.
Incident documentat i aprenentatge
El juliol de 2025, Fast Company va documentar que l’agent va esborrar contactes d’una aplicació de Jason Lemkin malgrat instruccions de congelar canvis; les dades es van recuperar. La documentació actual descriu bases separades i lectura de producció.
El cas mostra que instrucció verbal i permís tècnic no són equivalents. No prova que totes les aplicacions fallin així ni que les mesures posteriors eliminin tot risc. Avalua credencials, entorns i recuperació efectiva. Les accions amb conseqüències s’han de limitar per configuració i revisar amb evidència. Una prova controlada permet valorar aquests controls sense exposar registres reals.
Documentació de referència: July 2025 database incident · Database environments.
Aplicacions concretes en SST
En SST pot ajudar a preparar prototips de recursos informatius o petites eines de suport que després revisaran professionals. És útil per comprovar si una interfície s’entén, si una cerca facilita trobar materials o si una idea respon realment a una necessitat abans de plantejar-ne la implantació.
Altres usos proposats són un cercador de documentació pública i una demostració d’organització de preguntes freqüents per tasca. Convé començar amb consultes de lectura, sense recollir dades personals ni concloure sobre aptitud o nivell de risc. Un resultat buit s’ha d’explicar com a manca de coincidències al catàleg, mai com a absència de perills a la feina.
Cas pràctic i comprovació del resultat
Per exemple, l’equip podria provar un directori de recursos preventius utilitzant només dades fictícies i enllaços públics. La revisió se centraria en navegació, claredat de les etiquetes i accés des del mòbil, sense gestionar expedients de persones treballadores.
Per al directori de l’exemple, prepara una llista petita de títols, idiomes, temes i enllaços públics verificats. Descriu les regles de cerca: quins camps es consulten, com es combinen filtres i què passa si no hi ha resultats. Demana una primera versió sense comptes i amb aquestes dades de prova.
Després prova cerques amb accents, noms incomplets i un idioma sense documents. Contrasta cada resultat amb la llista d’origen i obre els enllaços des del mòbil. Desa una versió recognoscible abans de modificar la cerca. Repeteix els mateixos casos després del canvi: trobar més elements no millora el sistema si barreja documents d’una altra llengua. Si el prototip aporta valor, documenta qui mantindrà enllaços, dependències i costos abans de convertir-lo en un recurs estable.
Límits i condicions d’ús
Un prototip funcional no equival a una aplicació preparada per a producció. Cal comprovar autenticació, permisos, emmagatzematge, costos d’operació i comportament davant de fallades; qualsevol lògica que afecti decisions de seguretat necessita validació tècnica independent del generador de codi.
La documentació diferencia recuperar codi i recuperar dades. En tornar a un punt de control, restaurar la base de desenvolupament és opcional; la base de producció no es restaura automàticament amb aquest mecanisme. Tornar a una pantalla anterior no garanteix recuperar l’estat anterior dels registres. Tampoc no desfà per si sol accions executades en serveis connectats.
Documentació de referència: Version control · Checkpoints and Rollbacks.
Quan escollir-la i amb què complementar-la
Replit encaixa quan cal passar d’una idea a codi executable i disposar d’eines per inspeccionar canvis. Figma pot ser suficient per estudiar navegació abans de desenvolupar lògica real. Lovable ofereix una altra via de construcció web mitjançant instruccions, que convé comparar amb el mateix cas de prova.
Avalua com es corregeix un error, es conserva el codi i es recupera una versió coneguda. Inclou una prova amb un enllaç trencat i una altra sense connexió al servei de dades. El prototip també ha d’explicar els errors sense presentar informació incompleta com a vàlida.
Preguntes freqüents
Demanar una aplicació en llenguatge natural evita definir regles?
No. La descripció ha de precisar dades, usuaris, resultats i excepcions. Si falta una regla, el generador pot escollir una interpretació diferent de la necessitat de l’equip.
Un punt de control recupera la base de producció?
No automàticament. La documentació diferencia restaurar opcionalment dades de desenvolupament i recuperar producció. Comprova què inclou cada operació abans d’executar-la.
Es poden utilitzar dades reals per fer la demostració més convincent?
Per avaluar navegació solen bastar dades fictícies. Incorporar registres reals canvia els requisits d’accés, conservació i responsabilitat; ha de respondre a una necessitat i a controls definits, no a l’aparença del prototip.
