쉐도잉 연습: The 7 phases of AI-driven development - 영상으로 영어 말하기 배우기

연습 모드 선택

각 모드는 전체 화면 연습실로 열립니다.

104 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

What's up friends, I'm going to keep this short and sweet.

I have identified seven phases of development with AI.

In other words, as you're working through coding with your AI coding assistant, in my case Claude Code usually, then these are the seven phases you should be thinking about for shipping great work.

The way you achieve these phases is kind of up to you.

There are many different implementations of it, but these are the ones that I have understood to be common across lots and lots of different approaches.

Whether you're doing Ralph loops like I mostly am, whether you're doing GSD, whether you're using spec kit, you are probably going to be using these seven phases.

If you dig this stuff and you believe that engineering fundamentals are really important in the AI age, then guess what?

So do I.

And this is what I cover and elaborate on in my newsletter.

This is not for vibe coders.

We are people that are serious about AI engineering and serious about building applications that are built to last.

So if that sounds like you and you want to improve your skills, then this is the place.

But without Without further ado, let's go into the list.

Phase 1 we start with the idea.

You have some kind of idea, some reason that you are invoking this progress, something that you want the AI to do for you.

This might be that you have an entire app idea that you want to build.

Or you might just have a narrow thing that you want to complete within the codebase that you're in, like a bug fix or a feature.

I also count refactors as part of this too, so if you have a codebase that you need to refactor then this process will work for you too.

This idea can be as small and as big as you like.

We can expand this idea and this process can take very, very large ideas and turn them into reality.

Or it can be teeny, very narrow and very focused.

Doesn't matter.

Now just to give you a glimpse of the future setup here, the idea is going to be turned into a set of tickets which a kind of AI is going to complete.

Now that set of tickets might end up being lots

and lots of different kind of like AIs working at once

or maybe just a big list of tasks that the AI is going to complete sequentially.

So if this idea involves any kind of research here, any kind of like difficult explore phases as part of building the code,

then you may want to include a research phase now.

For instance, if you're doing like a Stripe integration or maybe integrating with an API that's not very common, then you might want to create an asset

that kind of takes all of the research about

that thing like based on your idea and kind of caches it

and puts it inside the repo or somewhere that your agent can access.

Essentially, every time your agent is doing work, it might need to explore the repo in a fresh context window.

And if that exploration is difficult, so it's in an external API or it's somewhere that's hard to access,

then you'll want to cache it in a research.md asset and you'll definitely want to run a research phase at this point.

The next step after research is to get to prototyping.

Now in the prototype stage we're still not really sure what we're actually building on even maybe why we're building it.

Prototyping is really important if you need to impose your taste on the outcome.

In other words, maybe you need some UI that needs to look a certain way or behave a certain

you're not quite sure which one to do.

What I tend to do is just chuck up a bunch of different ideas on a throwaway route, which is kind of like the LLM showing me all of

the different ways it can think of to build out the prototype.

I then iterate on the prototype inside a couple of sessions and say, okay, no, that one looks like the best.

I found that doing this early is absolutely essential

because then you can actually commit the prototype to your codebase

and then make that available to the agent when it actually goes to implement it.

The next step, we are in step four now, is to create a PRD.

Now that we understand a bit more about the external APIs that we're using in the research phase, now that we understand a bit more about the prototype and we've actually seen some code,

it's time to start actually properly describing the destination.

We should now feel confident in ourselves that we can kind of understand the end state, what we're trying to create at the end.

We won't know all of the implementation decisions yet, we will just kind of know the basic stuff

that the user is going to see and the way that it's going to behave.

We don't have to call this a PRD by the way, this is a PRD is a product requirements document, but really it's just some kind of document that describes the end state of where we're going.

Now in the process of creating this end state, we really need to hammer out the design.

And this means we need to prompt the agent to absolutely grill us walking down every part of our decision tree.

I have a writer PRD skill that is purpose designed for this, which I will link to below if you're interested.

But once we've created the PRD, then it's time to actually start breaking down the PRD into some kind of implementation plan.

For those of you who are not developers, or you've never used a Kanban board or a Jira board or anything like that,

a Kanban board is just a list of tickets that have blocking relationships between them.

We're essentially just describing the work that needs to be done.

So I then have a separate skill for turning my PRD into separate issues.

