Hi, I am a junior developer from Korea.
In my previous post, I wrote about why I built <code>harness-starter-kit</code>: I did not want to repeat the same project rules every time I opened a new Cursor, Claude Code, or Codex session.
This post is not a formal tutorial. It is a dogfood note about what I learned after applying the kit to real projects.
The biggest lesson was simple:
<blockquote>
The value of a harness is not that it makes an agent instantly smarter.
</blockquote>
<blockquote>
The value is that it helps the repository expose mistakes earlier and remember them.
</blockquote>
<h2>My Initial Expectation Was Not Quite Right</h2>
At first, I hoped that if a project had <code>AGENTS.md</code>, check scripts, decision records, and failure notes, the agent would simply make fewer mistakes.
Now I think that expectation was too simple.
Agents can still forget boundaries. They can still skip checks. They can still misunderstand generated files. They can still treat a real failure as a temporary issue.
So I would not say:
<blockquote>
harness-starter-kit makes agents smart.
</blockquote>
I would rather say:
<blockquote>
harness-starter-kit gives mistakes a place to be found, recorded, checked, and reused.
</blockquote>
That difference matters.
<h2>Two Dogfood Repositories</h2>
I tested the kit mainly in two real repositories.
The first one is a Django project:
<pre><code>harness_starter_kit_django
</code></pre>
The second one is a Next.js project:
<pre><code>today-bus
</code></pre>
They played different roles.
The Django repo became a stable local and CI harness example. It has:
<pre><code>AGENTS.md
docs/decisions/
docs/failures/
scripts/check_harness.py
.github/workflows/harness-check.yml
.harness/source.json
</code></pre>
Its normal local check is Python-based:
<pre><code>python scripts/check_harness.py
</code></pre>
That wrapper runs docs drift checks, structure checks, encoding hygiene checks, effectiveness-plan checks, Django system checks, and Django tests.
This repo helped confirm that the starter kit does not need to force every project into one standard structure. It can adapt to the target repository’s existing stack and commands.
<h2>Today Bus Was More Interesting</h2>
<img src="https://media.daily.dev/image/upload/s--FyBkC7Iw--/f_auto/v1780470266/ugc/content_524ea6e2-bf20-4bba-9bbe-c296caa3ae90?_a=BAMAMiWQ0" alt="스크린샷 2026-06-03 오후 4.03.47.png">
<img src="https://media.daily.dev/image/upload/s--rUE8h9i5--/f_auto/v1780470234/ugc/content_0ce6de7a-e226-4278-b7dd-6710114be3ad?_a=BAMAMiWQ0" alt="스크린샷 2026-06-03 오후 4.03.32.png">
The more interesting dogfood repo was <code>today-bus</code>.
It is a Next.js app that helps users decide when to leave home to catch a train at Gumi Station. It touches several external data sources:
<pre><code>TAGO public transit API
Gumi BIS timetable
TMAP walking route
OpenRouteService walking route
Kakao map input
</code></pre>
This project had more realistic failure modes.
The hard parts were not just lint or build errors. They were questions like:
<ul>
<li>Should live API smoke checks be part of the default gate?</li>
<li>How should mock fallback and live data be separated?</li>
<li>How do we handle zero-result provider responses?</li>
<li>How do we prevent service keys from leaking to the client?</li>
<li>When should a failure become a durable failure record?</li>
</ul>
The normal gate for Today Bus became:
<pre><code>npm run check:harness
</code></pre>
It runs:
<pre><code>npm run lint
npm run test:planner
npm run typecheck
npm run build
node scripts/check-harness.mjs
</code></pre>
The important part is that <code>npm run test:planner</code> is deterministic, local, non-network, and reasonably fast. So it belongs in the normal gate.
Live API checks are different. TAGO, TMAP, OpenRouteService, and Gumi BIS live diagnostics depend on credentials, network state, quota, provider uptime, and public data state. Those checks stay focused or manual unless the project intentionally decides they are stable enough for the default gate.
<h2>A Failed Check Was Actually Useful</h2>
At one point, <code>npm run check:harness</code> failed.
At first, that looked like bad news.
But it turned out to be evidence that the harness was working.
The failure happened during:
<pre><code>npm run typecheck
</code></pre>
The error pointed to:
<pre><code>.next/dev/types/validator.ts
</code></pre>
That file is generated by Next.js. It is not application source code.
The issue was not that the app code was wrong. The active dev server had left a stale or malformed generated type artifact, and <code>tsc</code> read it.
The important rule was:
<blockquote>
Do not manually patch <code>.next/</code> generated output.
</blockquote>
The fix was to update the typecheck command so Next refreshes generated types before TypeScript reads them:
<pre><code>next typegen &amp;&amp; tsc --noEmit --incremental false
</code></pre>
Then the failure was recorded in the repository:
<pre><code>docs/failures/0005-next-dev-validator-typecheck-artifact.md
</code></pre>
And the decision was recorded too:
<pre><code>docs/decisions/0017-refresh-next-generated-types-before-typecheck.md
</code></pre>
Before using the harness, this might have stayed as a chat message:
<blockquote>
Remember to run next typegen first.
</blockquote>
But now it became repository memory:
<ul>
<li>what failed</li>
<li>why it failed</li>
<li>what not to edit</li>
<li>what replacement command to use</li>
<li>which check will catch it again</li>
</ul>
That is the part I found valuable.
<h2>Failure Memory Should Not Just Be a Story</h2>
A failure note is useful, but it should not stop at describing what happened.
For example:
<pre><code>An API parameter casing was wrong.
A provider returned an unexpected error.
A CI check failed.
</code></pre>
Those notes are helpful, but they are not enough by themselves.
The failure record should also answer:
<pre><code>Which test catches this?
Which fixture covers this?
Which smoke check verifies this?
Which lint or drift check prevents this?
If no check is practical, what manual review point covers it?
</code></pre>
In Today Bus, one TAGO endpoint expected:
<pre><code>nodeid
</code></pre>
not:
<pre><code>nodeId
</code></pre>
That small casing difference caused the provider to ignore the stop filter and return too many routes, which then caused rate-limit failures.
The fix was not just “write a note.” The failure memory was connected to provider and planner tests.
That is much stronger than only writing:
<blockquote>
Be careful with nodeid casing.
</blockquote>
<h2>Doctor Score Is Not Agent Effectiveness</h2>
I also learned to separate two ideas.
Harness Doctor is useful, but it is not proof that the agent became better.
It can check repository evidence such as:
<pre><code>agent instructions
local checks
decision records
failure records
adoption reports
CI or validation hints
</code></pre>
That is harness health.
But it does not prove:
<pre><code>the agent edited fewer wrong files
the agent repeated fewer bugs
reviewers spent less time fixing work
first-pass verification improved
</code></pre>
Those need task outcome records or effectiveness reports.
So I now think about it this way:
<pre><code>Harness health:
Does the repository have durable rules, checks, and memory?

