Практика Shadowing: GitHub's AI Problem - How AI Is Damaging the Platform - Изучайте разговорный английский по видео

Выберите режим практики

Каждый режим открывает полноэкранную комнату практики.

379 предложений

Если предложения слишком короткие или длинные, нажмите Edit, чтобы их изменить.

GitHub has an AI problem.

You may have heard about GitHub's uptime problem, but the problem is a lot more complex than you might know.

So let's talk about why AI is crushing GitHub and what the solutions might be.

Now, if you don't know me, my name is Tim Corey, and I teach people how to be an expert software developer,

not just an AI code monkey.

In today's world of just prompting for solutions, expert software development skills are more important than ever.

Otherwise, you become just another easily replaceable part with no actual skill.

That's why I provide free training here on YouTube, including multiple free courses and Patreon.

I am Tim Corey dot com.

I just wrapped up work on my game development master course, which covers how to become a game developer using

Unity and C Sharp.

So definitely check it out.

OK, let's look at the GitHub status page.

You probably heard that, you know, GitHub's been down a lot recently.

And yet, if you look at the GitHub status page, you see, well, Git operations, 99 .78%.

Now, that's not great, to be clear.

99 is only two nines of availability.

They should be shooting for four or five.

Before the Microsoft acquisition of GitHub, it was five nines.

Actually, it was zero nines.

It was 100 % uptime, but we could call it at least five nines or six nines or seven nines.

But right now, we're down to two nines in Git operations.

And you look at webhooks, 99 .66%.

That's still not great.

Two nines.

API requests, 99 .95.

That's three, actually three and a half nines.

That's pretty good.

And then issues, 99 .77 and so on.

You look at these and they're all 99 point something.

And you might say, well, that looks pretty good.

I mean, it's not four nines of availability, but it's something, right?

Well, they actually just put these percentages back up because they had taken them down.

And that really kind of hides the problem.

If you look at this and you see a lot of green

and you have some red and some yellows in here and some darker greens.

But, you know, you mostly see, you know, green.

So it looks like things are going OK.

And if you look at this, you might say, well, GitHub's not really having that much of a problem.

But then someone built the missing GitHub status page.

And this shows a whole different story.

Because when you talk about Git, you're talking about the whole, right?

If you're using GitHub, you're talking about the whole of GitHub.

And sure, if the site is down, but actions are up, that might mean that some things are still working.

But that's still a problem, right?

You still have issues.

And so, cumulatively, the GitHub platform should be a accumulation of all of those uptimes or downtimes, actually.

And based upon that, the 90 -day uptime is 87 .93%.

That is abysmal.

That is horrible.

Notice here, 93 incidents in the last 90 days.

That is, quite frankly, unacceptable.

Now, even GitHub will say that's unacceptable.

But notice that this shows a different number, right?

In fact, we come down here to get operations, which again, we go back over here, get operations.

This is this category, right?

This category says 99 .78 % on GitHub's status page.

On the missing status page, it says 98 .898%.

What's the difference?

Well, if we look here, let's come to this incident right here.

March 22nd, 2026.

There's a partial outage for 57 minutes.

We can actually look at this, let's open this up, And we'll see that this outage says disruption with some GitHub services.

Okay, on March 22nd, between 9 .05 and 10 .02, that's just under an hour, users may have experienced intermittent errors and increased latency.

Intermittent errors, if you look down here, high latency and errors.

Basically, people are timing out trying to do Git operations on GitHub.

That's a pretty significant thing because that's what you normally do with GitHub, right?

It's Git operations.

So this is a big deal, but you're saying, well, some people might have, and they use these words, try and dumb it down.

But that was March 22nd, 2026 for GitHub or Git operations, right?

So let's go to Git operations and hover over March 22nd, 2026, no downtime record on this date.

So their own status site says, yeah, we had downtime.

It wasn't for everybody, but we had downtime of some people

that had significant timeouts or significant latency connecting to and doing Git operations on GitHub.

But yet on their own status page, they don't even list it.

So that's a problem.

