शैडोइंग अभ्यास: GitHub's AI Problem - How AI Is Damaging the Platform - वीडियो के साथ अंग्रेजी बोलना सीखें

अभ्यास मोड चुनें

हर मोड पूरी स्क्रीन का अभ्यास कक्ष खोलता है।

379 वाक्य
यदि वाक्य बहुत छोटे या लंबे हों, तो समायोजित करने के लिए Edit पर क्लिक करें।
1
GitHub has an AI problem.
2
You may have heard about GitHub's uptime problem, but the problem is a lot more complex than you might know.
3
So let's talk about why AI is crushing GitHub and what the solutions might be.
4
Now, if you don't know me, my name is Tim Corey, and I teach people how to be an expert software developer,
5
not just an AI code monkey.
6
In today's world of just prompting for solutions, expert software development skills are more important than ever.
7
Otherwise, you become just another easily replaceable part with no actual skill.
8
That's why I provide free training here on YouTube, including multiple free courses and Patreon.
9
I am Tim Corey dot com.
10
I just wrapped up work on my game development master course, which covers how to become a game developer using
11
Unity and C Sharp.
12
So definitely check it out.
13
OK, let's look at the GitHub status page.
14
You probably heard that, you know, GitHub's been down a lot recently.
15
And yet, if you look at the GitHub status page, you see, well, Git operations, 99 .78%.
16
Now, that's not great, to be clear.
17
99 is only two nines of availability.
18
They should be shooting for four or five.
19
Before the Microsoft acquisition of GitHub, it was five nines.
20
Actually, it was zero nines.
21
It was 100 % uptime, but we could call it at least five nines or six nines or seven nines.
22
But right now, we're down to two nines in Git operations.
23
And you look at webhooks, 99 .66%.
24
That's still not great.
25
Two nines.
26
API requests, 99 .95.
27
That's three, actually three and a half nines.
28
That's pretty good.
29
And then issues, 99 .77 and so on.
30
You look at these and they're all 99 point something.
31
And you might say, well, that looks pretty good.
32
I mean, it's not four nines of availability, but it's something, right?
33
Well, they actually just put these percentages back up because they had taken them down.
34
And that really kind of hides the problem.
35
If you look at this and you see a lot of green
36
and you have some red and some yellows in here and some darker greens.
37
But, you know, you mostly see, you know, green.
38
So it looks like things are going OK.
39
And if you look at this, you might say, well, GitHub's not really having that much of a problem.
40
But then someone built the missing GitHub status page.
41
And this shows a whole different story.
42
Because when you talk about Git, you're talking about the whole, right?
43
If you're using GitHub, you're talking about the whole of GitHub.
44
And sure, if the site is down, but actions are up, that might mean that some things are still working.
45
But that's still a problem, right?
46
You still have issues.
47
And so, cumulatively, the GitHub platform should be a accumulation of all of those uptimes or downtimes, actually.
48
And based upon that, the 90 -day uptime is 87 .93%.
49
That is abysmal.
50
That is horrible.
51
Notice here, 93 incidents in the last 90 days.
52
That is, quite frankly, unacceptable.
53
Now, even GitHub will say that's unacceptable.
54
But notice that this shows a different number, right?
55
In fact, we come down here to get operations, which again, we go back over here, get operations.
56
This is this category, right?
57
This category says 99 .78 % on GitHub's status page.
58
On the missing status page, it says 98 .898%.
59
What's the difference?
60
Well, if we look here, let's come to this incident right here.
61
March 22nd, 2026.
62
There's a partial outage for 57 minutes.
63
We can actually look at this, let's open this up, And we'll see that this outage says disruption with some GitHub services.
64
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.
65
Intermittent errors, if you look down here, high latency and errors.
66
Basically, people are timing out trying to do Git operations on GitHub.
67
That's a pretty significant thing because that's what you normally do with GitHub, right?
68
It's Git operations.
69
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.
70
But that was March 22nd, 2026 for GitHub or Git operations, right?
71
So let's go to Git operations and hover over March 22nd, 2026, no downtime record on this date.
72
So their own status site says, yeah, we had downtime.
73
It wasn't for everybody, but we had downtime of some people
74
that had significant timeouts or significant latency connecting to and doing Git operations on GitHub.
75
But yet on their own status page, they don't even list it.
76
So that's a problem.
77
So when you look at this status page, you realize...
78
this isn't actually accurate.
79
This is even by their own standards is inaccurate, which is why this missing status page is a whole lot more accurate.
80
And even down here, you can look and see 98 .9,
81
98 .9, 99 .78, they actually have a higher uptime than what's listed on GitHub's status page for API requests.
82
But you can see 98s and some 99s in here.
83
So, but all told, you add all this up to this, which is the github platform you're at 87 .93
84
and this is why again we're talking about building software quick aside here we talk building software
85
and you say well you know the ai is going to write my software for me
86
and it's only you know it's 99 right
87
and that's not a problem right well 99 is right here
88
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?
89
They're high 99, 98.
90
But when they add them all together, when you use this as a whole, the application as a whole,
91
your uptime is more like 87 % because these things add up, right?
92
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.
93
Well, yeah, it kind of does because it doesn't matter if the website's up, if you can't order anything, right?
94
So those, the ordering affects the website.
95
And so there's, these are interconnected problems.
96
And so it actually compounds.
97
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.
98
Okay.
99
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.

