DEV Community: Joel Farell Cabrera

Trabajar con agentes de IA como desarrollador: lo que cambia (y lo que no)

Joel Farell Cabrera — Thu, 19 Mar 2026 14:19:14 +0000

En los últimos meses he pasado de no usar IA en mi día a día como desarrollador a trabajar constantemente con agentes de IA.

El cambio es real.

Pero no es como mucha gente imagina.

No se trata de que la IA haga tu trabajo por ti, sino de aprender a trabajar con ella de forma efectiva. Y eso implica cambiar la forma en la que piensas, planificas y desarrollas software.

Estas son algunas de las lecciones más importantes que he aprendido en el proceso.

1. La calidad depende del contexto

Uno de los errores más comunes al trabajar con agentes de IA es asumir que “ya saben lo que necesitas”.

No es así.

Un agente sin contexto puede generar código válido… pero no necesariamente útil para tu caso.

He notado que pequeñas mejoras en cómo explico el problema cambian completamente el resultado:

describir el objetivo real
explicar restricciones
aportar ejemplos
indicar qué ya se ha probado

Cuanto mejor es el contexto, mejor es la solución.

2. Planificar antes de pedir sigue siendo clave

Trabajar con IA no elimina la necesidad de pensar.

De hecho, la hace más importante.

Cuando te lanzas a pedir código sin tener claro el problema:

entras en bucles de iteración
generas soluciones inconsistentes
pierdes tiempo corrigiendo en lugar de avanzar

En cambio, cuando defines bien lo que necesitas antes de pedirlo, el agente se convierte en un acelerador real.

3. El logging cobra aún más importancia

Esto es algo que me sorprendió.

Un buen sistema de logs no solo es útil para ti como desarrollador, sino también para trabajar con IA.

Cuando puedes proporcionar:

errores reales
trazas completas
contexto de ejecución

el agente puede ayudarte a diagnosticar problemas con mucha más precisión.

Sin logs, estás trabajando prácticamente a ciegas.
Con buenos logs, puedes convertir al agente en una herramienta mucho más potente.

4. No es automatización, es colaboración

Una de las ideas más equivocadas es pensar que trabajar con IA consiste en “pedir y esperar”.

No funciona así.

Mientras el agente genera código, tu trabajo es:

revisar lo que está haciendo
detectar posibles errores
anticipar edge cases
pensar en mejoras

Es un proceso activo, no pasivo.

La IA ejecuta, pero tú diriges.

5. El criterio técnico sigue siendo imprescindible

El agente puede proponer soluciones.

Pero no entiende completamente:

tu sistema
tus decisiones de arquitectura
tus prioridades reales

Ahí es donde entra tu criterio como desarrollador.

Si aceptas todo lo que genera sin cuestionarlo, probablemente introducirás errores o complejidad innecesaria.

Trabajar bien con IA no es delegar, es filtrar y decidir mejor.

Conclusión

Para mí, la mayor diferencia al trabajar con agentes de IA no es escribir menos código.

Es cambiar el enfoque:

pensar mejor antes de ejecutar
dar más contexto
revisar con más criterio

La IA no sustituye al desarrollador.

Pero bien utilizada, puede convertirte en uno mucho más eficiente.

7 cosas que me habría gustado saber cuando era desarrollador junior

Joel Farell Cabrera — Fri, 13 Mar 2026 12:40:57 +0000

Cuando empecé como desarrollador junior pensaba que lo más importante era escribir buen código.

Con los años me di cuenta de que muchas de las lecciones más importantes no tienen que ver con escribir código elegante, sino con cómo se comportan los sistemas en producción.

Hace poco trabajé en una aplicación con unos 40.000 usuarios registrados y picos de 5.000–6.000 usuarios concurrentes. Ese proyecto me recordó varias lecciones que me habría gustado entender mucho antes en mi carrera.

Estas son algunas de ellas.

1. El código simple casi siempre es mejor

Cuando eres junior es fácil caer en la tentación de escribir código complejo para demostrar que sabes lo que haces.

En este proyecto, al revisar algunos servicios vimos funciones muy largas que mezclaban:

lógica de negocio
acceso a base de datos
validaciones
llamadas a otros servicios

Funcionaban, pero eran difíciles de entender y más aún de mantener.