So when you look at this status page, you realize...

this isn't actually accurate.

This is even by their own standards is inaccurate, which is why this missing status page is a whole lot more accurate.

And even down here, you can look and see 98 .9,

98 .9, 99 .78, they actually have a higher uptime than what's listed on GitHub's status page for API requests.

But you can see 98s and some 99s in here.

So, but all told, you add all this up to this, which is the github platform you're at 87 .93

and this is why again we're talking about building software quick aside here we talk building software

and you say well you know the ai is going to write my software for me

and it's only you know it's 99 right

and that's not a problem right well 99 is right here

and i put 78 98 .9 98 .9 these different parts let's say as parts your application, they're all in the high 90s, right?

They're high 99, 98.

But when they add them all together, when you use this as a whole, the application as a whole,

your uptime is more like 87 % because these things add up, right?

They don't just live in their own little bubble where, yeah, sure, ordering's down, but that doesn't affect the other parts of your application.

Well, yeah, it kind of does because it doesn't matter if the website's up, if you can't order anything, right?

So those, the ordering affects the website.

And so there's, these are interconnected problems.

And so it actually compounds.

So when you're using a system that is mostly accurate and you do that over and over and over again, these issues and errors compound.

Okay.

Off a soapbox, off the rabbit trail here, let's get back to GitHub and let's just understand what's going on at GitHub.

100

And then we'll talk about why it's happening.

101

It's important to understand what's happening first.

102

What's happening is they're having downtime all over.

103

Now, some of us is co -pilot.

104

We have code spaces, pages, packages, actions.

105

They've got a lot of new stuff.

106

In fact, to be clear, when Microsoft took over GitHub, GitHub was basically, now I'm simplifying it,

107

but it was basically a place to put your Git repository with issues,

108

a place for issues and a place for tracking or commits and those kinds of things.

109

But that was basically what GitHub was.

110

And then it had a little bit of actions, but not very much.

111

Microsoft came in and said, Hey, let's do more with, with actions and with, with code code spaces and pages

112

and co -pilot and let's broaden it and open it up to more people in the community for free.

113

So there's a lot more that went into Microsoft add a lot more features and a lot more moving parts.

114

And when you add a lot more moving parts, what do you get?

115

Well, you get more problems, right?

116

That's just the nature of the game.

117

When you add more of these things to track, that reduces your downtime every time one of the components has a problem.

118

So to be fair, they're doing more things, but there's more to it than that.

119

And, you know, some people say, well, how do you know this is AI's problem?

120

I can tell you for a fact, this is AI problem, but it's actually a couple of AI problems.

121

And let's talk about each.

122

First, let's talk about this right here.

123

This is Kyle Daigle.

124

I hope I'm saying that name right.

125

He's a chief operating officer over at GitHub.

126

By the way, GitHub does not have a CEO.

127

Microsoft, when the last CEO left, said, hey, we're not going to add a new CEO.

128

That might be adding to things that's been some speculation here that without that clear direction,

129

that clear oversight, they may be floundering a bit under Microsoft's leadership.

130

That may be true, that's speculation.

131

But here's what

132

Kyle says about the status issue, the downtimes.

133

He said, yep, platform activity is surging.

134

There were, listen very carefully to this, 1 billion commits in all of 2025.

135

Now, 2025 was an up year because AI is starting to pick up

136

and people are starting to use AI more and a lot more

137

Vibe code was starting and those kind of things were happening.

138

And so there is a lot more code commits being done on GitHub in 2025.

139

But it's now 275 million commits per week.

140

Okay.

141

So 1 billion commits all of 2025 five, that's happening now in about four weeks.

142

So they're on track for 14 billion commits this year.

143

It was 1 billion.

144

Now it's 14 billion now.

145

And that's if their growth remains linear, which he said, spoiler, it won't.

146

This is because of AI.

147

this is because everyone is using ai

148

and they're doing a lot more commits ai is a lot more verbose it does a lot more things

149

and people are using things like agents and background agents

150

and you know their own spun off tasks

151

