ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: How Great Software Engineers Are Moving Faster Than Ever
กำลังสร้างบทเรียน...
1
The thing that got me excited about learning how to build software was the ability to solve a problem.
2
This is Logan Kilpatrick, product lead for AI studio over at Google DeepMind.
3
There's so much interesting innovation that's happening in this way that like was not happening three years ago.
4
Every two weeks, every three months, every six months, what's possible changes.
5
You have to reset your level of ambition.
6
Somebody should build that company. Which skills really matter nowadays?
7
The rules of software engineering have changed.
8
Here's the full episode.
9
I love your keynote yesterday.
10
Thank you. I was very excited to see anti-gravity CLI. Yeah, yeah.
11
And I feel like more and more engineers are moving towards CLI first.
12
I do feel like we're trying to meet developers where they are.
13
And I think this like story of like developer preference has also never been more.
14
I think it's actually been hard to meet developers where their because it's expensive to build an SDK and the CLI and ID and an agent manager, and then also in a managed service.
15
And I think it was cool to see the anti-gravity story come to life, literally with like the full breadth of that.
16
You could literally use it in an IDE, you could use it in the agent manager, you can use the CLI, you can you could use it and through managed agents in the Gemini API, which is really cool.
17
It was a unique, unique story that I don't think we've been able to pull off before.
18
And I think it's actually based on feedback from developers who are like, give us a single product.
19
We don't want to have to, you know, wade through the ecosystem of 50 different AI products that Google is offering for developers.
20
And so you even like the consolidation of the Gemini CLI.
21
Sort of moving over to the integrated CLI is all based on that feedback.
22
Gotcha. The Gemini CI was open source, was open source.
23
I noticed that the anti-gravity one is not.
24
Yeah. This is an interesting thread.
25
I think we'll all.
26
I work super closely with the anti-gravity folks and actually also the Gemini CLI folks.
27
It'll be interesting to see how this ends up shaking out over time.
28
My sense is it's not like a deeply strategic choice right now.
29
It's just like a you can move, there's a there's a cost to doing open source.
30
Of course, you can move a lot faster.
31
Actually right now. I think not doing it.
32
And so I think if they decide to go open sourcing, they want to like actually lean in and do it.
33
But my sense is it's not like there.
34
I don't I don't think the headspace is that there's a bunch of like secret stuff that they're trying to do.
35
I think it's mostly just like an operational thing.
36
And like even does that team have like expertise and the desire to like, go and do that?
37
I think the team who is working on Gemini Kelly and actually some of them are now working on a bunch of anti-gravity stuff.
38
It's just like maybe less less the thing that they're that they've done before and have the expertise for. So it'll be interesting. We'll see.
39
We'll see how it shakes out.
40
But I definitely saw the feedback of folks wanting to have an open source variant.
41
Yeah, I've seen a thread online as well that says, well, there is this kind of the ID is dying, right?
42
Because if your agents are generating code and you if you have the right guardrails or if you have the right hardness capabilities, even engineering around your harness, then you don't necessarily need to look at the code that is generated.
43
Right. You might do it in a pull request or even if that becomes a bottleneck.
44
That's something we need to solve as engineers.
45
But do people then.
46
Do you see this narrative of the ID is dying or what's your take on that?
47
I think my framing of it is not not necessarily the ID is dying.
48
I think it's like the way that software is being built is evolving.
49
And actually, in some sense, it's interesting that like, there's there's maybe even more tools that are involved in some sense, you know, there's there's less tools in some sense there's more tools.
50
And actually your example where like, you spend a lot more time reviewing code in a pull request than historically you would before until like, I'd imagine there ends up being a lot more innovation and focus on like, how do you build great code review tools that maybe actually look different than the code review tools of the today era that were built with the assumption that it was a human writing code, not an agent writing code.
51
So I think the the focus definitely moves.
52
You still need an editor.
53
And so actually for anti-gravity, like there is still an editor, you can actually hook it up to the editor of your choice now as well.
54
So if you're like, hey, I love into your favorite editor, you can go and continue to use that.
55
And I think developers will need to do like some.
56
And this is, I think the biggest difference of like, you know, vibe coding versus a genetic engineering.
57
And I think the engineer needs to be able to go into an IDE and edit code.
58
In some cases, they'll probably maybe predominantly be using some sort of like agent manager, but you still need the ability to, when the time comes to go and edit code and look through and use a bunch of like, rich debugging tools that only exists in an editor and don't exist in the context of sort of an agent manager experience.
59
So I don't think it's going to go away.
60
I think developers will spend more time, though, probably outside the IDE.
61
And to me that feels like a very natural thing that like developer tooling, continues to change.
62
The developer tooling of today's era is very different than it was 10 or 15 years ago.
63
And so it doesn't feel that part's not super surprising to me.
64
Yeah. Same here.
65
I feel like the bottleneck will be will requests very, very soon.
66
Right. I feel this already inside of Google.
67
Like I write code all the time now and it's like the code is actually reasonable.
68
The the burden is now on a bunch of engineers across Google who have to review the code that I'm writing and give feedback and all that stuff.
69
So like, it's I think it's it's quickly shifted into a bunch of different places.
70
And I think we can speed up code review and then the, the, the actually, Jeff Dean made this comment to me a couple of weeks ago, but like the burden in a lot of cases actually moved to like tool execution.
71
And so as models get faster, even as you sort of maybe if you had a human who could review your code right away instantly, there's still like the CI time maybe becomes, you know, you have to run a whole set of tests and maybe you have a lot of tests because you're a great agent engineer and you're being really thoughtful about it, but like that becomes the burden.
72
So I think the burden, the sort of bottleneck actually.
73
So the bottleneck is going to be sort of all over the place.
74
And I think it'll actually be interesting to see how developers and how companies are measuring this, like where in the process of creating software is the bottleneck moved to.
75
And I think Google's actually had historically a great culture.
76
And like a ton of instrumentation that helps us answer this question internally because we want to, you know, remove the bottleneck for engineers building software.
77
Yeah, it's really a puzzle that it's more on my day to day to solve.
78
How do we measure kind of productivity?
79
Because that's the the marketing, right.
80
You become more effective. Engineers feel that.
81
But the costs are also rising.
82
That's why specifically with 3.5 flash being very cost efficient, I was super excited.
83
If this is where we can go.
84
For example, Cloud Code has opus plan where you reason and you create, for example, your plan in a higher end model, and then you execute in a more lightweight model.
85
And I see the ambition with 3.5 is to just use the same model and do both.
86
That's the goal.
87
Yeah. And I love I love feedback.
88
As far as where it lands, I think this is this is definitely like the first iteration of the 3.5 family.
89
And I feel like also the first iteration where we've done this model product harness symbiosis.
90
So the model is being trained at the same time that we're using the harness, at the same time that we're thinking about like, how is that actually impact?
91
There's lots of feedback historically about the Gemini models, sort of like looking great on paper and not being great for real world use cases.
92
And sort of we've taken that feedback super seriously over the last, probably more than a year now to to try to make sure that they're as representative in the products themselves as they are in benchmarks.
93
And so it's cool to see that flywheel actually spinning now and all of the all the progress happening.
94
Yeah, for me, the at least in my community, for the engineer that's listening, for example, it could be someone that is very on the higher end, but it could also be someone that's kind of not even dabbled their feet in there.
95
And skills are evolving for the person that's listening.
96
Which skills really matter nowadays from your perspective?
97
It's a good question.
98
I think it depends what you want to do and like what your what your actual job is. I think there's, there's there's definitely like evergreen skills.
99
I mean, I think, you know, taste I think is important if you're, if you're an engineer who, you know, can sort of see a user bug, report it and know, like, oh, this is how I should go and solve that problem, and this is how I should get my agent to solve that problem.
100
Whatever it is.
101
I think there's alpha in that because I think there's, there's there's so much software to be built that as much as engineers can sort of take the burden of building that software and just go and run with it.
102
I think so much of the and actually, again, this is like goes back to measuring like where all the bottlenecks so much of the bottleneck is in this like human communication loop that happens like someone reports an issue or says they want x, Y and z feature.
103
There's this like long ping pong game of humans talking about the something before somebody makes a plan and then actually goes and builds it and then brings it to users.
104
And like most of the ping pong, probably in some cases it's really useful.
105
And like the taste aspect is like knowing when you need to play ping pong.
106
And if you if you sort of know in a lot of cases and you have a high degree of accuracy of knowing when you need to play ping pong and knowing when you don't need to, it speeds up the process so much, and there's like a huge amount of alpha in in being able to do that and like actually the best, the best sort of engineers I work with have a great sense of being able to answer that question.
107
Yeah, I like that a lot.
108
I wonder how long it takes to kind of develop this taste if you start out or if you're already here kind of working with a generic tooling, because it is a I think it's a loss in kind of productivity initially.
109
Right? Whenever we try something new, there's an investment there and the payoff could be three months, it could be six months.
110
It really depends also on the curiosity and the eagerness and the drive, but it varies.
111
What is like the minimum investment that you think people should do?
112
Yeah it does. It varies.
113
And I think it also varies depending on what your team has done to set up.
114
And so I think we've had a lot of conversations with the studio engineering team as an example.
115
And one of the conversations and I told them, I told the engineering team this, I was like, hey, I want to do the minimal amount of setup humanly possible to get like full context of all of the engineering information that I need for my agent to go and make a bunch of changes in the studio code base.
116
And they were like, yep, okay.
117
And they literally got a like a whole suite of skills set up.
118
And I literally ran one command and then I not actually, but then I like had as much content.
119
My agent had as much context as every engineer on the team should have.
120
Not fully, of course. It's definitely loss here.
121
And then literally that same day, I was making production code changes in the AI studio code base.
122
So I think in some cases it actually can be months depending on what your setup looks like.
123
In some cases it's like days or hours.
124
And I think that's the that's the interesting thing is also like just trying to identify which of the situations you're in, like, and maybe there's a, you know, I'm sure there's lots of great engineers everywhere.
125
So maybe it's not that we have the smartest engineers who are just really good at doing it.
126
Maybe it's our tech stack actually just like works really well.
127
We already had Agent Rails, sort of.
128
We had the governance structure set up so that we could do the things we needed to add the AI tooling we actually wanted, and maybe that's harder at other companies, but it could be the best cases, like literally ours, where you're able to actually get that.
129
And I felt that as somebody who was doing a ton of software engineering work before I joined Google, joined Google on the product ladder originally, and like actually stopped doing a lot of engineering work because two years ago it was really like Google's internal infrastructure is actually really different than the rest of the world's developer infrastructure.
130
And so the learning curve is really hard.
131
It's sort of a lot more difficult to use some of the tools because they're designed to scale to like billion user products.
132
And even if you're not using a billion user product, it's sort of it's sort of difficult.
133
And this AI coding era has brought me back into like making real production software changes, which I've appreciated so much because I'm a I'm a software engineer and I love building software.
134
Yeah. So I think in that sense I got lucky.
135
But it's been it's been cool to see it happen.
136
And again, the best case is like literally they built the skills that day and I was able to benefit from them and start sending code changes.
137
Yeah, the best engineers that I know, the organization trusts them with kind of overarching ventures, right.
138
Bigger changes across multiple teams.
139
So the ability to fly in a team, kind of do your research or make impact is incredibly valuable.
140
I think we give those stakes when the stakes are high to the best engineers we have within organizations.
141
And then part of that, for me, something I've been recently thinking about is going to be agent experience.
142
So within a code base or within a team, can we measure some form of experience?
143
Right. If I come in and I have my stack, how well can I indeed familiarize myself and what in the repository allows for that to be able to be productive quite quickly?
144
I frame this to our team as I was thinking about this, and I'm curious actually what others think, and I would love to.
145
I'll read the comments on this video and see what people's reaction is to this.
146
But around sort of this idea of like code, code test coverage has existed for a long time.
147
You actually want the same thing for agents.
148
It's like agent coverage.
149
Like how much context?
150
How can you measure the amount of context that your agent has on the systems that it's it's orchestrating over?
151
The impressive thing is oftentimes these models can like, do a bunch of really, really smart things without having any of that context.
152
But if you give it the context, here's why this system was built this way.
153
Here's the chat threads where the engineers talked about, you know, the design trade offs or the meeting notes from the from the design review for this UI feature.
154
So you have that context.
155
The more of that context and the more coverage that exists for the actual software, the faster you can run.
156
And the best case is you actually need a system that's like continually updating that context that's being created about the software.
157
And I think it's a new I think I don't think there's a ton of startups thinking about this, but it's an interesting area of like, somebody should build that company.
158
I feel like it's very it'd be very interesting and it needs to live in the code too.
159
That's the other thing, because the agent needs to go, I'm, I think it needs to actually go there and like one, one really quick example of this is like as agents go and create more software, the artifact in like in anti-gravity.
160
And we use antigravity internally, and I use it outside of Google to the artifact that gets created is like this plan and this walk through and all this like checklist of like, here are the 50 things I did.
161
Here are the test that I ran.
162
When you actually commit the code, all that goes away.
163
So like I as somebody reviewing even going back to like where's the bottleneck?
164
Move to the code review process looks completely different than the fact that I just created all these artifacts that actually show the the proof of work is now different.
165
The proof of work for developers used to be creating code, passing the set of tests that were running at CI, and then that was like sort of it.
166
And I think the proof of work is now different because the bottleneck is not creating code.
167
Yeah, I've seen people experiment with spectrum and development frameworks where they then in the end, they trust the process and the guardrails they've built around not just agent, but also built around the harness capabilities, specifically making making it explicit some of the things they want.
168
And then in the review, reviewing the spec that is then also committed as part of the change, which I think is fascinating, I love it, I feel like it's the, the, my main takeaway is like there's there's so much interesting innovation that's happening in this way that like was not happening three years ago.
169
I feel like we all sort of like were, you know, this is how software gets built, whatever the, whatever the way is that the company was operating.
170
That's how software gets built.
171
And I feel like now that there's so much disruption happen, people are like, oh, let's try ten different things and we'll see.
172
And like maybe it is spec driven development that's going to be the thing.
173
Maybe it's something else.
174
So it's cool to see the level of experimentation.
175
I have so much fun.
176
Just like reading about what teams and are doing to to try out things.
177
Yeah, I feel like a kid in a candy store and like you like a couple years ago I was responsible for product.
178
I always wanted that role, being responsible more from a vision, more high over perspective.
179
And then things just accelerated and I got the biggest FOMO I have to go back to hands on.
180
And now I have a new role, which is more kind of productivity based.
181
And how do we level up our whole engineers entirely?
182
And then there are different challenges, right?
183
Some people are they don't really mind as much.
184
They like it even.
185
And some people really take pride in the craft that they have built in this, which is also the the writing code is a big component of that.
186
And that's slowly going away. Yeah.
187
To the to them I say, well, like there's still the part that is personal hobby projects where you can always do that, get that fulfillment.
188
But there is kind of a strong narrative.
189
That generation is just really what agents are good at and the engineering capabilities, they are kind of going more high over, and we are stacking things to make this work right.
190
We have agents, we have harnesses, we are building around that.
191
So it's a fascinating time. It is fascinating.
192
I feel this myself too.
193
I used to get the thing that got me excited about learning how to build software was like the ability to solve problems.
194
And I think if I go back to, you know, like computer science education, I think like independent of like clicking a bunch of keys on a keyboard is, is about sort of like a way of it's like a way of seeing the world.
195
Actually, I draw this analogy to like the, the legal system when you if you haven't studied the legal system and like have a deep understanding of how law works, you see the world in a way.
196
They're like, oh, there's a bunch of laws in a vacuum, and maybe I follow a speed limit here and there, and I have to pay my taxes, otherwise something's going to happen.
197
But you sort of don't have this depth of appreciation of like, actually, how does how do all of these complex systems work?
198
I think about and when you have that appreciation, you go about the world in a specific way.
199
You see the world in a specific way.
200
Software is the same thing, I think, like because I study computer science, because I understand how systems work, I see the world in a specific way.
201
The fact that now, today, I'm not the one who's like typing the keys.
202
I think doesn't actually diminish the the fact that there's alpha and seeing the world in that way in a lot of cases.
203
And so the abstraction layer changes.
204
But actually the skill of solving problems and actually very acutely, like the art of building software is the art of, you know, the code doesn't run, there's a problem, there's a bug, this thing, it's like almost like a building resilience in software engineers who are like trying to tackle all these really complicated problems and thinking about things in an interesting way is like the art of thinking, the art of, you know, again, solving problems.
205
That's such a useful skill.
206
Like, it's so, so I'm very I'm very bullish for like both like computer science education, but also like people who have this ability in the world.
207
Because if you can solve problems, you can do the world is filled with problems to be solved, which is exciting.
208
Yeah, I, I recently had this thought and it was because of one of the demo booths.
209
Right. The demo was you've got your own game, and I asked a lot of questions on kind of what happened under the hood, and they said they're going to release it in a month or so.
210
Open source, I can play around with it.
211
But in essence, I could just put my thoughts on paper and a game rolled out.
212
It took a little bit of a back and forth, but the outcome was there.
213
And then I felt this kind of like, I'm happy with how my career flew.
214
I'm happy with where I'm at now, but I am a little bit jealous about this newer generation because I feel like I think in constraints.
215
Right. And as a kid I had that less and less.
216
So if all of a sudden I can, for example, my little brother or my cousins, I can put them in front of the system and say, let's design a game.
217
I am sure they will be way more creative than I can be, because I now think in constraints, this is what you have to reset.
218
And I feel like this.
219
This is this is the hardest thing as humans and I fall, I'm I'm saying this to you to remind myself that I need to do this.
220
But like the every two weeks, every three months, every six months, what's possible changes.
221
And I frame this to people and like you have to reset your level of ambition and I've there's a double edge of this and I'll give this for like personal projects.
222
I've reset my level of ambition on personal projects so much that I'm like, my bar is now.
223
This is like I'm basically building a company.
224
Like if I can only companies everywhere, mini company that I'm going to go after.
225
And so I'm like, okay, if this isn't a mini company, like I probably shouldn't do this because like, it's not ambitious enough, but like that is that is the level of ambition that I think you can actually have.
226
And like the crazy thing is, I was always personally somebody who, like, wanted to who like you, I'm sure, who's like wanted to be able to build something ambitious.
227
And I was like, I just couldn't like, I never had enough time.
228
I couldn't actually, you know, I wasn't good enough software engineer.
229
I didn't have the right team, whatever it was.
230
And that's now completely changed.
231
And it is like it feels very empowering.
232
Yeah. For me, the the thing that will give people an edge, right.
233
All of a sudden, if you're looking for a job or you're looking to level up specifically a portfolio right now, doing really cool things is what will give you an edge.
234
I feel like more easily your foot in the door.
235
Do you also see that from a hiring perspective or the things you've been involved in?
236
Yeah, I love this proof of work set up, which has always made hiring a little bit easier when you have this proof of work.
237
And I think like actually open source historically to the original thread of our conversation, I think is a was always a great example.
238
So I love the open source community and why I spent like so much of my early career doing open source, because it was it was permissionless in many ways, like getting a job is like or an internship.
239
Your first internship doing software engineering is like convincing someone to let you change to like, contribute to their code base.
240
And the coolest thing in the world is open source.
241
I could just show up to anyone's code base and ideally in a non annoying way, like contribute something meaningful and actually become a part of this thing without needing them to like hire me.
242
And I still think that's like such an empowering force.
243
And now it's even more significant than that is like, I don't even need to go to it.
244
You still could go to an open source project, but like, you can actually just go build the project yourself and like, you could be in the driver's seat of the whole thing and the story and the narrative and the problem you want to solve and the way of bringing that thing to the market.
245
It's very interesting to see that that transition.
246
And it does feel it does feel empowering.
247
Yeah. The how you do that for me is incredibly crucial, right?
248
Because I feel like I learn a lot from it.
249
But I'm so curious, like, I want to know intricacies and I ask questions and that's where I get my knowledge.
250
You can also just go autopilot. No, no.
251
You build something, you don't know what it is.
252
You can go autopilot.
253
And then there's the best quote, the best sort of the quote of the era, which I'm going to get on a t shirt or something or put up a poster, will end with that.
254
The mascot of the poster in my room, which is sort of you can you can outsource intelligence, but you can't outsource understanding.
255
And so there's so many things.
256
There's a there's a, there's nuance of a line to walk of in what cases, what can you build where like it's actually fine to outsource both of those.
257
But like you go and build a product and you put real users and then you don't understand how it works.
258
Like you probably it's probably a recipe for bad things to happen.
259
So you could, you know, take advantage of the fact that you can outsource intelligence, don't outsource understanding.
260
I think there's a ton of alpha still on that.
261
Logan, thanks so much for coming on. This is a blast.
262
Thank you for coming to IO and having this conversation.
263
Thanks for having me, man. This was a blast.
264
I love it. Cool. That's it.
📺 ช่องเดียวกัน
✨ วิดีโอแนะนำ
C12
129 ประโยค
How to Become a Great Software Developer — Best Advice from Top-Notch Engineers
Business EnglishInterview EnglishUniversity Students
C11
28 ประโยค
Gemma 4 Just Released - Whats In? In 2026!
Business EnglishUniversity StudentsWorking Adults
C1762 ประโยค
Building Anthropic | A conversation with our co-founders
Business EnglishUniversity StudentsWorking Adults
B23
62 ประโยค
Day In my Life as a Software Engineering Intern at Google
Business EnglishInterview EnglishUniversity Students
B21
196 ประโยค
I cloned 3 apps and now make $35K/month
Business EnglishInterview EnglishUniversity Students
C12
20 ประโยค
Is prompt engineering dead? Advice on optimizing AI interactions | Amazon Web Services
Business EnglishUniversity StudentsWorking Adults
B21
22 ประโยค
I'm an ex-Google interviewer. You're doing LeetCode wrong.
Business EnglishInterview EnglishUniversity Students
B2278 ประโยค
Fastest way to become an AI Engineer in 2026
Business EnglishInterview EnglishUniversity Students
B22
8 ประโยค
Google product manager behavioral interview (Top 5 questions)
Business EnglishInterview EnglishUniversity Students
C11
218 ประโยค
Next.js 16.3 got good (if you care)
Business EnglishUniversity StudentsWorking Adults
C11
315 ประโยค
how AI broke the SWE Career Ladder
Business EnglishUniversity StudentsWorking Adults
ทำไมการฝึกพูดกับวิดีโอนี้ถึงสำคัญ?
การฝึกพูดภาษาอังกฤษกับวิดีโอนี้ช่วยให้ผู้เรียนได้สัมผัสกับการสื่อสารที่เป็นธรรมชาติและมีความหลากหลาย โดยเนื้อหาในวิดีโอเกี่ยวกับวิศวกรรมซอฟต์แวร์แสดงถึงการพัฒนาศักยภาพในการสร้างสรรค์และการแก้ปัญหาที่เกิดขึ้นในชีวิตประจำวัน การฟังและพูดตามจะช่วยให้ผู้เรียนเข้าถึงศัพท์ที่ทันสมัยและวลีที่ใช้บ่อยในวงการเทคโนโลยี สามารถนำไปใช้ในการสนทนาหรือการสัมภาษณ์งานในอนาคตได้
ไวยากรณ์ & วลีในบริบท
- “solve a problem”: การใช้วลีนี้ช่วยเน้นถึงการแก้ไขปัญหา ซึ่งเป็นหัวใจของวิศวกรรมซอฟต์แวร์
- “meet developers where they are”: การสื่อสารความเข้าใจในความต้องการของนักพัฒนา ช่วยให้เข้าใจการทำงานร่วมกันได้ดีขึ้น
- “feedback from developers”: การใช้คำว่า “feedback” ช่วยให้เห็นถึงกระบวนการพัฒนาโปรแกรมที่มีการปรับปรุงตามความคิดเห็นของผู้ใช้
กับดักการออกเสียงทั่วไป
ในวิดีโอนี้มีคำบางคำที่อาจทำให้เกิดความยากในการออกเสียง เช่น “anti-gravity” และ “integration” คำเหล่านี้มักมีเสียงที่ซับซ้อนและอาจทำให้ผู้เรียนเกิดความสับสนได้ นอกจากนี้ การออกเสียงที่ถูกต้องจะช่วยให้ผู้เรียนสื่อสารได้อย่างมั่นใจมากขึ้นและสร้างความประทับใจในบทสนทนา ทำให้การเรียนภาษาอังกฤษจากยูทูปมีประสิทธิภาพมากยิ่งขึ้น
การฝึกพูดด้วย shadow speech จากวิดีโอดังกล่าวไม่เพียงแค่ช่วยเพิ่มความคล่องแคล่วในภาษาอังกฤษเท่านั้น แต่ยังทำให้คุณได้เรียนรู้บริบทที่ใช้ในโลกของซอฟต์แวร์และเทคโนโลยีอีกด้วย ดังนั้นแนะนำให้ทดลองใช้ shadowspeaks ในการฝึกอีกด้วย!
ไวยากรณ์ในวิดีโอนี้
โครงสร้างที่ผู้พูดใช้บ่อยที่สุด พร้อมคำพูดจริงจากวิดีโอ:
| โครงสร้าง | ในวิดีโอ |
|---|---|
| “used to” used to + กริยา — นิสัยหรือสภาพในอดีตที่ตอนนี้ไม่เป็นแล้ว | used to be · used to get |
| Present perfect have/has + กริยาช่อง 3 — เหตุการณ์ในอดีตที่ยังเกี่ยวข้องกับปัจจุบัน | have changed · has also never been · we've been |
| Passive voice be + กริยาช่อง 3 — เน้นสิ่งที่เกิดขึ้น ไม่ใช่ผู้กระทำ | is generated · being built · are involved |
| Relative clauses who / which + อนุประโยค — ข้อมูลเพิ่มเติมเกี่ยวกับคนหรือสิ่งของ | API, which is · somebody who was · role, which is |
เทคนิค Shadowing คืออะไร?
Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