Shadowing Practice: Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic - Learn English Speaking with Video

Elige un modo de práctica

Cada modo abre una sala de práctica a pantalla completa.

286 oraciones

Si las oraciones son demasiado cortas o largas, haz clic en Editar para ajustarlas.

I had some technical difficulties during my talk this morning.

So I ran back home and I'm just going to record it from my computer instead.

So hi everyone.

I'm Lydia.

I work on the clock code team at Anthropic and the models have gotten really good lately.

So we have Opus 5 .5, which is my favorite daily driver.

And earlier this week, we also launched Fable 5 .2.

And these models are extremely good at long running tasks and understanding your code base.

And especially Fable was also really good at verifying its own output.

But as these models get better, the way that we work with them in Cloud Code also changes.

So earlier this year, I don't know if you remember, but sessions kind of used to look like this.

So we'd use a model like Opus 4 .5, which honestly for its time was really good.

I really enjoyed working with Opus 4 .5.

But compared to today, it would just stop a lot earlier.

So it would just run for shorter amounts of time.

And we'd also keep correcting it.

We'd keep reminding it to do things, add things like importance, exclamation mark, all these things to our CloudMD file.

And also features like auto mode didn't exist yet.

So we were either approving everything manually or taking the riskier approach with dangerously skip remission.

So we were still very much in the loop as humans.

But as these models got better at taking on bigger tasks, our sessions also changed.

So nowadays, at least at Anthropic, our sessions look more like this.

So we're running dozens of sessions at the same time, running for hours, verifying their own results along the way,

and we even have sessions orchestrate other sessions.

So whereas we used to be in the loop for almost every step

and running one or just a couple sessions at a time, we've now essentially become managers for dozens of sessions.

We also get a lot more done, though.

Now, you may have seen our blog post in October about

how Enthropic went from about 2 ,500 changes a day in May to more than 30 ,000 a day in September.

But this also means that we as developers just have to rethink on what we're focused on instead.

So if you think about our best practices from earlier this year, it was mainly about steering sessions,

approving commands, saying no to certain things or restricting what

Cloud could do, checking the output and also starting the sessions.

So everywhere that we now step out of that loop, something else has to take over.

And this is either the model, the harness, or the environment that it's running in.

So if we are not in a loop to approve every command and we're running so many sessions at the same time,

how can we make sure that the code it's writing is still high quality?

And most importantly, if these sessions are running for hours without our supervision, how can we make sure that they're running safely?

So let's go through that by taking this old session

and seeing what we have to change to get to that end result that I showed earlier.

Well, first of all, let's use the actual defaults we start sessions in nowadays.

So that's not really something you should think about.

So let's update the model here from Opus 4 .5 to Opus 5 .5 and change the manual permission to auto mode.

And Opus 5 .5 is a lot better at understanding your intent and understanding your code base.

So we really don't have to steer it as much anymore mid -session.

And you also no longer have to approve every command

because we started making auto mode the default permission mode back in August.

Now being better at understanding your intent and your code base also means

that we have to rethink the instructions we have in our code base.

So if you followed our best practices from earlier this year you may still have things like important

or never do this exclamation mark all these things in your cloud MD file

but with today's models you really don't need that

and it can actually make the model go off track

so you end up with more tool calls and overall a worse results

so nowadays your cloud md file should only include the things

that cloud cannot see from your code

so for example maybe you have a service that's still using some legacy source somewhere

but it's not directly referenced in the code that's still good to keep in there

but everything else like what stack you're on

or where to look you really don't need that anymore

and we actually have a command for this called dr prompt audit

which makes it really easy to optimize your environment for a specific model.

So if you're on Opus 5 .5 here and you run this command,

it will automatically check your CloudMD and your skills to see what the new model no longer needs.

Now auto mode is a permission mode

that runs a separate classifier on pretty much everything that isn't just reading or editing files in your project.

So it automatically allows commands that it knows are safe, like running tests or installing dependencies, but still blocks commands where it's unsure whether they're safe

and normally that's pretty good normally that's kind of you know what we want

but for example here

if we ask it to ship something to staging

we would have just you know approved the push to our deploy repo

but by default auto mode only trusts this folder and this repo

so it would block that command

so we're back in the loop now the defaults should be good in most cases

but if you still notice that you have to approve a lot of commands, even in auto mode.

The first thing to look at is settings here because you can configure auto mode in your own settings, just in plain English.

And this is what gets sent to the classifier, which then decides whether to reject or allow certain commands.