that run in the background all the time they're trying to see how many tokens they can use

152

and they're writing a ton of code now unfortunately some that code is for existing production apps.

153

I don't love that.

154

And we'll see why in the future, I've got a lot more content coming around what AI is doing to our everything, to society.

155

But we know that a lot of code is being written by AI in production applications,

156

but there also is a lot more sample apps.

157

There's a lot more, hey, is it just an app for me?

158

And so the amount of code being put on GitHub has exploded.

159

So 14 billion commits this year.

160

Okay.

161

Now, seeing the trickle -down effects, because again, if you look at all these different services, okay, so you're doing Git operations, right?

162

And that's going to take a load because you're going to upload the files,

163

you're going to download the files when people pull the new versions, et cetera.

164

But then there's also more issues because you have more code there's more pull requests

165

because you're creating more commits and you're creating more prs

166

but then here's the big one actions now it depends on the repository how you set it up

167

but for example in my repository whenever

168

i commit a new setup changes to one of my branches it will build

169

that branch and deploy it to a development server so

170

if you create a new pull request on my sites than on my actual code sites.

171

Then what it's going to do, it's going to build that.

172

It's going to deploy it to a development server, a different one.

173

It's its own standalone.

174

We are using Azure.

175

So I can easily see it running.

176

Well, every time I create a pull request, a new one of those gets created.

177

Think about if I'm creating 10 times or 100 times in a pull request, what that's doing to the number of actions that are running.

178

So it's not just that there's more code or more pull requests.

179

It's that there's more processing going on.

180

And Microsoft integrated co -pilot into GitHub.

181

And quite frankly, it's the best co -pilot Microsoft owns.

182

There's so many different ones.

183

This is the GitHub co -pilot.

184

And it's not perfect.

185

It's far from perfect, but it's the best one they have.

186

And what it can do is it can do things like review pull requests automatically.

187

And it can do code reviews, it can create its own pull request.

188

It can do work on code.

189

If you submit an issue, it can do initial work and do some initial code commits for fixing that issue.

190

All of that is triggered off of issues.

191

If you have more issues, you have more code, you have more work being done by Copilot.

192

So the load isn't just linear with the number of pull requests is actually probably exponential

193

because of all these additional things that have been added.

194

So with that in mind, GitHub Actions has grown from 500 million minutes per week in 2023.

195

Now that's three years ago to a billion minutes per week in 2025.

196

That's last year to now 2 .1 billion minutes so far this week.

197

Okay, think about that.

198

So it was a billion minutes a week in 2025.

199

Now it's twice as many minutes.

200

Again, that's CPUs running.

201

That's processes running.

202

And that's 2 .1 billion.

203

And that's at this time in the week.

204

I don't think this was the end of the week, right?

205

So there's a lot of stuff going on, right?

206

Their load has dramatically increased because of AI, okay?

207

OK, so we're pushing pretty hard on more CPUs, scaling services and strengthening GitHub's core features.

208

OK, so that's the explanation from GitHub.

209

Always take an explanation from a person in power with a big grain of salt,

210

because that is their perspective of what they want you to know.

211

Now, I'm not saying this person is lying.

212

I'm not.

213

But there's always a bit more to the story, right?

214

There's a bit more that can be talked about beyond just what they say, because there's things they don't say.

215

So yes, platform activity is surging.

216

That's absolutely true.

217

And I love the fact that he shared these numbers, because this is really important to understand that, yes.

218

There is an incredible load on these servers.

219

So it's not unexpected to see downtime as we stress out platforms.

220

This is actually one of the big problems right now, even with AIs, where we're seeing more downtime with LLMs

221

because of the fact they simply don't have enough GPUs running to support the amount of work people are asking for.

222

And so they're raising prices

223

and they're doing all these other things to try to figure out how to manage

224

that because there isn't enough processing power for all of the demand because the demand is spiking so hard.

225

So yes, that is absolutely accurate, but that doesn't mean it's the only part of the story.

226

Because first of all, this downtime, again, remember, Rosie view the downtime, actual view based on their actual numbers, right?

