Skip to main content
📝 Modelos de IA

Probé Gemini 3.1 Flashlight — La Bestia de Velocidad de Google

Probé Gemini 3.1 Flashlight a 363 tokens por segundo. Benchmarks reales contra Claude y GPT en programación, razonamiento y tareas multimodales.

21 min

Tiempo de lectura

4,165

Palabras

Mar 03, 2026

Publicado

Engr Mejba Ahmed

Escrito por

Engr Mejba Ahmed

Compartir Artículo

Probé Gemini 3.1 Flashlight — La Bestia de Velocidad de Google

Probé Gemini 3.1 Flashlight — La Bestia de Velocidad de Google

Trescientos sesenta y tres tokens por segundo.

Leí ese número en la hoja de especificaciones y pensé que era un error tipográfico. Llevo suficiente tiempo trabajando con modelos de IA como para saber que las afirmaciones de velocidad casi siempre vienen con asteriscos, letra pequeña y condiciones de benchmark que nadie encuentra realmente en el uso del mundo real. Así que cuando Google lanzó Gemini 3.1 Flashlight — posicionado como su modelo más rápido y eficiente en costos hasta la fecha — hice lo que haría cualquier desarrollador escéptico. Abrí mi terminal, accedí a la API y empecé a lanzarle tareas reales.

Lo que sucedió durante las siguientes horas me sorprendió genuinamente. No porque el modelo sea perfecto — definitivamente no lo es — sino porque cambió fundamentalmente cómo pienso sobre qué modelo pertenece a qué parte de mi stack de desarrollo. Hay una clase específica de trabajo donde Flashlight no solo compite con modelos más grandes. Los avergüenza.

Pero me estoy adelantando. Antes de contarte qué me impresionó (y qué falló), necesitas entender qué estaba intentando construir Google realmente — y por qué importa si estás escribiendo código profesionalmente.

Por Qué Otro Modelo "Light" Realmente Importa Esta Vez

Algo que he notado sobre el panorama de modelos de IA durante el último año: la brecha entre modelos "flagship" y "eficientes" sigue reduciéndose de formas extrañas e impredecibles. Solíamos pensar en los modelos más pequeños como claramente inferiores — útiles para tareas rápidas de clasificación o relleno de chatbot, pero nada en lo que confiarías para trabajo de ingeniería real.

Esa suposición se está desmoronando. Rápido.

Gemini 3.1 Flashlight se ubica en una categoría que Google está llamando su tier optimizado para velocidad dentro de la familia Gemini 3. La propuesta es directa: tomar las ganancias de inteligencia de Gemini 3, eliminar el overhead que hace que los modelos grandes sean caros y lentos, y entregar algo que los desarrolladores puedan realmente permitirse ejecutar a escala — sin sentir que han hecho un downgrade.

Los precios cuentan parte de la historia: $25 por millón de tokens de entrada, con tokens de salida que van de $0.50 a $1.50 por millón dependiendo de tu configuración. Eso es agresivo. No es "tier gratuito para proyecto hobby" barato, pero está bien dentro del rango para cargas de trabajo de producción donde haces miles de llamadas a la API diariamente.

Lo que es más interesante son los datos de rendimiento. En el benchmark GPQA — que prueba razonamiento de nivel de posgrado — Flashlight obtuvo 86.9%. El benchmark MMU Pro, que evalúa comprensión multimodal, llegó al 76.8%. Y en el leaderboard de Arena, registró un puntaje ELO de 1400. Esos no son números de "modelo light". Son números que habrían sido de tier flagship hace dieciocho meses.

Llevo suficiente tiempo construyendo herramientas impulsadas por IA como para saber que los benchmarks solo te cuentan la mitad de la historia. La otra mitad está en lo que sucede cuando realmente pones el modelo a trabajar. Ahí es donde las cosas se pusieron realmente interesantes.

La Prueba de Velocidad que Cambió Mi Opinión

Mi primera prueba real fue simple pero reveladora. Le pedí a Flashlight que generara un componente de visor de producto 360 grados — el tipo de cosa que verías en un sitio de e-commerce de alta gama. Múltiples ángulos de cámara, rotación suave y capacidad de cambio de color. No trivial, pero tampoco ciencia espacial.

La respuesta llegó en segundos. No segundos de "algo rápido". El tipo de velocidad donde te preguntas si el modelo realmente procesó tu solicitud o simplemente cacheó una plantilla.

