#9 El problema de la falta de programadores y arquitectos "seniors" es que, básicamente, las big tech, multis de renombre y startups de altos vuelos los están acaparando a todos con salarios estratosféricos, por lo que muchas pymes y charcuteras clásicas han visto en la IA la tabla de salvación a este problema.
Pero como ya predijimos muchos hace años, lo único que conseguirán serán productos más mediocres al limitarse a copypastear lo que caga la IA sin ningún control ni criterio. Y como es obvio, el tiempo nos ha dado la razón.
El problema de la falta de programadores y arquitectos "seniors" es que, básicamente, las big tech, multis de renombre y startups de altos vuelos los están acaparando a todos con salarios estratosféricos, por lo que muchas pymes y charcuteras clásicas han visto en la IA la tabla de salvación a este problema.
Pero como ya predijimos muchos hace años, lo único que conseguirán serán productos más mediocres al limitarse a copypastear lo que caga la IA sin ningún control ni criterio. Y como es obvio, el tiempo nos ha dado la razón.
#9 La nueva subcontratación a la India. Algo de lo que ni el director de consultora más chorizo plantea ya.
Mientras los "gurús" y los que por alguna extraña razón desean que la IA triunfe y mande a muchos al paro o a cobrar en cuencos de arroz siguen dando bombo al asunto, los que ya peinamos canas y llevamos al menos dos vaporwares a cuestas sabemos que lo que se promete al gran público con la IA es simplemente imposible con un ordenador de toda la vida. Si se acaba… » ver todo el comentario
Todavía recuerdo un proyecto, grande, con muchísimo código, donde debido a la nula estructura y calidad del mismo cada release era un infierno de bugs y regresiones. Se me ocurrió preguntar por el "arquitecto". Nadie supo quien era, no llegué a conocerlo por lo que intuí que cada programador escupía código donde le tocaba preocupándose sólo de su mierda. Pensé que era un caso aislado.
#60 Incluso así esa función es necesaria de alguna manera o se cae en lo que dice #46 .
Tiene que haber un estándar y una forma común de trabajar. Que da la coña que el equipo es lo bastante maduro y sabe organizarse sin un policía encima, enhorabuena y profit. Pero si cada uno barre para su lado, al final el código se convierte en un ñordo inmantenible que al final acabará en el cubo de la basura.
Yo estas cosas no las negocio. Un estándar. El que sea. Mejor uno incompleto que ninguno.
#64 ¡Claro que es necesaria! Una persona con un látigo y marcando las directices y líneas rojas en un proyecto grande es muy necesaria. En muchas ocasiones o no existe o no da la taya, que es casi hasta peor.
#60 Depende del tamaño del proyecto. Se pueden hacer muchísimas cosas sin que sea necesitado un ingeniero en arquitectura de datos. También que su trabajo lo esté haciendo un senior sin apuntarse el mérito.
#9 Aquí en España yo aún no he ido a parar a un proyecto que considere que realmente se está desarrollando correctamente.
Vamos, es que desde las bases ya está mal, yo puedo mergear mi propio código a las ramas de desarrollo y no puedo desplegar a producción. Ahí ya hay suficientes problemas para trabajar antes que ponerse a meter IA en el código.
#51 No puedes desplegar a producción directamente porque tú no ejecutas un sin fin de tests de todo tipo para asegurarse que no has roto nada de lo anterior.
Si tu producto no es clave a la hora de funcionar, podeis hacer TBD para hacer pequeños commits a producción. Yo siempre que me he encontrado esa situacion, se debe a que hay programadores que llevan en la empresa un millón de años y conocen el producto como la palma de su mano. En productos donde hay una gran rotacion, y con gran rotacion me refiero a que entra gente nueva cada año, o año y medio, es mejor no hacer TBD. Se necesita tiempo para que los nuevos conozcan el código.
#90 Es que justo me refiero a eso, que donde falta cultura es en la parte de testeo del software, que al final consigue agilizar los cambios y los evolutivos.
En mi caso sí tenemos cobertura completa de test unitarios pero ya sabrás que eso no es suficiente para asegurar que las modificaciones al producto no rompen nada de lo anterior.
Y no, no hacemos ni TBD ni tampoco hacemos TDD a pesar de tener 100% cobertura.
Por ahora es lo que hay supongo, ojalá termine en algún sitio donde se respeten unos principios que me gusten, por ahora no.
#91 no basta con hacer unitarios. Hay que hacer tests de regresión, end to end, de integración, funcionales, de aceptación,...
La cobertura 100% no sirve casi de nada si no se alinea con los tests de un sonarqube a la hora de escanear vulnerabilidades del código. Es un afrodisíaco, uno peligroso, porque te hace indicar que todo va bien y estás arrastrando problemas que un día un puto cracker va a aprovechar.
“ …está generando 'profesionales' que simplemente copian y pegan código generado sin entenderlo del todo”
Y esto lo está produciendo la IA, claro, claro.
#3 Esto va a ser como en el cole con la prohibición de la calculadora "que luego me poneis los números que salen en la pantallita y no sabeis ni lo que estais haciendo".
#3 como si nunca hubiera existido el chiste aquel:
- ¿de dónde has sacado ese código?
- de stackoverflow
- ¿lo copiaste de la pregunta o de la respuesta?
Yo lo suelo usar casi exclusivamente para los tests. Haces una función y le dices a copilot qué te pruebe todas las casuísticas. Compruebas que las entradas y salidas son correctas y ya.
Para poco más sirve. La mayoría de las veces no es capaz ni de arreglar un error de compilación de forma correcta, mucho menos crear código optimo, de hecho una vez probé a que me calculase la complejidad ciclomatica de un algoritmo y falló absurdamente y mucho menos saber optimizar para hacer menos memory allocations.
#57 si no estoy haciendo una libreria para terceros raramente. En Go por ejemplo la documentación es mucho mas laxa. cualquier comentario ya vale
// NewReaderSize returns a new [Reader] whose buffer has at least the specified
// size. If the argument io.Reader is already a [Reader] with large enough
// size, it returns the underlying [Reader].
func NewReaderSize(rd io.Reader, size int) *Reader {
// Is it already a Reader?
b, ok := rd.(*Reader)
if ok && len(b.buf) >= size {
… » ver todo el comentario
#62 por favor, usa mejores nombres para las variables. Qué es r? que es b? que representa funcionalmente? cuando hablamos de comentar o no, precisamente argumentamos que hay que documentar por culpa de tu estilo de primero de programación donde todos usábamos estos nombres de variables que no significan nada para una persona que acaba de leer tu código por primera vez.
El código debería ser como una novela, una entretenida a ser posible, y debe tener la menor complejidad ciclotómica posible.
Tanto cuesta poner que r es reader? que b es un buffer de memoria del reader anterior?
No te molestes, es una buena crítica que te hará mejor profesional.
#87 pues vaya, y de lo que te he dicho, algo que decir?. ¿Qué sea la librería standard de Go implica que es palabra de Dios?
Paso de hacer pull requests a lenguajes que no uso. ¿Vas a hacer lo mismo con tu código? Del Clean Code, no tengo nada que decir, considero que es un libro que ha envejecido muy mal.
#92 pues que hay muchas filosofías diferentes, en concreto la de Go es ser escueto, inclusive los nombres de las variables. Pero es que si te vas a cualquier code base de C, de donde bebe Go, te encontrarás lo mismo. De ahi los for i, j de los que llevamos ya tiempo en esto.
Te animo a que mires el código de Kubernetes o de Prometheus y lo compruebes por ti mismo, y son dos proyectos OSS muy usados
Conclusión. Hay muchas formas de hacer las cosas. No hay que ser dogmático ni dar por hecho cosas, como que el código que había pegado era incorrecto porque yo soy un programador novato. Y respecto a mi código, pues si te pasas por uno de los proyectos OSS con más estrellas lo encontrarás, pero valoro la privacidad
#94 si te entiendo, pero esos proyectos, k8s y prometheus está lleno de gente con más años que tu y que yo en esos proyectos, y probablemente con toda la experiencia del mundo en lenguajes como c, c++ y ahora go y rust que han heredado todo lo malo de programar con c y c++.
Yo quiero leer código que pueda entender de una pasada, a ser posible no quiero tener que preguntar al programador que cojones quiere hacer en esa subrutina. Si, hay muchas formas de hacer las cosas, legibles o no legibles. No te enfades.
#96 No me enfado, llevo 15 años programando (profesionalmente), he programado de forma profesional en C, C++, C#, Python, JS y Go. Como todo el mundo pasé por mi época del clean code, TDD, extreme programing, programación funcional y acabé volviendo al punto de partida. Te das cuenta que "cada" comunidad tiene sus mantras y su forma de ver las cosas.
Al final cada uno crea su estilo de programación y para eso tienes que exponerte a muchos tipos de código. A dia de hoy valoro más la simplicidad y eficiencia que la elegancia.
#97 a mí también me gusta la simplicidad y eficiencia, pero al mismo nivel está la legibilidad. En mi opinión, esas tres características ofrecen código elegante. Yo llevo unos años más, no muchos más, profesionalmente hablando. C, c++, c#, java, scala, y python. Todos hemos pasado por ese camino, al final, nos quedamos con lo que más nos gusta y desechamos lo que no. A mí no me gusta demasiado el estilo funcional ni la programación de puertos y adaptadores.
#1, si de verdad opinas que las herramientas de generación de código solo sirven para los tests, opino que o te reciclas o tienes un futuro muy crudo en la industria.
#78, estamos hablando de una tecnología que hace 4 años era ciencia ficción, es normal que todavía no se note el impacto. Además no para de evolucionar. Yo creo que vivir en la negación es lo mismo que el que no quiere ir al médico para que no le digan las cosas malas que tiene. Pero la IA en programación va a arrasar, no tengo ninguna duda.
#82 nadie vive en la negación. Tengo licencia de Copilot, tengo Ollama corriendo en mi máquina con Llama 3.2. Uso OpenAi, Claude etc. I justamente por eso SE lo que ofrece a dia de hoy. En el futuro ya veremos
#83, yo también y también se lo que ofrecen hoy en día por eso no me casa con los que dicen que no sirve para nada. Yo soy el triple de productivo escribiendo código.
Si lo han entrenado con lo que subí a GitHub en su día... no me extraña que salga un código funcional (lo que hice era funcional), pero ineficiente, poco nos pasa.
#5 Sólo han cogido el código de mayor calidad para entrenarlo. La gran mayoría de código, el tuyo, el mío, el de todos en este chat ha sido descartado. Por ejemplo, cogen el de los proyectos con cientos o miles de estrellas, el que aparece en los how-to oficiales de los proyectos open source.
#19 el mismo código que como sea un poco largo te dará tras 5-6 "continuar" eternos, en que verás como todo el código que te va dando no cambia para nada respecto al anterior, salvo una última linea (linea 1553 de un script de 1600 lineas) en que habrá hecho un cambio minúsculo (y equivocado).
#15 yo a estos modelos de lenguaje que escupen código los tomo como cuñados sabios pero cuñados, con lo que hay que andar con ojo. Van muy bien de apoyo pero al final es el usuario el que se responsabilice de lo que meta en el listado...
Al menos se nos disculpan y no nos sueltan un "tú confia en mi" cuando les cazamos los gazapos, aunque también se le podría decir al modelos que emule esa actitud
#6, prueba de preguntarle a o1, verás que en la mayoría de casos ya no es así. El problema con la IA es que cuando descubres el modelo que acaban de lanzar, ya es el penúltimo en cuanto a capacidades. La gente se queda con fotos estáticas de una tecnología que evoluciona a la velocidad de la luz. Mi pronóstico es que el desarrollo de código con lenguaje no natural, será tan residual dentro de 10 años, como hoy lo es el ensamblador.
#79 Imagino un compilador universal, en el que puedas programar con lenguaje natural o con cualquier otro lenguaje, incluso mezclando varios distintos, y que él integre los lenguajes que has usado, corrija los errores, optimice el código, los compile y los ejecute.
#100, los repositorios de código serán descripciones hechas con lenguaje natural de lo que quieres que haga el programa y a lo sumo algún fichero multimedia o de configuración.
Los llms no piensan, no entienden, lo que hacen es interpretar muy bien.
La calidad de la respuesta viene dada por la calidad de la pregunta, los detalles, el contexto y los límites.
Si le das todo el problema muy bien planteado normalmente te genera código muy bueno, que luego puedes llegar a optimizar pasándole nuevas órdenes.
Yo lo uso así cuando me atasco en algo muy complejo, que me supondría tener que pasar por muchos errores sintácticos hasta llegar a un código óptimo dentro de los parámetros que necesito.
Obviamente para eso hay que saber el lenguaje para poder descartar o no lo que te está ofreciendo.
Los malos desarrolladores copian-pegan codigo sin mirarselo de la IA o de donde sea (o peor: se lo miran y lo pegan igual). Los buenos ingenieros usamos ese codigo, lo entendemos y lo aplicamos reescrito si es necesario, usando la IA como la herramienta que es... No como si fuera el oráculo de Delfos.
#22 No es un tema de "IAFobia", es un tema de que la gente no es consciente de que la I de IA es una "i pequeñita". No hay verdadera inteligencia, esa la tienes que poner tú cuando usas la herramienta.
Tal y como dice #21
#7 y de gente que pone el sonarqube para que no salten alarmas ante problemas menor que crítico. Se va acumulando con el paso de los años decenas de miles de bugs de menor categoría e incluso algún crítico que otro con un CVE publicado pero que los mandamases que no programan obligan a los mantenedores a desactivar el sonar para crear una build porque para tal día tenía que haber una release, so pena de multa. Visto con estos ojitos en grandes bancos, empresas de telecomunicaciones,… » ver todo el comentario
#88 yo he sido uno de esos tech leads talibanes del código, y lo único que conseguí es recibir palos tanto de mi empresa como de los clientes. Y peor todavía de otros tech leads que al final eran poco más que parias del acceptance pero Como salga y patada palante. Cada auditoria interna un drama terrible.
Mi equipo encantadísimo. Pero los plazos y el para ayer y te pongo 5 junios y cobramos 4 seniors, pues... Eso. Y ser visto como un policía de asuntos internos de calidad, peor.
#89 joder, no me considero talibán del código, pero joder, si tenemos herramientas que nos están diciendo que hay algo mal aquí, y que se puede solucionar haciendo esto o lo otro, para mejorar el código y/o la legibilidad del mismo y el mismo sonar te dice como hacerlo, pues, no cuesta nada no?
No hacerlo implica que tarde o temprano vienen despidos porque tal base de código ya no vale, hay que rehacerlo por completo, a lo mejor con otro lenguaje, y los que tienen el conocimiento funcional a la puta calle porque son de java y ahora hay que hacerlo con python porque blablabla de un CTO al que nunca has visto pero su palabra es Dios.
Cambia PROGRAMACIÓN por COPYWRITING y es exactamente lo mismo. Al final una de las pocas cosas buenas de la IA es que pondrá el valor el tono humano para los que aún sepan hacer su trabajo, si es que aún estamos vivos para cuando llegue ese momento.
Todo va a tender a la mierdificación porque para el capitalismo lo cuantitativo siempre es más rentable que lo cualitativo (o al menos eso creen).
Estará haciendo a algunos desarrolladores codificar peor. La otra noticia, que no sale a la palestra porque no tiene en mismo morbo que criticar a un colectivo profesional al completo, es que te dispara la productividad si sabes usarla.
No a la IAfobia, porfaBor. Criticar a la IA ahora es como criticar a los ordenadores cuando se usaba máquina de escribir.
Dentro de unos años habrá proyectos creados a golpe de IA que se tendrán que volver a implementar desde cero, por que no escalan y no son fáciles de mantener
Bueno. Eso ya ocurre hoy en dia, pero será mas exagerado
"He visto a gente usar loops dobles en lugar de métodos optimizados"... esto es anterior a ChatGPT y lo hemos hecho todos alguna vez... gurús... que sois unos gurús
Clickbait de manual para que los desarrolladores republiquen dicha “noticia” y digan ves ? Como la IA es mala !
La IA acabará programando mejor que el ser humano, seguramente en un par de años , ahora solo está empezando , es irrelevante que ahora gente que no sabía programar use la IA y esté empezando a hacerlo con supuestos peores resultados que las de un programador con experiencia, la noticia es que ya hay gente programando que antes no sabía , en un año o dos serán indistinguibles de los que programaban con años de experiencia a sus espaldas.
#45 Dudo que la IA acabe programando mucho mejor que ahora, al usar IA para programar se irá dejando de escribir en stackoverflow o semejantes, por lo que el alimento de la IA será cada vez menos suculento.
#69 La IA podrá entrenarse a sí misma de manera sintética , además muchas empresas grandes ya están metiendo IA en sus repositorios para que aprenda y obtenga feedback en tiempo real para saber si lo está haciendo bien o no.
#71 Así es como lo hace el ser humano , va probando , descartando y se queda con las mejoras , no somos tan diferentes de cómo actuará la IA a corto plazo.
La diferencia es que unos dos años estas pruebas sintéticas las estarán generando cientos de miles de ingenieros de la talla de un Linus Torvalds, no de programadores de medio pelo como podamos ser cualquiera de los que escribamos aquí hoy.
#72 a ver, los datos sintéticos los genera la IA con sus propios datos conocidos, por lo que es complicado que aprenda de su propio conocimiento.
A eso me refería con comerte tus propios desechos, que algo sacarás, pero poco.
Que existan entrenadores de IA pues está bien, ahora tener al gran y malhumorado Linus para eso lo veo complicado.
A parte los datos de calidad y nuevos, combustible de las IA emprezará, o debería empezar a ser más caro.
Nada de lo que existe hoy en día es IA aún. Son todo LLMs, que interpretan muy bien y tienen a su alcance una librería enorme. Pero sin el contexto adecuado no pueden dar una buena respuesta.
Si entendéis que Chatgpt y otros no son más que otra herramienta, y que en realidad NO ENTIENDE NADA de lo que escribís, entonces irá todo mucho mejor.
Pues a mi me estan haciendo un curso de estos de IA y la visión de ellos es que el Senior Software Developer no tocará código y se dedicará a la visión.
A mi lo que me esta molestando del tema de la IA es todo el humo que hay, gente diciendo que Amazon uso IA para actualizar la versión de Java y luego miras su carrera profesional y es un fotógrafo.
Bueno, yo hice un plugin para Wordpress en 5 min con nuestro querido amigo chatgpt sin tener ni puta idea y funcionó (que vale que era mostrar todas las entradas, algo más de 800), pero ya me creí desarrollador senior jeje.
#28 Exacto, para lo que muchos llaman usuarios "avanzados" es de gran ayuda, no para manejar un proyecto de implantación en la gestión de la base de datos de una multinacional. En mi caso para hacer widgets para Moodle también me sirvió. Y para comentar código, cosa que muchos programadores de vieja escuela pasan de hacer para que su código sólo lo entiendan ellos también va como un tiro.
En mi época no existía chatgpt ni internet. Programábamos en dBase III y msDos. La generación anterior nos tachaba de nenitas por no usar tarjetas perforadas.
Yo creo que el problema viene de antes, de no valorar la experiencia y sustituir seniors por juniors hasta límites de no poder controlar lo que hacen los juniors.
Las empresas contratan cada vez a menos gente y al postor más barato, precisamente porque pensaban que con las IAs iban a ahorrarse puestos de trabajo y dinero.
Igual el problema no es que la gente use Copilot si no que han contratado personas sin la experiencia necesaria y por debajo de las necesidades (y sin tiempo para aprender).
monto apps el doble de rapido que antaño. No programaremos mejor, pero sin duda desarrollamos MAS, lo cual no necesariamente está bien. A la industria le da igual la receta de la tarta de manzana, quiere tartas e manzana y cuantas mas, mejor.
Al final programar con IA de momento es como llevar un caballo. Te lleva bien lejos, pero tienes que saber montarlo. Con el tiempo ese caballo se transformará en algo mas facil de montar. Pero de momento es asin
Ya no me acuerdo si lo comenté aquí hace tiempo o en otro foro pero yo tuve que ir a reparar un mariadb que se cargaron unos admins por que siguieron a pies juntillas los pasos que le dio chatgpt para reducir el espacio del ib_data después de reconfigurarla con ficheros independientes por tabla y la dejaron totalmente inutilizable, con todos los tablespace desligados y chatgpt no era capaz de darles una solución a la que habían montado.
#47 Bueno, era la primera vez que tenían que hacer ese tipo de actuación, no lo tenían procedimentado y se fiaron de lo que les dijo la IA porque vieron que eran pocos pasos y pensaron que no podría estar mal.
Vaya ostia más etratosférica se van a pegar todos los que prefieren autoengañarse con que la IA es un churro que jamás les va a poder sustituir. La realidad es que estás herramientas funcionan cada vez más y mejor. La última prueba es o1. En 10 años dudo que queden más del 10% se desarrolladores que hay ahora.
Si no "terminas de entender" es porque tienes que leer más hasta lograr entenderlo, y no incluir dicho código hasta que no acabes de entenderlo. Ahí radica la diferencia entre los buenos y los pésimos programadores.
Normal, las herramientas son herramientas y si no se saben usar, es muy probable que el resultado sea una mierda.
Hay muchísimas maneras de usar "AI". Si se usan mal... pues los resultados serán malos.
Hay muchas otras formas como el uso de "agentes", nodos, etc. o para tareas específicas, p.e. éste desarrollador da muchísimos ejemplos de cómo él las usa:
Es que el que coge la propuesta de código de ChatGPT y la inserte sin revisarla, sin validarla, sin mirarla, no es un profesional.
Y no es por ChatGPT. Un profesional siempre revisará un código ofrecido por otro, sea IA o compañero de al lado, antes de colocarlo en su código como propio.
Para poder resolver un problema técnico bastante complejo dentro del mundo de la programación el Jefe de Proyecto me venía con "posibles" soluciones y fragementos de código que había escupido la IA de turno, ya no recuerdo si ChatGPT o qué. Lo que sí sé es que nada de todo eso sirvió ni por asomo para poder resolver ese problema. Fue tirar de foros técnicos (StackOverflov, CodeProject, etc.) y a base de pruebas hasta dar con la solución. A las distintas herramientas IA todavía les… » ver todo el comentario
Pero como ya predijimos muchos hace años, lo único que conseguirán serán productos más mediocres al limitarse a copypastear lo que caga la IA sin ningún control ni criterio. Y como es obvio, el tiempo nos ha dado la razón.
Pero como ya predijimos muchos hace años, lo único que conseguirán serán productos más mediocres al limitarse a copypastear lo que caga la IA sin ningún control ni criterio. Y como es obvio, el tiempo nos ha dado la razón.
Mientras los "gurús" y los que por alguna extraña razón desean que la IA triunfe y mande a muchos al paro o a cobrar en cuencos de arroz siguen dando bombo al asunto, los que ya peinamos canas y llevamos al menos dos vaporwares a cuestas sabemos que lo que se promete al gran público con la IA es simplemente imposible con un ordenador de toda la vida. Si se acaba… » ver todo el comentario
Todavía recuerdo un proyecto, grande, con muchísimo código, donde debido a la nula estructura y calidad del mismo cada release era un infierno de bugs y regresiones. Se me ocurrió preguntar por el "arquitecto". Nadie supo quien era, no llegué a conocerlo por lo que intuí que cada programador escupía código donde le tocaba preocupándose sólo de su mierda. Pensé que era un caso aislado.
Con el tiempo he descubierto que esta causística donde el… » ver todo el comentario
Tiene que haber un estándar y una forma común de trabajar. Que da la coña que el equipo es lo bastante maduro y sabe organizarse sin un policía encima, enhorabuena y profit. Pero si cada uno barre para su lado, al final el código se convierte en un ñordo inmantenible que al final acabará en el cubo de la basura.
Yo estas cosas no las negocio. Un estándar. El que sea. Mejor uno incompleto que ninguno.
Vamos, es que desde las bases ya está mal, yo puedo mergear mi propio código a las ramas de desarrollo y no puedo desplegar a producción. Ahí ya hay suficientes problemas para trabajar antes que ponerse a meter IA en el código.
Si tu producto no es clave a la hora de funcionar, podeis hacer TBD para hacer pequeños commits a producción. Yo siempre que me he encontrado esa situacion, se debe a que hay programadores que llevan en la empresa un millón de años y conocen el producto como la palma de su mano. En productos donde hay una gran rotacion, y con gran rotacion me refiero a que entra gente nueva cada año, o año y medio, es mejor no hacer TBD. Se necesita tiempo para que los nuevos conozcan el código.
En mi caso sí tenemos cobertura completa de test unitarios pero ya sabrás que eso no es suficiente para asegurar que las modificaciones al producto no rompen nada de lo anterior.
Y no, no hacemos ni TBD ni tampoco hacemos TDD a pesar de tener 100% cobertura.
Por ahora es lo que hay supongo, ojalá termine en algún sitio donde se respeten unos principios que me gusten, por ahora no.
La cobertura 100% no sirve casi de nada si no se alinea con los tests de un sonarqube a la hora de escanear vulnerabilidades del código. Es un afrodisíaco, uno peligroso, porque te hace indicar que todo va bien y estás arrastrando problemas que un día un puto cracker va a aprovechar.
El uso de IA para programar cuanto lleva ¿2 años? Hablemos en 3 a ver qué hay de nuevo
Y esto lo está produciendo la IA, claro, claro.
- ¿de dónde has sacado ese código?
- de stackoverflow
- ¿lo copiaste de la pregunta o de la respuesta?
Para poco más sirve. La mayoría de las veces no es capaz ni de arreglar un error de compilación de forma correcta, mucho menos crear código optimo, de hecho una vez probé a que me calculase la complejidad ciclomatica de un algoritmo y falló absurdamente y mucho menos saber optimizar para hacer menos memory allocations.
Cursor para esto es increíble.
que tú sepas
Tal vez o1 lo haga mejor
// NewReaderSize returns a new [Reader] whose buffer has at least the specified
// size. If the argument io.Reader is already a [Reader] with large enough
// size, it returns the underlying [Reader].
func NewReaderSize(rd io.Reader, size int) *Reader {
// Is it already a Reader?
b, ok := rd.(*Reader)
if ok && len(b.buf) >= size {
… » ver todo el comentario
El código debería ser como una novela, una entretenida a ser posible, y debe tener la menor complejidad ciclotómica posible.
Tanto cuesta poner que r es reader? que b es un buffer de memoria del reader anterior?
No te molestes, es una buena crítica que te hará mejor profesional.
Amigo, esta es la libreria standard de Go, si quieres hazle una pull request
github.com/golang/go/blob/2f507985dc24d198b763e5568ebe5c04d788894f/src
Algunos os leis el Clean Code y os volveis locos y empezais a hacer el ridículo
Paso de hacer pull requests a lenguajes que no uso. ¿Vas a hacer lo mismo con tu código? Del Clean Code, no tengo nada que decir, considero que es un libro que ha envejecido muy mal.
Te animo a que mires el código de Kubernetes o de Prometheus y lo compruebes por ti mismo, y son dos proyectos OSS muy usados
Conclusión. Hay muchas formas de hacer las cosas. No hay que ser dogmático ni dar por hecho cosas, como que el código que había pegado era incorrecto porque yo soy un programador novato. Y respecto a mi código, pues si te pasas por uno de los proyectos OSS con más estrellas lo encontrarás, pero valoro la privacidad
Yo quiero leer código que pueda entender de una pasada, a ser posible no quiero tener que preguntar al programador que cojones quiere hacer en esa subrutina. Si, hay muchas formas de hacer las cosas, legibles o no legibles. No te enfades.
Al final cada uno crea su estilo de programación y para eso tienes que exponerte a muchos tipos de código. A dia de hoy valoro más la simplicidad y eficiencia que la elegancia.
www.youtube.com/watch?v=VlpT-qZBWdk
Joder, haced el prompt como toca y el código estará mejor
El resultado puede ser muy aleccionador!
Al menos se nos disculpan y no nos sueltan un "tú confia en mi" cuando les cazamos los gazapos, aunque también se le podría decir al modelos que emule esa actitud
Los llms no piensan, no entienden, lo que hacen es interpretar muy bien.
La calidad de la respuesta viene dada por la calidad de la pregunta, los detalles, el contexto y los límites.
Si le das todo el problema muy bien planteado normalmente te genera código muy bueno, que luego puedes llegar a optimizar pasándole nuevas órdenes.
Yo lo uso así cuando me atasco en algo muy complejo, que me supondría tener que pasar por muchos errores sintácticos hasta llegar a un código óptimo dentro de los parámetros que necesito.
Obviamente para eso hay que saber el lenguaje para poder descartar o no lo que te está ofreciendo.
Tal y como dice #21
Usar AI para acelerar trabajo: bien.
Usar AI para copiar y pegar a ciegas: needs more work y ya llorarás al PO o PM de turno por los puntos del sprint
Mi equipo encantadísimo. Pero los plazos y el para ayer y te pongo 5 junios y cobramos 4 seniors, pues... Eso. Y ser visto como un policía de asuntos internos de calidad, peor.
Así que te comprendo.
No hacerlo implica que tarde o temprano vienen despidos porque tal base de código ya no vale, hay que rehacerlo por completo, a lo mejor con otro lenguaje, y los que tienen el conocimiento funcional a la puta calle porque son de java y ahora hay que hacerlo con python porque blablabla de un CTO al que nunca has visto pero su palabra es Dios.
Todo va a tender a la mierdificación porque para el capitalismo lo cuantitativo siempre es más rentable que lo cualitativo (o al menos eso creen).
No a la IAfobia, porfaBor. Criticar a la IA ahora es como criticar a los ordenadores cuando se usaba máquina de escribir.
Bueno. Eso ya ocurre hoy en dia, pero será mas exagerado
La IA acabará programando mejor que el ser humano, seguramente en un par de años , ahora solo está empezando , es irrelevante que ahora gente que no sabía programar use la IA y esté empezando a hacerlo con supuestos peores resultados que las de un programador con experiencia, la noticia es que ya hay gente programando que antes no sabía , en un año o dos serán indistinguibles de los que programaban con años de experiencia a sus espaldas.
Y lo digo como programador.
Eso es "la noticia", en serio?
Mariano, eres tú?
Eso está a ley altura del "se está muriendo gente que nunca se había muerto antes"...
Vamos a dejarlo en que lo hará un poco mejor.
Cada repositorio que metan pues irá mejorando, pero ya está todo lo gordo dentro.
La diferencia es que unos dos años estas pruebas sintéticas las estarán generando cientos de miles de ingenieros de la talla de un Linus Torvalds, no de programadores de medio pelo como podamos ser cualquiera de los que escribamos aquí hoy.
A eso me refería con comerte tus propios desechos, que algo sacarás, pero poco.
Que existan entrenadores de IA pues está bien, ahora tener al gran y malhumorado Linus para eso lo veo complicado.
A parte los datos de calidad y nuevos, combustible de las IA emprezará, o debería empezar a ser más caro.
Que la arquitectura mejorará, pues está claro, y… » ver todo el comentario
Nada de lo que existe hoy en día es IA aún. Son todo LLMs, que interpretan muy bien y tienen a su alcance una librería enorme. Pero sin el contexto adecuado no pueden dar una buena respuesta.
Si entendéis que Chatgpt y otros no son más que otra herramienta, y que en realidad NO ENTIENDE NADA de lo que escribís, entonces irá todo mucho mejor.
A mi lo que me esta molestando del tema de la IA es todo el humo que hay, gente diciendo que Amazon uso IA para actualizar la versión de Java y luego miras su carrera profesional y es un fotógrafo.
Era.algo obvio.
Un saludo.
Igual el problema no es que la gente use Copilot si no que han contratado personas sin la experiencia necesaria y por debajo de las necesidades (y sin tiempo para aprender).
Al final programar con IA de momento es como llevar un caballo. Te lleva bien lejos, pero tienes que saber montarlo. Con el tiempo ese caballo se transformará en algo mas facil de montar. Pero de momento es asin
Hay muchísimas maneras de usar "AI". Si se usan mal... pues los resultados serán malos.
Hay muchas otras formas como el uso de "agentes", nodos, etc. o para tareas específicas, p.e. éste desarrollador da muchísimos ejemplos de cómo él las usa:
nicholas.carlini.com/writing/2024/how-i-use-ai.html
Y no es por ChatGPT. Un profesional siempre revisará un código ofrecido por otro, sea IA o compañero de al lado, antes de colocarlo en su código como propio.
Salu3