227

So this downtime didn't start since AI took over.

228

It didn't start in the past 90 days.

229

Now, it's gotten a lot worse in the last 90 days, but this actually started soon after

230

Microsoft took over.

231

And remember, Microsoft added Copilot and Codespaces and actions, well, they improved actions, a lot more of actions,

232

and did some other things as well that added to the platform and added to the complexity.

233

So it's natural to see some downtime from that, but it has not gotten better.

234

In fact, it's getting worse.

235

Now you add additional things with the additional load.

236

You might say, well, that probably is enough.

237

I would argue it's not enough.

238

I argue it's not the whole story.

239

It's a great part of the story.

240

And it's, it's a great thing to say because it feels like it's right, but we're ignoring a couple of things here.

241

Again, Microsoft is a heavy user of AI.

242

Microsoft has been telling us for a while now

243

that AI is here and we need to use AI more to build things.

244

They've been saying since early 2025 that they are using AI to write more and more of their software.

245

When you talk to, you know, you hear from any of the, like the head of OpenAI or the head of Anthropic,

246

you'll hear them say things like, we're going to replace developers with just AI

247

or AI is going to do most of the work and we should have AI write all of our code.

248

These are things they're saying, but we're also seeing that the result of that is a large increase in the number of errors.

249

There's a report out recently, and I'll be sharing it in a future video.

250

There's a report out recently where it says that for every line of code that AI writes,

251

there's three times as likely to have bugs compared to a human writing that code.

252

That's stunning, right?

253

That's stunning the amount of problems.

254

And that's a recent report using things like Opus

255

and other late gen models that are supposed to be the best at software development.

256

And there's still that significant of an issue.

257

So when you put that into perspective

258

And you say, well, if AI was great and

259

if AI really was able to solve these major problems and solve things at scale,

260

then we should at least see a leveling out where,

261

yeah, maybe you still have some downtime because that's going to happen under load and under stress.

262

But it should be getting better because they should have written more tests and they should have fixed more problems.

263

But we're not seeing that.

264

We're not seeing the improvement.

265

We're seeing a degradation that continues.

266

And so AI is not solving this problem, is not stabilizing this environment.

267

What we're seeing instead is they're increasing in the number of problems they have and significant ones.

268

So there is a problem.

269

Let's pull up.

270

So this one right here, this happened as I'm recording this a couple of days ago.

271

So, on April 23rd, between 4 p .m and 8 p .m.,

272

the pull request service experienced a regression affecting merge queue operations.

273

Pull requests merged via merge queue using the squash merge method produced incorrect merge commits

274

when the merge group contained more than one pull request.

275

In affected cases, changes from previously merged pull requests and prior commits were inadvertently reverted by subsequent merges.

276

This is a five alarm fire.

277

This is a major issue.

278

This is not just the site was slow.

279

We had to wait for an hour for the site to come back up.

280

We couldn't commit because there was no, like it was down.

281

This is not that.

282

What this is, is the site was working but it destroyed or damaged the Git history of your commits.

283

That right there is a massive problem.

284

Now, to their credit, they did reach out in theory to all the people affected and said,

285

hey, we're going to, here's how to fix this problem.

286

We apologize to the problem, et cetera but they told them how to fix it in theory.

287

But what this means is that code could have gone to production

288

that was the wrong code or missing parts and trying to fix that and revert that and change that and bring it.

289

That's a significant downtime for their customers.

290

Now, again, of all the pull requests on this day, now this is again where numbers can really be used to manipulate.

291

um again this was from uh kyle i know the tweet pulled up here

292

but kyle said hey there was four million pull requests in this day

293

and only 0 .07 were affected about 2700 i believe um

294

which sounds like well it's not a big deal well actually even one is a big deal

295

and he did say it later he's like no anything more than zero is a problem

296

but if you start looking at this well it's over a few hours, four hours, not all day.

297

And so your 4 million pull requests in that day was actually a smaller fraction of that.

298

And it wasn't all pull requests.

299

It was pull requests that were merged via the merge queue.