No había cacheado nada. El código era específico para mi prompt, correctamente estructurado y — aquí está la parte que me tomó desprevenido — visualmente más atractivo que lo que había obtenido de Gemini 3.1 Pro para una tarea similar. Un modelo más ligero y barato produciendo mejor output de front-end que su hermano mayor. Se supone que eso no pasa.

Ejecuté el componente en mi navegador. Rotación suave. Ángulos de cámara funcionando. El cambio de color necesitaba un pequeño arreglo, pero la base era sólida. Para prototipado rápido, este era exactamente el tipo de output que me ahorra una hora de scaffolding.

Ahora, antes de que pienses que voy a decirte que Flashlight es perfecto en todo — no lo es. Cuando aumenté la complejidad, empezaron a aparecer grietas. ¿Un dashboard multi-componente con widgets interdependientes? Llegó a un 70% aproximadamente. Algunas brechas en el seguimiento de instrucciones aparecieron donde el modelo parecía perder el rastro de restricciones que yo había establecido en el prompt.

Pero esto es a lo que sigo volviendo: el costo por ese output imperfecto fue insignificante. Cuando estás iterando rápido, una solución al 70% a 1/10 del precio y 3x la velocidad es a menudo más valiosa que una solución al 95% que tarda más y cuesta más generar. Corriges los vacíos más rápido de lo que esperas por el modelo caro.

Ese compromiso no siempre es correcto. Pero para los flujos de trabajo que uso diariamente — prototipado rápido, generación de componentes, exploración de UI — es un cambio de juego a este precio.

La Función de "Nivel de Pensamiento" de la que Nadie Habla

Aquí hay algo que la mayoría de las reseñas de Flashlight están pasando por alto, y honestamente, creo que es la característica más importante de todo el modelo.

Gemini 3.1 Flashlight incluye un ajuste de "nivel de pensamiento" configurable. Puedes ajustar la profundidad de razonamiento hacia arriba o hacia abajo dependiendo de tu tarea. ¿Respuesta de chat simple? Bájalo. ¿Generación de código compleja de múltiples pasos? Súbelo al máximo.

¿Por qué importa esto? Porque significa que no estás pagando por razonamiento que no necesitas.

Todo desarrollador de IA ha tenido esta experiencia: envías una solicitud simple de formateo a un modelo poderoso, "piensa" demasiado tiempo, quema tokens y entrega una respuesta mucho más elaborada de lo necesario. El control de nivel de pensamiento elimina ese desperdicio.

Probé esto en tres escenarios:

Nivel de pensamiento bajo — reformatear datos JSON y generar definiciones de tipos básicas. Los tiempos de respuesta cayeron dramáticamente, los costos fueron mínimos y la calidad era exactamente lo que necesitaba. Sin sobrepensar.

Nivel de pensamiento medio — generar componentes React con requisitos específicos de estilado y gestión de estado. Buen equilibrio entre velocidad y precisión. Este se convirtió en mi configuración predeterminada para la mayoría de las tareas de desarrollo.

Nivel de pensamiento alto — generación de código multi-archivo con lógica de negocio compleja y manejo de errores. Más lento, pero la calidad del output subió notablemente. El modelo detectó casos extremos que se le escaparon en configuraciones más bajas.

La capacidad de ajustar esto dinámicamente por solicitud es genuinamente poderosa para sistemas de producción. Imagina enrutar consultas simples de usuarios al modo de bajo pensamiento y solicitudes analíticas complejas al modo de alto pensamiento — todo desde el mismo modelo, con el mismo endpoint de API. Tu infraestructura se mantiene simple, tus costos se mantienen optimizados y tus usuarios obtienen la calidad de respuesta apropiada para sus necesidades específicas.

No he visto suficientes desarrolladores hablando sobre este patrón, pero va a convertirse en práctica estándar. Marca mis palabras.

Tareas Reales, Resultados Reales: El Desglose Completo

Hablar es barato. Los benchmarks son interesantes. Pero lo que importa es si el modelo hace trabajo útil. Pasé un día completo lanzándole tareas cada vez más difíciles a Flashlight, y esto es lo que encontré.

Desarrollo Front-End: Sorprendentemente Fuerte

Aquí es donde Flashlight genuinamente brilla — y quiero ser específico sobre lo que quiero decir.

Para generación de componentes individuales (tarjetas, modales, barras de navegación, exhibidores de productos, widgets interactivos), Flashlight produce output que está a la par o ocasionalmente es mejor que modelos que cuestan 5-10x más. El código es limpio, el CSS es moderno y los componentes realmente funcionan cuando los colocas en un proyecto.