We could create a single sequential plan that turns the PRD into like actual code, but with a Kanban board you actually get to parallelize really effectively.

And so I can just literally go on my Kanban board, all of the tickets that aren't blocking and spin up an agent for each one and get it to resolve it.

But of course what I'm starting to talk about here is execution.

So in some kind of loop here run a coding agent to execute all of the tickets on the Kanban board.

Most times you won't need to parallelise this, most times a sequential agent just working through each ticket will be enough.

And for me this is a Ralph loop which works really really effectively with this setup.

And I'll drop some links below on writing about Ralph that I've done.

once you've done with execution and you've got a completed asset for you to actually look at,

then you get the agent to create a QA plan for the human to QA the completed work.

And what this usually results in is more tasks in the Kanban board and going through the execution loop again.

So you will tend to loop these last three steps quite a few times until you iterate towards a perfect product.

And QA here also involves a human actually going and reading the code that has been produced during the execution loop.

That might not always be needed, especially if you're using a kind of gray box architecture that I've talked about in previous videos.

But overall, these seven phases are the things I'm thinking about whenever I'm working with an AI agent.

We start with the idea, some kind of app or feature or refactor.

If we know there are external dependencies and difficult to execute explore phases, then we cache it in a research phase.

And by the way, this research generally only lives for the lifetime of this sprint, essentially, or the lifetime of the idea that we're imposing on the app.

The reason for that is that research can go out of date, or it can just rot away, essentially, and actually cause our agent to take a wrong turn where it's not needed.

If I need to impose my taste, then I will use a prototype here.

So I will really just sit with an agent, human in the loop, to hash out some ideas.

This is not just for design as well it can be for software architecture too

or let's say testing something out with an external service.

This is an essential step because by the time we get to the PRD it's a little bit too abstract.

You really need concrete feedback first.

Then I write the PRD which is the documentation, the spec for where we are going.

Next I make a kind of understanding of the journey towards the PRD by turning it into a Kanban board.

I generally use GitHub issues for both the PRD and the Kanban board by the way, it's just an easy thing I've found.

Although GitHub doesn't have yet a kind of built in way to represent blocking relationships between tickets, so you might be just better off with something like linear which does.

Once the Kanban board is all ready and set up then I execute it in some kind of loop, for me that's a Ralph loop.

You could also I suppose do execution human in the loop style where you sit and execute the tickets individually.

But I generally find with all of this set up, with the research, with the prototype with the Kanban board with the PRD helping it, you can totally run this execution loop AFK and the results will be really good.

And to make sure

that they're really good we then enter a QA phase where we get the agent to produce a QA plan.

Then a human, yes a human, yep we're here, actually walks through and QAs the completed work

and then produces more tickets for the Kanban board which then goes and are executed, more QA, you get the idea.

But what do you think about this?

What did I get wrong and what am I missing here?

I imagine these phases will grow to 8 phases and 9 phases as I get more ideas.

100

There's no explicit mention of code review here really, I suppose I could do that as part of the execution flow.

101

I suppose maybe it comes under QA, but it's definitely an essential step to producing good code.

102

Either way, you can tell that I care about good code

103

and if you do too then you should check out my newsletter.

104

But whether you sign up or don't, thanks for watching and I'll see you very soon.

앱 다운로드

유창하게 말하는 데 필요한 모든 것

AI 발음 평가문장마다 점수 확인

IPA 발음 연습모든 소리 마스터

단어 학습나만의 단어장 만들기

단어 게임놀면서 외우기

QR 스캔

Download on theApp Store Get it onGoogle Play

같은 채널

New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

Business EnglishUniversity StudentsWorking Adults

