Trabajar como un dev

Cuatro herramientas, un mini-proyecto

Este bloque es applied: los conceptos ya pasaron por tus ojos en el pre-work, acá los usamos en vivo. Cuatro herramientas que vas a usar el resto del día:

• Python — para escribir un script que hace algo útil.
• Markdown — para documentar qué hace y cómo correrlo.
• Git — para guardar el historial y poder volver atrás si rompés algo.
• Docker — para empaquetar el proyecto y que corra igual en cualquier máquina.

Al final del bloque vas a tener un mini-proyecto con script + README + primer commit + imagen Docker. Ese proyecto es la base sobre la que el agente va a trabajar en la tarde — por eso es el puente.

Un programa es un archivo de texto con instrucciones

Un script de Python es literalmente un .py con instrucciones. Lo ejecutás con uv run y listo. No hay compilación, no hay magia — el archivo entra, la computadora lo ejecuta línea por línea, y ves el resultado.

El modelo mental: Input → Proceso → Output

• Input — de dónde saca los datos (un CSV, una variable de entorno, una respuesta de API).
• Proceso — qué hace con ellos (filtra, cuenta, ordena, transforma).
• Output — qué devuelve (imprime a pantalla, escribe un archivo, llama a otra API).

El 90% de los scripts que vas a escribir con el agente tienen esta forma. Si te pedís explicar cualquier script en estos tres pasos, entendés qué hace.

Un script mínimo que lee un CSV

import csv

with open("datos/clientes.csv") as f:
    reader = csv.DictReader(f)
    filas = list(reader)

print(f"Total de personas: {len(filas)}")
print(f"Columnas: {', '.join(filas[0].keys())}")

top = max(filas, key=lambda x: int(x["agentes_ai"]))
print(f"Más agentes: {top['nombre']} ({top['area']}) con {top['agentes_ai']}")

Se corre con uv run scripts/analisis.py. Y ya. Eso es Python.

Texto con estructura, sin WYSIWYG

Markdown es texto plano con convenciones mínimas que cualquier editor sabe renderizar: GitHub, Notion, Slack, Claude, este sitio. Si aprendés Markdown, podés documentar cualquier cosa sin depender de Word o Docs.

# Header 1
## Header 2
### Header 3

Texto normal. **Negrita** y *cursiva*.

- Item de lista
- Otro item
  - Sub-item

1. Lista numerada
2. Segundo punto