Generé una página completa de exhibición de productos con transiciones animadas, breakpoints responsivos y marcado accesible. El modelo clavó el comportamiento responsivo al primer intento. Las animaciones necesitaban ajustes — eligió una transición basada en spring donde yo quería un ease lineal — pero la estructura era sólida.

Donde tiene dificultades: layouts multi-página con lógica de routing compleja, patrones de gestión de estado profundamente anidados y tareas donde el prompt incluye más de 6-7 requisitos distintos. El modelo empieza a soltar restricciones a ese nivel de complejidad.

Mi veredicto: Si estás haciendo prototipado front-end, desarrollo de bibliotecas de componentes o exploración de UI, Flashlight debería ser tu modelo predeterminado. Cambia a algo más pesado solo cuando realmente lo necesites.

Generación de Código Más Allá del Navegador

¿Generación de SVG? Excelente. Pedí una mariposa con animaciones de aleteo, y el output fue genuinamente impresionante — paths SVG apropiados, animaciones CSS keyframe suaves y gradientes de color apropiados. Todo renderizó hermosamente.

Funciones utilitarias generales, scaffolding de endpoints de API, pipelines de transformación de datos — todo sólido. Flashlight escribe código competente y legible para las tareas de programación del día a día.

Donde noté el techo: implementación de algoritmos complejos. Cuando pedí un algoritmo optimizado de recorrido de grafos con restricciones específicas de memoria, el primer intento fue correcto pero ingenuo. Un modelo más poderoso habría alcanzado la solución óptima inmediatamente.

Generación de Juegos y Simulaciones: La Carta Sorpresa

Aquí es donde las cosas se pusieron divertidas — y donde mis expectativas necesitaron más calibración.

Le pedí a Flashlight que construyera un juego de carreras 2D con animación y renderizado en tiempo real. Lo que volvió fue... en realidad bastante bueno. La física del auto usó atajos matemáticos inteligentes para simular inercia y derrape. El loop de renderizado era suave. El diseño de la pista era básico pero funcional.

Luego presioné más fuerte. Una simulación de derrape de un auto de Fórmula 1 en 3D. Aquí es donde Flashlight alcanzó sus límites reales. La simulación era técnicamente funcional — el auto se movía, la física tenía alguna base en la realidad y renderizaba sin crashear. Pero ¿visualmente? Parecía un juego de PlayStation 1. No de forma retro encantadora. De la forma de "esto claramente alcanzó el techo de complejidad del modelo."

Honestamente, esperaba eso. Generar gráficos 3D convincentes desde un solo prompt sigue siendo un problema increíblemente difícil, y Flashlight está explícitamente optimizado para velocidad, no para empujar los límites de lo que el código generado por IA puede hacer visualmente. El hecho de que produjera algo funcional es notable.

Mi opinión honesta: No uses Flashlight para desarrollo de juegos complejos o simulaciones 3D ricas. Úsalo para juegos 2D, demos interactivas y prototipos visuales donde la velocidad de iteración importa más que el pulido visual.

Generación de Texto Largo: Mejor de lo Esperado

Le pedí a Flashlight que escribiera un ensayo analítico sobre la profundidad temática de El Señor de los Anillos, enfocándose en el impacto narrativo y los fundamentos filosóficos. ¿Por qué este tema? Porque el análisis literario requiere razonamiento coherente sostenido, hilado temático y conciencia estructural — exactamente el tipo de cosa que los modelos "light" usualmente arruinan.

El ensayo volvió bien organizado, con una tesis clara, argumentos de soporte que realmente se construían unos sobre otros y referencias textuales específicas. La prosa no iba a ganar un Pulitzer, pero era considerablemente mejor que lo que Gemini 3 Flash produjo para el mismo prompt — y llegó notablemente más rápido.

Para desarrolladores que construyen herramientas de contenido, pipelines de resumen o generadores de documentación, esto importa. Velocidad más calidad aceptable a escala es todo el juego.

La Integración con Kilo Code: Donde la Velocidad Se Encuentra con el Workflow

Una de las cosas que más me impresionó no fue Flashlight en sí — fue lo bien que funciona dentro de la herramienta CLI Kilo Code y la extensión de VS Code.

Conecté Flashlight al modo autónomo de Kilo Code, donde el modelo maneja cadenas de razonamiento de múltiples pasos: leyendo archivos, ejecutando verificación, usando herramientas externas y generando output en un workflow continuo. La experiencia fue notablemente fluida.

