DEV Community: Monica Orellana

Predicting SLA Breaches in Technical Support

Monica Orellana — Fri, 25 Sep 2026 14:18:00 +0000

Case Study: Predicting SLA Breaches in Technical Support
Project: NovaTech AI Support (hypothetical scenario, synthetic data)
Repo: GitHub-novatech-ai-bottleneck

Executive Summary

In technical support teams, not all tickets represent the same level of operational risk. Some are resolved in minutes; others consume hours of specialized work and end up breaching the Service Level Agreement (SLA).

This case study explores how to build a Machine Learning (ML) system capable of identifying, from the moment a ticket is created, which ones are most likely to breach their SLA.

The project was developed as a hypothetical scenario for NovaTech AI Support, using synthetic data to replicate a real IT support problem. The objective was not only to maximize predictive performance but to design a realistic, explainable, reproducible, and deployable ML workflow.

The most important outcome of the project was not achieving a particular metric. It was discovering that the first model was using information from the future, and redesigning the problem around a more rigorous question:

What can we know about a ticket's risk at the exact moment it enters the system?

The Business Problem

Imagine a technology company that receives hundreds of support tickets every day. Each ticket can represent anything from a simple product question to an integration problem requiring specialized investigation.

For support managers, the challenge is not just resolving tickets. It's deciding:

Which ones need immediate attention,
Where to allocate specialized resources,
Which tickets have the highest risk of breaching the SLA,
How to move from a reactive to a preventive operation.

Business Hypothesis: If high-risk tickets are identified in advance, support teams can prioritize resources before the problem becomes a breach, improving resource allocation, prioritization, and customer experience.

Success Criteria

A high ML metric was not enough. The system had to meet four conditions:

Predictive Performance: Correctly identify tickets with breach risk.
Temporal Validity: Use only information available at the moment of prediction.
Operational Explainability: Enable understanding of why a ticket was classified as risky.
Engineering Readiness: Separate data, training, prediction, and documentation in a reproducible way.

The Alarm Signal: 100% Accuracy

The first result was exactly the type of outcome that generates a false sense of success: the model achieved ~100% on its classification metrics.

In a real operational problem, a perfect prediction should generate more questions than celebration.

The variable audit revealed the problem: temporal data leakage. The model was using information that would only be available after the ticket had been resolved particularly, the actual resolution time.

This creates an almost direct relationship with the target: if we already know how long it took to resolve a ticket, it's trivial to know whether it breached its SLA. But that information doesn't exist when the ticket has just entered the system.

The model wasn't predicting the future. It was using future information to reconstruct the past.

Methodological Correction: Strict T=0 Restriction

The solution wasn't removing a column. It was redefining the problem around the moment when the model would actually be used.

I defined T=0 as the moment of ticket creation (intake). From there, a variable could only be used if it was already available at that instant.

Features available at T=0 (kept):

Ticket category
Priority
Channel
Target SLA time

Removed (only exist after intake):

Actual resolution time
Accumulated waiting time

This decision had an immediate consequence: the ROC-AUC dropped from 1.0000 → 0.9606. At first glance, it seems like a deterioration, but a slightly less accurate model that is valid in production is much more valuable than a perfect model that cannot be used.

Architecture Benchmarking: More Complexity Doesn't Mean Better

With the problem redefined, two approaches were compared under the same T=0 feature set. The system solves a dual task: classification (will it breach the SLA?) and regression (estimating the associated risk/time), which is why both classification metrics (ROC-AUC, F1) and regression metrics (R²) are reported.

Model	Scenario	ROC-AUC	F1-Score	R² (Reg)	Ready for production?
Random Forest	Intake (T=0)	0.9606	0.9095	0.6416	✅ Yes (Recommended)
PyTorch Multitask	Intake (T=0)	0.9617	0.9047	0.5232	️ Optional
Random Forest	Omniscient (Leaky)	1.0000	1.0000	N/A	❌ No (Post-mortem only)

Random Forest was the chosen candidate for production. Both T=0 models are practically tied in classification (RF wins on F1; the neural network wins by a minimal margin on ROC-AUC — 0.0011), but RF has clearly better regression performance (R² 0.64 vs 0.52), plus native integration with TreeSHAP and lower computational cost. The additional complexity of deep learning is not justified for a marginal gain in classification that is also paid for with worse R² and less direct interpretability.

The decision was based on the balance between performance, speed, interpretability, complexity, and required resources, not just the highest metric.

Operational Explainability with SHAP: From Black Box to Support Tool

