Claude Sonnet 4.6 Probado: Casi-Opus a Mitad de Precio

Claude Sonnet 4.6 a Prueba: Casi Opus a Mitad de Precio

Casi no pruebo Sonnet 4.6.

En serio. Estaba inmerso en un flujo de trabajo con Opus 4.6 — agentes ejecutándose, código desplegándose, toda la maquinaria funcionando — y mi primera reacción cuando Anthropic lanzó Sonnet 4.6 fue "genial, lo reviso la semana que viene." Entonces un amigo de mi Discord me envió una captura de pantalla de una landing page para SaaS que Sonnet 4.6 había generado con un solo prompt. Tipografía limpia. Sistema de colores cohesivo. Una sección hero que parecía que un diseñador había dedicado tres horas a perfeccionarla.

Dejé lo que estaba haciendo y abrí la consola de la API.

Lo que siguió fue una maratón de pruebas de 72 horas que cambió fundamentalmente mi forma de pensar sobre la selección de modelos para mis proyectos. Porque la cuestión es la siguiente: he sido leal a Opus desde el primer día. Opus 4.6 es mi caballo de batalla. Mi herramienta de uso diario. El modelo en el que confío para código en producción y arquitecturas complejas de agentes. Así que cuando les digo que Sonnet 4.6 me hizo cuestionar esa lealtad, entiendan el peso de lo que estoy diciendo.

Este no es un modelo que sea "bastante bueno por el precio." Es un modelo que iguala o supera a Opus en tareas específicas mientras se ejecuta el doble de rápido y cuesta aproximadamente la mitad. ¿Y la ventana de contexto de un millón de tokens actualmente en beta? Eso cambia las reglas del juego para cualquiera que construya sistemas de agentes o trabaje con bases de código extensas.

Puse a Sonnet 4.6 a prueba en todo lo que se me ocurrió: generación de front-end, simulaciones 3D, automatización de navegador, desarrollo de juegos, gráficos SVG y construcción completa de proyectos dirigidos por agentes. Algunos resultados genuinamente me sorprendieron. Otros revelaron limitaciones claras que necesitas conocer antes de hacer el cambio.

Permíteme guiarte a través de todo.

Por Qué Otro Sonnet Importa (Incluso Si Ya Usas Opus)

Necesito abordar algo que veo constantemente en las comunidades de desarrolladores: la fatiga de modelos. Cada pocas semanas, sale un nuevo modelo y todos debaten si es "el definitivo." Entiendo el cinismo. La mayoría de las actualizaciones son incrementales. Un punto o dos en algún benchmark que a nadie le importa en la práctica.

Sonnet 4.6 es diferente, y puedo señalar exactamente por qué.

El anterior Sonnet 4.5 era sólido. Suficientemente bueno para tareas simples, suficientemente rápido para aplicaciones en tiempo real, suficientemente económico para ejecutar a escala. Pero tenía un techo. El razonamiento complejo de múltiples pasos lo hacía tropezar. Los archivos de código largos le hacían perder el contexto y alucinar nombres de funciones que no existían. Los flujos de trabajo de agentes con más de 3-4 pasos a veces se descarrilaban.

Sonnet 4.6 no solo eleva ese techo, sino que lo elimina para la mayoría de los casos de uso prácticos. Los números de los benchmarks cuentan parte de la historia: un 79.6 en la prueba verificada de SWE-Bench, puntuaciones de vanguardia en codificación agéntica, y resultados en análisis financiero que compiten con modelos del doble de su rango de precio. Pero los benchmarks son solo marketing hasta que ejecutas el modelo tú mismo.

Así que lo ejecuté. Intensamente. En las tareas exactas para las que uso Opus todos los días.

Y el contexto de precios importa aquí. Opus 4.6 cuesta aproximadamente $6 por millón de tokens de entrada y $12 por millón de tokens de salida. Sonnet 4.6 mantiene los precios de Sonnet 4.5: $3 de entrada, $6 de salida. Eso no es un ahorro marginal — es la mitad del costo por un modelo que, en mis pruebas, ofrece entre el 85-95% de la capacidad de Opus dependiendo de la tarea.

¿Para desarrolladores independientes y equipos pequeños que consumen créditos de API? Esa aritmética lo cambia todo. Pero, ¿la calidad realmente se mantiene bajo presión? Tuve que averiguarlo, empezando por la tarea que más me importa: desplegar código front-end real.