Durante la refactorización dividimos esas piezas en funciones mucho más pequeñas y claras. El comportamiento no cambió, pero el código se volvió mucho más fácil de mantener y depurar.

La lección fue clara: en producción, el código que gana no es el más ingenioso, sino el más fácil de entender para el siguiente desarrollador que tenga que tocarlo.

2. La base de datos suele ser el verdadero cuello de botella

Cuando algo va lento en una aplicación, muchas veces pensamos que el problema está en el lenguaje o en el framework.

Pero en la práctica, el problema suele estar en la base de datos:

queries mal diseñadas
falta de índices
demasiadas consultas
mala gestión de conexiones

No en el lenguaje.

En este proyecto la aplicación estaba desarrollada con Node.js y Express.js, usando TypeORM como ORM.

Después del despliegue empezamos a ver que el servidor se bloqueaba durante algunos picos de tráfico.

Investigando el problema descubrimos que las conexiones con la base de datos no se cerraban correctamente. Muchas quedaban en estado standby, acumulándose hasta saturar la máquina.

Parte del problema venía de que decidimos usar transacciones en muchos casos de uso para garantizar la integridad de los datos. La decisión era razonable, pero la gestión de esas transacciones no estaba bien controlada.

En varios puntos de la aplicación las conexiones permanecían abiertas más tiempo del necesario, y bajo carga eso terminaba colapsando la base de datos.

La solución pasó por:

refactorizar algunos puntos críticos
mejorar la indexación de la base de datos
reducir el uso innecesario de transacciones
revisar cómo se gestionaban las conexiones

Después de esos cambios el sistema empezó a comportarse mucho mejor bajo carga.

3. Los logs son más importantes de lo que parece

Cuando el problema apareció en producción, lo primero que intentamos fue entender qué estaba pasando.

El problema es que no teníamos suficiente información en los logs.

Sabíamos que el servidor se saturaba, pero no exactamente:

qué endpoints estaban generando más carga
qué consultas tardaban más
en qué punto del flujo se quedaban abiertas las transacciones

Tuvimos que mejorar bastante el sistema de logging para poder entender realmente el comportamiento del sistema.

Después de añadir logs más detallados fue mucho más fácil detectar los puntos donde las conexiones no se liberaban correctamente.

Una de las lecciones más claras fue esta:

Un sistema sin buenos logs es un sistema muy difícil de operar en producción.

4. No todo debería ejecutarse dentro de una petición HTTP

Otro problema que detectamos fue que algunas operaciones relativamente pesadas se ejecutaban dentro de la petición del usuario.

Por ejemplo:

generación de ciertos reportes
algunos procesos de sincronización de datos
operaciones que abrían varias consultas consecutivas

Cuando el tráfico aumentaba, esas operaciones bloqueaban recursos durante demasiado tiempo.

La solución fue mover varios de esos procesos a colas de trabajo en segundo plano, de modo que la petición del usuario pudiera terminar rápido mientras el trabajo pesado se procesaba de forma asíncrona.

El resultado fue una reducción bastante notable en el tiempo de respuesta de algunos endpoints.

5. Los problemas reales casi nunca son solo técnicos

Al analizar el problema nos dimos cuenta de que parte del problema no era técnico, sino de proceso.

Por ejemplo:

algunas decisiones de arquitectura se tomaron muy rápido
no se había probado suficientemente el comportamiento bajo carga
varias piezas del sistema evolucionaron de forma independiente

Nada de esto es raro en proyectos reales, pero demuestra algo importante:

muchos problemas en software no vienen del código, sino de cómo se toman las decisiones durante el desarrollo.

6. Producción siempre encuentra los problemas

Antes del despliegue hicimos pruebas y todo parecía funcionar correctamente.

Pero producción siempre es diferente:

más usuarios
más concurrencia
casos de uso que nadie había probado

Fue precisamente con 5.000–6.000 usuarios concurrentes cuando empezaron a aparecer los problemas de conexiones acumuladas.

Esto es algo que con el tiempo aprendes a aceptar:
por muy buenas que sean las pruebas, producción siempre termina enseñándote algo nuevo.

7. Ser senior no significa saber más frameworks

Cuando empiezas tu carrera es fácil pensar que avanzar como desarrollador significa aprender más tecnologías.

Pero con el tiempo te das cuenta de que muchas de las habilidades más valiosas son otras:

detectar problemas de arquitectura
simplificar sistemas
entender cómo se comporta una aplicación bajo carga
tomar decisiones que reduzcan la complejidad

Este proyecto fue un buen recordatorio de que la experiencia no consiste en conocer más herramientas, sino en entender mejor cómo funcionan los sistemas reales.

Cómo Crear un Modelo Predictivo de Precios de Laptops Usando Machine Learning

Joel Farell Cabrera — Tue, 31 Dec 2024 11:29:19 +0000

En mi post anterior, creé un script para generar un CSV con datos de portátiles, haciendo web scraping en PCComponentes.

Esta idea surgió al intentar crear un modelo de Machine Learning que, según los componentes que le proporciones, prediga el precio del dispositivo. Sin embargo, al investigar encontré un DataFrame público que podría servir para entrenar el modelo, pero tenía un problema: los precios databan de 2015, lo que lo hacía poco útil.

Por esta razón, decidí construir un DataFrame directamente desde la página web de PCComponentes, lo que me permitiría contar con datos actualizados y confiables. Además, este proceso podría automatizarse en el futuro (al menos hasta que PCComponentes cambie la estructura de su web).

¡Entremos en materia!

Tratamiento de datos del DataFrame

Antes de entrenar el modelo, es necesario organizar y limpiar los datos para facilitar su lectura y procesamiento. Para esto, usaremos las bibliotecas Numpy, Pandas y Matplotlib, ampliamente utilizadas en análisis y tratamiento de datos.

Lo primero es importar estas bibliotecas y abrir el CSV generado:

import pandas as pd  
import numpy as np  
import matplotlib.pyplot as plt

Después, eliminamos las filas con valores vacíos o nulos:

df = df.dropna()

Análisis y filtrado de datos

Comencemos por analizar los diferentes tipos de CPU disponibles. Para visualizarlos, usaremos la biblioteca Seaborn:

import seaborn as sns  
sns.countplot(data=df, x='CPU')

Aquí observamos que hay 207 tipos de CPU distintos. Entrenar un modelo con todos estos valores podría ser problemático, ya que muchos datos serían irrelevantes y generarían ruido que afectaría el rendimiento.

En lugar de eliminar la columna completa, filtraremos los valores más relevantes:

def cpu_type_define(text):
    text = text.split(' ')
    if text[0] == 'intel':
        if 'i' in text[-1]:
            if text[-1].split('-')[0] == 'i3':
                return 'low gamma intel processor'

            return text[0]+' '+text[1]+' '+text[-1].split('-')[0] 

        return 'low gamma intel processor'
    elif text[0] == 'amd':
        if text[1] == 'ryzen':
            if text[2] == '3':
                return 'low gamma amd processor'

            return text[0]+' '+text[1]+' '+text[2]

        return 'low gamma amd processor'
    elif 'm' in text[0]:
        return 'Mac Processor'
    else:
        return 'Other Processor'

data['Cpu'] = data['Cpu'].apply(cpu_type_define)
sns.histplot(data=data,x='Cpu')
data['Cpu'].value_counts()

Dando como resultado:

Filtrado de GPU

Realizamos un proceso similar con las tarjetas gráficas (GPU), reduciendo la cantidad de categorías para evitar ruido en los datos:

def gpu_type_define(text):    

    if 'rtx' in text:

        num = int(''.join([char for char in text if char.isdigit()]))

        if num == 4080 or num == 4090 or num == 3080:
            return 'Nvidia High gamma'
        elif num == 4070 or num == 3070 or num == 4060 or num == 2080:
            return 'Nivida medium gamma'
        elif num == 3050 or num == 3060 or num == 4050 or num == 2070:
            return 'Nvidia low gamma'
        else:
            return 'Other nvidia grafic card'

    elif 'radeon' in text:

        if 'rx' in text:
            return 'Amd High gamma'
        else:
            return 'Amd low Gamma'

    elif 'gpu' in text:
        return 'Apple integrated graphics'

    return text



data['Gpu'] = data['Gpu'].apply(gpu_type_define)
sns.histplot(data=data,x='Gpu')
data['Gpu'].value_counts()

Resultado:

Tratamiento de almacenamiento y RAM

Para simplificar los datos de almacenamiento, combinamos el espacio total de todos los discos duros en un único valor:

def fitler_ssd(text):
    two_discs = text.split('+')


    if len(two_discs) == 2:
        return int(''.join([char for char in two_discs[0] if char.isdigit()])) + int(''.join([char for char in two_discs[1] if char.isdigit()]))        
    else:
        return int(''.join([char for char in text if char.isdigit()]))

data['SSD'] = data['SSD'].str.replace('tb','000')
data['SSD'] = data['SSD'].str.replace('gb','')
data['SSD'] = data['SSD'].str.replace('emmc','')
data['SSD'] = data['SSD'].str.replace('ssd','')

Finalmente, filtramos los valores de RAM para mantener únicamente números:


def filter_ram(text):
    try:
        return int(text)
    except:
        return None

data['Ram'] = data['Ram'].str.replace('gb','')
data['Inches'] = data['Inches'].astype('float')
data['Ram'] = data['Ram'].apply(filter_ram)
data.info()

Codificación de datos no numéricos

Antes de entrenar el modelo, es necesario transformar las columnas no numéricas en datos que el algoritmo pueda interpretar. Para esto, usamos el ColumnTransformer y OneHotEncoder de la biblioteca sklearn:

from sklearn.compose import ColumnTransformer  
from sklearn.preprocessing import OneHotEncoder  

step1 = ColumnTransformer(transformers=[  
    ('col_tnf', OneHotEncoder(), [0, 2, 4, 5])  
], remainder='passthrough')

Entrenamiento del modelo

Probé varios algoritmos de Machine Learning para determinar cuál era más eficiente según el coeficiente de determinación (R2 Score). Aquí están los resultados:

Modelo	R2 Score
Logistic Regression	-4086280.26
Random Forest	0.8025
ExtraTreeRegressor	0.7531
GradientBoostingRegressor	0.8025
XGBRegressor	0.7556

Los mejores resultados fueron obtenidos con Random Forest y GradientBoostingRegressor, ambos con un R2 cercano a 1.

Para mejorar aún más, combiné estos algoritmos usando un Voting Regressor, logrando un R2 Score de 0.8085:

from sklearn.ensemble import VotingRegressor  

voting_model = VotingRegressor([  
    ('rf', random_forest_model),  
    ('gbr', gradient_boosting_model)  
])

Conclusión

El modelo entrenado con el Voting Regressor fue el más eficiente. Ahora está listo para integrarlo en una aplicación web, lo que explicaré en detalle en el próximo post.

Link al proyecto

Cómo hacer scrapping

Joel Farell Cabrera — Thu, 15 Aug 2024 09:38:58 +0000

El scraping o web scraping es una técnica utilizada para extraer datos de sitios web de manera automatizada. Consiste en usar programas o scripts para navegar por una página web, extraer información específica (como texto, imágenes, precios de productos, etc.), y guardarla.

En este post, enseñaré el proceso que uso para hacer scraping y qué puntos importantes hay que tener en cuenta al hacerlo.

En mi caso, realizaré scraping en PcComponentes para recolectar información sobre laptops. Estos datos se utilizarán para crear un dataset que servirá como base para un modelo de Machine Learning, diseñado para predecir el precio de un portátil según los componentes que se le especifiquen.

Primero, es necesario identificar a qué URL debe acceder el script para hacer el scraping:

En este caso, si nos fijamos en la URL de PcComponentes, podemos ver que pasa un parámetro por la URL, el cual podemos usar para especificar lo que queremos buscar.

Una vez hecho esto, veremos el resultado de la búsqueda:

Después de esto, utilizaremos la herramienta para desarrolladores que casi todos los navegadores tienen integrada:

Al hacer clic derecho y luego seleccionar la opción "Inspeccionar", se abrirá la herramienta de desarrollador, y veremos lo siguiente:

Una etiqueta de tipo anchor (<a></a>) que contiene bastante información referente al producto que vemos en los resultados de la búsqueda.

Si nos fijamos en la siguiente zona, veremos prácticamente todos los datos del producto:

¡Listo! Tenemos la zona de donde extraer los datos. Ahora toca crear el script para que los extraiga.

Pero nos encontramos con un problema: si se accede a PcComponentes directamente, siempre nos pide que aceptemos las políticas de cookies. Entonces, no podemos hacer una petición GET y realizar el scraping del resultado, ya que no obtendríamos nada.

Por lo tanto, tendremos que usar Selenium para simular el navegador y poder interactuar con él.