Aquí hay un ejemplo específico. Le pedí que generara una interfaz de navegador estilo Mac OS con apps funcionales básicas — una calculadora, bloc de notas y explorador de archivos. Desde el prompt hasta el output funcionando: 35 segundos. Costo total: 8 centavos.

Ocho centavos. Por una interfaz multi-componente y multi-app con interactividad básica.

Ahora, ¿estaban las apps completamente pulidas? No. La calculadora funcionaba. El bloc de notas era funcional pero básico. El explorador de archivos era más un mockup estático que una interfaz real del sistema de archivos. Pero ¿como punto de partida para iterar? Esa es una relación costo-valor increíble.

La integración también maneja verificación de datos en vivo, lo que significa que el modelo puede verificar sus propios outputs contra fuentes de datos reales durante la generación. Esa es una capacidad sutil pero poderosa para construir workflows autónomos confiables.

Consejo profesional: Kilo Code actualmente ofrece $25 en créditos de uso gratuito para su herramienta CLI. Si vas a probar Flashlight en un entorno de desarrollo real — y deberías — esta es la forma de menor fricción para hacerlo.

Lo que la Mayoría de la Gente Está Malinterpretando Sobre Este Modelo

Quiero ser sincero sobre algo. Después de probar Flashlight extensivamente, creo que la comunidad de desarrolladores lo está juzgando mal en dos direcciones opuestas.

El grupo del hype lo trata como un modelo que puede reemplazar las opciones de tier Pro para todo. No puede. Refactoring multi-archivo complejo, razonamiento arquitectónico profundo y seguimiento de instrucciones matizado todavía requieren modelos más poderosos. Si intercambias Flashlight en un workflow que genuinamente necesita razonamiento profundo, te frustrarás.

Los escépticos lo descartan como "solo otro modelo pequeño" que solo es útil para proyectos de juguete. Esto es igualmente equivocado. Para las cargas de trabajo específicas para las que está optimizado — generación rápida, tareas de alto volumen, aplicaciones en tiempo real y prototipado front-end — Flashlight es genuinamente la mejor opción disponible en su rango de precio.

La jugada inteligente no es elegir Flashlight O un modelo más grande. Es construir lógica de enrutamiento que envíe las tareas correctas al modelo correcto. Tareas de generación simple, prototipado de UI, formateo de contenido, scaffolding básico de código — enrútalos a Flashlight. Razonamiento complejo, problemas de múltiples restricciones, decisiones arquitectónicas — enrútalos a Pro.

Aprendí esto por las malas. Mi primer instinto fue ejecutar todo a través de Flashlight porque la velocidad era intoxicante. En un día, había encontrado suficientes casos extremos para darme cuenta de que la selección de modelos necesita ser específica por tarea, no de talla única.

Aquí está la verdad incómoda que nadie quiere admitir: el modelo que es "mejor" depende enteramente de lo que estás haciendo ahora mismo, no de lo que obtuvo el puntaje más alto en un leaderboard. El ELO de 1400 de Flashlight no importa si tu tarea necesita capacidades que no tiene. Y el razonamiento superior de Pro no importa si tu tarea es lo suficientemente simple como para que solo estés quemando dinero en cómputo innecesario.

La Verificación de Realidad de los Precios

Mencioné que Flashlight cuesta $25 por millón de tokens de entrada. Vale la pena examinar esto más cuidadosamente.

Cuando vi estos precios por primera vez, tuve una reacción mixta. Por un lado, por el rendimiento que obtienes, es competitivo. Por otro, esperaba que Google fuera más agresivo dado el posicionamiento "light". Modelos en este tier de eficiencia de otros proveedores pueden salir más baratos.

Aquí está mi desglose después de un día de uso real:

  • Sesión ligera de prototipado (15-20 generaciones de componentes, nivel de pensamiento bajo): aproximadamente $0.30-0.50
  • Sesión pesada de desarrollo (tareas complejas multi-paso, nivel de pensamiento alto): aproximadamente $2.00-4.00
  • El proyecto del navegador Mac OS (multi-paso autónomo con Kilo Code): $0.08

Para desarrolladores individuales y equipos pequeños, estos costos son triviales. Para sistemas de producción que hacen miles de llamadas por hora, las matemáticas se ponen más interesantes — y aquí es donde la ventaja de velocidad de Flashlight realmente se acumula. 2.5x más rápido en time-to-first-token significa que tus usuarios esperan menos, tu infraestructura maneja más solicitudes concurrentes y tus costos de cómputo por solicitud se mantienen más bajos.