So here we can just write which repos, buckets, domains we trust and what it should always allow or never do.

Okay, so honestly, this was pretty easy by just using today's defaults, we've already gotten rid of most of our in the loop stuff

because the model took over the steering

and auto mode took over all the approving so getting out of the loop is easy.

But the harder question now is how do we make sure it's okay that we're not there anymore?

So first is keeping it safe, and then also verification.

So let's start with keeping it safe, because everything so far, so upgrading the model and using auto mode, it's just working with a model.

And in most cases, it does what you tell it to do, but that's not a guarantee.

So in a study we published back in August, we tested auto mode versus real people in the loop,

and only about 14 % of people caught a clearly dangerous command.

AutoMode blocked 89 % of them, so it is a lot better at it than we were.

But about 1 in 10 of those commands still went through.

So if you do want the guarantee, you can only enforce that in the harness.

And this is where some of our older best practices still matters, and that's permission.

So, for example, if you have a deny rule for a specific tool call in your project,

clot code looks at this rule before the automo classifier even looks at it in fact

if a tool call matches a deny rule the classifier never even sees it

so having deny rules is still the best way to make sure clot actually never does something

but then how do you know what needs to be a

rule in your project versus what the model can just know

because they've gotten so good at it i think it kind of just comes down to

if clot gets this wrong once can i take it back so if it writes the wrong code, you can still revert that.

100

So you can still leave that to the model.

101

But if it throws away our uncommitted changes

102

or it reads a key that's now in your transcript and you don't want that, that should still be a rule.

103

So for example, let's say that we just never want Claude reading our .end file.

104

Now by default, Automode is fine with this.

105

So it would have just approved it.

106

So if you want to make sure that Claude can never read this file, you should just add a deny rule

107

and then commands like cat cannot open this file either

108

but it's not always that straightforward because sometimes certain commands can have side effects

109

so for example let's say

110

that npm test here a very normal command it's just a test

111

so automote runs it that's fine but

112

when the script is running it runs code

113

that you didn't write like your dependencies

114

or maybe clod runs a script real quick

115

that it wrote just to quickly check something so

116

if one of those scripts is compromised it could just open

117

that same end file or your ssh keys

118

and send those to a server you've never heard of right

119

and even if we were still there as humans approving everything honestly we would have just clicked allow

120

because there's nothing to say no to it's just part of the script

121

that in this example case npm test runs and permissions only decide

122

if a tool call runs but they cannot limit what it can reach once it's running

123

so we want to make sure that these kinds of scripts can still run

124

because this is just part of you know how cloud can check its own work running tests

125

so we cannot just block npm tests

126

but we want to limit its side effects

127

so really we just want to limit the environment

128

that it's running in so if you're running it locally

129

or on your own machine you can run commands like

130

that in a sandbox so then you have control over

131

which files in a command it can read

132

which folders it can write to which hosts it can reach

133

and the operating system enforces that also this also applies to everything that command then starts so any child processes

134

so on its own that deny rule got checked by claude before the command runs

135

but all it sees there is npm test so it doesn't see

136

which files that scripts ends up opening but with the sandbox on

137

that same rule gets passed on to the operating system

138

so now when when

139

that dependency tries to open our end file the operating system just doesn't let it

140

and by default it can still read most of your machine

141

so you'd want to add another rule for your ssh keys

142

if you care about that um and it also cannot reach a host

143

that wasn't approved but the sandbox only covers the shell commands

144

that cloud runs and whatever those start but claude's own files your mcp servers

145

and all of your hooks still run outside of it

146

so the rest of your session still runs on your own machine

147

and everything that's on there

148

so ideally you want this whole thing to run somewhere where none of

149

that is even there in the first place and

150

that is a cloud session

151

because there it gets its own machine with a fresh copy of a repo

152

and this runs even when we close our laptop

153

which is definitely something you want for these longer running sessions

154

that run for hours so in this case this automatically gets rid of the end file issue

155

because it's not in git and neither are my ssh keys

156

or our github token and if it still needs an api key uh you can add

157

that as a network secret where it will it will tell you like hey

158

i'm missing an api key mid -session um

159

so it can use it without actually ever sending it to the model

160

and by default also in a cloud session network access is limited to things like package registries and github

161

so you have to explicitly add those domains to your environment for claw to to reach other hosts okay

162

so with a cloud session we can run these long running sessions even with our laptop closed

163

and it keeps us safe

164

because it runs in its own environment now it's still good to remember

165

that this machine is disposable but the things that leave it aren't

166

so a commit that pushed or a message it sent through a connector

167

so we still run it in auto mode with our deny rules just commit it into the repo

168

so they come along so it could still catch things like a force push

169

or a secret and a commit all that kind of stuff

170

and beyond just safety we also need to make sure

171

that Claude is actually working on the right thing

172

so next is verification

173

and the nice thing about being in a loop uh like we kind of knew the work was good

174

because we'd already kind of seen every change we'd proved everything

175

but now if claude works for hours in the background we don't have

176

that anymore and we're not really going to read every file at the end either

177

so you know say

178

that we ask it to move our auth to a new

179

api well claude is very good at understanding what we want

180

but there are still a lot of small decisions

181

that it has to make along the way

182

so with the exact same problems you know one run might move it over

183

but leave the old api in there or one might move it

184

but only for new logins and another one might move it

185

but log everyone out and these all look pretty reasonable

186

but it really helps to set up these verification points along the way

187

so claude keeps verifying its own results and those can be anything

188

that comes back as a pass or fail

189

so tests a build a screenshot whatever you have

190

so now we just want to make sure that we review these verification points.

191

They're a lot shorter to review than if we just had to, you know, review the whole change at the end.

192

So that's pretty reasonable.

193

So if one of these runs would still log everyone out, it doesn't get past that first check,

194

and then it just has to find another way.

195

And there's a couple ways to set this up.

196

The easiest one is, of course, just in your prompt.

197

So, you know, you say what done looks like

198

and ask it to split that into tasks so they have their own tests.

199

And I also like to ask it to show the actual output

200

because you weren't there to see it but again prompting is not a guarantee

201

that a model will do it so for the ones

202

that have to run guaranteed run i would use hooks

203

which are just you know scripts that cloud code runs at a specific point

204

and those give you a lot of control because you decide

205

when they run and what they run and what they check

206

so for example every time it edits a file

207

we can run our linter every time

208

it wants to mark a task as complete we can run the tests for what it changed um

209

so you know if it touch our off code or something.

210

It has to pass the off tests.

211

And when it wants to finish the whole session, we can just run the entire test suite.

212

And if one of those fails, it goes, oh, that's still broken.

213

It goes back until it passes.

214

So it fixes it.

215

Now, just one thing, when a test fails, by default, most tools that exit with a one exit code.

216

But with a one, that task by Cloud Code just gets marked as completed anyway.

217

So make sure that your scripts exit with a two exit code

218

because that's what actually sends cloud back to fix it

219

so okay now we have one session that i'm pretty comfortable with leaving alone

220

so now we can start with a few more of those

221

because they've all got their own machine

222

so they're you know not all working in the same folder

223

and we don't really have to think about work trees too much ourselves anymore

224

but then we still start every session ourselves

225

and we review every one of them

226

and honestly this is already a pretty good place to be

227

we are still fully in control over what gets started and

228

when we call a task done

229

but even there um you know we're still the ones kicking off every session

230

and we're still in the loop for all of them

231

so i think the most important thing to have in place here now is your ci

232

because all of these sessions eventually open a pr

233

and your ci runs the same checks on every one of them no matter how

234

that session was set up or you know what claude decided to do along the way.

235

And if you turn on autofix, we have like CI autofix,

236

Cloud can also see when one of those checks fails and then go back to fix it.

237

So you're not the one spending your review on things that, you know, a check could have already caught.

238

And for some of them, you can even turn on merge when ready.

239

So then GitHub merges the PR once all of the checks have passed.

240

So you're not in the loop to review.

241

But again, that's not the default.

242

And that really depends on how risky the changes

243

so for example on our team every pr gets reviewed by cloud first

244

so not by the session that wrote it

245

so it comes with a fresh context

246

and also a separate group of agents to just double check every bug it finds

247

and then how much we review ourselves just depends on the risk

248

so smaller changes like docs or copy they don't need a person so once the automated checks are green

249

we're pretty good to go.

250

Maybe ordinary product changes just need one reviewer, and then risky changes might need two.

251

Now, ultimately, kind of where we see things going, and we're already kind of doing more of that adnthropic,

252

is that you're not really starting all of those sessions yourself either.

253

Because if you're anything like me, I'm terrible at context switching, so having to manage so many sessions at the same time doesn't always go well.

254

So instead, you just have one main session that's your orchestrator

255

and you can already see this in things like cloud code projects

256

which is still in beta but you just tell it what it needs to be done

257

and the orchestrator splits it up and then starts other sessions for each task

258

and it keeps track of what comes back so it automatically starts

259

and verifies these threads which are just new sessions

260

so instead of talking to eight sessions you're just talking to one

261

and the main session doesn't write the code itself

262

so there you want a model that's really good at deciding what to do

263

and judging what comes back a model like fable and

264

if something comes back that isn't actually done it just you know sends it back

265

so until it's actually done and passes everything

266

and the threads need a model that's good at actually doing the work like opus 55

267

and you can set those separately so you know one model for the main session

268

and then another one for the threads and another benefit is

269

that with this setup with cloud code projects specifically we don't manage context anymore that's all done automatically for us

270

so we no longer have to think about you know

271

when to compact or clear all of that stuff okay so

272

if you look back at those old best practices they're all still there but they've just moved

273

so the model sears it now um auto mode approves your deny rules

274

and the environment restrict what's possible your test your hooks

275

and your ci check set and then ultimately cloud can just start them as well

276

so almost everything we used to do ourselves is now either the model the harness

277

or the environments and we're really just here to start

278

that first one and to just review what comes out so

279

if you want to try this in your own setup

280

i would say just take one thing

281

that's way bigger than you normally give claude make sure your ci actually catches the things you care about

282

and then spend a bit of time just configuring your environment like it's network access it's secret

283

and it's you know setup script and then start in the cloud

284

and see where your sessions get stuck and where you're still in the loop

285

because that's the next thing to hand over to claude

286

i also highly recommend checking out our best practices in the docs as well thank you so much

Descargar app

Todo lo que necesitas para hablar con fluidez

Pronunciación con IAEvalúa cada oración

Práctica de IPADomina cada sonido

VocabularioConstruye tu banco de palabras

Juego de vocabularioAprende mientras juegas

Escanea el QR

Download on theApp Store Get it onGoogle Play

Mismo canal

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

Daily ConversationUniversity StudentsWorking Adults

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

Business EnglishUniversity StudentsWorking Adults

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

Daily ConversationUniversity StudentsWorking Adults

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Business EnglishInterview EnglishUniversity Students

Why Software Factories Fail

Daily ConversationUniversity StudentsWorking Adults

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Business EnglishUniversity StudentsWorking Adults

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

Business EnglishUniversity StudentsWorking Adults

"Software Fundamentals Matter More Than Ever" — Matt Pocock

Business EnglishUniversity StudentsWorking Adults

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

Business EnglishUniversity StudentsWorking Adults

FOR YOU

Recomendar Video

37 oraciones

Vocabulario y notas de pronunciación para esta lección

Esta lección de conversación se basa en el vídeo “Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic”. Las palabras que más se repiten: session, model, command, code, cloud. Este vídeo tiene 286 frases y 3581 palabras para practicar shadowing. La parte hablada dura 17:31. El hablante habla rápido, unas 204 palabras por minuto, así que espera sonidos enlazados y reducidos. El 86 % de las palabras está entre las 3.000 más comunes del inglés; conviene repasar el resto antes de empezar.

Vocabulario clave de este vídeo

15 palabras del vídeo que vale la pena aprender, con su pronunciación y significado:

Palabra	Pronunciación	Significado
cloud sustantivo	/ˈklaʊ̯d/	nube, nimbo
loop sustantivo	/luːp/	lazo, lazada
approve verbo	/əˈpɹuːv/	aprobar, sancionar
default sustantivo	/dɪˈfɔlt/	mora, default
script sustantivo	/skɹɪpt/	escrito, escripto
deny verbo	/dəˈnaɪ/	negar, impugnar
guarantee sustantivo	/ˌɡæɹ.ənˈtiː/	garantía, caución
exit sustantivo	/ˈɛɡzət/	salida, partida
verify verbo	/ˈvɛɹɪfaɪ/	verificar
verification sustantivo	/ˌvɛ.ɹə.fɪˈkeɪ.ʃən/	verificación
thread sustantivo	/ˈθɹɛd/	hilo, bouclé (buclé)
output sustantivo	/ˈaʊtpʊt/	producción, output
hook sustantivo	/hʊk/	gancho, garfio
commit verbo	/kəˈmɪt/	encomendar
nowadays adverbio	/ˈnaʊ.ə.deɪz/	hoy en día, hogaño

Phrasal verbs que vas a escuchar

Palabra	Pronunciación	Significado
take over verbo		apoderarse, enseñorearse
go through verbo		atravesar
check out verbo		investigar, chequear
come along verbo		avanzar, marchar
come out verbo	/ˌkʌm ˈaʊt/	revelarse, salir a la luz
end up verbo		terminar, ir a parar
get out of verbo		salirse de, ponerse fuera de
get past verbo		pasar desapercibido

Gramática en este vídeo

Las estructuras que más usa el hablante, con las palabras exactas del vídeo:

Estructura	En el vídeo
“Used to” used to + verbo — un hábito o estado pasado que ya no es cierto	used to look · used to be · used to do
Present perfect have/has + participio pasado — una acción pasada que sigue importando ahora	have gotten · we've now essentially become · we've already gotten
Voz pasiva be + participio pasado — importa lo que ocurre, no quién lo hace	is compromised · wasn't approved · was set

Pronunciación a tener en cuenta

El hablante usa 63 contracciones y formas reducidas, como we're, don't, you're. Dilas en su forma corta, tal como las oyes.

Los sonidos de “th”: thread /ˈθɹɛd/, rethink /ɹiːˈθɪŋk/, auth /ɔːθ/
Los sonidos de “sh” y “zh”: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, essentially /ɪˈsɛnʃəli/, shell /ʃɛl/, instruction /ɪnˈstɹʌkʃən/, supervision /ˌs(j)uːpəˈvɪʒən/
Palabras largas — cuida el acento: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, dependency /dɪˈpɛndənsi/, essentially /ɪˈsɛnʃəli/, ordinary /ˈɔɹdɪnɛɹi/, difficulty /ˈdɪfɪkəlti/

Sonidos difíciles para hispanohablantes:

s + consonante al inicio — sin añadir una “e” delante: script /skɹɪpt/, steer /stɪɹ/, skip /skɪp/, suite /swiːt/, stack /stæk/
/v/ — no es /b/: los dientes tocan el labio inferior: approve /əˈpɹuːv/, verify /ˈvɛɹɪfaɪ/, verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, server /ˈsɝvɚ/, versus /ˈvɝsəs/
/z/ — sonora, no /s/: exit /ˈɛɡzət/, nowadays /ˈnaʊ.ə.deɪz/, whereas /(h)wɛɹˈæz/, compromise /ˈkɑmpɹəˌmaɪz/, disposable /dɪsˈpoʊzəbl̩/

Cómo practicar con este vídeo

Escucha el vídeo entero una vez sin hablar y anota las palabras que no conoces.
Empieza a velocidad 0,75×, haz shadowing frase por frase y vuelve a la velocidad normal cuando te resulte fácil.
Grábate y compara con el original, prestando atención a palabras como cloud, loop, approve.

¿Qué es la Técnica de Shadowing?

Shadowing es una técnica de aprendizaje de idiomas respaldada por la ciencia, desarrollada originalmente para la formación de intérpretes profesionales y popularizada por el políglota Dr. Alexander Arguelles. El método es simple pero poderoso: escuchas audio en inglés nativo y lo repites en voz alta de inmediato, como una sombra que sigue al hablante con solo 1-2 segundos de retraso. A diferencia de la escucha pasiva o los ejercicios de gramática, el shadowing obliga a tu cerebro y músculos de la boca a procesar y reproducir simultáneamente patrones de habla reales. Las investigaciones muestran que mejora significativamente la precisión de la pronunciación, la entonación, el ritmo, el habla conectada, la comprensión auditiva y la fluidez al hablar, convirtiéndola en una de las metodologías más efectivas para la preparación del IELTS Speaking y la comunicación en inglés en el mundo real.

Técnica de shadowing: lee la guía completa paso a paso →

Shadowing Practice: Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic - Learn English Speaking with Video

Elige un modo de práctica

Descargar app

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Why Software Factories Fail

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

"Software Fundamentals Matter More Than Ever" — Matt Pocock

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

How Anthropic uses Claude in Product Management

Armchair Architects: Resiliency in the Cloud – Core Patterns

Did Anthropic Kill Git?

We Let $200 GPT-Pro Think for 7 Days on Unsolved Math

Claude Code Is Wasting Tokens... Microsoft Built a Fix

Sec Growth DataScience staff meeting Sep 14 2022

I Looked Into How Devs Are Actually Using AI

What's New in Zephyr 4.5?

9 Insane Claude Mods I Already Can't live Without

We've got separation of concerns wrong

The last real programmers are dying out...

Vocabulario y notas de pronunciación para esta lección

Vocabulario clave de este vídeo

Phrasal verbs que vas a escuchar

Gramática en este vídeo

Pronunciación a tener en cuenta

Cómo practicar con este vídeo

¿Qué es la Técnica de Shadowing?