Metodo
ChatGPT, Codex e altri strumenti affiancano lo studio, l’analisi e lo sviluppo. Il lavoro comprende la scelta del modello, la preparazione del contesto, la supervisione delle attività e la verifica delle implementazioni.
New data does not imply a scroll request.
Screenshot autentico, dati demo. Animazione illustrativa.
Problema
In Codex Relay la conversazione cambia mentre la persona legge. Seguire ogni aggiornamento e rispettare la lettura della cronologia sono due comportamenti diversi.
La posizione del lettore è un requisito, non un effetto grafico.
Comprensione
La quantità di testo non basta a decidere lo scroll. La policy distingue un gesto in corso, la lettura della cronologia e la vicinanza all’ultimo messaggio.
Fonti e codice delimitano il problema prima di chiedere proposte all’AI.
Implementazione
TranscriptScrollPolicy conserva l’intenzione di seguire gli aggiornamenti. Leggere la cronologia sospende il follow; il ritorno all’ultimo messaggio lo riattiva.
L’AI può aiutare a esplorare la modifica. La decisione e la revisione restano tecniche.
Verifica
I test distinguono i gesti dagli aggiornamenti: la fine di un’interazione lontano dall’ultimo messaggio non deve riattivare il follow. Il controllo software non sostituisce la prova su iPhone.
La CI e il simulatore sono prove circoscritte, non accettazione fisica completa.
Risultato
Seguire la conversazione oppure fermarsi a leggere: il codice rende questa scelta verificabile. La correzione e i suoi test sono consultabili nel progetto.
Un risultato documentato, con il confine della verifica ancora visibile.
Pratiche ed esempi, non una sequenza obbligatoria: un difetto circoscritto e un nuovo componente richiedono profondità di indagine diverse.
In Codex Relay, una nuova risposta e la lettura della cronologia sono due eventi diversi. Il primo non deve annullare il secondo: descrivere questa regola rende il problema più preciso di un generico ‘migliorare lo scroll’.
Prima di affidare un’attività a un agente: problema da affrontare, file pertinenti, versioni, operazioni consentite e risultato da verificare. Le basi informatiche servono a scegliere le interfacce, comprendere il comportamento e riconoscere una proposta inadatta.
Un’indagine sul codice, una sintesi di documentazione e una prova locale hanno esigenze diverse. Accesso ai dati, capacità del modello, costo e possibilità di eseguire verifiche orientano la scelta; il modello più grande non è automaticamente quello adatto.
Il problema viene scomposto in attività verificabili, con dipendenze e confini espliciti. Durante lo sviluppo si controllano modifiche, comandi e risultati, anche quando il lavoro attraversa più repository o macchine. I dati riservati richiedono accordi prima di essere condivisi con strumenti esterni.
La revisione controlla cosa cambia e quali comportamenti può compromettere. I test devono osservare anche input inattesi, accessi negati, riconnessioni e stato obsoleto. Una risposta convincente non sostituisce l’esecuzione.
Codice versionato, istruzioni e problemi ancora aperti rendono possibile continuare il lavoro. Installazione e uso nell’ambiente previsto si verificano separatamente dalla build. Manutenzione e supporto successivo hanno un perimetro concordato.
Relay: conservare il punto di lettura mentre arrivano nuovi messaggi.
App e sincronizzazioneREPLAI: input Unicode e rifiuto dei risultati riferiti a uno stato precedente.
API e test del terminaleYVEX: confronto con un riferimento e controlli sulla memoria. Non un benchmark universale.
Runtime e kernel