Latest Blog Post Review Report

Run date: 2026-05-01
Scope: _posts/2026-05-01-how-i-use-cursor-to-run-agentic-work.md only
Workflow: fixed 10-reviewer loop (6 persona + 4 discipline), single round, report-only

Executive Summary

Score Summary

Round 1 averages

Reviewer overall scores

Categorized Findings

UX / Content

  1. The strongest proof arrives too late. Multiple reviewers said the post spends too much time on general framing before landing the certification-program example and the clearest thesis: Cursor is where Jenny runs work that needs agents, structure, and review rather than “just an answer.”
  2. The workspace-setup section is too dense relative to scan value. The file tree, long “What lives where” list, custom prompt block, and repeated setup sentence slow momentum in the exact section that should teach the reusable pattern most clearly.
  3. Some technical terms need plainer first-use definitions. “Agentic harness,” “Plan mode,” “subagents,” and “MCP” are mostly explained, but reviewers still saw moments where the post assumes more tool familiarity than it should for non-technical operators or executive readers.
  4. The ending becomes more generic than the rest of the article. Several reviewers flagged the final section for drifting into broad encouragement about learning the muscle now, rather than landing on the sharper insight the post has earned about inspectability, recoverability, validation, and operating judgment.

UI / Design

  1. The custom prompt block is heavier than it needs to be. The interactive Copy block with heading-like content inside a <pre> feels more like embedded product UI than editorial support. Reviewers suggested either simplifying it or making the internal text visually lighter.
  2. The 56-112 stat callout is memorable but slightly imprecise in presentation. The hyphenated range looks looser than the surrounding prose, which uses the more careful wording “roughly 56 to 112 agent review passes.”
  3. The article uses several special presentation modes in one piece. Figures, custom prompt UI, and a stat callout all appear in one post. That does not break the article, but it slightly fragments the visual rhythm.

Code / Semantics

  1. There is one clear publish-blocking markup error. The duplicated sentence The quality of that setup mattered more than the cleverness of any one prompt. is followed by a stray closing </p>. This was the only consensus Must issue across multiple reviewers because it visibly undercuts rigor and can interfere with clean rendering.
  2. Raw HTML components create semantic fragility. The prompt block and stat callout are implemented as raw <div> structures in a markdown post, including an inline onclick button. Reviewers saw this as workable but brittle compared with simpler or more semantic editorial structures.
  3. The prompt block includes heading-like prompt text that muddies the article outline. The literal ## Intake, Output, and Archive Rules line inside the copied instructions competes with the real article headings and was flagged as an accessibility/outline problem.

SEO / Accessibility

  1. Title and description undersell the strongest value of the piece. Reviewers found the current title and description accurate but flatter than the body, which contains stronger operator framing and more credible proof.
  2. There is no explicit next-step bridge inside the article body. Some recruiter-oriented reviewers treated this as a conversion weakness: the post persuades but does not explicitly tell an interested reader what to do next.
  3. A few accessibility/structure details reduce polish. These include the false heading inside the prompt block, the malformed HTML fragment, and slightly under-explanatory alt/label patterns compared with the otherwise careful instructional voice.

Persona / Resonance

  1. The post reads as strong operator proof once the reader gets into it. The certification example, role-based review loop, MCP validation section, and recovery story all landed as unusually concrete and differentiated.
  2. The role signal is not immediate enough for recruiter-style scanning. Several persona reviewers wanted earlier translation from “operator” and “agentic operations” into the kind of cross-functional, systems-minded role ownership Jenny actually demonstrates.
  3. One claim reads more hype-prone than the rest of the piece. The comparison to “a team of 4 or 5 developers weeks to deliver” was repeatedly flagged as the line most likely to trigger skepticism unless narrowed or qualified.

Prioritized Action Plan

Must

  1. Remove the duplicate sentence and stray </p> in the workspace-setup section. Why now: This is the clearest publish-blocking issue because it creates visible sloppiness in a post arguing for disciplined systems.
    Implementation notes:
    • Keep the sentence once.
    • Delete the orphan closing tag entirely.
  2. Fix visible copy/grammar errors across the post. Why now: These are low-effort, high-leverage credibility repairs that multiple reviewers flagged.
    Implementation notes:
    • Correct excell -> Excel
    • Correct color-coordinaed -> color-coordinated
    • Correct scaling operation -> scaling operations
    • Correct and couple hundred dollars -> and a couple hundred dollars
    • Correct Assement -> Assessment