Generación de Front-End: La Prueba Que Más Me Sorprendió

Tengo una prueba estándar de front-end que ejecuto con cada modelo nuevo. El mismo prompt, cada vez: generar una landing page premium para SaaS con una sección hero, cuadrícula de características, tabla de precios, testimonios y pie de página. Especifico la paleta de colores, preferencias tipográficas y la estética general. Luego comparo la salida HTML/CSS en crudo.

Opus 4.6 ha producido consistentemente los mejores resultados en esta prueba. Estructura de componentes limpia. Espaciado sofisticado. Uso del color que realmente parece que un diseñador lo tocó. Así que mis expectativas para Sonnet 4.6 eran modestas — supuse que produciría algo funcional pero obviamente un nivel por debajo.

Estaba equivocado.

La landing page que Sonnet 4.6 generó tenía mejor tipografía que lo que Opus típicamente me da. Las combinaciones de fuentes eran más intencionales. Los degradados de color eran más suaves. La sección hero tenía una sutil sugerencia de animación en los comentarios que, al implementarla, se veía genuinamente premium.

Donde falló: el comportamiento responsive necesitó más ajustes manuales que la salida de Opus, y el componente del pie de página era ligeramente genérico. Pero estos son arreglos de 5 minutos. La base — la parte que más tiempo lleva hacer bien — fue excepcional.

Ejecuté esta prueba tres veces más con diferentes briefs de diseño. Sonnet 4.6 ganó dos de tres. La que perdió fue un dashboard en modo oscuro con componentes complejos de visualización de datos, donde el razonamiento más fuerte de Opus sobre la jerarquía de componentes marcó una diferencia visible.

Esta es mi conclusión para cualquiera que haga trabajo de front-end: si estás generando landing pages, sitios de marketing o interfaces SaaS estándar, Sonnet 4.6 no es solo "suficientemente bueno" — podría ser tu mejor opción. La ventaja de velocidad por sí sola (aproximadamente 2x más rápido que Opus) significa que puedes iterar más rápidamente, y el ahorro de costos se acumula rápido cuando haces múltiples rondas de generación y refinamiento.

Pero el código front-end es una cosa. ¿Qué pasa con algo verdaderamente complejo, como simular un sistema operativo completo?

La Simulación de Mac OS Que Me Voló la Cabeza

Esta prueba empezó como una broma. Un desarrollador de mi comunidad me retó a que Sonnet 4.6 generara una interfaz funcional de Mac OS en el navegador. "No hay forma de que maneje la complejidad," dijo. "Demasiados componentes interactuando."

Reto aceptado.

Le di a Sonnet 4.6 un prompt detallado describiendo un escritorio estilo Mac OS con Finder, Safari, Notes, Mail, Photos, Terminal, Calculator y Settings — todos funcionales en cierto grado. Esperaba una maqueta estática con quizás algunos elementos clicables.

Lo que obtuve fue genuinamente inquietante en su calidad.

La ventana de Finder se abría y cerraba. Podías crear carpetas y navegar entre ellas. Safari tenía una barra de direcciones funcional con gestión básica de pestañas. Notes te permitía crear y editar entradas de texto. La Calculator realmente funcionaba — cada botón, cada operación, resultados correctos. Settings incluía personalización de fondo de pantalla (con opciones reales de fondos), controles deslizantes de volumen y brillo que se animaban suavemente, y una barra de búsqueda estilo Spotlight que filtraba aplicaciones.

¿Era un sistema operativo real? Obviamente no. Pero como una generación de un solo prompt de un prototipo de UI interactivo, nunca había visto nada así de un modelo a este precio.

El reproductor de música fue el detalle que me atrapó. No solo reproducía pistas (simuladas) sino que animaba el ícono del dock mientras la "música" estaba activa. Ese es el tipo de detalle de diseño que requiere entender el contexto, las expectativas del usuario y los patrones de retroalimentación visual — no solo renderizar componentes.

Ejecuté el mismo prompt en Opus 4.6 para comparar. Opus produjo un resultado más técnicamente sofisticado con mejor manejo de errores y gestión de estado más limpia. Pero la versión de Sonnet se veía mejor y tenía más pulido interactivo. Es casi como si Sonnet priorizara la experiencia de usuario mientras Opus priorizaba la ingeniería.

