跟讀練習: They want mediocre developers... - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

133 句
如果句子過短或過長,請點選 Edit 進行調整。
1
I miss the good old days when technical debt
2
and student debt were the only debts we had to worry about in the software world.
3
Looking back at it, technical debt was actually quite fun.
4
We would take shortcuts to move faster,
5
ignore best practices to meet a deadline,
6
or delay updating a library because we were in no mood to work through the side effects.
7
The worst that could've happened was
8
that you would end up paying for it later through increased complexity in systems that nobody wanted to touch.
9
But ultimately, this increased complexity would increase your job security because
10
if If you were the only person who understood a messy part of the system,
11
you would suddenly become very hard to replace.
12
This is why for the past 20 years,
13
software engineering has been a pretty nice gig,
14
with a lot of perks and more than decent paychecks.
15
And I'm not making this video to tell you that all these are going to end,
16
but I want to discuss a new emerging kind of debt which will actually make our lives much more difficult.
17
Adios Money recently posted about a new concept called Comprehension Debt
18
and in this Monday morning review will look at the importance of being able to think
19
and solve problems in the generated code era.
20
Comprehension debt is the growing gap between how much code exists in your system
21
and how much of it anyone on the team can genuinely explain.
22
At first, this doesn't look like a problem,
23
since most AI-generated code looks really clean at first and it might look like all the best practices are being followed.
24
But underneath that, something subtle starts to shift because the understanding of the system begins to slowly degrade.
25
In a recent study, engineers were asked to learn a new library.
26
Some of them used AI to generate solutions,
27
others used it more as a guide to explore concepts and ask questions.
28
Both groups completed the task in roughly the same time,
29
so from a productivity perspective, everything looked identical.
30
But when they were tested afterwards,
31
the group that relied on generation performed significantly worse,
32
especially when it came to debugging.
33
And debugging is where things become very real very quickly.
34
If you've been involved in software for a while,
35
you probably know that reading and understanding code at a deep level is one of the most difficult parts of the job.
36
I'm not talking here about going through some random syntax filled with for loops and if statements.
37
I'm talking about complex implementations,
38
which have interactions, implicit assumptions,
39
and behavior that only makes sense once you follow the entire execution path end-to-end.
40
This part is so difficult that you'll go through code you wrote yourself six months ago
41
and you'd still be confused trying to reconstruct what you were thinking at the time.
42
When everything works, speed feels like the most important metric.
43
The moment something breaks, the only thing that matters is whether someone can explain what the system is doing and why.
44
And, if I have issues understanding my own code from six months ago
45
and I can proudly call myself an average developer with a weird accent and a copied YouTube channel,
46
I expect
47
that most of us will have a lot of issues understanding thousands of lines of code generated in a couple of minutes.
48
For a long time, writing code and reviewing it acted as a natural bottleneck in development.
49
It slowed teams down, but it also forced engineers to read code written by others,
50
to question decisions, and to build a shared understanding of how the system behaved.
51
The process was one of the main ways knowledge spread across a team.
52
With AI-generated code, the volume changes the nature of that interaction.
53
Code is produced faster than it can be meaningfully reviewed,
54
and because it is usually clean and well-structured,
55
it gives off all the signals that historically indicated quality.
56
And the AI labs are telling you to ignore the problem.
57
You spend your tokens generating code,
58
and then they provide you the tools to review that generated code for the convenient price of $15-25 for each review.
59
In other words, the token sellers just want you to buy more tokens,
60
ideally hundreds of thousands of dollars worth of tokens.
61
I keep trying to avoid highlighting the absurdity of some of these CEOs' comments,
62
but they are making it very tough for me to ignore them.
63
screams trying to inflate the bubble more than focusing on quantity over quality.
64
Sure, you could easily spin up Todo apps in an endless loop to burn through $250,000 in tokens.
65
That would be completely pointless and will consume a few more million gallons of water,
66
but at least the billionaire Jensen Huang with his geeky leather
67
jackets will be happy to see his Nvidia stock keep going through the roof.
68
But I digress.
69
Back to the topic of comprehension debt,
70
there's also a more subtle failure mode that starts to show up in AI-heavy workflows.
71
When an implementation changes and the associated tests are updated to match,
72
the conversation quietly shifts.
73
Instead of asking whether the code behaves correctly,
74
you now have to ask whether the behavior itself is correct.
75
The test passing no longer answered the most important question.
76
As we discussed in last Monday's episode,
77
another common reaction is to rely more on specifications.
78
You define the behavior in detail,
79
review the specification carefully, and let AI handle the implementation.
80
On paper, this creates a clean separation between intent and execution.
81
In practice, translating a specification into working software involves a large number of implicit decisions that rarely get captured in full.
82
Data structures, edge cases, error handling,
83
and performance trade-offs all shape the final behavior in ways that are difficult to fully describe up front.
84
This year's DORA report also highlights this new emerging comprehension crisis.
85
In teams where engineering practices are already solid,
86
where workflows are clear, and where people have a strong mental model of the system they are working on,
87
AI tends to make everything move faster in a way that actually compounds quality.
88
Developers spend less time on repetitive tasks,
89
decisions are made with more context,
90
and the system evolves in a relatively controlled way.
91
But in teams where things are already messy,
92
where architecture has grown organically without much discipline,
93
and where understanding is fragmented across individuals,
94
AI scales all of those issues at the same time.
95
The same acceleration that helps good systems becomes a multiplier for bad ones,
96
and the difference between the two becomes much more visible.
97
What's interesting is that the report states
98
that around 90% of developers are already using AI in their work and more than 80% believe it improves their productivity.
99
But at the same time,
100
a significant portion of them openly admit that they do not fully trust the code that AI produces.
101
So you end up in a situation where developers rely on a tool daily,
102
move faster because of it,
103
and still carry a constant layer of uncertainty about what is actually being generated.
104
The DORA data also highlights something that reinforces this dynamic even further.
105
AI adoption correlates with higher throughput,
106
meaning teams are shipping more changes and moving faster through their backlog.
107
At the same time, delivery instability increases,
108
which means those changes introduce more issues into the system.
109
So basically, you move faster,
110
create more issues, you fix those issues faster,
111
and create even more issues.
112
Your KPIs go through the roof,
113
management has nice graphics to look at,
114
clients are happy to see results,
115
and token sellers are making a lot of money.
116
Everybody is happy and Jensen Huang gets richer.
117
If I'm being honest, I spent the past couple of months worrying about the future of software engineering.
118
AI code generation is far from perfect,
119
it has improved a lot in the past couple of months.
120
However, something feels off.
121
The AI labs are pushing these coding agents hard and we have to pay very little to use their models.
122
However, their computing costs are huge and they are very far from running a profitable business.
123
This is clearly the customer acquisition phase,
124
where their pricing is so low you can't ignore them
125
and their agents are slowly becoming an integral part of the software workflow.
126
And I believe that this comprehension debt is exactly what they need to make sure you can't really walk away later.
127
This is not going to happen overnight,
128
but imagine a world 10 years from now where most of the software engineers have lost most of their critical thinking,
129
problem solving and debugging skills because they are used to delegating all of it.
130
At that point, Anthropic could increase the cost of their agents to thousands of dollars per month
131
and there would be little we could do because most of the skills are lost,
132
we have no idea what our code actually does
133
and the jobs pipeline was destroyed when we decided AI can do a better job than juniors.