300

So that's an even smaller number.

301

And so also your percentages look a lot bigger because you're actually looking at real numbers, not just, you know, If I said,

302

well, they merged 14 billion pull requests this year and only 0 .00004 % had this problem,

303

that sounds tiny.

304

But the reality is, it's a significant problem for a significant number of customers.

305

This right here is not an issue where, oh, they had too many things going on at once.

306

This was not an issue where they had, you know, too much load at the time because they had too many people doing too many things.

307

This is a bug in the code.

308

This is a major bug in the code.

309

This is a bug in the system that should never have gotten to production.

310

This is just one of the many issues you'll see in this status reports

311

that can be attributed to something besides just it was load, right?

312

Load is an easy thing to point to because you have all these big numbers.

313

If you look at these numbers, this seriously is a huge number.

314

And I can't imagine 2 .1 billion minutes of GitHub actions running in a week.

315

That's just an insane amount.

316

So yes, totally understand that load is a major factor and that's coming from AI usage of everybody else.

317

However, that's not the only thing in the picture.

318

We can see there are other issues that are going on at GitHub because of poorly written code or not checked correctly.

319

And they did say, hey, we're deploying new tests to cover those areas.

320

Why were there not tests beforehand?

321

That's a great question because you have an AI that could have helped you write those tests in theory.

322

But the reality is that when you're dealing with production applications, you can't just say, hey, let the AI do more work.

323

Because what happens is you have more issues like this, your uptime looks like this, and your customers start looking elsewhere.

324

And if you look online, This is what a lot of people are asking right now is, where do I go if I'm not on GitHub?

325

GitHub has a stranglehold on the market.

326

They have so much of the market share.

327

And yet, their customers are saying, hey, what about GitLab?

328

Or what about, you know, this or that?

329

And all of a sudden, they can start losing real customers.

330

And they might get to the point where they have real competition.

331

Not because their competition was better necessarily.

332

but because their competition wasn't as bad.

333

And that's not a great place to be.

334

So it's important that when you look at, if you look at this from your perspective, when you are writing software,

335

your software, whatever part of the business it's supposed to help, the reality is your business will rely on that software.

336

And if your software can't get the job done, then you're going to cause problems for your business.

337

And if you sell that software, software as a service, something else, you know, then your customers will rely on that software.

338

And if they can't use that software well, they're going to look somewhere else.

339

And so if your job depends on, if your company's...

340

Income depends on software, and it almost certainly does to one extent or another, then you need to think about, is this okay?

341

Is it okay to lose customers?

342

Is it okay to potentially damage our customers?

343

Like this issue right here,

344

they damaged their customers, and potentially those customers had problems with their own customers because of this.

345

That's a big deal.

346

Are you okay with that?

347

Now, I encourage you to really think about how you use AI

348

because of the fact that this type of thing just snowballs.

349

It doesn't get better with writing more AI code.

350

What happens is it gets worse and worse and worse.

351

When I talked about this about a month or so ago, this was in the 90s.

352

It was 92 or 3, I think it was.

353

So, this has dropped another 3 % to 5 % in uptime in just the past month and a half or so.

354

Like this is a major problem and it's getting worse, not better.

355

Now, again, load is part of it.

356

I don't want to discount that, but I do want you to think about how you write your software, writing software that is performance,

357

writing software that is secure, writing software that has been tested and verified is really important.

358

And just saying it's faster to let the AI write it isn't going to be good enough

359

because it will be for a while.

360

And then you'll see the snowball and that snowball is going to keep rolling and keep getting bigger.

361

And it's going to bury you under downtime, under lost customers, under lost revenue and major issues.

362

So I guess my conclusion here is don't be like GitHub, right?

363

Plan for how you write good software, not just provide faster software,

364

as in faster to market with new versions and new features.

365

It's more important that your features work than that they're faster because getting things out there faster,

366

getting more features isn't going to be helpful when they start to break down even more frequently.

367

So make sure that you're writing good software.

368

Make sure you know how to actually read the code that your AI writes.