Fortalezas diferentes. Ambos impresionantes. Pero solo uno cuesta $3 por millón de tokens de entrada.

La pregunta real, sin embargo — la que más me ponía nervioso — era cómo Sonnet 4.6 maneja los flujos de trabajo de agentes de múltiples pasos. Porque ahí es donde vivo profesionalmente, y ahí es donde Opus ha sido irremplazable. Hasta ahora.

Desarrollo Dirigido por Agentes: Boxelcraft y la Prueba Multi-Agente

Esta es la prueba que realmente importa para mi trabajo. Construyo sistemas de agentes de IA profesionalmente. Mis clientes me pagan para diseñar flujos de trabajo donde múltiples agentes colaboran, escriben código, lo prueban e iteran — a menudo de forma autónoma. Opus 4.6 ha sido la columna vertebral de estos sistemas porque maneja la planificación compleja, el razonamiento con contexto extenso y el uso de herramientas mejor que cualquier otra cosa disponible.

Así que configuré la prueba más difícil que pude imaginar: un despliegue autónomo multi-agente usando Kilo Code (que, por cierto, ofrece $25 en créditos gratis — una buena forma de probarlo tú mismo). ¿La tarea? Construir un clon de Minecraft basado en navegador desde cero.

Los agentes dividieron el trabajo: uno manejó la generación de terreno, otro gestionó las mecánicas del juego (colocación de bloques, destrucción, inventario), un tercero trabajó en la UI (barras de salud, medidores de comida, elementos del HUD), y un agente coordinador gestionó la arquitectura general.

El resultado fue un juego jugable llamado Boxelcraft. Generación de terreno con cuevas. Sistemas funcionales de salud y comida. Colocación y destrucción de bloques. Un sistema de inventario básico.

¿Era perfecto? Ni de cerca. El rendimiento tenía lag. Parte de la generación de cuevas producía artefactos visuales. La física tenía casos extremos donde atravesabas los bloques. Pero esta es la métrica que importa: los agentes completaron toda la construcción de forma autónoma. Sin intervención humana. Sin depuración manual a mitad del proceso. La planificación, implementación, pruebas e iteración ocurrieron todas dentro del enjambre de agentes.

He ejecutado pruebas similares con Opus 4.6, y aquí está la comparación honesta:

Esa diferencia de velocidad y costo no es trivial. Para el desarrollo iterativo — donde ejecutas agentes, revisas la salida, ajustas prompts y ejecutas de nuevo — Sonnet 4.6 te permite hacer el doble de iteraciones con el mismo presupuesto. Y en mi experiencia, más iteraciones casi siempre supera una mejor calidad en un solo intento.

Consejo profesional: He empezado a usar un enfoque híbrido. Sonnet 4.6 para las iteraciones iniciales de construcción (rápido, económico, te lleva al 80%), luego Opus 4.6 para el pase final de pulido (exhaustivo, detecta casos extremos, produce código más limpio). Esto redujo los costos de mis flujos de trabajo de agentes en aproximadamente un 40% sin una caída notable en la calidad del resultado final.

Hay una capacidad más que probé que merece su propia sección — porque es la que tiene más implicaciones prácticas para los desarrolladores que quieren automatizar trabajo real, no solo generar demos.

Automatización de Navegador: Donde Sonnet 4.6 Genuinamente Destaca

He estado construyendo sistemas de automatización de navegador para clientes desde 2023 — bots de investigación, scrapers de datos, agentes de llenado de formularios, dashboards de monitoreo. Este es trabajo pesado que consume tiempo de desarrollador, y es exactamente donde los modelos de IA pueden ofrecer un ROI masivo.

Mi prueba: darle a Sonnet 4.6 la tarea de crear una configuración completa de automatización de navegador usando Python con Playwright, automatizar una búsqueda en Google de las últimas noticias de IA, extraer los cinco titulares principales, guardarlos en un CSV y mostrar los resultados en un dashboard en tiempo real.

El modelo generó todo el pipeline en una sola respuesta. Script en Python con Playwright para el control del navegador. Manejo asíncrono apropiado. Operaciones de escritura CSV con marcas de tiempo. Un dashboard simple con Flask que lee el CSV y muestra los resultados con auto-actualización.