How to actually force Claude Code to use the right CLI (don't use CLAUDE.md)

Business EnglishUniversity StudentsWorking Adults

Most devs don't understand what agents are

Daily ConversationUniversity StudentsWorking Adults

Most devs don't understand how LLM tokens work

Business EnglishUniversity StudentsWorking Adults

New Skills! /handoff, /prototype, /review and /writing-* | Skills Changelog

Business EnglishUniversity StudentsWorking Adults

FOR YOU

맥락 & 배경

이 비디오는 AI 주도의 개발 과정에 대한 내용을 다루고 있습니다. 발표자는 AI 코딩 도우미를 활용하여 개발을 진행하면서 겪는 다양한 단계를 설명하며, 각 단계를 통해 어떻게 효과적인 작업을 수행할 수 있는지를 공유합니다. 특히, AI와의 협업에서 눈여겨봐야 할 여러 가지 점과 함께, 기본적인 엔지니어링 원칙이 AI 시대에도 여전히 중요하다는 메시지를 전하고 있습니다. 이러한 배경 지식을 바탕으로 영어 회화 연습과 관련된 활용도를 높이는 방법을 알아보겠습니다.

일상 소통을 위한 상위 5개 구문

“이것을 진행하기 위해 아이디어가 필요해요.” - 아이디어의 중요성을 강조하며 시작하는 문장입니다.
“프로토타입을 만드는 과정이 매우 중요합니다.” - 개발 과정에서 빠르게 시각적 결과물을 만들어 보는 것을 설명합니다.
“연구 단계에서 우리가 사용할 외부 API를 이해해야 합니다.” - 외부 자원에 대한 이해가 필요하다는 점을 강조하는 구문입니다.
“서로 다른 아이디어를 시도해 보는 것이 중요해요.” - 다양한 비전을 시험해보는 것의 중요성을 나타냅니다.
“우리는 최종 결과에 대해 자신감을 가져야 합니다.” - 자신감을 가지고 목표를 명확히 하는 것이 필요하다고 설명합니다.

단계별 섀도잉 가이드

이 영상을 통해 영어 회화 연습을 위한 효과적인 방법을 배워보세요. 영상의 내용을 섀도잉하기 위해 다음 단계를 따라 해보세요:

전체 내용을 이해하기: 영상의 주제와 간단한 내용을 먼저 파악합니다. AI 개발 단계의 흐름을 이해하세요.
구문 반복 연습: 위에서 언급한 5개 구문을 반복적으로 읽고 발음합니다. 차근차근 자연스럽게 발음해보세요.
섀도잉 실습: 발표자의 발음을 따라 말해보세요. 발음의 억양과 리듬을 최우선으로 고려합니다.
자기 목소리 녹음하기: 자신의 발음을 녹음하고 들어보세요. 차이점이 있다면 개선해야 할 점을 파악합니다.
피드백 받고 반복하기: 스스로 혹은 친구에게 피드백을 받고, 부족한 부분을 보완하여 반복 연습하세요.

이 과정을 통해 유튜브 영어 공부를 보다 효과적으로 할 수 있으며, 영어 발음 교정에도 큰 도움이 될 것입니다. 잊지 말고 꾸준히 연습하세요!

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때	have identified · have understood · we've actually seen
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	are built · be turned · be done
관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보	people that are · route, which is · PRD which is

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: The 7 phases of AI-driven development - 영상으로 영어 말하기 배우기

연습 모드 선택

앱 다운로드

같은 채널

New Skills! v1.3 brings /pr, /implement-spec, and /retro

mattpocock/skills: A complete AI Coding workflow, end-to-end

I was an AI skeptic. Then I tried plan mode

/wayfinder: Nothing is too big to plan anymore

New Skills! v1.2 brings /wait-what, /writing-for-agents, and fixes /grill-me

Learn anything with the /teach skill

5 Claude Code skills I use every single day

Can Cursor's HARDCORE Review Skill Stop The Slop?

New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

How to actually force Claude Code to use the right CLI (don't use CLAUDE.md)

Most devs don't understand what agents are

Most devs don't understand how LLM tokens work

New Skills! /handoff, /prototype, /review and /writing-* | Skills Changelog

추천 영상

Design Thinking 101

Be Better than AI: 8 Highest Value Skills to Learn Now

Rapid Engineering With AI

AI Concepts Every Product Manager Should Know in 25 Minutes | Crash Course

Incremental Cooking in UE 5.7: A Dive Into the UE Cook Pipeline | Unreal Fest Chicago 2026

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

How to Become a Great Software Developer — Best Advice from Top-Notch Engineers

Understand AI in 14 minutes – with Anthropic's Chloe Lubinski [ARC 2026]

I've Changed My Opinion On DEVELOPERS Vibe Coding

I Wrapped an API Into a Real SaaS (full build / step-by-step)

맥락 & 배경

일상 소통을 위한 상위 5개 구문

단계별 섀도잉 가이드

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법