Mi cálculo aproximado: cambiar cargas de trabajo apropiadas de un modelo de tier Pro a Flashlight me ahorró alrededor del 60-70% en costos de API mientras realmente mejoraba los tiempos de respuesta. El compromiso de calidad existía pero era aceptable para las tareas que le enruté.

Si Google baja el precio incluso un 20-30% — y la presión competitiva sugiere que podrían — esto se convierte en un predeterminado obvio para la mayoría de las llamadas a la API de desarrolladores.

El Benchmark Real: Mi Workflow de Producción

Los benchmarks te dicen lo que un modelo puede hacer en condiciones controladas. Lo que realmente me importa es lo que hace en mi workflow de desarrollo desordenado y del mundo real.

Después de una semana de pruebas de integración, así es como Flashlight se ganó un lugar permanente en mi kit de herramientas:

Sesiones de prototipado matutinas: Cuando estoy explorando ideas, probando diferentes enfoques de UI o armando rápidamente nuevas funcionalidades, Flashlight es ahora mi predeterminado. La velocidad significa que puedo iterar a través de 5-6 variaciones en el tiempo que antes tomaba generar una. Esa no es una mejora menor — cambia fundamentalmente cómo abordo la exploración de diseño.

Preparación de demos para clientes: Cuando necesito construir rápidamente prototipos interactivos para mostrar a clientes, Flashlight más Kilo Code me lleva de concepto a demo clickeable en minutos. No es código de producción pulido, pero lo suficientemente convincente para una revisión de diseño.

Pipelines de documentación y contenido: Para generar contenido estructurado, reformatear datos y construir documentación a partir de comentarios de código, Flashlight maneja el 90% de mis necesidades a una fracción del costo.

Donde todavía recurro a modelos más grandes: Sesiones de debugging complejas donde necesito que el modelo razone sobre patrones sutiles de interacción. Refactoring multi-archivo donde el contexto a través de muchos archivos importa. Recomendaciones arquitectónicas donde quiero el "mejor pensamiento" del modelo, no su pensamiento más rápido.

La combinación de rápido-y-barato más lento-y-poderoso es genuinamente más efectiva que cualquiera de los dos solos. Es como tener tanto un auto deportivo como una camioneta. No conduces la camioneta al supermercado, y no transportas madera en el auto deportivo.

Dónde Encaja Flashlight en la Familia Gemini 3

Para dar contexto, así es como posicionaría la línea actual de Gemini 3 basándome en mis pruebas:

Gemini 3.1 Pro — tu caballo de tiro. Razonamiento complejo, problemas de múltiples restricciones, tareas donde necesitas el mejor output absoluto del modelo y el costo es secundario. Recurro a este cuando la tarea es difícil y hay mucho en juego.

Gemini 3.1 Flashlight — tu velocista. Generación de alto volumen, prototipado rápido, aplicaciones en tiempo real y cualquier tarea donde la velocidad de iteración importa más que la perfección al primer intento. Este es mi predeterminado para el 60-70% de las tareas de desarrollo diarias.

Gemini 3 Flash — el modelo eficiente de la generación anterior. Todavía tiene su lugar, pero Flashlight lo supera en velocidad y calidad en prácticamente cada prueba que ejecuté. Si todavía estás usando Flash, actualiza.

La velocidad de output 45% más rápida y la mejora de 2.5x en time-to-first-token sobre Flash no son mejoras incrementales. Cruzan un umbral donde el modelo se siente genuinamente en tiempo real. Los prompts que solían sentirse como "esperando a la IA" ahora se sienten como "tener una conversación."

Ese cambio perceptual importa más que cualquier número de benchmark, porque cambia cómo los desarrolladores interactúan con el modelo — y en última instancia, lo que construyen con él.

Mi Predicción: El Patrón de Nivel de Pensamiento Va a Todas Partes

Mencioné el nivel de pensamiento ajustable antes, y quiero volver a él porque genuinamente creo que es la característica más visionaria de Flashlight — y una que cada proveedor importante de modelos copiará dentro de los próximos 12 meses.

La idea es simple: no todas las solicitudes necesitan la misma cantidad de razonamiento. Un modelo que puede ajustar dinámicamente su esfuerzo computacional por solicitud no es solo más eficiente — es más útil. Esencialmente estás obteniendo múltiples modelos en un endpoint de API.

