From Issue to Merge with AI — 4-Week AI-Native Development Challenge, Cohort 2
A 4-week AI-native, execution-focused challenge that codifies project rules, tool permissions, and acceptance tests, then iterates from issues to validated GitHub PRs.
🚀 Toss and POSTECH graduate | Working backend developer (9+ years) 🎥20K YouTuber | Creates development content 📚 Inflearn instructor | 18,000+ cumulative students 👥 Runs a developer employment community (8,000+) 🧩 Contributor to numerous open-source projects (Gradle, Spring AI, etc.) 📝38 successful application processes and over 100 resume editing sessions on Kmong (5.0 rating)
I deliver vivid, real-world information in an easy-to-understand and logically structured way.
AI Native 4-Week Challenge · Free · First 100 Participants Only
DINGCO CHALLENGE · 4 WEEKS
Development that used to involve asking AI questions, transformed into a loop where we merge together within four weeks.
We turn project rules, tool permissions, and acceptance tests into code, repeating the process from issues through validated PRs. After four weeks, you’ll have an operations manual that your team can reuse as-is.
Free · First 100 people only
Created by Dingcodingco, with over 18,000+ cumulative Inflearn learners, an average satisfaction rating of 4.9, and experience helping applicants get hired by 38 companies
This challenge does not provide lectures or textbooks. It is an execution track where you prove what you already know or have learned independently through practical problems and GitHub PRs. Preparation before starting and submissions take place in a personal private repository created by Dingcodingco. It includes a Next.js·TypeScript·Tailwind blog project, with the mission solutions left blank.
A four-week execution track where you prove the concepts you’ve already learned through code, experiments, and explanations.
WHAT YOU SHIP
What You’ll Have Upon Completion
Project context by selected agent, recurring task workflows, and validation and blocking mechanisms
The collaboration loop from issues documenting permission boundaries to tested PRs
AI review and failure recovery, operational signals, and template app feature capstone
BEFORE
Each time, we rewrite a long prompt and manually check the results from scratch.
AFTER
The selected agent’s context, recurring tasks, and verification mechanisms remain in the repository and are repeated from the issue through a validated PR.
ACTUAL WORKFLOW
From application to review, in the order shown on the actual screen
You do not copy and submit a GitHub URL. The Dingco homepage guides you through preparing your personal repository, creating a mission branch and PR, and checking the detailed review.
1GitHub first, Discord lastAfter completing Kakao login and the preliminary assessment, we prepare your personal private repository and connect your Discord role and cohort channel at the end.2Complete missions in my private repositoryThe homepage guides you through creating a branch and PR titled “Create an operational baseline and validation PR with the selected agent.” You don't need to copy and paste the PR URL.3Review the 90-point score and specific evidenceCheck the strengths and areas for improvement identified by the automated checks and AI review in the Dingo detailed review and GitHub PR comments, then revise the same PR.4AI Native Challenge Cohort 2 Operations ChannelIndividual detailed reviews are not posted on Discord; only weekly summaries and operational announcements are shared.
The screen above is an example based on the actual operation UI and repository/channel rules. The repository name, cohort number, and review score vary depending on the participant and cohort.
4-WEEK ROUTE
Weekly missions that turn what you already know into tangible deliverables
Each week, submit implementation and experiments, tests and logs, the rationale behind your choices, and answers to the questions in a single PR. The questions are not homework requiring memorized answers submitted separately; answer them using the code you just created and the evidence it provides.
W1
Agent Operating Baseline
Build context, repeatable workflows, and verification mechanisms in the selected agent, and prove them through a small change submitted as a PR.
Weekly Integration PRCreate an operational baseline and verification PR with your selected agent
[Required] Choose one AI coding agent to use this week and document its tool name and version, the reason for choosing it, and where the following three capabilities are implemented in docs/agent-workflow.md: project context, reusable workflows, and verification or blocking mechanisms before and after changes.
[Required] Using equivalent functionality of the selected tool, provide the project structure, execution commands, rules, and completion criteria, and turn one repetitive task into a reusable command, skill, prompt, or workflow.
[Required] Connect one of the tests, linting, permission checks, or change-blocking as a verification mechanism, and deliberately make it fail or attempt a prohibited change to leave a captured output showing that it was caught.
[Required] Use the workflow you created to make a small code or test change in the template app, then submit a PR that passes npm test or Playwright validation.
[Optional extension] Reproduce the same capabilities in a second agent to compare the differences and porting costs.
Submission evidence · The selected agent, the implementation locations of the three common capabilities, and the mapping of equivalent functions · Code or test artifacts produced by the repetitive workflow · Output showing failures or prohibited changes caught by the verification mechanisms · Test-passing output for a small change and the PR link · Answers to Questions 1–3
함께 답할 근거형 질문 3개
What information about the project provided to the selected agent was insufficient in the general README alone?
How far did you delegate repetitive tasks and verification mechanisms, respectively, and where did you retain human review?
What mistakes did the verification mechanisms fail to catch, and how do you plan to address them next time?
W2
From the issue to a validated PR
Set the permission boundaries for the agent and external tools, then run through the entire cycle from the issue to a tested PR.
Weekly Integration PRUse the selected agent to go from an issue through to a validated PR
[Required] Record this week’s agent and the external tools used (GitHub, MCP, CLI, editor integrations, etc.) in docs/agent-workflow.md, and note the read/write scope and the points requiring human approval.
[Required] Create one feature issue in this repository, implement the feature on the feature/<issue-number>-<slug> branch, and then merge it into the common submission contract’s submit/<module>__<mission> branch. Since the PR being graded is the single PR opened by the homepage submission button from the submit branch, do not open a separate PR from the feature branch to the default branch. Record the links between the issue, branch, and PR, along with the acceptance criteria, in the submission PR description.
[Required] Pin the feature’s behavior with one Playwright scenario under tests/, and leave evidence of both the failure before implementation and the passing output after implementation.
[Optional extension] Have another agent review the work or proceed in parallel, and document the conflict-prevention boundaries and differences.
Submission evidence · selected agents · external tools · read/write scope and approval points · issue number, feature branch name, and a PR link with the PR template completed · one Playwright scenario under tests/ and the failure output before implementation and passing output after implementation · answers to questions 1–3
함께 답할 근거형 질문 3개
How did you distinguish between the points where read-only access was sufficient and those where write permissions were required for the external tools you used?
How did the agent’s output change after providing issue, branch, and PR acceptance criteria?
What does the Playwright scenario guarantee about this feature, and what does it still fail to guarantee?
W3
AI Review and Failure Recovery
Connect AI review, automated verification, and operational signals to detect and fix failures, then establish a trust boundary before merging.
Weekly integrated PRPractice the AI review and failure recovery loop
[Required] Have an agent review your changes this week, and document one issue they identified that a human might have missed or one sound judgment confirmed through validation, along with the code and tests.
[Required] Intentionally reproduce one failure case. Choose one of a test failure, runtime error, or invalid input, and leave the reproduction output, cause, and passing output after the fix.
[Required] Choose one signal to check first during operation and monitor it through logs, error tracking, test reports, or CI results. Define the signal’s normal and warning thresholds using numbers or clear conditions.
[Required] Record in docs/agent-workflow.md the role the selected agent played in recovering from this failure and the boundaries that were verified by a human.
[Optional Extension] Attach one of Docker, Sentry, Langfuse, CI/CD, or cloud deployment to automate monitoring or recovery. Services that incur costs are not required.
Submission evidence · AI review results and why people adopted or deferred them · Intentional failure reproduction, cause, and passing output after the fix · One operational signal and its normal/warning thresholds · Verification boundaries between the agent and humans · Answers to questions 1–3
함께 답할 근거형 질문 3개
Which of the issues identified by the AI review might a person have missed, and why did you adopt or defer them?
Among testing, review, and operational signals, which should have detected this failure first?
What signals and alerting thresholds would reveal an issue in production first?
W4
Template App Feature Capstone
Complete a full feature delivery loop from the user problem through success criteria, issues, implementation, testing, demo, and retrospective.
Weekly Integration PRComplete the full feature cycle from user problem to merge and demo
[Required] Choose one feature to add to this blog and fill in docs/prd.md with the user problem, measurable success criteria, user stories, functional and non-functional requirements, and out-of-scope items.
[Required] Break the PRD down into implementation-level issues and write acceptance criteria for each issue. Link the issue numbers and acceptance criteria so they can be tracked in the PR description.
[Required] Choose one feature from them to implement this week with the selected agent and complete its merge. Lock in the acceptance criteria with a scenario under tests/, and leave a short demo or capture showing how it works.
[Required] In docs/retrospective.md, document the bottlenecks that four weeks of automation actually reduced, the new bottlenecks it created, the differences if there was a reason for switching agents, and the personal dependencies that must be removed for team members to reuse it.
[Optional extension] Use docker-compose to launch the entire local stack or automate the demo and deployment through CI/CD.
Submission evidence · An issue documenting the problem definition, success criteria, user stories, requirements, non-scope, and acceptance criteria in docs/prd.md, along with the body of the PR that references it · The implemented feature’s tests/ scenarios and passing output, the merged commit, and a brief demo or screenshots · The reduced bottlenecks, new bottlenecks, and personal dependencies in docs/retrospective.md · Answers to Questions 1–3
함께 답할 근거형 질문 3개
Which of the PRD’s success criteria were actually verified by this implementation, and which have not yet been verified?
Among the context, recurring tasks, and verification mechanisms created in weeks 1–3, which actually helped this time, and which got in the way?
What still needs to be documented or removed for a team member to take over this repository as-is?
WEEKLY LOOP
Complete a week’s hands-on practice in a single PR.
Check the weekly hands-on problems
Complete the mission in your personal branch
Submit the code, tests, and explanation in a PR.
Check the automated tests and AI review
Modify the same PR and merge automatically
Check approved PRs and the official explanations
Reflect accumulated peer reviews and crew learning records
Submissions must be made using GitHub PRs only. AI-generated changes must pass accurate commits, tests, and reviews just like regular code. We automatically check whether the necessary evidence is included in the PR.
CREW ENGAGEMENT
We talk for just 20 minutes about the mission one-liner.
Starting from week 2, leave a brief comment on the PR, and the crew shares only blockers and alternative approaches.
From week 2, leave one comment on the mission When submitting a PR, describe what you got stuck on in 10–300 characters.
20 minutes at the time set by the team Tuesday at 21:15 by default, share only what you’re stuck on and alternative approaches.
The leader wraps up in 1–30 characters Starting in Week 2, completion earns the crew +5, separate from individual completion.
Team bonus activity Participants should not write a separate post beyond a brief comment on the mission. Crew +5 is separate from individual completion.
LIVE SESSION
Once live, we align on how to proceed together.
We will hold one live session during the challenge. We’ll align on the completion criteria and see on the spot how submissions flow on screen.
KICKOFF LIVE10/6(Tue) 20:00
60 minutes · Online
AI Native Challenge Kickoff Live
Overview of the 4-week process and completion criteria
At Tuesday’s kickoff, we’ll prepare the first mission branch and demonstrate submitting a GitHub PR after Wednesday’s start.
Live Q&A
The participation link will be posted in the Discord announcements before the start. Even if you cannot attend the live session, you can still find the completion criteria and submission methods on the Dingo website and in the Discord announcements.
CHALLENGE CONTRACT
Learn the concepts individually, practice and feedback together
This challenge does not provide lectures, textbooks, Notion pages, or bonus materials. You apply what you already know or have learned independently to real-world problems and prove it through GitHub PRs.
What the challenge provides
Weekly hands-on problems · Individual private practice repositories · Clear passing criteria · Automated checks and AI reviews · Peer comparison and completion records
Participants prepare
Basic concepts in the relevant field · Experience with Git and GitHub PRs · Time to practice each week · A willingness to independently reinforce concepts you lack
This course and textbook are not included in the challenge, and taking the course is not mandatory. Choose them only if you have gaps in certain areas in the pre-assessment or need to reinforce your understanding of the concepts.
Regardless of whether you applied through Inflearn, check the current cohort’s recruitment status using the “Recruitment & Participation Check” button above. Log in with Kakao through Dinko to secure your spot, and once all connections are completed, you’ll be ready to participate.
On the Dinko recruitment and participation confirmation page, select the current cohort and log in with Kakao to instantly create your challenge membership and secure your spot.
Once you pass the cohort-specific pre-assessment, the GitHub connection step will open.
If you connect GitHub first, checking your organization permissions and preparing a private repository for AI operations experiments will be scheduled automatically.
When you connect Discord, permissions for the AI Native Challenge-specific category and the announcements, reading materials, questions, and general discussion channels will be configured.
Create a submit/<mission> branch on the homepage, push the rules, automation, and execution evidence, then submit a PR with a single click.
The latest commit that passes automated checks and AI review is automatically merged by Dingco, and everyone celebrates together in the free channel. Security-sensitive or low-confidence results are handled after human review. In the crew Discord, members share questions and progress, while official reviews first prioritize passing PRs from the same crew; if there are none, they proceed with PRs from other crews in the same cohort. The leaderboard is reflected provisionally during the week and finalized after the deadline for the final cumulative review.
Read access for participants in the same cohort Personal repositories remain private, and participants in the same cohort may refer to them in read-only mode after the weekly results are made public. Write access is granted only to each participant’s own repository. Crews typically consist of 5–6 people, and the roster remains hidden until it is made public. Detailed score sheets are not disclosed; after the final scores are confirmed, only the winning crews that have given consent are featured in the Hall of Fame, with a GitHub badge and their public names. Registration closes at 19:00 on the Wednesday of the starting week. Tracks with a preliminary assessment require participants to pass it by the same time, and the crew rosters and dedicated Discord channels are revealed at 20:00. The official start and the release of the Week 1 mission take place at 21:00 on the same day. After that, a new mission opens every Wednesday at 21:00, and submissions close the following Tuesday at 21:00. Official reviews do not have to be completed immediately each week, but the required number of reviews, based on different weeks, must be completed by 21:00 on the Sunday after the final week. The Week 1 problem, personal repositories, and mission branches can be prepared in advance, and the PR submission button is automatically activated once my crew channel is ready. Participants whose GitHub–Discord connection is not fully set up will retain their assigned crew.
FIT CHECK
This is a good fit for these people, but not for these people.
Recommended for you
Those who want to establish both which AI coding agent to use and how to validate it.
Regardless of your role—development, planning, design, data, or otherwise—if you want to leave deliverables as GitHub PRs
People who want to turn AI automation into reusable rules and repository structures for their team
Those who want to manage not only speed but also testing, permissions, and recovery strategies.
Not recommended.
Those without experience using Git, testing, or running basic projects.
Those looking for a way to merge generated code as-is without verification
COMPLETION
We disclose the completion criteria before the start.
Submit all four weekly integration mission PRs over the course of four weeks.
Submit official reviews for passing PRs from three different weeks.
Preparation Before Starting
Submissions are made in a personal private repository created by Dinko. It contains a Next.js·TypeScript·Tailwind blog project, provided with the mission solutions left blank.
You may choose any agent, but the submission stack is fixed according to operational standards. Submissions using other frameworks are not allowed.
Each week, you must spend approximately 4–6 hours using your chosen agent to leave behind code, tests, and evidence of execution.
FAQ
Frequently Asked Before Participating
Is this the same program as the existing 10-week bootcamp?
No. This challenge is a separate track designed to complete one subject over four weeks. It only leads into the 10-week bootcamp if you need a longer project-based and job-focused program.
Are lectures or textbooks also provided?
No. The challenge provides weekly problems, a private practice repository, submission criteria, and a review loop. The accompanying course is optional prerequisite learning available for separate purchase, and enrollment is not required.
Can I submit through the website or paste a link?
We only accept submissions as GitHub PRs. However, preparing the repository, branch, and PR, as well as checking reviews, can be easily accessed through buttons on the Dinko homepage.
What will be made public on Discord?
We do not post detailed individual reviews on Discord; we only share weekly summaries and operational announcements. The shared channel for the second AI Native Challenge cohort is a space for reading materials, questions, open discussion, and operational guidance.
CREATOR NOTE
How to Turn an AI Agent into a Reusable Development Workflow
You can first check in the video what criteria to use to execute and validate this problem.