369

And yes, you have to verify line by line.

370

And that's a problem because of the fact that AI writes so many lines of code.

371

You have to actually tell it, write less lines of code.

372

And that's part of being a senior developer is saying, how can we solve this problem with less lines of code?

373

So you have to build up your skills so you can better drive AI.

374

Otherwise, you're in danger of your entire business collapsing if you're not careful, okay?

375

Thanks for watching.

376

I hope that this is helpful.

377

I hope that this can give you some new things to think about and new ways of approaching software development.

378

But as always, I am Tim Corey.

379

We'll be right back.

Скачать приложение

Всё для свободной речи

ИИ-оценка произношенияОценка каждой фразы

Практика IPAОсвойте каждый звук

СловарьСоберите свой словарный запас

Игра со словамиУчитесь играя

Сканировать QR

Download on theApp Store Get it onGoogle Play

FOR YOU

Лексика и советы по произношению к этому уроку

Этот урок разговорной практики построен на видео «GitHub's AI Problem - How AI Is Damaging the Platform». Чаще всего повторяются слова: github, code, software, request, pull. В этом видео 379 предложений и 4368 слов для шедоуинга. Речь длится 28:19. Говорящий говорит в естественном темпе, около 154 слов в минуту, близком к повседневной речи. 86% слов входят в 3000 самых частых слов английского языка; остальные стоит разобрать перед занятием.

Ключевая лексика этого видео

15 слов из видео, которые стоит выучить, с произношением и значением:

Слово	Произношение	Значение
commit глагол	/kəˈmɪt/	вверя́ть
merge глагол	/mɝd͡ʒ/	объедини́ть, слить
solve глагол	/sɒlv/	реша́ть, реши́ть
developer существительное	/dɪˈvɛləpɚ/	разрабо́тчик, разрабо́тчица
server существительное	/ˈsɝvɚ/	се́рвер
depend глагол	/dɪˈpɛnd/	зави́сеть
queue существительное	/kju/	о́чередь
deploy глагол	/dɪˈplɔɪ/	развёртывать, разверну́ть
percentage существительное	/pə(ɹ)ˈsɛntɪd͡ʒ/	проце́нт, проце́нтное отноше́ние
argue глагол	/ˈɑɹ.ɡju/	спо́рить, обсужда́ть
explanation существительное	/ˌɛkspləˈneɪʃən/	объясне́ние, разъясне́ние
helpful прилагательное	/ˈhɛlp.fl̩/	поле́зный, любе́зный
rely глагол	/ɹɪˈlaɪ/	полага́ться, положи́ться
compound существительное	/ˈkɑmpaʊnd/	соедине́ние, сочета́ние
availability существительное	/əˌveɪ.ləˈbɪl.ɪ.ti/	нали́чие

Фразовые глаголы, которые вы услышите

Слово	Произношение	Значение
take over глагол		брать на себя́, взять на себя́
back up глагол		дава́ть за́дний ход
break down глагол		ломаться, сломаться
build up глагол		накапливаться, скапливаться
come around глагол	/kʌ.məˈɹaʊnd/	переду́мать
come down глагол		спуска́ться, спусти́ться
figure out глагол		разбира́ться, разобра́ться
pick up глагол		подбира́ть, подобра́ть

Фразы, которые стоит повторять

Короткие законченные фразы из видео, которые пригодятся в повседневном разговоре:

First, let's talk about this right here.
I hope I'm saying that name right.
There's a lot more, hey, is it just an app for me?
Is it okay to potentially damage our customers?
Are you okay with that?

Грамматика в этом видео

Конструкции, которые говорящий использует чаще всего, с точными словами из видео:

Конструкция	В видео
Present Perfect Continuous have/has been + -ing — действие началось раньше и продолжается	has been telling · They've been saying
Пассивный залог be + причастие прошедшего времени — важно, что происходит, а не кто это делает	are interconnected · being done · being written
Present Perfect have/has + причастие прошедшего времени — прошлое действие, важное сейчас	GitHub's been · that's been · has exploded
Придаточные определительные who / which + предложение — уточнение о человеке или предмете	inaccurate, which is · this, which is