下載應用

流利口語所需的一切

AI 發音評分逐句打分
音標練習掌握每個音
詞彙學習建立你的詞庫
詞彙遊戲邊玩邊學

同頻道

FOR YOU

推薦影片

背景與背景資訊

在當今的科技世界中,軟體開發不僅僅是編寫程式碼,更是解決問題與理解複雜系統的重要過程。背景中的講述者提到了一個新興的概念——理解債務(Comprehension Debt),這意味著程式碼的數量與團隊對這些程式碼的真正理解之間的差距在不斷擴大。在這個影片中,講者邀請大家關注這種變化對軟體工程師的影響,尤其是如何提高他們在面對日益複雜的系統時的理解力。

日常溝通的五大短語

  • “技術債務” - 描述在軟體開發中常常因為時間緊迫而出現的妥協性決策。
  • “解決問題” - 在軟體開發中,能夠清楚地說明系統的行為是至關重要的。
  • “生成程式碼” - 隨著 AI 技術的興起,自動生成的程式碼看似整潔,但可能隱藏著理解上的困難。
  • “除錯” - 程式碼執行出現問題時,除錯成為開發者必須面對的挑戰。
  • “共享理解” - 團隊成員需要相互理解系統的行為,以確保高效協作。

逐步跟讀指南

為了掌握這段話題中的重要內容,語言學習者可以採取以下步驟來挑戰影片中的難度。

  1. 選擇影片並快速瀏覽內容,瞭解大致的主題和結構。
  2. 使用shadowspeak的方法,將影片的文本內容打印出來或準備好隨時檢視。
  3. 逐句播放影片,嘗試跟隨說話者的節奏,集中於抓取每個短語的發音和語調。這不僅可以幫助你提高英語發音,還能增強理解力。
  4. 記錄下每一句話並反覆練習,直到能夠流利地複述。在這個過程中,反覆比較自己的發音與原聲,比如用shadowspeaks的方式進行自我對照。
  5. 最終嘗試完整複述影片內容,而不僅僅是區域性。這樣可以增強整體的語言能力和思維的連貫性。

通過這些方式,你不僅能在電子裝置前提高自己的英語口語練習和發音水平,還能對軟體開發中的複雜理解有更深的領悟。堅持下去,你會發現自己在真正理解與應用英語的過程中收穫滿滿!

影片中的語法

說話人最常用的結構,並附上影片中的原話:

結構影片中的用法
被動語態 be + 過去分詞 — 強調發生了什麼,而不是誰做的being followed · were asked · were tested
現在完成時 have/has + 過去分詞 — 過去發生但與現在仍有關聯的事has been · you've been involved · has grown
定語從句 who / which + 從句 — 補充說明人或事物person who understood · debt which will

什麼是跟讀法?

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧,最初開發用於專業口譯員的培訓,並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大:您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同,跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性,語調,節奏,連讀,聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →