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

Bir pratik modu seçin

Her mod tam ekran bir pratik odası açar.

286 cümleler

Cümleler çok kısa veya çok uzun ise, ayarlamak için Düzenle'ye tıklayın.

I had some technical difficulties during my talk this morning.

Bu sabahki konuşmam sırasında bazı teknik sorunlar yaşadım.

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

Bu yüzden eve geri koştum ve bilgisayarımdan kaydedeceğim.

So hi everyone.

Herkese merhaba.

I'm Lydia.

Ben Lydia.

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

Anthropic'te saat kodlama ekibinde çalışıyorum ve modeller son zamanlarda gerçekten çok gelişti.

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

Yani elimizde Opus 5.5 var, bu da benim günlük kullanımda en sevdiğim aracım.

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

Bu hafta başında da Fable 5.2'yi piyasaya sürdük.

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

Bu modeller uzun süren görevlerde ve kod tabanınızı anlamada son derece başarılıdır.

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

Özellikle Fable, kendi çıktısını doğrulama konusunda da gerçekten çok başarılıydı.

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

Ancak bu modeller geliştikçe, Cloud Code'da onlarla çalışma şeklimiz de değişiyor.

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

Bu yılın başlarında, hatırlıyor musunuz bilmiyorum ama oturumlar aşağı yukarı şöyleydi.

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

Bu yüzden Opus 4.5 gibi bir model kullanırdık ki, dürüst olmak gerekirse, o dönem için gerçekten çok iyiydi.

I really enjoyed working with Opus 4 .5.

Opus 4.5 ile çalışmaktan gerçekten keyif aldım.

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

Ama bugüne kıyasla, çok daha erken bir tarihte sona ererdi.

So it would just run for shorter amounts of time.

Dolayısıyla, çalışma süresi daha kısa olurdu.

And we'd also keep correcting it.

Ve biz de bunu düzeltmeye devam ederdik.

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

CloudMD dosyamıza sürekli olarak yapması gereken şeyleri hatırlatır, önem derecesi, ünlem işareti gibi şeyler eklerdik.

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

Ayrıca otomatik mod gibi özellikler de henüz mevcut değildi.

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

Yani ya her şeyi manuel olarak onaylıyorduk ya da riskli bir yaklaşım benimseyerek remisyonu atlıyorduk.

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

Dolayısıyla biz insanlar olarak hâlâ olup bitenlerden büyük ölçüde haberdardık.

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

Ancak bu modeller daha büyük görevleri üstlenmede daha iyi hale geldikçe, oturumlarımız da değişti.

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

Dolayısıyla günümüzde, en azından Anthropic'te, oturumlarımız daha çok şöyle geçiyor.

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

Yani aynı anda onlarca oturum yürütüyoruz, saatlerce sürüyor ve bu süreçte kendi sonuçlarını doğruluyoruz.

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

Uygulamayı İndir

Akıcı konuşmak için ihtiyacınız olan her şey

AI TelaffuzHer cümleyi puanla

IPA AlıştırmasıHer sesi ustalaştır

Kelime BilgisiKelime bankanızı oluşturun

Kelime OyunuOynarken öğrenin

QR Tara

Download on theApp Store Get it onGoogle Play

Aynı Kanal

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

Video Öner

37 cümleler

Bu dersin kelimeleri ve konuşma notları

Bu konuşma dersi “Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic” videosuna dayanıyor. En çok tekrarlanan kelimeler: session, model, command, code, cloud. Bu videoda gölgeleme çalışması için 286 cümle ve 3581 kelime var. Konuşma bölümü 17:31 sürüyor. Konuşmacı hızlı konuşuyor, dakikada yaklaşık 204 kelime; bu yüzden birbirine bağlanan ve zayıflayan sesler duyacaksınız. Kelimelerin %86’i İngilizcede en sık kullanılan 3.000 kelime arasında; geri kalanına başlamadan önce bakmakta fayda var.

Bu videodaki önemli kelimeler

Videodan öğrenmeye değer 15 kelime, telaffuzu ve anlamıyla:

Kelime	Telaffuz	Anlam
cloud isim	/ˈklaʊ̯d/	bulut
loop isim	/luːp/	ilik
approve fiil	/əˈpɹuːv/	onaylamak
default isim	/dɪˈfɔlt/	temerrüt
script isim	/skɹɪpt/	hat
deny fiil	/dəˈnaɪ/	inkâr etmek
guarantee isim	/ˌɡæɹ.ənˈtiː/	garanti, güvence
exit isim	/ˈɛɡzət/	çekilme, çıkış
verify fiil	/ˈvɛɹɪfaɪ/	doğrulamak
thread isim	/ˈθɹɛd/	iplik
output isim	/ˈaʊtpʊt/	çıktı
hook isim	/hʊk/	kanca, çengel
risky sıfat	/ˈɹɪski/	riskli
folder isim	/ˈfoʊldɚ/	klasör
steer fiil	/stɪɹ/	yönetmek

Duyacağınız deyimsel fiiller

Kelime	Telaffuz	Anlam
check out fiil		gözden geçirmek
come out fiil	/ˌkʌm ˈaʊt/	çıkmak
go off fiil		patlamak
throw away fiil		atmak

Bu videodaki dil bilgisi

Konuşmacının en çok kullandığı yapılar, videodaki sözcüklerin aynısıyla:

Yapı	Videoda
“Used to” used to + fiil — artık geçerli olmayan eski bir alışkanlık ya da durum	used to look · used to be · used to do
Present perfect have/has + fiilin üçüncü hâli — geçmişte olan ama şimdi de önemli olan bir eylem	have gotten · we've now essentially become · we've already gotten
Edilgen yapı be + fiilin üçüncü hâli — kimin yaptığı değil, ne olduğu önemli	is compromised · wasn't approved · was set

Dikkat edilecek telaffuzlar

Konuşmacı we're, don't, you're gibi kısaltılmış biçimleri 63 kez kullanıyor. Bunları duyduğunuz gibi kısa söyleyin.

“th” sesleri: thread /ˈθɹɛd/, rethink /ɹiːˈθɪŋk/, auth /ɔːθ/
“sh” ve “zh” sesleri: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, essentially /ɪˈsɛnʃəli/, shell /ʃɛl/, instruction /ɪnˈstɹʌkʃən/, supervision /ˌs(j)uːpəˈvɪʒən/
Uzun kelimeler — vurguyu doğru yere koyun: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, dependency /dɪˈpɛndənsi/, essentially /ɪˈsɛnʃəli/, ordinary /ˈɔɹdɪnɛɹi/, difficulty /ˈdɪfɪkəlti/

Türkçe konuşanların zorlandığı sesler:

/w/ — dudaklar yuvarlak, /v/ değil: whereas /(h)wɛɹˈæz/, suite /swiːt/, straightforward /ˌstɹeɪtˈfɔː(ɹ)wə(ɹ)d/
Kelime başındaki ünsüz kümesi — araya ünlü eklemeyin: cloud /ˈklaʊ̯d/, script /skɹɪpt/, thread /ˈθɹɛd/, prompt /pɹɑmpt/, steer /stɪɹ/
/æ/ — “e”den daha açık: guarantee /ˌɡæɹ.ənˈtiː/, laptop /ˈlæp.tɑp/, package /ˈpæk.ɪd͡ʒ/, whereas /(h)wɛɹˈæz/, manual /ˈmæn.j(u)əl/

Bu videoyla nasıl çalışılır

Videonun tamamını konuşmadan bir kez dinleyin ve bilmediğiniz kelimeleri not edin.
0,75× hızla başlayın, cümle cümle tekrar edin ve kolaylaşınca normal hıza dönün.
Kendinizi kaydedin ve orijinaliyle karşılaştırın; cloud, loop, approve gibi kelimelere özellikle dikkat edin.

Gölgeleme Tekniği Nedir?

Gölgeleme, başlangıçta profesyonel tercüman eğitimi için geliştirilen ve çok dilli Dr. Alexander Arguelles tarafından popüler hale getirilen, bilim destekli bir dil öğrenme tekniğidir. Yöntem basit ama güçlüdür: ana dili İngilizce olan bir sesi dinler ve hemen yüksek sesle tekrar edersiniz — konuşmacıyı 1-2 saniye gecikmeyle takip eden bir gölge gibi. Pasif dinleme veya dilbilgisi alıştırmalarının aksine, gölgeleme beyninizi ve ağız kaslarınızı gerçek konuşma kalıplarını eşzamanlı olarak işlemeye ve yeniden üretmeye zorlar. Araştırmalar, telaffuz doğruluğu, tonlama, ritim, bağlı konuşma, dinleme anlama ve konuşma akıcılığını önemli ölçüde geliştirdiğini göstermektedir — bu da onu IELTS Konuşma hazırlığı ve gerçek dünya İngilizce iletişimi için en etkili yöntemlerden biri yapar.

Shadowing tekniği: adım adım eksiksiz rehberi okuyun →

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

Bir pratik modu seçin

Uygulamayı İndir

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...

Bu dersin kelimeleri ve konuşma notları

Bu videodaki önemli kelimeler

Duyacağınız deyimsel fiiller

Bu videodaki dil bilgisi

Dikkat edilecek telaffuzlar

Bu videoyla nasıl çalışılır

Gölgeleme Tekniği Nedir?