Произношение, на которое стоит обратить внимание

Говорящий использует 94 сокращённых и редуцированных форм, например you're, they're, we're. Произносите их коротко, так, как слышите.

Звуки «sh» и «zh»: explanation /ˌɛkspləˈneɪʃən/, potentially /pəˈtɛnʃ(ə)li/, speculation /ˌspɛk.jəˈleɪ.ʃən/, conclusion /kənˈkluːʒən/, acquisition /ˌæk.wɪˈzɪʃ.ən/
Длинные слова — следите за ударением: developer /dɪˈvɛləpɚ/, explanation /ˌɛkspləˈneɪʃən/, potentially /pəˈtɛnʃ(ə)li/, availability /əˌveɪ.ləˈbɪl.ɪ.ti/, speculation /ˌspɛk.jəˈleɪ.ʃən/

Звуки, трудные для русскоязычных:

/w/ — губы округлены, это не /v/: subsequent /ˈsʌbsɪkwənt/, acquisition /ˌæk.wɪˈzɪʃ.ən/, tweet /ˈtwiːt/, squash /skwɔʃ/, webhook /ˈwɛb.hʊk/
/h/ — лёгкий выдох, а не русское «х»: helpful /ˈhɛlp.fl̩/, horrible /ˈhɔɹ.ɪ.bəl/, beforehand /bɪˈfɔɹhænd/, hover /ˈhɒvə/, webhook /ˈwɛb.hʊk/
Звонкие согласные в конце слова — не оглушайте их: merge /mɝd͡ʒ/, solve /sɒlv/, depend /dɪˈpɛnd/, percentage /pə(ɹ)ˈsɛntɪd͡ʒ/, compound /ˈkɑmpaʊnd/

Как заниматься с этим видео

Прослушайте всё видео один раз молча и выпишите незнакомые слова.
Начните со скорости 0,75×, повторяйте предложение за предложением и вернитесь к обычной скорости, когда станет легко.
Запишите себя и сравните с оригиналом, обращая внимание на такие слова, как commit, merge, solve.

Что такое техника Shadowing?

Shadowing — это научно обоснованная техника изучения языка, изначально разработанная для подготовки профессиональных переводчиков и популяризированная полиглотом доктором Александром Аргуэльесом. Метод прост, но эффективен: вы слушаете аудио на английском от носителей языка и немедленно повторяете вслух — как тень, следующая за говорящим с задержкой в 1–2 секунды. В отличие от пассивного прослушивания или грамматических упражнений, Shadowing заставляет мозг и мышцы рта одновременно обрабатывать и воспроизводить реальные речевые паттерны. Исследования показывают, что это значительно улучшает точность произношения, интонацию, ритм, связную речь, понимание на слух и беглость речи — что делает его одним из самых эффективных методов для подготовки к IELTS Speaking и реального общения на английском.

Техника шедоуинга: читать полное пошаговое руководство →

Практика Shadowing: GitHub's AI Problem - How AI Is Damaging the Platform - Изучайте разговорный английский по видео

Выберите режим практики

Скачать приложение

Рекомендуемое видео

Did Anthropic Kill Git?

How AI deprives young Singaporeans of jobs and critical thinking | Deep Dive

STOP Running Code On Your Computer

900+ hours of Learning AI Agents in 9 Minutes

I Looked Into How Devs Are Actually Using AI

They JUST Accidentally Revealed the Truth: The AI Bubble

GitHub Copilot now controls your command line...

The hottest programming skill in 2026

The Only SaaS Moats Left in 2026

AI Destroyed My Profession

I Tested The Viral Reverse Engineering Repo

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

Лексика и советы по произношению к этому уроку

Ключевая лексика этого видео

Фразовые глаголы, которые вы услышите

Фразы, которые стоит повторять

Грамматика в этом видео

Произношение, на которое стоит обратить внимание

Как заниматься с этим видео

Что такое техника Shadowing?