Lo que me impresionó no fue que funcionara — Opus también puede hacerlo. Lo que me impresionó fue lo limpio que era el código en el primer intento. El manejo de errores era cuidadoso (lógica de reintentos para fallos de red, degradación elegante si la estructura del objetivo del scraping cambia). Los selectores de Playwright eran lo suficientemente específicos para ser robustos pero no tan frágiles como para que un cambio menor en el DOM rompiera todo.

Desplegué este pipeline y lo dejé funcionar durante 48 horas. Cero caídas. El CSV acumuló datos de forma fiable. El dashboard se mantuvo responsivo.

Para comparar, cuando le di a Opus la misma tarea, produjo código ligeramente más sofisticado — mejor logging, más parámetros configurables, un diseño de dashboard más pulido. Pero la versión de Sonnet estaba lista para producción sin modificaciones, y se generó en aproximadamente la mitad del tiempo.

# Enfoque de Sonnet 4.6 para el scraper — limpio y práctico
async def scrape_ai_headlines(page):
    await page.goto("https://news.google.com/search?q=artificial+intelligence")
    await page.wait_for_selector("article h3", timeout=10000)

    headlines = await page.eval_on_selector_all(
        "article h3",
        "elements => elements.slice(0, 5).map(el => el.innerText)"
    )

    timestamp = datetime.now().isoformat()
    with open("headlines.csv", "a", newline="") as f:
        writer = csv.writer(f)
        for headline in headlines:
            writer.writerow([timestamp, headline])

    return headlines

Nada sofisticado. Nada sobrediseñado. Solo código sólido y funcional que hace exactamente lo que se pidió. ¿Y honestamente? Eso es lo que quiero de un modelo de IA el 90% del tiempo. No necesito que diseñe un microservicio distribuido. Necesito que escriba el script de automatización que me ahorra dos horas de trabajo manual — rápido, económico y correcto.

Pero te haría un flaco favor si solo hablara de dónde Sonnet brilla. También encontré limitaciones reales, y necesitas conocerlas antes de tomar cualquier decisión.

Donde Sonnet 4.6 Se Queda Corto (La Evaluación Honesta)

He sido positivo sobre este modelo, y se merece el elogio. Pero hay áreas específicas donde claramente queda por detrás de Opus 4.6, y fingir lo contrario sería deshonesto.

Generación de SVG y gráficos complejos. Ejecuté una batería de pruebas SVG — mariposas, robots, un pelícano montando bicicleta, un control de PS5. Sonnet produjo resultados decentes. Formas reconocibles, elecciones de color razonables, niveles de detalle aceptables. Pero comparado lado a lado con Opus, la diferencia es obvia. Opus genera SVGs con detalle más fino, mejor proporcionalidad y uso más sofisticado de degradados y sombras. Si la fidelidad visual importa para tu caso de uso, Opus sigue siendo el claro ganador aquí.

Razonamiento profundo de múltiples pasos con ambigüedad. Cuando una tarea tiene especificaciones claras, Sonnet 4.6 ejecuta brillantemente. Pero cuando los requisitos son vagos y el modelo necesita tomar decisiones de criterio — "construye algo que se sienta premium" o "maneja los casos extremos apropiadamente" — Opus toma mejores decisiones. Es la diferencia entre un buen desarrollador de nivel medio y un arquitecto senior. Ambos escriben código funcional, pero el senior toma mejores decisiones sobre qué construir y cómo estructurarlo.

Refactorización de código extenso. A pesar de la ventana de contexto de un millón de tokens (que es genuinamente impresionante y funciona bien para leer y analizar código), Sonnet ocasionalmente pierde coherencia al refactorizar archivos grandes. Podría renombrar una función en una sección pero omitir una referencia a ella 200 líneas más abajo. Opus maneja esto de forma más fiable. No perfectamente — ningún modelo lo hace — pero notablemente mejor.

La brecha de alucinaciones se ha reducido pero no se ha cerrado. Anthropic afirma que las alucinaciones se han reducido en Sonnet 4.6, y mis pruebas lo respaldan. Alucina menos que Sonnet 4.5. Pero aún alucina más que Opus 4.6, particularmente con firmas de API y sintaxis específica de bibliotecas. Lo atrapé inventando un método de Playwright que no existe en una prueba. Opus raramente comete ese tipo de error.

Este es el marco al que llegué después de todas estas pruebas:

Usa Sonnet 4.6 cuando:

• La velocidad importa más que la perfección
• Estás iterando rápidamente y revisarás la salida
• La tarea está bien especificada con requisitos claros
• El costo es un factor (siempre lo es, seamos honestos)
• Necesitas generación en tiempo real o casi en tiempo real

