"He visto a gente usar loops dobles en lugar de métodos optimizados porque simplemente asumieron que lo que generó ChatGPT estaba bien"
|
etiquetas: inteligencia artificial , programación , desarrolladores , calidad , código 125 168 1 K 248
125 168 1 K 248
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