Should

  1. Move the strongest proof and thesis earlier. Shift the certification-program proof and/or the “agents, not just an answer” thesis higher so readers understand the operator signal before the tooling explanation expands.
  2. Tighten the certification-program claim. Keep the concrete facts, but qualify or narrow the “team of 4 or 5 developers” comparison and define what “production-ready” meant in practice.
  3. Compress and sharpen the workspace-setup section. Reduce explanatory bulk in the “What lives where” list, and add one clear line translating the folder/rules pattern into operator value: cleaner handoffs, inspectable work, lower coordination overhead, and better recovery.
  4. Define technical terms more plainly on first use. Especially agentic harness, then optionally tighten Plan mode, subagents, and MCP with more operator-native definitions before examples.
  5. Rewrite the ending to land on Jenny’s standards rather than generic encouragement. End on recoverability, inspectability, human review, or the type of work this system is best for.
  6. Review title and meta description for stronger positioning. Align metadata with the sharper operator framing already in the body.

Nice

  1. Simplify the custom AGENTS.md prompt block or reduce its heading weight.
  2. Make the 56-112 stat callout more explicit and semantically precise.
  3. Add a light in-body next-step bridge for recruiter or hiring-manager readers if that is the intended conversion path.
  4. Reduce the number of bespoke visual treatments if editorial coherence becomes a priority in the revision pass.

Top Blockers To 8.0

  1. Technical/publish polish: the markup error and typo cluster hurt trust too much for the current score.
  2. Opening hierarchy: the best proof is buried after too much setup.
  3. Claim calibration: one large comparison risks reading as hype instead of controlled judgment.
  4. Ending discipline: the close does not yet cash out the strongest operator insight.

Round Notes

Concrete Revision Recommendations

This section is intentionally specific because the main risk here is not “make it cleaner” in some generic way. The main risk is making well-meaning edits that flatten the voice, over-correct the ambition, or remove the lived specificity that makes the post work. The goal of these recommendations is to protect the strongest parts of the draft while tightening the places where the current version creates avoidable skepticism.

1. Fix only the publish-quality errors with zero voice tradeoff

These are not voice edits. They are trust repairs.

Impact: These changes do not alter tone, rhythm, or point of view. They simply remove the small errors that make readers doubt the rigor of a post whose argument depends on rigor.

2. Move the strongest proof up earlier without rewriting the voice of the opening

The opening currently has the right material, but the order makes the piece feel more abstract than it is. The fix is not to replace Jenny’s opening voice with a more recruiter-ish one. The fix is to move one of the strongest concrete proof moments earlier.

Current structure:

  1. Operator identity and project-shaped work
  2. Difference between chatbots and agent-oriented work
  3. Explanation of Cursor
  4. Workspace argument
  5. Certification-program proof

Recommended structure:

  1. Operator identity and project-shaped work
  2. One-sentence thesis about why Cursor matters for that work
  3. Certification-program proof
  4. Then explain Cursor and the workspace model

Specific wording move I would make:

Impact: This preserves the current voice and conceptual frame, but lets the reader experience the post as grounded operator proof much earlier. It should increase clarity and confidence without making the piece feel more corporate or resume-like.

3. Tighten the biggest claim instead of toning it down into something timid

The problem is not that the claim is too bold. The problem is that one part of it feels broader than the surrounding evidence can fully support. The best fix is not to make the whole paragraph smaller. The best fix is to keep the specific scope and tighten the least grounded comparison.

Current wording:

With 48 hours, a small host of agents, and couple hundred dollars of tokens, I shipped a full production-ready three-course, 21-module certification program. What, in the past, would have taken a team of 4 or 5 developers weeks to deliver, a single non-engineer could deploy in 2 days.

Recommended direction:

With 48 hours, a small host of agents, and a couple hundred dollars of tokens, I shipped a production-ready three-course, 21-module certification program, complete with labs, review loops, and in-product validation. It compressed a project that would once have taken a much larger team and a much longer timeline into two days of tightly structured work.

Or, if Jenny wants to preserve the developer comparison more directly:

With 48 hours, a small host of agents, and a couple hundred dollars of tokens, I shipped a production-ready three-course, 21-module certification program. It was the kind of project that, in our old workflow, would have required multiple people and a much longer build timeline.