Usa Opus 4.6 cuando:

• La tarea requiere razonamiento arquitectónico profundo
• La ambigüedad es alta y las decisiones de criterio importan
• Necesitas la máxima calidad de código en el primer intento
• La fidelidad visual es crítica (SVGs, UI compleja)
• Estás haciendo el pulido final de algo importante

Esta no es una decisión de uno u otro. Es una estrategia de portafolio. Y esa es la verdadera conclusión que quiero dejarte.

La Ventana de Contexto de Un Millón de Tokens Lo Cambia Todo (Casi)

Guardé esto para la segunda mitad porque es la característica con más implicaciones a largo plazo, aunque todavía está en beta.

Un millón de tokens de contexto. Déjame ponerlo en perspectiva. La novela promedio tiene entre 80,000 y 100,000 palabras, o aproximadamente 130,000-160,000 tokens. Un millón de tokens equivale aproximadamente a seis novelas completas. O, más relevante: toda tu base de código, toda tu documentación, los requisitos de tu proyecto, tus suites de pruebas y tus configuraciones de despliegue — todo contenido en una sola ventana de contexto.

Probé esto con un proyecto real: una aplicación Laravel de 340 archivos con aproximadamente 45,000 líneas de código. Cargué toda la base de código en el contexto de Sonnet 4.6 y le pedí que identificara posibles vulnerabilidades de seguridad a lo largo del proyecto.

El modelo encontró cuatro problemas genuinos que yo no había detectado en mi propia auditoría. Uno era una vulnerabilidad de asignación masiva en un modelo que había estado ahí durante ocho meses. Otro era una ruta de API con alcance incorrecto que exponía datos de otros inquilinos en una configuración multi-tenant.

¿Podría haberlos encontrado con una auditoría manual? Probablemente — eventualmente. Pero la velocidad con la que el modelo cruzó referencias entre archivos, rastreó flujos de datos a través de controladores, modelos y middleware, e identificó los patrones de interacción que creaban las vulnerabilidades... Eso me habría tomado días de trabajo concentrado. Sonnet lo hizo en menos de tres minutos.

Las capacidades de planificación estratégica son igualmente impresionantes. Alimenté a Sonnet 4.6 con una especificación completa de proyecto (12,000 palabras), la base de código existente y una lista de nuevas funcionalidades. Generó un plan de implementación que identificó correctamente cadenas de dependencias que yo había pasado por alto, sugirió un orden de ejecución que minimizaba conflictos y señaló tres funcionalidades que requerirían migraciones de base de datos que afectarían datos en producción.

La limitación: el contexto de un millón de tokens está en beta, y noté un rendimiento degradado hacia los extremos de contextos muy largos. Cuando superé los 800,000 tokens, las respuestas se volvieron ligeramente menos precisas. Las referencias a código en el "medio" del contexto (ni al principio ni al final) eran a veces vagas o incorrectas. Este es un problema conocido con los modelos de contexto extenso y está mejorando, pero vale la pena saberlo.

Para mi flujo de trabajo, el punto óptimo práctico es de aproximadamente 500,000-600,000 tokens. Suficiente para contener una base de código sustancial con espacio para el historial de conversación. Eso por sí solo es transformador para el desarrollo basado en agentes.

Mi Nueva Estrategia de Modelos (Y Cuánto Cuesta)

Déjame darte números reales de mi último mes de trabajo de desarrollo, porque las comparaciones abstractas son inútiles sin datos concretos.

Antes de Sonnet 4.6 (flujo de trabajo solo con Opus):

• Gasto mensual en API: ~$380
• Iteraciones promedio por funcionalidad: 3-4
• Tiempo de construcción con agentes para tarea de complejidad media: ~40 minutos
• Bugs en producción por código generado por IA: 6-8 por mes

Después de adoptar la estrategia híbrida Sonnet/Opus:

• Gasto mensual en API: ~$220
• Iteraciones promedio por funcionalidad: 5-6 (más iteraciones, misma calidad)
• Tiempo de construcción con agentes para tarea de complejidad media: ~25 minutos
• Bugs en producción por código generado por IA: 4-5 por mes

El gasto se redujo un 42%. La cantidad de bugs se redujo aproximadamente en un tercio. Y en realidad estoy iterando más, lo que significa detectar problemas antes en el ciclo de desarrollo en lugar de en producción.