A prediction alone is not enough for a support operation. If the system flags a ticket as "high risk," the team needs to know why. To answer that question, SHAP (SHapley Additive exPlanations) was incorporated at two levels.

Global explanation

Probability of breach. Positive SHAP values push the prediction toward "high risk."

The SHAP analysis identified the main risk factors:

Integration/API is the most consistent category that increases risk.
A short target SLA (8h) significantly increases risk compared to a broader one (72h).
Technical Issue is the highest-magnitude feature, but it's bidirectional: it can increase or decrease risk depending on context.
The entry channel (email, chat, or phone) has minimal impact.

This transforms the model from a purely predictive tool into a source of operational information.

Local Explanation

For a ticket with a final breach probability of 99.1%, the analysis decomposes the prediction as follows:

A ticket with a 99.1% probability of a breach.

The question shifts from "Does the model say this ticket is risky?" to "What factors are making this ticket risky?", a fundamental difference when predictions must be translated into human decisions.

Production Implementation and Software Robustness

Another common problem in ML projects is confusing a model trained in a notebook with a usable system. To avoid this, the project explicitly separates training and prediction.

train.py - loads the data, executes the pipeline, trains the model, and saves it for later use. Reproducible via a single command, without depending on manually running a notebook.

predict.py - receives new tickets, executes the transformation flow, generates predictions, and saves the results along with their probabilities.

This creates a clear boundary: Training → Model Artifact → Prediction, leaving the system ready for future integration with other systems.

Results

First model with leakage: ROC-AUC = 1.0000 / F1 = 1.0000 (invalid, uses future information).
Corrected model with T=0 features (Random Forest): ROC-AUC = 0.9606 · F1 = 0.9095 · R² = 0.6416.
Multitask neural network (PyTorch) T=0: ROC-AUC = 0.9617 · F1 = 0.9047 · R² = 0.5232.
Random Forest selected as production candidate for its balance between performance, simplicity, and interpretability.
SHAP enabled explanation of both global patterns and individual predictions.

Key Lessons

A perfect metric can be a warning sign, not a success.
Define the moment of prediction before choosing features. The question is not "Is this variable predictive?" but "Would this variable exist at the moment I need to predict?"
Complexity must earn its place. Deep learning is not used just because it's more advanced.
Explainability matters when it answers concrete operational questions, not when it's included as an additional visualization.
A notebook is not a production system: it takes data pipeline + validation + model + prediction workflow + logging + documentation + reproducibility.

Conclusion

NovaTech AI started as an SLA prediction problem and ended up becoming a Machine Learning Engineering exercise.

The most valuable result was not moving from one ROC-AUC to another slightly better one. It was identifying that the first perfect result was misleading, redefining the problem around T=0, comparing models considering complexity and operational value, incorporating explainability, and building a structure that could evolve from an experiment to a system.

If you have feedback on the T=0 approach, the choice of Random Forest over deep learning, or ideas to take this further (drift monitoring, calibration, inference API), I'd be glad to read them in the comments. The complete code is in the repo linked above.

Optimizador de Retención de Talento con Machine Learning

Monica Orellana — Wed, 23 Sep 2026 16:46:41 +0000

La rotación de empleados no es solo un "problema de Recursos Humanos": es una fuga directa de capital. Según Gallup, reemplazar a un empleado cuesta habitualmente entre 0.5 y 2 veces su salario anual, entre reclutamiento, onboarding y pérdida de productividad.

La mayoría de los proyectos de Machine Learning en este dominio se detienen en una métrica superficial: "nuestro modelo predice quién se irá con 85% de ROC-AUC". Pero esa cifra, por sí sola, no le dice a un director financiero cuánto invertir para evitarlo, ni a quién priorizar cuando el presupuesto es limitado.

Este artículo documenta el diseño, evaluación y entrega de un Sistema de Soporte a la Decisión (DSS) que combina modelado predictivo, explicabilidad con SHAP, segmentación no supervisada y optimización financiera bajo restricción de presupuesto, junto con el proceso de control de calidad que se aplicó antes de considerarlo listo para producción.

Repositorio completo:
👉github.com/purischaky/workforce_attrition_project

Paso 1: Diseñar el problema

El primer paso no fue elegir un algoritmo. Fue definir qué pregunta de negocio se estaba respondiendo. "Predecir la rotación" no es el objetivo real; el objetivo es estimar un costo esperado y decidir dónde asignar presupuesto. Esa distinción definió toda la arquitectura:

src/features.py - un transformador custom (LaborEconomicsFeatures) que construye ratios econométricos, no solo variables crudas. Por ejemplo la presión de burnout:

Burnout Ratio = \frac{Workload Score \times Overtime Hours}{Manager Support + ϵ}

Junto con la velocidad de carrera, el índice de estancamiento y el salario relativo contra la mediana correspondiente a departamento y nivel de cargo.

src/models.py - Un enfoque de modelado dual:

una regresión logística (para interpretabilidad vía odds ratios)
un HistGradientBoostingClassifier calibrado con CalibratedClassifierCV. Un buen AUC no es suficiente: si las probabilidades no están calibradas, cualquier cálculo de ROI que dependa de ellas pierde validez matemática.

src/explainability.py - SHAP para explicar por qué el modelo predice lo que predice, a nivel global y local.

src/segmentation.py - Análisis de Componentes Principales(PCA) + K-Means para encontrar arquetipos latentes de empleados, más allá de la etiqueta binaria "se va / se queda".

src/retention_optimizer.py - el módulo central desde una perspectiva de negocio. Dado un presupuesto fijo, resuelve un problema para determinar ¿a quién se le asigna una intervención de retención para maximizar el valor esperado neto?

Paso 2: Traducir el modelo a una decisión de asignación de presupuesto

Tras entrenar y calibrar, el modelo alcanzó un ROC-AUC ≈ 0.81 con un Brier Score de ~0.10, es decir, probabilidades bien calibradas y no solo un buen ranking. SHAP confirmó los principales drivers de rotación: satisfaction_score, burnout_pressure_ratio y promotion_wait_years.

El resultado con mayor peso de negocio fue el siguiente: con un presupuesto de $50,000 distribuido entre 20 empleados de alto riesgo (a $2,500 por intervención), el modelo proyectó $745,000+ en valor esperado salvado, un ROI neto de ~1,391%.

Esa cifra se deriva directamente de la optimización bajo restricción de presupuesto:

Ganancia Neta Total = i = 1 \sum k [(P_{i} \cdot C_{reemplazo, i} \cdot S_{i}) - I_{i}]

Donde:

k: número de empleados seleccionados dentro del presupuesto disponible.
P_i: probabilidad calibrada de que el empleado i renuncie.
C_reemplazo,i: costo estimado de reemplazar al empleado i (1.5 × salario anual).
S_i: tasa de éxito estimada de la intervención de retención.
I_i: costo directo de implementar la intervención (ej. $2,500).

El valor de este enfoque no está en la cifra en sí, sino en que convierte una lista de probabilidades en una tabla de asignación de capital accionable: qué empleados, con qué prioridad, y con qué retorno esperado. Esa es la diferencia entre un modelo predictivo y una herramienta de decisión ejecutiva.

Paso 3: Control de calidad: auditar el código antes de entregarlo como producción

Un pipeline que produce buenas métricas no es lo mismo que un pipeline listo para producción. Antes de considerar el proyecto terminado, se ejecutó un proceso de auditoría técnica, tests y reproducibilidad, módulo por módulo, con apoyo de IA para acelerar la revisión y las correcciones.

Los hallazgos y sus correcciones:

Path roto → el pipeline apuntaba a un archivo incorrecto y caía en un fallback silencioso que auditaba datos ya procesados en vez de datos crudos. Una vez corregido, se agregó un warning explícito para que cualquier futura desviación de este tipo sea visible en consola.
Reentrenamiento → el modelo se entrenaba desde cero tres veces en una sola corrida del pipeline. Se introdujo serialización con joblib: el modelo se entrena una vez y los módulos de explicabilidad y optimización cargan el artefacto en vez de reentrenar. El pipeline pasó de 3 entrenamientos a 1 por corrida.
README vs. tests → Se sincronizó la documentación con el código real y se agregó el test que faltaba (test_models.py) en vez de solo borrar la mención.
Módulo desconectado → eda_economic.py, responsable de la validación de hipótesis econométricas, no estaba integrado en el pipeline principal. Se conectó a main.py como paso formal del proceso.
Reproducibilidad del split de datos → no existía un script que generara los conjuntos de entrenamiento y prueba desde el dato crudo. Se creó src/make_dataset.py, con train_test_split estratificado y semilla fija, para que el pipeline sea reproducible de punta a punta por cualquier persona que clone el repositorio.

Lo que este proceso demuestra, desde una perspectiva de negocio

Hoy en día, el verdadero diferencial no está en la métrica, sino en la capacidad de traducir esa predicción en una decisión de negocio con un ROI cuantificado. Para ello, se debe someter el propio trabajo a un rigor de ingeniería implacable antes de darlo por terminado: rutas de datos verificadas, persistencia de modelos, documentación sincronizada y reproducibilidad garantizada desde el dato crudo.

Ese debe ser el estándar para evaluar cualquier proyecto de Machine Learning que aspire a estar en producción. No se trata solo de que el modelo prediga bien, sino de que el sistema completo (pipeline, tests, documentación y arquitectura), resista una auditoría externa sin una sola sorpresa.

¿Quieres replicarlo o contribuir?

El proyecto usa datos sintéticos con propiedades econométricas realistas, pensado para adaptarse a datasets reales de cualquier organización interesada en cuantificar su exposición financiera a la rotación de talento.

🔗Explora el código, clona el repositorio y ejecuta el dashboard aquí:
👉 https://github.com/purischaky/workforce_attrition_project.git

¿Has abordado el problema de la rotación de personal en tu empresa? ¿Usaste algún enfoque de optimización de presupuesto? ¡Déjame tus comentarios abajo! 👇

Prediciendo Brechas de SLA en Soporte Técnico

Monica Orellana — Mon, 14 Sep 2026 16:31:45 +0000

Caso de estudio: Predicción de brechas de SLA
Proyecto: NovaTech AI Support (escenario hipotético, datos sintéticos)
Repo: GitHub-novatech-ai-bottleneck

Resumen ejecutivo

En los equipos de soporte técnico, no todos los tickets representan el mismo nivel de riesgo operacional. Algunos se resuelven en minutos; otros consumen horas de trabajo especializado y terminan incumpliendo el Service Level Agreement (SLA).

Este caso de estudio explora cómo construir un sistema de Machine Learning (ML) capaz de identificar, desde el momento en que se crea un ticket, cuáles tienen mayor probabilidad de incumplir su SLA.

El proyecto se desarrolló como un escenario hipotético para NovaTech AI Support, usando datos sintéticos para replicar un problema real de soporte TI. El objetivo no fue únicamente maximizar el desempeño predictivo, sino diseñar un flujo de ML realista, explicable, reproducible y desplegable.

El resultado más importante del proyecto no fue alcanzar una métrica determinada. Fue descubrir que el primer modelo estaba utilizando información del futuro, y rediseñar el problema alrededor de una pregunta más rigurosa:

¿Qué podemos saber sobre el riesgo de un ticket en el momento exacto en que entra al sistema?

El problema de negocio

Imaginemos una empresa tecnológica que recibe cientos de tickets de soporte cada día. Cada ticket puede representar desde una pregunta simple sobre el producto hasta un problema de integración que requiere investigación especializada.

Para los responsables de soporte, el reto no es solo resolver tickets. Es decidir:

cuáles necesitan atención inmediata,
dónde asignar recursos especializados,
qué tickets tienen mayor riesgo de incumplir el SLA,
cómo pasar de una operación reactiva a una preventiva.

Hipótesis de negocio: si se identifican anticipadamente los tickets de mayor riesgo, los equipos de soporte pueden priorizar recursos antes de que el problema se convierta en un incumplimiento, mejorando la asignación de recursos, la priorización y la experiencia del cliente.

Criterios de éxito

Una métrica alta de ML no bastaba. El sistema debía cumplir cuatro condiciones:

Rendimiento predictivo: identificar correctamente los tickets con riesgo de breach.
Validez temporal: usar únicamente información disponible en el momento de la predicción.
Explicabilidad Operativa: permitir entender por qué un ticket fue clasificado como riesgoso.
Preparación de ingenieria: separar datos, entrenamiento, predicción y documentación de forma reproducible.

La señal de alarma: 100% de precisión

El primer resultado fue exactamente el tipo de resultado que genera una falsa sensación de éxito: el modelo alcanzó ~100% en sus métricas de clasificación.

En un problema operacional real, una predicción perfecta debería generar más preguntas que celebración.

La auditoría de variables reveló el problema: temporal data leakage. El modelo usaba información que solo estaría disponible después de que el ticket hubiera sido resuelto — en particular, el tiempo real de resolución.

Eso crea una relación casi directa con el target: si ya sabemos cuánto tardó en resolverse un ticket, es trivial saber si incumplió su SLA. Pero esa información no existe cuando el ticket acaba de entrar al sistema.

El modelo no estaba prediciendo el futuro. Estaba usando información del futuro para reconstruir el pasado.

Corrección metodológica: restricción estricta a T=0

La solución no fue eliminar una columna. Fue redefinir el problema alrededor del momento en que el modelo realmente se usaría.

Definí T=0 como el momento de creación del ticket (intake). A partir de ahí, una variable solo podía usarse si ya estaba disponible en ese instante.

Features disponibles en T=0 (se mantuvieron):

Ticket category
Priority
Channel
Target SLA time

Se eliminaron (solo existen después del intake):

Actual resolution time
Accumulated waiting time

Esta decisión tuvo una consecuencia inmediata: el ROC-AUC cayó de 1.0000 → 0.9606. A primera vista parece un empeoramiento, pero un modelo ligeramente menos preciso pero válido en produccion es mucho más valioso que un modelo perfecto que no puede utilizarse.

Benchmarking de arquitecturas: más complejidad no significa mejor

Con el problema redefinido, se compararon dos enfoques bajo el mismo feature set T=0. El sistema resuelve una tarea dual: clasificación (¿va a incumplir el SLA?) y regresión (estimación del riesgo/tiempo asociado), de ahí que se reporten tanto métricas de clasificación (ROC-AUC, F1) como de regresión (R²).

Model	Scenario	ROC-AUC	F1-Score	R² (Reg)	¿Listo para producción?
Random Forest	Intake (T=0)	0.9606	0.9095	0.6416	✅ Sí (Recomendado)
PyTorch Multitask	Intake (T=0)	0.9617	0.9047	0.5232	️ Opcional
Random Forest	Omniscient (Leaky)	1.0000	1.0000	N/A	❌ No (Post-mortem only)

Random Forest fue el candidato elegido para producción. Ambos modelos T=0 quedan prácticamente empatados en clasificación (RF gana en F1; la red neuronal gana por un margen mínimo en ROC-AUC - 0.0011), pero RF tiene un desempeño de regresión claramente mejor (R² 0.64 vs 0.52), además de integración nativa con TreeSHAP y menor costo computacional. La complejidad adicional del deep learning no se justifica para una ganancia marginal en clasificación que además se paga con peor R² y menos interpretabilidad directa.

La decisión se basó en el equilibrio entre desempeño, velocidad, interpretabilidad, complejidad y recursos necesarios, no solo en la métrica más alta.

Explicabilidad operativa con SHAP: de caja negra a herramienta de soporte

Una predicción por sí sola no es suficiente para una operación de soporte. Si el sistema marca un ticket como "high risk", el equipo necesita saber por qué. Para responder esa pregunta se incorporó SHAP (SHapley Additive exPlanations) en dos niveles.

Explicación global

probabilidad de breach. Valores SHAP positivos empujan la predicción hacia "alto riesgo".

El análisis SHAP identificó los principales factores de riesgo:

Integration/API es la categoría más consistente que incrementa el riesgo.
Un SLA objetivo corto (8h) incrementa significativamente el riesgo frente a uno más amplio (72h).
Technical Issue es la feature de mayor magnitud, pero es bidireccional: puede aumentar o disminuir el riesgo según el contexto.
El canal de entrada (email, chat o teléfono) tiene un impacto mínimo.

Esto transforma el modelo de una herramienta puramente predictiva en una fuente de información operacional.

Explicación local

Para un ticket con una probabilidad final de incumplimiento de 99.1%, el análisis descompone la predicción así:

Ticket con 99.1% de probabilidad de breach.

La pregunta deja de ser "¿el modelo dice que este ticket es riesgoso?" y pasa a ser "¿qué factores están haciendo que este ticket sea riesgoso?", una diferencia fundamental cuando las predicciones deben convertirse en decisiones humanas.

Implementación en producción y robustez de software

Otro problema común en proyectos de ML es confundir un modelo entrenado en un notebook con un sistema utilizable. Para evitarlo, el proyecto separa explícitamente entrenamiento y predicción.

train.py - carga los datos, ejecuta el pipeline, entrena el modelo y lo guarda para uso posterior. Reproducible mediante un solo comando, sin depender de ejecutar un notebook manualmente.

predict.py - recibe nuevos tickets, ejecuta el flujo de transformación, genera predicciones y guarda los resultados junto con sus probabilidades.

Esto crea una frontera clara: Training → Model Artifact → Prediction, dejando el sistema listo para una futura integración con otros sistemas.

Resultados

