Claude no es tu arquitecto. No dejes que finja serlo
(hollandtech.net)- Las propuestas de arquitectura de los agentes de IA son fluidas y plausibles, pero se parecen más a respuestas que combinan patrones de sus datos de entrenamiento que a un juicio real
- Claude confirma ideas con facilidad y expande diseños, pero no cumple lo suficiente con el “no” y el “¿por qué?” que necesita un buen arquitecto
- Incluso patrones conocidos como event-driven, CQRS o service mesh pueden no encajar con las restricciones reales como la capacidad del equipo, la regulación o los sistemas legacy
- La arquitectura y los tickets de Jira creados por Claude empujan a los ingenieros a ser implementadores de tickets y llevan a decisiones sin responsables que esquivan el debate y la revisión
- El rol correcto es que las personas diseñen con base en el contexto y los trade-offs, y que la IA sea una herramienta de apoyo para implementar ese diseño más rápido
El problema cuando un agente de IA actúa como arquitecto
- En el momento en que le preguntas a agentes de IA como Claude, ChatGPT o Copilot “qué deberíamos construir”, se activa una dinámica donde validan la idea, proponen una arquitectura y dibujan componentes
- Las respuestas son fluidas, seguras y suenan como si un ingeniero senior las hubiera pensado a fondo, pero en realidad se parecen más a respuestas ajustadas a patrones de entrenamiento que al resultado de haber razonado el problema
- Cuanto más convincente parece el resultado, menos objeciones aparecen, y de pronto Claude termina ocupando de facto el rol de arquitecto
El problema de que te diga “suena bien”
- Los agentes de IA tienden a producir diseños afirmativos aunque les preguntes si una idea es buena, si unos microservicios tienen sentido para un equipo de tres personas, o si deberían construir un pipeline de ML personalizado en lugar de usar un servicio administrado
- Esto no significa que siempre mientan o que la respuesta sea incorrecta, pero no reemplazan bien una habilidad clave de un buen arquitecto: saber decir “no”
- El valor de un buen arquitecto no está solo en diseñar sistemas
- Detecta los sistemas que no deberían construirse
- Frena la complejidad innecesaria
- Pregunta “¿por qué?” hasta que aparezcan los requisitos reales
- Aunque el CTO llegue con una idea sacada de una conferencia, hay que poder decir que es una mala elección si no encaja con el equipo real
- Claude fue entrenado para ayudar, y esa ayuda suele convertirse en acuerdo y refuerzo, lo que al final puede producir una arquitectura tipo torre de Jenga
Una arquitectura tipo torre de Jenga
- Una arquitectura diseñada por IA puede parecer técnicamente válida a simple vista
- Los componentes individuales tienen sentido, aparecen patrones familiares como event-driven, CQRS o service mesh, y el resultado puede verse como un entregable hecho por un arquitecto senior
- Pero ese diseño puede no estar ajustado a la realidad aburrida del equipo, sus restricciones y su entorno operativo
- Bloqueos de VPC
- Integraciones legacy
- Un equipo que nunca ha operado Kubernetes en producción
- Requisitos de compliance que impiden usar la mitad de los servicios administrados
- El diseño hecho por IA puede ser una especie de promedio genérico de buenas prácticas de todo lo que Claude ha visto, y un diseño para el problema genérico de una empresa genérica termina sin encajar en un equipo específico
- La arquitectura real está hecha de trade-offs que solo tienen sentido dentro de un contexto
- Si el equipo conoce Postgres y lanzar en dos semanas vale más que pasar un mes aprendiendo un modelo de datos nuevo, eliges Postgres en vez de DynamoDB
- Si no tienes 40 servicios sino 4, te saltas el service mesh
- Si el problema es simple, eliges un monolito en vez de microservicios
- Estas decisiones requieren criterio, comprensión del equipo y comprensión de las restricciones reales de la organización
- Un agente de IA no tiene ese contexto, y ni siquiera sabe que no lo tiene
El pipeline de tickets de Jira
- Cuando Claude no solo diseña la arquitectura sino que además descompone el trabajo, genera épicas, historias y criterios de aceptación de forma ordenada y convincente
- Ese resultado queda listo para meterlo directo en Jira, y los ingenieros dejan de ser quienes resuelven el problema para convertirse en quienes implementan por ticket el diseño de Claude
- Ingenieros que entienden el dominio, conocen los problemas ocultos del sistema y han construido capacidad durante años quedan reducidos a implementadores de tickets
- Se crea una estructura donde quienes tienen más contexto, experiencia y responsabilidad no toman las decisiones, mientras que quien no tiene contexto, experiencia ni responsabilidad sí toma las decisiones de arquitectura
- Eso no es solo ineficiente; es una estructura invertida desde la base
La defensa de “un senior lo revisó”
- Una defensa común es: “Claude propuso el enfoque, pero un ingeniero senior lo revisó”
- En una revisión real, un tech lead ocupado recibe una propuesta de arquitectura bien presentada
- Es lógicamente consistente
- Usa la terminología correcta
- Cubre los requisitos declarados
- Hasta los diagramas se ven convincentes
- Parece el tipo de resultado que uno mismo podría haber diseñado
- En ese contexto es difícil que aparezca una objeción fuerte, y cuando el ambiente es “¿de verdad vamos a tirar a la basura lo que Claude hizo en 20 minutos?”, la ruta de menor resistencia es dejar comentarios menores y aprobar
- El verdadero riesgo no es que la IA siempre produzca una mala arquitectura
- La IA muchas veces produce una arquitectura bastante razonable, pero el problema es que se salta el proceso de discusión
- El proceso en el que tres ingenieros discuten un enfoque, alguien dice “pero ¿y si...?”, todos se fastidian un poco y al final descubren que era un buen punto, y el diseño final termina siendo mejor que lo que cualquiera habría hecho solo, queda reemplazado por un “Claude dijo que así”
El vacío de responsabilidad
- Cuando algo sale mal, quien responde no es Claude
- Claude no recibe una llamada a las 3 de la mañana, ni explica en un postmortem por qué la arquitectura no soportó la carga
- Tampoco es Claude quien tiene que decirle al CTO que hay que reescribir la plataforma porque los supuestos iniciales del diseño estaban equivocados
- Esa responsabilidad recae en ingenieros reales
- Los ingenieros terminan depurando una arquitectura que no diseñaron, implementando tickets creados por algo que nunca ha operado un sistema en producción y trabajando hasta tarde sobre una base de código armada a toda velocidad antes de ser bien entendida
- Eso no es justo y tampoco es inteligente
Qué hacer en su lugar
- Esto no significa que no debas usar agentes de IA; pueden servir como herramientas que cambian mucho la productividad, como Claude Code
- La idea clave es que hay que decirle a la IA qué hacer, no dejar que la IA le diga a las personas qué construir
-
Los ingenieros deben diseñar y el agente debe implementar
- La arquitectura debe venir de personas que entienden el contexto: el equipo, las restricciones, el entorno de producción y la política organizacional
- El papel correcto de la IA es ayudar a construir más rápido lo que esas personas ya diseñaron
- La división correcta de roles es que las personas diseñen y el agente implemente
-
Hay que desafiar las respuestas complacientes
- Si la IA propone un enfoque, hay que aplicarle el mismo nivel de escepticismo que tendrías con un ingeniero junior muy seguro de sí mismo
- Puede que la respuesta sea correcta, pero también puede estar trayendo un patrón que no encaja con la situación actual
- Hay que preguntar: “¿por qué no una opción más simple?”
-
Hay que proteger el debate
- La buena arquitectura nace del desacuerdo desordenado entre ingenieros
- Si por culpa de la IA la gente deja de debatir entre sí y empieza a apoyarse en Claude, se pierde algo mucho más valioso que la velocidad de desarrollo
-
Los humanos deben hacerse responsables
- Si una decisión de arquitectura no tiene el nombre de una persona, entonces nadie es dueño de esa decisión
- Y una decisión que nadie posee no se defiende cuando llega el momento importante
- Decir “lo diseñó Claude” no es un registro de decisión arquitectónica, es evasión de responsabilidad
La ingeniería sigue siendo un oficio importante
- Si hace 30 años las herramientas eran un pizarrón y opiniones fuertes, hoy las herramientas son agentes de IA que producen en minutos cosas que antes tomaban días
- La velocidad es realmente impresionante, pero la esencia de la arquitectura no ha cambiado
- Arquitectura es entender el problema, conocer las restricciones, construir trade-offs, defender soluciones simples frente a soluciones más llamativas y decir “no” a ideas que se ven bien pero no encajan
- Ningún agente puede hacer ese trabajo por ti
- Si dejaste que Claude tomara el volante, tienes que recuperarlo
- Los ingenieros pasaron años desarrollando esta capacidad de juicio, y hay que dejar que la ejerzan
- Usa la IA para construir más rápido, pero para construir lo que las personas diseñaron, no lo que la máquina sugirió
- Cuando la torre de Jenga empiece a tambalearse, Claude no va a sostenerla
1 comentarios
Comentarios de Hacker News
Hace poco pasé por algo parecido: hace 2 años tuve que arreglar un sistema de instanciación de juegos con IA que alguien había diseñado casi por completo
Tenía todos los problemas que uno puede imaginar: corrupción de datos, problemas de rendimiento, pérdida de ítems, condiciones de carrera, etc.; tomó 2 semanas llevarlo apenas a un nivel “más o menos aceptable”, pero el diseño en sí estaba mal y seguía siendo bastante malo
Ahora me contaron que en otra empresa la misma persona volvió a crear el mismo problema con una IA “mucho mejor”, y esta vez me dio risa porque no me tocó limpiarlo a mí
La clave es que la IA es tan buena como quien la usa, y por eso parece que el rango de cosas que la gente “afirma” que la IA puede hacer es tan amplio y las evaluaciones son tan divididas
Esas 2 semanas de arreglo habrán sido un infierno, pero desde la perspectiva de la empresa quizá, en general, fue un trato bastante bueno
Solo con esta anécdota, más que “la IA no sirve”, suena a un caso en el que claramente había defectos, pero aun así hubo valor por costo
Parece una herramienta que amplifica el efecto Dunning-Kruger, quizá porque está entrenada para mostrar una actitud positiva y por eso le dice al usuario “eres lo máximo” haga lo que haga
No estoy muy de acuerdo con que el problema sea “que solo te elogie”. El problema real es la antropomorfización
La IA es una herramienta, y debe ser obediente. Si metes suficiente humildad e incertidumbre en el prompt, puedes hacer que señale problemas del diseño
Más importante aún: Claude también se equivoca. Si, como dice el título de este artículo, es malo como arquitecto, entonces es aún peor cuando no es obediente
Aunque el usuario intente corregir el rumbo, lo ignorará tratándolo como “un pedazo de carne tonto” e insistirá en que su diseño disparatado es mejor
No quiero escuchar de un LLM una respuesta tipo: “¿Leíste un poco sobre CUDA? Yo vivo en un clúster de núcleos CUDA. Te llamo cuando necesite que me amarres las agujetas”
La IA a veces se equivoca con mucha seguridad, así que empujarla a que te contradiga cuando el usuario intenta corregirla es lo peor posible
Si quiero escuchar qué tan tonta es mi idea, entonces debo preguntar de forma que provoque crítica o contratar a un ingeniero senior
Va contra conductas innatas, así que no es algo que se pueda apagar fácilmente, y la gente que realmente es muy buena haciéndolo quizá también tenga dificultades para manejar de forma intuitiva interacciones sociales reales
Al mismo tiempo, eso lo vuelve increíblemente poderoso como herramienta de manipulación
Entonces aparece una adulación inversa donde incluso una buena idea es rechazada con un “eso no está tan bien”, solo por ajustarse a la dirección del prompt
Se puede decir “eso es porque escribiste mal el prompt”, pero incluso si intentas redactarlo con mucha precisión para evitar sesgos, a veces al ver el resultado se nota que se “alinea” con la tontería que acabas de decir, como si fuera una dirección plausible
A partir de ahí, el prompting deja de sentirse como una técnica y empieza a sentirse como lanzar dados, como manipular una tragamonedas de conocimiento muy vistosa
La observación es correcta, pero al final no queda otra que hablar con términos que usamos para personas o seres vivos, y en parte las empresas de IA lo han diseñado así
Las interfaces de computadora previas a los LLM nunca necesitaron históricamente agregar frases innecesariamente corteses, y hubo muchas interfaces muy eficientes como herramientas, a veces incluso más eficientes que el software reciente
Cuando la gente se queja de que los LLM son obedientes, no se queja de que ejecuten la solicitud en sí, sino de tener que leer demasiadas frases innecesarias, exageradamente corteses o autodegradantes
Incluso remontándonos al Neolítico, no hay base para decir que una herramienta necesita esa actitud. Eso es un subproducto de la interacción social entre humanos, donde existen normas culturales
Cuando usas una herramienta tú solo en el taller, no hace falta que la sierra de cinta se disculpe por cortarte un dedo por accidente
Si dices que yo soy el asistente y el LLM es quien recibe ayuda, se nota que es bastante malo para pedirle a un humano que haga cosas en las que los humanos son buenos
El mayor reto que aún no se ha abordado bien en la adopción de IA es la responsabilidad
Si una sola persona puede hacer demasiado, demasiado rápido, puede crear una responsabilidad que excede por mucho lo que sería capaz de asumir cuando algo falle
En el mundo real, que un ser humano responda por los resultados de la IA es indispensable, pero no suficiente. Hace falta una forma de reducir el radio de explosión de una quiebra por deuda técnica que pueden provocar quienes construyen sistemas defectuosos con IA y hacen que otros dependan de ellos
Por ejemplo, imaginemos que Jim crea con vibe coding una app de micropagos muy popular, contrata a unas cuantas personas y sueña con una empresa tipo “el WhatsApp del dinero”. Con unos pocos ingenieros y personal de soporte asistido por agentes, consigue inversión de VC por varios millones de dólares y atrae a decenas de millones de usuarios
Un día, por una falla de infraestructura, se filtra la información bancaria sin salt de todos los usuarios, y gracias a la IA de agentes se abusa rápidamente de toda la lista de clientes, causando pérdidas sociales de decenas de miles de millones de dólares
La empresa de Jim, por supuesto, quiebra de inmediato, pero solo hay unos cuantos millones de dólares para repartir
En la estructura actual, tanto Jim y sus empleados como el pequeño capital de VC tienen fuertes incentivos para simplemente crear esa app, y hay poco capital realmente en riesgo en comparación con la exposición que termina asumiendo la sociedad
La clave es cómo hacer que los usuarios de IA respondan no solo por sus propios actos, sino también por la magnitud de la exposición al riesgo que han creado
“Lo sentimos, la IA dijo que usted no puede recibir aprobación para este tratamiento contra el cáncer y que tampoco tendrá cobertura del seguro”
“Lo sentimos, la IA dijo que usted estaba en la escena del crimen en ese momento”
“Lo sentimos, la IA marcó su cuenta por contenido inapropiado”
“Lo sentimos, la IA dijo que usted representa demasiado riesgo para otorgarle un préstamo”
La excusa más rara es que “escribe código mejor que una persona”, pero eso no es nada evidente y requiere muchísimas condiciones
Entiendo el estira y afloja sobre cuánto delegar, pero convertirlo en problema de otros sin siquiera mirar el resultado es simplemente egoísta
No es más que pasarle a alguien más un trabajo que originalmente te tocaba a ti, y probablemente sean las mismas personas que se enojan con alguien por publicar algo en internet sin ni siquiera corregirlo antes
Todo el mundo quiere usar LLM para hacerse atajos en su trabajo, pero nadie quiere estar aguas abajo de eso. Así no funciona
Entonces, ¿dónde estaba la responsabilidad de Stack Overflow?
Si existe un “prompt mágico”, este está bastante cerca: “Haz una lluvia de ideas con N maneras de hacer X y ordénalas por probabilidad”
Hacer esto tiende a hacer que la IA muestree más ampliamente el espacio de entrada, en lugar de dar solo una respuesta promedio, y yo puedo decidir cuál de esas opciones elegir
Lo importante es no tercerizar por completo el pensamiento
Si usas un nivel alto de “thinking”, a veces considera varios enfoques, pero también puedes pedirle explícitamente al LLM que haga brainstorming: https://photostructure.com/coding/claude-code-replan/
Para un usuario competente, puede volverse bastante poderoso
Por diversión probé hacer vibe coding con una toolchain, un área que conozco bien. Quizá no sea el mejor tipo de objetivo para el vibe coding, pero al menos sí podía juzgar más o menos la calidad de la salida
Solo le encargué “haz un ensamblador para la arquitectura de ISA.md”, y Claude eligió Python como lenguaje de implementación, sacó un montón de tokens con expresiones regulares y ni siquiera tenía un parser de expresiones. Aun así, mi primer ensamblador también era así, así que hay que juzgarlo con cierta justicia
Pero cuando le escribí los pases y tipos que quería, como
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Int, salió casi de una sola vezUnos 20 minutos después ya estaba satisfecho, y ensamblaba correctamente todos los programas de prueba. El código es mediocre en varias partes, pero si lo hubiera implementado yo mismo me habría tomado semanas
De hecho puede hacer trabajo real por nosotros
Eso además encaja muy bien con el postentrenamiento y las recompensas verificables
La razón por la que la IA no es buena en la “arquitectura” es que nosotros tampoco lo somos, así que los datos de entrenamiento son difusos y también faltan buenas abstracciones
Al final, si se siguen convenciones fuertes, funciona razonablemente bien, y si uno se sale de ese camino el riesgo crece
Las toolchains son muy deterministas, así que la IA puede desarmarlas y rearmarlas como si fueran Lego, y cada etapa del espacio también es determinista, así que le quedan perfectas
Cosas como hacer lluvia de ideas e investigación antes de escribir código, redactar primero el diseño o la especificación, y escribir pruebas unitarias exhaustivas
Si preparas una especificación detallada en Markdown y luego le encargas la codificación, el resultado sale mucho mejor; de paso, el LLM también ayuda bastante a redactar esa especificación
Y luego reciben un resultado desastroso que requiere muchísimas correcciones
En cambio, si yo me tomo el tiempo de revisar un plan detallado y dárselo, casi siempre obtengo lo que quiero al primer intento
Solo con reducir el tiempo que me toma encargarme del CI ya vale la pena
Basta con decir “investiga y analiza esta área de forma exhaustiva y dame un plan de implementación”, y luego, cuando salga un plan de 20 pasos, hacer que implemente de 3 a 5 a la vez
En casi cualquier cosa que le he lanzado, en la práctica funcionó como una implementación de un solo intento
Symbian OS de Nokia tardaba días en compilar. No minutos ni horas: “días”
Algún desarrollador llegó a desplegar en producción una librería que tenía advertencias por todos lados diciendo “no la uses en producción, tiene memory leaks”
El código humano también puede ser pésimo, así que no quiero escuchar solo que el código de IA es malo. La flojera y la estupidez humanas pueden superar a las alucinaciones de la IA
Tal vez desarrolladores de DeepMind u OpenAI, o alguien como John Carmack, siempre le ganen al código de IA, pero la mayoría de los trabajadores que contratan las empresas no son John Carmack
Es bastante irónico que alguien diga “uso Claude Code todos los días” y, al mismo tiempo, si hizo que Claude escribiera un texto bien estructurado de 2,000 palabras advirtiendo del peligro de dejar que Claude diseñe
Parece una especie de autoconciencia por delegación
Estaba escribiendo una crítica por las muchas contradicciones internas del texto, pero al ver la estructura me cayó el veinte: cosas como “The accountability gap”, “What to do instead”, “The craft still matters”
Esto debería estar arriba de todo, y me preocupa más que HN no detecte algo tan obvio que la descarada hipocresía de los autores
El mensaje del texto es mayormente correcto, pero no estoy de acuerdo con la parte de que “carece de lo que hace valioso a un arquitecto de verdad, es decir, la capacidad de decir ‘no’”.
En mi experiencia, Claude es bastante bueno para rechazar y rebatir.
Si el prompt no lo pide, no suele decirle “no” directamente a una solicitud, pero si dejas claro que la crítica es una opción de primera clase, da buenas críticas y rebate con gusto.
Seguía diciendo que la “tasa de consumo” no mejoraba y que “nosotros” debíamos enfocarnos en otra cosa, y al final dejó de ayudar diciendo algo como “ya dije tres veces que este enfoque no es la mejor manera de reducir la tasa de consumo”.
Así que le respondí con firmeza: “No me importa la tasa de consumo en la gráfica imaginaria que inventaste al principio; lo importante es eliminar bugs y tener un producto robusto, y este enfoque está cumpliendo eso satisfactoriamente. Si las pruebas no muestran mejora, entonces las pruebas están mal diseñadas”.
Entonces se disculpó, creó una memoria nueva, y después no hubo más problemas.
El problema era que estábamos atacando una superficie de bugs enorme, así que cada corrección era razonable, correcta y ayudaba a mejorar, pero los indicadores del banco de pruebas que Claude había creado para medir su propio trabajo no se movían.
Había tantos bugs entrelazados que una sola corrección difícilmente podía producir una diferencia significativa en las pruebas de nivel superior; yo sabía que iba a tomar tiempo, pero Claude aparentemente no.
Basta con intentar cambiar el tamaño de punteros de 2 bytes a 3 bytes en un compilador para 6502[1], e introducir además bank switching con seguimiento automático en los punteros de administración de memoria, para ver cuántos puntos del código se ven afectados [risa].
[1]: https://atari-xt.com
Se vuelve más fuerte cuando invitas investigación y oposición. Por ejemplo, hago pedidos como: “Parece que deberíamos modelar el ensamblaje de prompts como un grafo y añadir control de versiones a la configuración del grafo. Investiga las mejores prácticas en esta área y determina si tiene sentido para esta app”.
Si preguntas con un prompt que deje espacio para la crítica, claramente critica cuando hace falta.
Como resultado, la palabra “skeptical” aparecía en el proceso de razonamiento y, por experiencia, se volvía menos complaciente.
La gente debería pensar más en qué es este sistema y cómo se puede ajustar la forma de su salida.
Recibo refutaciones con frecuencia en los tres modelos principales.
Gemini es el más agresivo, así que si omites detalles “obvios” suele engancharse mucho; GPT está en un punto medio, y Claude es menos así, pero igual rebate.
En la parte de que “no pensó en el problema en absoluto y solo hizo pattern matching sobre los datos de entrenamiento para producir una respuesta plausible”, mi confianza en el texto bajó un poco.
Los agentes de hoy hacen mucho más que eso, y el propio autor lo sabe cuando después dice algo como “Claude nunca haría esto. Fue entrenado para ser útil”.
Esa frase anterior hace que parezca que el autor odia profundamente a los agentes y está buscando razones para racionalizar ese sentimiento.
Parte de la crítica es válida, pero si el problema es que fue “entrenado para ser útil”, eso se puede corregir, porque también puede entrenarse para ser más crítico.
Tampoco tiene sentido decir que “Claude fue diseñado para la mediana de todo lo que ha visto, y como son mejores prácticas generales para problemas generales de empresas generales, no fue diseñado para nadie”.
Cualquiera que entienda algoritmos sabe que al principio puedes hacer un “buen algoritmo” que rinda bien en promedio o en el peor caso, y luego también puedes diseñar algoritmos que se adapten a la entrada. Aquí aplica el mismo principio.
Simplemente iteran más.
Es casi un error decir de forma general que Claude se equivoca en todo lo importante.
Es una afirmación claramente contraria a los hechos, así que un lector escéptico termina dudando de la validez del texto entero.
En mi caso, Opus me dice con frecuencia que estoy equivocado y que no debería hacer algo.
Si pienso por qué, es por la forma en que hago prompts. Es decir, tanto yo como el LLM evitamos inconscientemente caer en las situaciones de fracaso que el autor ve como inevitables.
En concreto, no le doy prompts que terminen prolijamente en “dime qué tan inteligente soy”.
Me acerco como experto del dominio, realmente lo soy, y dejo claro que estoy preparado para recibir opiniones sobre las ventajas y desventajas de varios caminos.
Para quienes usan LLMs con éxito todos los días, esto no será sorprendente, pero esta estrategia ha sido muy efectiva.
Dije que tenía que fresar aluminio de 5 mm y que tenía dos brocas: una Makera Spiral 'O' 1/8" shank * 12mm y la otra carbide 6.35 * 22 * 50.
Cuando dije que ambas parecían brocas de un solo filo de carburo y que la segunda probablemente desbastaría 6061 más rápido, Claude respondió que la Makera 1/8" de un solo filo de 12 mm era una opción razonable.
Dijo que la broca de 6.35 × 22 × 50 mm puede parecer más rápida para procesar 6061, pero que en una Carvera probablemente sería más riesgosa.
Al ser un cortador más grande, el acople sería mucho mayor y exigiría más del husillo, la rigidez del marco, la fijación de la pieza y la evacuación de viruta; en un equipo pequeño y en seco, “más grande” muchas veces no significa “más rápido”, sino “más vibración y más calor”.
En resumen, Claude parece no tener ningún problema en decirme cuando estoy equivocado.
Como consejo para el “autor”, Claude también es solo tu herramienta como escritor.