El flujo de trabajo se ve así en la práctica:

1. Fase de exploración (Sonnet 4.6): Prototipo rápido, probar el enfoque, validar la arquitectura. Rápido y económico.
2. Fase de implementación (Sonnet 4.6): Construir la funcionalidad con desarrollo dirigido por agentes. Múltiples iteraciones.
3. Fase de revisión (Opus 4.6): Revisión final de código, análisis de casos extremos, auditoría de seguridad. Exhaustivo y preciso.
4. Despliegue: Enviar a producción con confianza.

Los pasos 1 y 2 representan aproximadamente el 70% de mi uso de API. Ejecutarlos en Sonnet en lugar de Opus es de donde vienen los ahorros. El paso 3, donde la precisión importa más, se mantiene en Opus.

Ganancias rápidas si quieres probar esto hoy:

• Regístrate para los $25 de crédito gratis de Kilo Code para probar Sonnet 4.6 sin comprometer presupuesto
• Ejecuta tu prompt más común tanto en Sonnet como en Opus, compara lado a lado
• Prueba LM Arena para comparaciones a ciegas — podrías sorprenderte de lo seguido que no puedes distinguir cuál es cuál
• Si estás usando Claude Code, experimenta cambiando tu modelo predeterminado para tareas rutinarias

Lo Que Esto Significa Para los Próximos Seis Meses

Quiero cerrar con algo en lo que he estado pensando desde que terminé estas pruebas.

Anthropic ha puesto esencialmente inteligencia casi de nivel Opus disponible al precio de gama media. Eso no es solo una actualización de producto — es una señal de hacia dónde se dirige la industria. La brecha entre "el mejor modelo" y "el modelo asequible" se está colapsando. En seis meses, el modelo que cuesta $3 por millón de tokens probablemente igualará lo que el modelo de $15 de hoy hace.

Para los desarrolladores, esto significa que la barrera para construir sistemas sofisticados impulsados por IA sigue bajando. Las arquitecturas de agentes que construyo hoy — que requieren una cuidadosa optimización de costos y enrutamiento de modelos — serán trivialmente económicas de ejecutar para el próximo año. Los pipelines de automatización de navegador, los flujos de generación de código, los sistemas de construcción multi-agente — todo esto se vuelve accesible para desarrolladores independientes y equipos pequeños que no podían justificar los costos de API antes.

Pero hay algo a lo que sigo volviendo: los modelos más económicos no hacen mejores desarrolladores. Hacen que haya más código generado por IA disponible, lo que significa que la habilidad que más importa es la capacidad de evaluar, depurar y mejorar ese código. Los desarrolladores que prosperan en este panorama no son los que mejor hacen prompts — son los que entienden lo que el modelo está haciendo lo suficientemente bien como para saber cuándo se equivoca.

Probé Sonnet 4.6 durante 72 horas. Me impresionó. Me ahorró dinero. Cambió mi flujo de trabajo. Pero el momento en que lo atrapé inventando un método inexistente de Playwright — el momento en que reconocí la alucinación porque yo conozco la API de Playwright — ese fue el recordatorio.

El modelo es la herramienta. Tú sigues siendo el constructor.

Si estás usando Opus exclusivamente ahora mismo y no has probado el enfoque híbrido, hazlo esta semana. Ejecuta tu flujo de trabajo estándar en Sonnet para las fases de exploración y construcción, cambia a Opus para la revisión. Registra tus costos y calidad durante dos semanas. Creo que te sorprenderán los números — igual que a mí cuando mi amigo me envió esa captura de pantalla y dejé lo que estaba haciendo para investigar.

Esa landing page, por cierto, se la mostré a un cliente. Pensó que un diseñador humano la había hecho. El modelo que la generó me costó unos cuatro centavos.

¿Cuánto te cuesta tu flujo de trabajo actual con IA — y qué construirías diferente si ese costo se redujera a la mitad?

🤝 Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• 🔗 Fiverr (desarrollos personalizados e integraciones): fiverr.com/s/EgxYmWD
• 🌐 Portafolio: mejba.me
• 🏢 Ramlit Limited (soluciones empresariales): ramlit.com
• 🎨 ColorPark (diseño y branding): colorpark.io
• 🛡 xCyberSecurity (servicios de seguridad): xcybersecurity.io