Impact: This keeps the ambition and specificity, but removes the one sentence most likely to trigger “that sounds inflated.” It protects credibility without draining the energy out of the achievement.

4. Replace the most generic sentence with one that says the same thing more concretely

This is one of the few places where the draft sounds more AI/productivity-generic than Jenny-specific.

Current wording:

But scaling operation across sales, marketing, people operations, customers, and product, requires more hours in a day than I have. And unifying that chaos into a clear, AI-native structure enables me to get more done in the fraction of the time it took before.

Recommended direction:

But scaling operations across sales, marketing, people operations, customers, and product requires more coordination than any one person can hold together by memory and force of will. What changed for me was not just speed. It was having one structure where the plan, drafts, reviews, decisions, and handoffs could all live together.

Impact: This keeps the underlying idea, but makes it sound more like Jenny: practical, human, and specific about what improved. It also better sets up the rest of the article, which is really about structure, inspectability, and handoffs rather than generic acceleration.

5. Compress the workspace-setup section instead of removing the operational detail

This section should stay. It is one of the most differentiated parts of the piece. The risk is not that it exists. The risk is that it currently asks the reader to process too much explanation before cashing out why the structure matters.

Specific structural change I would make:

Example of the sentence I would add:

What matters about this structure is not the folder names themselves. It is that every part of the work has a place to live, which makes the system easier to hand off, inspect, recover, and improve.

Specific wording simplifications I would make:

Impact: This keeps the specificity and the operating texture, but reduces the feeling that the post has temporarily become documentation instead of narrative.

6. Define agentic harness in plainer language before naming the term

The current instinct is right, but the order is slightly backwards for non-technical readers.

Current wording:

Before I ask an agent to write anything, I set up the system around it first. Technical folks call the agentic harness. I mostly think of it as the structure that keeps the work organized and effective.

Recommended direction:

Before I ask an agent to write anything, I set up the system around it first: the files, rules, review process, and boundaries that keep the work organized. Technical folks might call that an agentic harness. I mostly think of it as the structure that keeps the work effective.

Impact: This keeps the term, but makes the idea accessible before the jargon appears. It improves clarity without making the voice sound more beginner-oriented or over-explained.

7. Keep the recovery anecdote, but make the landing line slightly more accountable

The anecdote is good. It humanizes the piece and proves the value of artifacts. The only possible tweak is to make the final beat land a little more on resilience than on comic relief.

Current wording:

At 3:31 a.m., seven hours before the deadline, I had one of the more humbling moments of the whole project. I accidentally permanently deleted the entire 301 course, one third of the project I was finishing, in a way no amount of smashing Command-Z could resolve. Not my best moment.

Recommended direction:

At 3:31 a.m., seven hours before the deadline, I had one of the more humbling moments of the whole project. I accidentally permanently deleted the entire 301 course, one third of the project I was finishing, in a way no amount of smashing Command-Z could resolve. A painful mistake, but not a fatal one.

Impact: This is optional. The current version is still good. This tweak would just align the punchline more tightly with the section’s real point: the system made recovery possible.

8. Rewrite the ending so it completes the argument instead of broadening it

This is the place where protecting voice matters most. The goal is not to turn the ending into a CTA or a lesson. The goal is to end on the truest thing the post has shown.

Current ending direction:

So if Cursor feels intimidating, I get it... now is a very good time to start exploring this way of working... build the muscle now...

Recommended direction:

End on one of the truths the post has already earned:

Example ending option:

What makes this way of working useful to me is not that it makes work feel futuristic. It is that it makes the work more inspectable, more recoverable, and easier to run with real standards under real deadlines. That is the part I trust.

Impact: This would preserve the seriousness and intentionality of the piece better than the current broader encouragement. It should make the ending feel more owned, more memorable, and more aligned with Jenny’s operator voice.

9. Change as little as possible in the places where the voice is already doing real work

There are sections I would not substantially rewrite unless Jenny herself wants to.

Why keep those mostly intact: These are the sections where the draft feels most like Jenny already. They are specific, they develop ideas instead of asserting them, and they carry the puzzle-solving / operator / systems-thinking mix that the stronger parts of the style guide are trying to protect.

10. Overall editorial principle for revising this post

If Jenny revises this, the safest editing principle is:

Keep the specifics. Tighten the order. Remove only the places where the language becomes more abstract than the lived experience.

That means:

The right revision is not “make it more polished” in a generic sense. The right revision is “make the strongest parts easier to trust sooner.”