ऐप डाउनलोड करें

धाराप्रवाह बोलने के लिए ज़रूरी सब कुछ

AI उच्चारण स्कोरहर वाक्य का स्कोर
IPA अभ्यासहर ध्वनि में महारत
शब्दावलीअपना शब्द भंडार बनाएँ
शब्द गेमखेलते हुए सीखें
QR स्कैन करें
QR स्कैन करें
FOR YOU

अनुशंसित वीडियो

इस पाठ की शब्दावली और बोलने के सुझाव

यह स्पीकिंग पाठ वीडियो “GitHub's AI Problem - How AI Is Damaging the Platform” पर आधारित है। सबसे ज़्यादा दोहराए गए शब्द ये हैं: github, code, software, request, pull। इस वीडियो में शैडोइंग के लिए 379 वाक्य और 4368 शब्द हैं। बोला गया हिस्सा 28:19 लंबा है। वक्ता लगभग 154 शब्द प्रति मिनट की स्वाभाविक गति से बोलता है, जो रोज़मर्रा की बातचीत के करीब है। 86% शब्द अंग्रेज़ी के 3,000 सबसे आम शब्दों में से हैं; बाकी शब्द अभ्यास से पहले देख लेना अच्छा रहेगा।

इस वीडियो की मुख्य शब्दावली

वीडियो के 15 सीखने लायक शब्द, उच्चारण और अर्थ के साथ:

शब्दउच्चारणअर्थ
solve क्रिया/sɒlv/सुलझाना, हल करना
developer संज्ञा/dɪˈvɛləpɚ/विकासक
server संज्ञा/ˈsɝvɚ/सर्वर
queue संज्ञा/kju/पंक्ति, क़तार
percentage संज्ञा/pə(ɹ)ˈsɛntɪd͡ʒ/प्रतिशतता
explanation संज्ञा/ˌɛkspləˈneɪʃən/स्पष्टीकरण, समझाना
helpful विशेषण/ˈhɛlp.fl̩/मददगार
compound संज्ञा/ˈkɑmpaʊnd/मिश्रण
verify क्रिया/ˈvɛɹɪfaɪ/परखना, जाँचना
ignore क्रिया/ɪɡˈnɔː/उपेक्षा, उपेक्षा करना
necessarily क्रिया विशेषण/ˌnɛs.əˈsɛɹ.ə.li/अवश्य, अनिवार्यतः
extent संज्ञा/ɪkˈstɛnt/विस्तार
package संज्ञा/ˈpæk.ɪd͡ʒ/पैकेज, पैकेट
encourage क्रिया/ɪnˈkʌɹ.ɪd͡ʒ/प्रेरित करना
trail संज्ञा/tɹeɪl/रास्ता

वीडियो में आने वाली फ़्रेज़ल वर्ब

शब्दअर्थ
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
Passive voice be + past participle — ज़ोर इस पर कि क्या होता है, न कि कौन करता हैare interconnected · being done · being written
Present perfect have/has + past participle — बीता हुआ काम जिसका असर अभी भी हैGitHub's been · that's been · has exploded
Relative clauses 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/

हिंदी भाषियों के लिए मुश्किल ध्वनियाँ:

  • /v/ और /w/ का फ़र्क़ — /v/ में ऊपर के दाँत निचले होंठ को छूते हैं, /w/ में होंठ गोल होते हैं: solve /sɒlv/, developer /dɪˈvɛləpɚ/, server /ˈsɝvɚ/, availability /əˌveɪ.ləˈbɪl.ɪ.ti/, verify /ˈvɛɹɪfaɪ/
  • /z/ — इसे “ज” (/dʒ/) न बनाएँ: acquisition /ˌæk.wɪˈzɪʃ.ən/, apologize /əˈpɑləˌd͡ʒaɪz/, repository /ɹɪˈpɒz.ɪ.t(ə.)ɹɪ/, abysmal /əˈbɪz.məl/, stabilize /ˈsteɪ.bəˌlaɪz/
  • शब्द की शुरुआत में s + व्यंजन — पहले “इ” न जोड़ें: speculation /ˌspɛk.jəˈleɪ.ʃən/, skill /skɪl/, spin /spɪn/, strengthen /ˈstɹɛŋ(k)θən/, spike /spaɪk/

इस वीडियो से अभ्यास कैसे करें

  1. पहले बिना बोले पूरा वीडियो एक बार सुनें और जो शब्द नहीं आते उन्हें लिख लें।
  2. 0.75× गति से शुरू करें, एक-एक वाक्य की शैडोइंग करें, और सहज लगने पर सामान्य गति पर लौटें।
  3. अपनी आवाज़ रिकॉर्ड करें और मूल से तुलना करें, ख़ासकर solve, developer, server जैसे शब्दों पर ध्यान दें।

शैडोइंग तकनीक क्या है?

शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 1-2 सेकंड की देरी से। शोध से पता चलता है कि यह उच्चारण सटीकता, स्वर, लय, जुड़ी हुई ध्वनियाँ, सुनने की समझ और बोलने की प्रवाहशीलता में काफ़ी सुधार करता है।

शैडोइंग तकनीक: पूरी चरण-दर-चरण गाइड पढ़ें →