Building an MVP with AI is no longer difficult. However, most projects stop at the next stage. 👉 You’ve built the features 👉 But development doesn't continue Why does this happen? The problem isn't the code; 👉 It's because there is no structure that allows AI to work continuously. --- In this course, based on an existing project, 👉 We will cover the process of building a structure 👉 That allows AI to continue development on its own. --- Instead of simply using AI tools, we will: * Create a docs structure * Define the SSOT (Single Source of Truth) * Execute development on a per-ticket basis * Connect QA and iteration cycles 👉 To complete a single "AI Development System." --- Through this process, you will: 👉 Create a structure where development continues 👉 Even without a human manually coding. In other words, you can: 👉 Build and understand a development system 👉 That operates AI like a team. --- This course is designed for: 👉 Those who want to build a structure applicable to their projects immediately 👉 Those who started development with AI but found it difficult to sustain 👉 Those who want to move to the next level after "Vibe Coding" --- Beyond just learning, we provide an experience where you: 👉 Take action 👉 Build a structure that actually works 👉 And walk away with a framework you can apply to your own projects.
69 learners
Level Basic
Course period Unlimited
We are directly building a structure where AI continuously carries out development based on SSOT.
Through ticket-based development, you will experience the process of completing a service from start to finish.
You can understand this structure from a harness engineering perspective and apply it to practical work.
Because AI cannot remember context over the long term, consistency breaks down as tasks accumulate.
Because AI interprets ambiguous requests on its own, the results vary every time.
If development is repeated without verification and modification, the AI will continue to add code without any standards.
Harness Engineering means designing a development environment
so that AI can work stably.
Legacy environments, frequently changing requirements...
Therefore, practical application of
harness engineering must be different.
Immediately applicable to practical work
This is a method where humans handle ticket creation and QA, while AI performs the remaining implementation, analysis, and deployment.
Because humans establish the standards and verification while AI executes on a per-ticket basis,
you can achieve both stability and flexibility.
Who is this course right for?
Those who have experienced building an MVP with AI, only to have the project stall because subsequent development didn't continue.
Those who are using tools like GPT and Cursor but are experiencing issues with inconsistent outputs and increasingly tangled contexts.
Developers and teams who want to utilize AI as an actual development resource, rather than just a simple code generation tool.
Those who want to apply AI to an existing legacy project but feel overwhelmed about where and how to start
Need to know before starting?
There are no required prerequisites.
It will be easier if you have experience creating repositories and committing with Git.
It is helpful to have an understanding of simple web service structures (FE / BE).
It is good if you have at least some experience using AI tools such as GPT or Cursor.
This course does not cover specific technologies, but rather the structure of how AI performs development.
Career Verified
538
Learners
19
Reviews
4
Answers
4.2
Rating
2
Courses
As an engineer with over 25 years of development experience,
I have built a "structure where AI can continuously carry out development"
through a repeated process of building and dismantling MVPs directly with AI.
I am directly designing and operating an "AI development system that runs on its own," covering everything from
planning → development → QA → deployment
based on ChatGPT, Cursor, and Python.
It is not just simple vibe coding;
I am creating a structure where AI Agents can continuously perform development,
and I am validating this by applying it to actual services.
All
6 lectures ∙ (2hr 16min)
Course Materials:
All
10 reviews
3.8
10 reviews
Reviews 3
∙
Average Rating 4.3
Reviews 3
∙
Average Rating 5.0
Reviews 14
∙
Average Rating 3.7
Edited
1
It feels more like an SSOT lecture rather than Harness Engineering... While it's not technically wrong if you view Harness in a narrow sense... Even calling it an SSOT lecture feels like it's lacking in various elements. It seems more suitable as a fragmentary case study presentation at a conference; it doesn't feel like a lecture intended to actually transfer knowledge to someone. To be honest, the screen is so small I can't even see it. Regarding the individual .md files provided as lecture materials: The core is ssot.md. While multi-level control is an advantage, it consumes costs inefficiently due to increased context (token) usage. Although it claims to maintain the existing structure through SSOT after the MVP, it causes excessive technical debt, making future refactoring difficult. Rather than showing the "forest" of Harness Engineering that connects SSOT + SDD + TDD, it delivers only a single branch of a single tree. It seems to have more disadvantages than advantages, such as creating excessive documentation or causing confusion by jumping back and forth, making it easy to make mistakes. Furthermore, it feels like a lecture calling itself Harness Engineering through extremely unfriendly, fragmentary examples without any explanation of ticket units like Sprinter, Epic, Story, or Task (though if one already knew these concepts, there would be no reason to take this lecture).
Thank you for your feedback. I am revising my previous response to be more specific. It is true that the issues with screen readability and the increased token consumption due to the nature of the document structure are actual trade-offs that were not sufficiently addressed in the lecture. While the explanations for SSOT design and ticket design are covered in Section 2, it seems they did not meet the depth you were expecting. Regarding the technical debt portion, it is slightly different. The flow of the lecture is designed to have Cursor analyze the structure of the MVP, modify the SSOT based on those results, and then proceed to ticket-based development. It is a structure where the existing framework is not simply layered on top, but rather refined after analysis before being applied. However, it is true that this flow was not sufficiently communicated in the lecture. Since the concepts of sprint/epic/ticket were set as prerequisite knowledge for this course, it may feel unfriendly if approached without that background. I should have made the target audience clearer in the course introduction. Thanks to your specific feedback, I believe I can make the content much clearer next time.
Reviews 5
∙
Average Rating 5.0
Reviews 2
∙
Average Rating 5.0
Explore other courses in the same field!
25% off for new members
$32.90
25%
$42.90
![[Season 2] Spring AI in Practice: Developing Multi-AI Agent SystemsCourse Thumbnail](https://cdn.inflearn.com/public/files/courses/339915/cover/01kbqgcec3hb576vxxdf9ch76y?w=420)
![[Part 2: Basics] OpenClaw.AI Master Class: A Smartphone Remote Assistant Completed with Telegram and Vision AICourse Thumbnail](https://cdn.inflearn.com/public/files/courses/341372/cover/01kmphpdty1zyjv7qmfwj5qx25?w=420)
![[VOD] 6-Week Complete! High-Concentration Vibe Coding for Development Practice (Cursor AI, Figma)Course Thumbnail](https://cdn.inflearn.com/public/files/courses/338156/cover/01k4c77bftwd8ec4k0yakavbrc?w=420)
![[AI] Implementing Ideas with Prompts Only_Vibe Coding BasicsCourse Thumbnail](https://cdn.inflearn.com/public/files/courses/336725/cover/01jr2vbd3dr8hh1n4qn2jcyj02?w=420)
![[AI Practice] Understanding Diffusion Models through Prompt-to-prompt Paper ImplementationCourse Thumbnail](https://cdn.inflearn.com/public/files/courses/339089/cover/01k7chg2b60npdvpaykrypzmk7?w=420)