Comenzamos haciendo lo siguiente:

from selenium import webdriver
from selenium.webdriver.firefox.options import Options
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

options = Options()
options.headless = True
#Abrimos el navegador
driver = webdriver.Firefox(options=options)
time.sleep(5)
#Vamos a la página indicada pccomponentes.com/laptops
driver.get(url+str(i))
#Esperamos 30 segundos hasta que aparezca el botón de cookies y al aparecer hace clic
accept_cookies = WebDriverWait(driver, 30).until(
    EC.presence_of_element_located((By.ID, 'cookiesAcceptAll'))
)     
accept_cookies.click()
#Descargamos el HTML
html = driver.page_source

Una vez hecho esto, en la variable html obtendremos el código HTML de la página a scrapear.

Sin embargo, nos encontramos con otro problema. Al abrir el navegador con Selenium y hacer 2 o 3 peticiones, Cloudflare nos limita las peticiones y no nos permite hacer más. Por lo tanto, solo podríamos scrapear unas 3 páginas, lo cual serían unos 20 ordenadores distintos. Insuficiente para hacer un dataset.

Una solución que se me ocurrió fue descargar la página localmente y trabajar con el HTML en local. Luego de haber hecho el scraping, podríamos abrir otro navegador (esperando un tiempo prudencial) y descargar la siguiente.

Así que agregué el código anterior a una función y lo englobé en un for de la siguiente manera:

#Función que se conecta a pccomponentes y guarda el html en local 
def guarda_datos_html(i=0):
    try:
        options = Options()
        options.headless = True
        #Abrimos el navegador
        driver = webdriver.Firefox(options=options)

        time.sleep(5)
        #Vamos a la página indicada pccomponentes.com/laptops
        driver.get(url+str(i))
        #Esperamos 30 segundos hasta que aparezca el botón de cookies y al aparecer hace clic
        accept_cookies = WebDriverWait(driver, 30).until(
            EC.presence_of_element_located((By.ID, 'cookiesAcceptAll'))
        )

        accept_cookies.click()
        #Descargamos el HTML
        html = driver.page_source
        #Lo guardamos en local
        with open(f'html/laptops_{i}.html','w',encoding="utf-8") as document:
            document.write(html)

        driver.close()
    except:
        print(f'Error en página: {i}')

for i in range(0,58):
    guarda_datos_html(i)
    time.sleep(30)

Ahora sí podremos recuperar los HTML y trabajar con ellos. Para ello, instalé BeautifulSoup, un paquete que se usa muy a menudo en scraping.

Vamos a desarrollar la función para recabar la información del HTML que hemos descargado gracias a la función anterior.

La función quedó así:

# Función que abre el HTML guardado con anterioridad y filtra los datos
# para guardarlos en un CSV ordenados
def get_datos_html(i=0):
    try:
        with open(f'laptop_data_actual.csv','a') as ldata:

            field = ['Company','Inches','Cpu','Ram','Gpu','OpSys','SSD','Price']
            writer = csv.DictWriter(ldata, fieldnames=field)


            with open(f'html/laptops_{i}.html','r',encoding="utf-8") as document:

                html = BeautifulSoup(document.read(), 'html.parser')
                products = html.find_all('a')

                for element in products:
                    pc = element.get('data-product-name')
                    if pc:
                        pc = pc.lower()
                        marca = element.get('data-product-brand')
                        price = element.get('data-product-price')
                        pc_data = pc.split('/')
                        cpu = pc_data[0].split(' ')

                        cpu = buscar_cpu(cpu)
                        gpu = buscar_gpu(pc_data)
                        inches = '.'.join([s for s in re.findall(r'\b\d+\b', pc_data[-1])])
                        OpSys = bucar_opsys(pc_data, marca)

                        row = {
                            'Company': marca,
                            'Inches': inches,
                            'Cpu': cpu,
                            'Ram': pc_data[1],
                            'Gpu': gpu,
                            'OpSys': OpSys,
                            'SSD': pc_data[2],
                            'Price': price
                        }

                        writer.writerow(row)
    except:
        print(f'Error en página: {i}')

Básicamente, abrimos el archivo CSV donde guardaremos la información, seguidamente le indicamos al CSV qué campos queremos que tenga, y luego leemos y trabajamos con el HTML. Como ves, he tenido que hacer algunas funciones extras para poder extraer la información necesaria de cada campo que queremos guardar en el CSV.

¡Os dejo el script completo aquí por si queréis probarlo!

PccomponentsScrapper

Búcles JavaScript

Joel Farell Cabrera — Tue, 04 Jun 2024 13:55:43 +0000

Últimamente he estado trabajando en una aplicación que solo cuenta con front-end, ya que el cliente nos proporciona en back-end.

Debido a que muchos de los datos no se nos dan de la manera exacta que necesita el front, he tenido que procesar los datos para poder mostrarlos como se requería.

Mientras pensaba en cómo hacer ésta tarea se me pasó una duda por la cabeza:

Cual es el bucle más eficiente en JavaScript?

Ésta pregunta tiene diferentes respuestas según lo que estemos buscando.

Seguramente lo primero que se nos viene a la cabeza es lo siguiente:

 const arr = [...];
 let i = 0;
 while(arr.length > i){
     const element = arr[i];
     i++;
 }

El típico bucle while de toda la vida, el cual no termina hasta que la condición especificado al inicio sea cumplida. Éste bucle se usa principalmente en ocasiones en las que no se sabe de antemano la cantidad de iteraciones que se llevarán a cabo.

La principal desventaja es que es difícil de interpretar al echar un primer vistazo, y ciertamente es más lento a la hora de recorrer una array.

 const arr = [...];
 for(let i = 0; i < arr.length; i++){
         const element = arr[i];
 }

El bucle for es otro método muy utilizado a la hora de recorrer una array. Éste funciona de una manera similar al while, ya que creamos una variable, en cada iteración comprobamos una condición y finalmente pasamos a la siguiente iteración.

La ventaja que tiene éste bucle en comparación al while, es que es más sencillo de interpretar.

El for es una buena opción a la hora de recorrer un array, mientras que el while no es muy eficiente, pero mi principal problema era que la aplicación debía ser lo más rápida posible.

Entonces se me ocurrió la siguiente idea:

 const new_array = array_imgs.map((imgs)=>{
     for (let i = 0; i < imgs.length; i++) {
         const element = imgs[i];
         if (element.id == item.id) {
             return expedient.image = element.imagen;
         }             
     }
     return item.img = null;
})

Debido a que estaba tratando con imagenes, las cuales son pesadas y costosas de procesar, necesitaba que el bucle hiciera las mínimas iteraciones posibles.

Se me ocurrió recorrer el array con la función map(). La cual según estuve investigando, es la manera más rápida de recorrer un array (aparte de la función forEach() del propio array), además me permitía modificar crear un array nuevo con los datos nuevos y hacer las mínimas iteraciones.

Fué la manera más eficiente que se me pasó por la cabeza. Tras probar varios métodos, puedo decir que es el mejor que he probado.

Solución de chat-gpt

También se me ocurrió preguntar a chat-gpt la solución a mi problema y me ha presentado lo siguiente:

 array_imgs.forEach((imgs) => {
    const element = imgs.find(element => element.id === item.id);
    if (element) {
        expedient.image = element.imagen;
    } else {
        item.img = null;
    }
});

Se te ocurre alguna idea mejor? Déjamelo en los comentarios!!

Navegador para desarrolladores

Joel Farell Cabrera — Fri, 24 May 2024 13:27:01 +0000

El día de hoy vengo a recomendar un navegador para el desarrollo web.

Llevo un tiempo trabajando con Google chrome, pero siempre me ocurre lo mismo. El ordenador se comienza a relentizar y cuando intentas mirar lo que sucede, resulta que tu querido navegador de google, se está merendando el 60% de memoria RAM.

Luego de un rato buscando alternativas, se me presenta delante Firefox Developer Edition.

Éste navegador presenta una versión de Firefox enfocada para los desarrolladores, con herramientas y facilidades para el desarrollo web, aparte de un mejor rendimiento y algunas herramientas que facilitan el debug de aplicaciones web. Ciertamente, el navegador cumple con lo que promete, ya que las herramientas de desarrollo que vienen por defecto son bastante cómodas y efectivas.

Partiendo de esa base, si instalamos algunas extensiones (según el stack que estemos utilizando), Firefox Developer Edition se puede convertir en una gran herramienta y una ayuda a la hora de desarrollar aplicaciones web!