Primer modelo con leakage: ROC-AUC 1.0000 / F1 1.0000 (no válido, usa información futura).
Modelo corregido con features T=0 (Random Forest): ROC-AUC = 0.9606 · F1 = 0.9095 · R² = 0.6416.
Red neuronal multitarea (PyTorch) T=0: ROC-AUC = 0.9617 · F1 = 0.9047 · R² = 0.5232.
Random Forest seleccionado como candidato de producción por su equilibrio entre desempeño, simplicidad e interpretabilidad.
SHAP permitió explicar tanto patrones globales como predicciones individuales.

Lecciones clave

Una métrica perfecta puede ser señal de alarma, no de éxito.
Definir el momento de la predicción antes de elegir features. La pregunta no es "¿esta variable es predictiva?", sino "¿esta variable existiría en el momento en que necesito predecir?"
La complejidad debe ganarse su lugar, deep learning no se usa solo porque sea más avanzado.
La explicabilidad vale cuando responde preguntas operativas concretas, no cuando se incluye como una visualización adicional.
Un notebook no es un sistema de producción: hace falta data pipeline + validation + model + prediction workflow + logging + documentation + reproducibility.

Conclusión

NovaTech AI comenzó como un problema de predicción de SLA y terminó convirtiéndose en un ejercicio de Machine Learning Engineering.

El resultado más valioso no fue pasar de un ROC-AUC a otro ligeramente mejor. Fue identificar que el primer resultado perfecto era engañoso, redefinir el problema alrededor de T=0, comparar modelos considerando complejidad y valor operacional, incorporar explicabilidad y construir una estructura que pudiera evolucionar de un experimento a un sistema.

Si tienes feedback sobre el enfoque de T=0, la elección de Random Forest sobre deep learning, o ideas para llevar esto más lejos (monitoreo de drift, calibración, API de inferencia), lo leo con gusto en los comentarios. El código completo está en el repo enlazado arriba.

🦆 Duck Generator Challenge

Monica Orellana — Tue, 17 Feb 2026 16:40:51 +0000

As someone learning AI, my strongest recommendation is this: the best way to learn is not only by reading, but getting your hands dirty.

In this hands-on project, I used Kiro An agentic AI with an IDE and CLI that helps you go from prototype to production with spec-driven development, to help me solve a challenge I discovered at the AWS re:Invent 2025.

The challenge?

Fixing a broken AI-powered duck image generator that uses AWS Bedrock Nova Canvas to create images. This exercise is a full-stack interactive web application where we frontend debudding, backend validation, AI integration, and user experience design.

Before touching any code, the first step was to understand how the system is designed:

• The frontend - built with React and Vite
• The backend - implemented using Flask and follows an agent-based workflow (duck_agent.py)
• The AI engine – powered by AWS Bedrock, using the Nova Canvas model for image generation.
• Reliability Layer - a fallback system that keeps the app running even without cloud credentials.

According to the README.md, the challenge consists of 4 task and should take about 25 minutes. But with Kiro I completed it by writing just two prompts:

Open Kiro app
Prompt: “clone this repo: https://github.com/aws-banjo/riv25_duck_game.git”
Prompt: “your task is to complete the challenge. To do so, open the README.md file and follow the setup and implementation steps provide there. The file contains all the instructions you’ll need to get the project running.”
Voila, the works is done!

At first glance, this might look to easy or even lazy, but here’s the key point: Kiro didn’t just do the work – it explained every step it executed, so it was actually a learning accelerator, because it helps you understand what is happening, why it matters, and how the pieces connect.

Here is what we accomplished doing the 4 tasks:

Task 1: Start Backend & Test MCP, we ensured the backend is alive and the Flask server was reachable on port 8081. This step confirms the Model Context Protocol (MCP) servers were ready to accept requests.

Task 2: Create Coding Standards, we defined how the AI should write a code, we created a Steering Document that define rules and conventions (e.g. quackFetch instead of fetch), also ensured error handling rules. This is a important lesson in AI governance and consistency.

Task 3: Build the Duck Generator, we fixed bugs in the API client and wrote a feature specification. We simulated a real product cycle: defining behavior, AI assistant implements it and developer focuses on user flows and states. It reinforces thinking like a product-oriented AI builder.

Task 4: Test with Chrome DevTools, this is end-to-end validation, we tested everything from API connectivity to the reliability of the fallback mechanism.

The result:

Is a fully functional demo where you can generate duck images. Even without live AWS credentials, the reliability layer allows you to visualize 23 pre-generated duck images.

If this project left you wanting more ways to bring your own AI art to life, stay tuned, in my next article, we’ll explore SageMaker Studio Lab, a free tool to experiment with AI.