[Link a un lugar](https://growketing.com)

`código inline` dentro de una línea.

```python
# Bloque de código con sintaxis
print("hola")
```

| Columna A | Columna B |
|-----------|-----------|
| dato 1    | dato 2    |

Con esto cubrís el 95% de los casos. Lo demás lo buscás cuando lo necesites.

El modelo: repo → add → commit → push

Git es un sistema para guardar el historial de cambios de un proyecto. Cada vez que cambiás algo significativo, hacés un commit — un snapshot — con un mensaje de qué cambió. Podés volver atrás a cualquier snapshot, comparar versiones, y compartir el proyecto en GitHub.

Git en 12 minutos

De los tres temas del bloque, Git es el que más conviene tener visto antes. Python ya es familiar para muchos, y Markdown se aprende haciendo (ver el tutorial interactivo en Referencias).

Armá el proyecto base del día

Si hiciste el pre-work, ya tenés ~/Desktop/hackathon-prueba/ armado. Si no, creémoslo ahora — son 4 snippets copiables.

1. Estructura

cd ~/Desktop
mkdir hackathon-prueba
cd hackathon-prueba
mkdir datos scripts docs
tree

2. Un CSV de prueba

cat > datos/clientes.csv << 'EOF'
nombre,area,agentes_ai
María,PPC,3
Juan,SEO,1
Laura,Data,5
Pedro,RevOps,0
Ana,Creative,2
Carlos,Programmatic,4
EOF

3. Script de Python que lo analiza

cat > scripts/analisis.py << 'EOF'
import csv

with open("datos/clientes.csv") as f:
    reader = csv.DictReader(f)
    filas = list(reader)

print(f"Total de personas: {len(filas)}")
print(f"Columnas: {', '.join(filas[0].keys())}")
print()

top = max(filas, key=lambda x: int(x["agentes_ai"]))
print(f"Más agentes: {top['nombre']} ({top['area']}) con {top['agentes_ai']} agentes")

sin_agentes = [f["nombre"] for f in filas if f["agentes_ai"] == "0"]
print(f"Sin agentes: {', '.join(sin_agentes)}")
EOF

uv run scripts/analisis.py

4. README, Git init y primer commit

cat > README.md << 'EOF'
# Hackathon Prueba

Mi primer proyecto desde la terminal.

## Qué tiene

- `datos/` — CSVs de ejemplo
- `scripts/` — Scripts de Python
- `docs/` — Documentación

## Cómo correr el análisis

    uv run scripts/analisis.py
EOF

git init
git add .
git commit -m "Mi primer commit desde la terminal"
git log --oneline

Si todo eso corrió sin error, tenés un mini-proyecto listo para que a la tarde el agente lo lea y lo modifique.

Dónde viven las API keys

En el Bloque 2 viste que las variables de entorno son valores que el shell "recuerda" ($HOME, $PATH). En el próximo Bloque 4 vas a ver en detalle el modelo cliente-servidor y por qué las API keys son credenciales para hablarle a un servidor remoto — por ahora alcanza con saber eso. Acá unimos los dos conceptos: las API keys se guardan en variables de entorno, y el lugar estándar de un proyecto es un archivo .env.

Crear el archivo

cd ~/Desktop/hackathon-prueba       # el proyecto del ejercicio de arriba
touch .env
echo 'ANTHROPIC_API_KEY=sk-ant-ejemplo' >> .env
echo 'OPENAI_API_KEY=sk-ejemplo' >> .env
cat .env                             # verificás el contenido

CRÍTICO: .gitignore

Antes del próximo commit, agregá .env al .gitignore para que Git nunca lo suba.

echo '.env' >> .gitignore
cat .gitignore            # confirmás que está
git status                # .env ya no debería aparecer como untracked

Leer el .env desde Python

Hay dos formas. La simple (sin dependencias):

# Cargar .env en la sesión actual de shell:
export $(grep -v '^#' .env | xargs)

# Desde Python:
import os
key = os.environ.get("ANTHROPIC_API_KEY")
print(f"Tengo key: {key[:10]}..." if key else "No hay key cargada")

La forma que usa todo el ecosistema Python (con python-dotenv — uv lo maneja):

uv add python-dotenv    # agrega la dep al proyecto

# scripts/test_env.py
# /// script
# dependencies = ["python-dotenv"]
# ///
from dotenv import load_dotenv
import os

load_dotenv()   # lee .env del directorio actual
key = os.environ.get("ANTHROPIC_API_KEY", "no-configurada")
print(f"API key cargada: {key[:15]}...")

Correlo con uv run scripts/test_env.py. Vas a ver los primeros caracteres de tu key — eso confirma que el script está leyendo el archivo .env correctamente. Este patrón es el mismo que vas a usar a la tarde cuando Claude Code lea tu ANTHROPIC_API_KEY.

Empaquetar tu proyecto en un contenedor

Hasta acá tu script corre en tu laptop porque tu laptop tiene Python instalado, uv, las dependencias, el .env en el lugar correcto. Si mañana se lo pasás a alguien, o lo subís a un servidor, arrancan los problemas clásicos: "a mí me funciona". Docker resuelve eso.

Qué es, en una frase

Un contenedor es tu proyecto empaquetado con todo lo que necesita para correr — un mini sistema operativo, Python, las dependencias, tu código — en una caja que se ejecuta igual en cualquier máquina que tenga Docker.

• Imagen — la receta/plantilla. Se construye a partir de un Dockerfile.
• Contenedor — la instancia corriendo de esa imagen. Podés tener muchos del mismo tipo.
• Dockerfile — un archivo de texto con los pasos para armar la imagen.

No es una máquina virtual — es mucho más liviano. Pensalo como "un zip que también sabe correrse solo".

El Dockerfile de tu proyecto

Parados en ~/Desktop/hackathon-prueba (el proyecto que armaste más arriba), creá un Dockerfile con esta receta:

cat > Dockerfile << 'EOF'
FROM python:3.13-slim

WORKDIR /app

COPY . .

RUN pip install --no-cache-dir python-dotenv

CMD ["python", "scripts/analisis.py"]
EOF

Línea por línea:

• FROM python:3.13-slim — arrancamos desde una imagen chica que ya trae Python.
• WORKDIR /app — la carpeta de trabajo dentro del contenedor.
• COPY . . — copia tu proyecto adentro.
• RUN pip install ... — instala las dependencias que tu script necesita.
• CMD [...] — qué se ejecuta cuando arranca el contenedor.

Construir la imagen y correrla

# Construir la imagen (la primera vez tarda — se baja Python):
docker build -t hackathon-prueba .

# Correr un contenedor a partir de esa imagen:
docker run --rm hackathon-prueba

# Ver las imágenes y contenedores que tenés:
docker images
docker ps -a

Si todo salió bien, vas a ver el mismo output del script de Python — pero esta vez corriendo adentro de un contenedor, totalmente aislado de tu sistema.

Para los que van rápido

• Modificá el script: agregá un filtro (solo líderes con más de 2 agentes), o contá cuántos hay por área.
• Escribí el resultado a un archivo nuevo en docs/resumen.md en lugar de imprimirlo.
• Creá un branch para tu cambio: git checkout -b feature/filtro, hacé el cambio, git add, git commit, y después volvé a main con git checkout main.
• Explorá git diff entre versiones y git stash para guardar cambios sin commitear.
• Si tenés cuenta de GitHub, creá un repo nuevo en github.com/new, copiá los 3 comandos que te muestran en "push an existing repository" y subí tu proyecto.

¿Lo hiciste y lo entendés?

Dos listas independientes. Marcá lo que ya pudiste hacer (izquierda) y los conceptos que ya te cerraron (derecha). Al final de este bloque tenés que tener un repo con al menos un commit — el agente de la tarde lo va a usar como punto de partida.

Videos y tutoriales