Creo que nos dirigimos hacia un mundo donde la selección de modelos no es "elige un modelo" sino "elige un presupuesto de razonamiento." Establecerás un nivel de pensamiento para cada llamada a la API basándote en la complejidad esperada, y el modelo asignará cómputo en consecuencia.

Flashlight es el primer modelo que he usado donde esto no es solo un concepto teórico sino una funcionalidad práctica lista para producción. Y una vez que empiezas a construir con él, volver a modelos de razonamiento fijo se siente despilfarrador.

Los desarrolladores que descifren la asignación dinámica de razonamiento primero tendrán una ventaja significativa en costos y velocidad. Este es el patrón a observar.

Lo que Le Diría a un Desarrollador Considerando Flashlight

Si estás indeciso, aquí está mi recomendación honesta.

Comienza identificando el 30-40% de tus llamadas actuales a la API de IA que son "simples" — formateo, generación básica, código de un solo componente, transformación de datos. Enruta esas a Flashlight hoy. Mide los ahorros en costos y las mejoras en velocidad. Verás retornos inmediatos.

Luego expande gradualmente. Pruébalo en tus workflows de prototipado. Inténtalo para generación de documentación. Introdúcelo en tu pipeline de CI/CD para comentarios automáticos de code review o generación de tests.

Encontrarás el límite donde la calidad de Flashlight cae por debajo de tu umbral. Ese límite es tu punto de cambio — todo por debajo va a Flashlight, todo por encima se queda con tu modelo actual.

Ese límite es más alto de lo que piensas. Esperaba alcanzar los límites de Flashlight rápidamente. En cambio, manejó aproximadamente el 65% de mi carga de trabajo diaria mejor o de forma comparable a los modelos más pesados que estaba usando antes — y a una fracción del costo y la latencia.

El modelo está disponible a través de Google AI Studio, la API de Gemini, OpenRouter y la extensión CLI/VS Code de Kilo Code. Mi recomendación: comienza con los créditos gratuitos de Kilo Code para probarlo en tu entorno de desarrollo real, luego pasa al acceso directo a la API una vez que hayas validado el ajuste.

Trescientos sesenta y tres tokens por segundo. Empecé este post pensando que ese número era marketing exagerado. Después de una semana enviando código real con Flashlight como mi motor principal de generación, creo que podría ser la especificación más prácticamente relevante en IA ahora mismo. No porque la velocidad lo sea todo — sino porque una vez que la generación es lo suficientemente rápida como para sentirse instantánea, dejas de esperar y empiezas a construir. Y eso cambia lo que es posible.


Trabajemos Juntos

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

Coffee cup

¿Te gustó este artículo?

Tu apoyo me ayuda a crear más contenido técnico detallado, herramientas de código abierto y recursos gratuitos para la comunidad de desarrolladores.

Temas Relacionados

Engr Mejba Ahmed

Sobre el Autor

Engr Mejba Ahmed

Engr. Mejba Ahmed builds AI-powered applications and secure cloud systems for businesses worldwide. With 10+ years shipping production software in Laravel, Python, and AWS, he's helped companies automate workflows, reduce infrastructure costs, and scale without security headaches. He writes about practical AI integration, cloud architecture, and developer productivity.

Discussion

Comments

0

No comments yet

Be the first to share your thoughts

Leave a Comment

Your email won't be published

7  +  12  =  ?

Seguir Aprendiendo

Artículos Relacionados

Ver Todos

Comments

Leave a Comment

Comments are moderated before appearing.

Learning Resources

Expand Your Knowledge

Accelerate your growth with structured courses, verified certificates, interactive flashcards, and production-ready AI agent skills.

Sample Certificate of Completion

Sample certificate — complete any course to earn yours

Engr Mejba Ahmed

Engr Mejba Ahmed

Claude Code Expert · Online

👋

Hey there!

Quick Actions

WhatsApp Instant reply

Chat on WhatsApp

+880 1723 741224 · Instant reply

Popular Questions

Engr Mejba Ahmed is connected
Engr Mejba Ahmed is typing...
Engr Mejba Ahmed avatar

✉ Want me to follow up? Drop your email

Engr Mejba Ahmed avatar

📞 Connect Directly

Choose how you'd like to reach me

WhatsApp

+880 1723 741224

Email

[email protected]

✓ Details sent! I'll get back to you shortly.

Powered by OpenAI

335+

Blog Posts

25

AI Courses

63

Projects

Services & Expertise

Pricing & Process

Learning & Resources

Connect & Support