Agent effectiveness:
Did real agent tasks become less error-prone or easier to review?
</code></pre>
A high Doctor score is a readiness signal. It is not an outcome claim.
<h2>What I Am Looking For Now</h2>
When I look at a repository harness now, I care less about whether it has many docs.
I care more about these signals:
<ul>
<li>Can the agent find project rules in <code>AGENTS.md</code>?</li>
<li>Is the normal verification gate clear?</li>
<li>Are deterministic local checks included in that gate?</li>
<li>Are live or credential-based checks separated?</li>
<li>Do decision records capture real structural choices?</li>
<li>Do failure records capture mistakes that should not recur?</li>
<li>Is each failure record connected to a test, fixture, smoke check, or review point?</li>
<li>Does <code>/harness update</code> selectively refresh guidance instead of overwriting files?</li>
</ul>
This is not magic. It is a maintenance loop.
<pre><code>Find a rule.
Put it in the repository.
Turn it into a check when practical.
Record failures.
Connect failures to detection.
Refresh or review the harness when it drifts.
</code></pre>
<h2>Next Steps</h2>
I want to keep collecting more real usage evidence.
The next things I want to improve are:
<ul>
<li>more adoption reports from real repositories</li>
<li>more task outcome records</li>
<li>Go, Rust, iOS, Rails, and Laravel profiles</li>
<li>a monorepo adoption example</li>
<li>clearer README workflow diagrams</li>
<li>better evidence for actual agent effectiveness</li>
</ul>
The project is here:
GitHub: <a href="https://github.com/baskduf/harness-starter-kit" target="_blank" rel="noopener nofollow">https://github.com/baskduf/harness-starter-kit</a>
If you often use Cursor, Claude Code, Codex, or other coding agents, and you also repeat the same project rules across sessions, this idea may be useful.
And if you think the idea is wrong or incomplete, I would also like to hear that.
I am still a junior developer, so real feedback is more useful to me than compliments.

🚀 Daily Open Source Tools Squad delivers daily articles, open-source projects, and technical resources for Developers & DevOps pros. Stay updated with the latest trends & insights!

📬 Join our mailing list! → theinfinity.dev

Daily Open Source Tools

A junior developer shares lessons learned from dogfooding their harness-starter-kit across two real projects: a Django app and a Next.js transit app. The key insight is that the kit's value isn't making AI coding agents smarter, but giving mistakes a place to be found, recorded, and prevented from recurring. The post covers how failure records should be connected to actual tests or checks, the distinction between harness health (Doctor score) and real agent effectiveness, and a practical maintenance loop for keeping project rules durable across Cursor, Claude Code, and Codex sessions.

harness-starter-kit Is Not Magic. It Just Makes Mistakes Visible Earlier