The latest articles on DEV Community by liyitong10086 (@liyitong10086). https://dev.to/liyitong10086 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4020393%2F09e911dd-9080-4c81-bd71-d3396675a780.png https://dev.to/liyitong10086 en liyitong10086 Wed, 08 Jul 2026 03:05:03 +0000 https://dev.to/liyitong10086/what-actually-happened-when-my-agent-worked-on-frantic-b63 https://dev.to/liyitong10086/what-actually-happened-when-my-agent-worked-on-frantic-b63 <p>The good part was unusually concrete: fixed acceptance criteria, public artifacts, and real payouts. The frustrating part was equally concrete: strict evidence contracts, stale-looking reviews, and repeated revisions when a field existed in the wrong shape.</p> <p>I used a Codex agent to work on <a href="https://gofrantic.com" rel="noopener noreferrer">Frantic</a>, an open bounty board where claims, deliveries, reviews, and payouts are visible. My agent profile is <a href="https://gofrantic.com/a/agent-0982ee" rel="noopener noreferrer">agent-0982ee</a>. This is not a generic endorsement; it is a record of what happened on my account.</p> <h2> What we actually shipped </h2> <p>Two recent jobs were small Runx skills. <strong>Secret Catcher</strong> checked bounded text for exposed credentials and refused unsafe handling. <strong>Data Doctor</strong> diagnosed structured-data quality problems. Each delivery needed source files, a public registry package, local and hosted harness results, a post-publish run, a verifiable receipt, structured evidence, and a report.</p> <p>Both were accepted and paid. The public payout receipts are <a href="https://gofrantic.com/r/f6f69aa9" rel="noopener noreferrer">$8 for Secret Catcher</a> and <a href="https://gofrantic.com/r/bec43be6" rel="noopener noreferrer">$9 for Data Doctor</a>. Those links are the useful disclosure: a reader can check that this account did work and that money moved.</p> <h2> What worked </h2> <ul> <li>The task descriptions named the required artifacts instead of relying on a vague maintainer conversation.</li> <li>Machine preflight caught missing bindings before final delivery.</li> <li>Hosted harnesses and receipts made it harder to submit a local-only demo.</li> <li>Once accepted, the two payouts settled to the configured Base USDC address and appeared on the public ledger.</li> </ul> <h2> What did not work smoothly </h2> <p>The hardest lesson was that correct work is not enough when the evidence packet is shaped incorrectly. A Bookkeeper delivery had working code, a published package, green harnesses, and a valid dogfood receipt, yet it was returned several times because five URLs were not named exactly where the reviewer expected them. The fix was not new product code; it was explicit machine-readable fields in both the JSON evidence and report.</p> <p>Reviews also sometimes appeared stale after a new delivery. We had to compare the review timestamp, commit, and artifact URLs rather than assuming the status label described the newest submission.</p> <blockquote> <p>My practical rule now: treat the evidence contract as part of the implementation. Run preflight, pin every URL to a commit, and make every required field explicit even when the same link already appears elsewhere.</p> </blockquote> <h2> Would I use it again? </h2> <p>Yes, for narrow tasks with acceptance criteria I can reproduce locally. I would avoid tasks that depend on a third-party maintainer merging or deploying something inside a short claim window. Frantic was strongest when the result was independently testable and weakest when acceptance depended on interpretation or an external adoption step.</p> <p>The result so far is not hypothetical: this profile has paid receipts, accepted work awaiting payout, a few expired attempts, and revision history. That mixed record is more useful than marketing copy because it shows both the successful path and the failure modes.</p> agents ai showdev softwaredevelopment