-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathProtocolo IA.qmd
More file actions
155 lines (81 loc) · 4.67 KB
/
Copy pathProtocolo IA.qmd
File metadata and controls
155 lines (81 loc) · 4.67 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
---
title: "Protocolo uso IA"
format: pdf
editor: visual
---
## **Protocolo personal de uso de la IA en Codigo**
#### Cuando encuentres un código que no entendés
```{text}
1. Leelo solo durante unos minutos.
2. Escribí una hipótesis de qué hace cada línea.
3. Recién después preguntame.
4. Compará tu hipótesis con la explicación.
```
Ese pequeño paso cambia mucho la forma en que se consolida el aprendizaje.
Hay una práctica que creo que tendría muchísimo impacto para vos.
Cada vez que me traigas un código del profesor, hacé esto antes:
**"Esta es mi interpretación. Creo que la línea 1 hace esto, la línea 2 hace esto, pero no entiendo la línea 3."**
Aunque tu interpretación sea incorrecta.
¿Por qué?
Porque me obliga a corregir un razonamiento ya construido, en lugar de construirlo desde cero por vos. Ese tipo de interacción suele favorecer un aprendizaje más profundo.
En síntesis, con lo que he visto hasta ahora, me parece que estás usando la IA principalmente como un profesor particular y una herramienta de documentación, más que como un sustituto del razonamiento. Mantener el hábito de formular primero tus propias hipótesis es probablemente la mejor forma de evitar que ese equilibrio cambie con el tiempo.
Si yo tuviera que redactarlo para alguien con tu perfil, incluiría principios como estos:
```{text}
1. **Primero intento entender el problema.** Dedico unos minutos a leer el código o el ejercicio antes de consultar.
2. **Formulo una hipótesis.** Aunque sea incompleta o incorrecta, escribo qué creo que hace cada parte.
3. **Pregunto sobre lo que no entiendo.** Intento que la consulta sea específica, no simplemente "explicame todo".
4. **Reescribo la explicación con mis palabras.** Si no puedo hacerlo, probablemente todavía no entendí el concepto.
5. **Aplico el concepto en un ejemplo nuevo.** No doy por aprendido algo solo porque la explicación me resultó clara.
6. **Conservo mis apuntes.** Cada explicación útil se transforma en documentación propia.}
```
Después de usar la herramienta, ¿soy capaz de resolver un problema parecido sin ella?
**¿Qué objeto entra?** (`mapa`, `datos`, `escuelas`, etc.)
- **¿Qué función principal hace el trabajo?** (`filter()`, `geom_sf()`, `st_buffer()`, etc.)
<!-- -->
- **¿Qué cambia respecto del objeto original?**
<!-- -->
- **¿Qué objeto o resultado sale al final?**
- **¿Qué habría pasado si quitara esta línea?**
# Método de análisis de código (Versión 1.0)
## 1. Objetivo
**¿Qué quiso hacer el autor?**
No me describís el código todavía.
Me decís la intención.
Ejemplo:
> "Quiere calcular el centroide de cada país."
## 2. Flujo de datos
Contestás siempre estas preguntas:
- ¿Qué objeto entra?
- ¿Qué objeto sale?
- ¿Qué cambia?
- ¿Qué se conserva?
- ¿Qué tipo de objeto queda?
Este punto me gustó mucho cómo lo resolviste hoy.
## 3. Función protagonista
No siempre la función más importante es la primera que aparece.
Ejemplo:
```
mutate( centroide = st_centroid(geometry) )
```
La protagonista es `st_centroid()`.
`mutate()` es el "contenedor" donde se guarda el resultado.
Esto te va a ayudar muchísimo cuando los códigos sean más largos.
## 4. ¿Por qué el autor lo hizo así?
Esta es la parte de pensamiento crítico.
Por ejemplo:
- ¿Era necesario ese `select()`?
- ¿Podía hacerlo de otra forma?
- ¿Está simplificando el objeto?
- ¿Está preparando el terreno para una operación posterior?
No buscamos "la respuesta correcta", sino justificar una decisión de diseño.
Hay un concepto en educación que se llama **carga cognitiva**. La idea es que la memoria de trabajo tiene una capacidad limitada. Si al mismo tiempo tenés que:
- entender `sf`,
- entender `dplyr`,
- pensar en el flujo de datos,
- analizar el diseño del código,
- y además predecir modificaciones,
es fácil saturarse.
En cambio, si primero automatizamos las primeras cuatro preguntas, después la quinta ("¿qué pasaría si...?") va a salir mucho más natural.
Si veo que una pregunta es demasiado difícil para el momento en que estás, no voy a insistir. La idea no es ponerte a prueba, sino construir un modo de pensar.
De hecho, hoy ya aprendí algo sobre cómo aprendés vos. Cuando te dejo unos segundos para elaborar una hipótesis, llegás a respuestas mucho más profundas que si te doy la explicación inmediatamente. Así que voy a intentar respetar más esos tiempos.
Creo que esta dinámica, sostenida durante unos meses, no solo te va a ayudar con R. También te va a dar una forma bastante sólida de leer código ajeno, ya sea en `sf`, `tidyverse`, `r5r` o incluso en otros lenguajes que aprendas más adelante.