DEV Community: Souren Khetcho

Claude Code Plan Mode: When to Plan, When to Build, and When to Add a Reviewer

Souren Khetcho — Sat, 26 Sep 2026 09:05:17 +0000

AI-drafted for AgentGrid, which makes the agent workspace discussed below. Documentation checked September 26, 2026. The prompts and diagrams propose a workflow; they are not a benchmark or a report of an executed session.

AI-generated editorial illustration of planning, building and reviewing.

Use Claude Code Plan Mode when you need to settle a consequential decision before implementation. Build directly when the intended change is clear and easy to check. Add a separate reviewer when a plausible mistake could survive your own inspection or the existing tests.

The difficult part is deciding how much process a task deserves. A long plan can consume the attention you needed for the diff. Another agent adds another handoff to check. Neither earns its place simply because the tools make it easy to start.

Ayman Nadeem's September 24 essay, “Plan mode is dead”, describes lessons from building Nuanced: lengthy generated specifications and a rigid separation between planning and building did not deliver the clarity intended. The account raises a useful question: what information helps a person stay oriented as code changes?

A Claude Code community discussion asks the practical version: when do planning frameworks and parallel agents repay their review and coordination overhead? That is a workflow question, not evidence that one method wins everywhere.

What Plan Mode does

Claude Code's common-workflows documentation presents Plan Mode as a way to explore and propose changes before implementation. Start in Plan Mode from the terminal.

claude --permission-mode plan

During a session, cycle modes with Shift+Tab and check the status bar. The detailed permission-mode documentation also documents /plan for a single prompt. When Claude presents a plan, you can request revisions or approve it and move into the selected execution mode.

Plan Mode is not a universal read-only sandbox. It can run exploratory shell commands, whose handling depends on session settings. The docs specifically say interactive terminal sessions with bypass permissions available do not enforce Plan Mode's blocks. Check your session configuration before relying on the mode to prevent changes.

Anthropic's best-practices guide recommends planning for uncertainty or unfamiliar code and direct implementation for small, clear changes. Our suggested extension is to consider the consequence of being wrong as well as task size.

Choose by uncertainty and consequence

These are editorial starting points. Your repository's required reviews still apply.

Task situation	Start here	What earns more process
A wording fix with a known location	Build directly; inspect the diff and affected view	Unexpected behavior or wider scope
A reproducible bug in familiar code	Investigate briefly, then implement one fix	Several plausible causes or unclear expected behavior
A feature with unsettled product behavior	Plan the decisions and acceptance criteria	A choice that changes the API, data model, or user experience
A small change to access control or data deletion	Plan first; arrange focused independent review	Consequences that a happy-path test cannot settle
An unfamiliar change across components	Map dependencies; choose one testable slice	Hidden coupling, migration risk, or missing checks

A one-line permission change may deserve more scrutiny than a large mechanical rename. Ask what you would have to undo if the assumption were wrong, and whether your checks would notice.

Proposed decision guide: settle uncertain decisions, build one bounded change, then choose review depth by the consequences of a missed defect.

Stop planning when you can check the next change

A useful plan names the unresolved decision, the evidence needed to settle it, and the next change that will test the answer. It need not predict every edit.

Consider a hypothetical search page where changing filters sometimes leaves the user on an empty results page. Before implementation, settle whether changing a filter should reset pagination. That product decision matters more than a detailed list of helper functions.

Here is an original prompt to adapt in Plan Mode:

Investigate the filter/pagination behavior without implementing yet.
Find the relevant state transitions and existing tests.
Propose the smallest fix for this expected behavior:
changing any filter resets the page to 1; changing pages preserves filters.
Identify unresolved decisions, likely affected files, and meaningful checks.
Keep the plan short enough to review in one sitting.
Stop when we can agree on one testable implementation slice.

Acceptance criteria could be three sentences: changing a filter resets the page; selecting page two keeps the filters; clearing filters restores the default results on page one. Add relevant constraints, such as preserving shareable URLs, only if the product requires them.

Review those criteria yourself. A model can propose internally consistent behavior that is wrong for your users. If you cannot decide between two behaviors, another implementation paragraph will not make that decision for you.

Build a slice that can change your mind

Once the behavior is agreed, implement the filter/page transition and its relevant checks. Leave unrelated search redesigns for another task. A bounded change gives you something concrete to inspect before extending the approach.

Proposed implementation prompt:

Implement the agreed filter/page behavior only.
Preserve unrelated local changes and follow the repository instructions.
Run the relevant existing checks and add coverage for the changed behavior.
If the fix needs an API or persistence change, stop and explain the decision.
Return the diff, exact commands and outcomes, and anything you could not verify.

If implementation exposes a false assumption, revise the affected decision and criteria. There is no benefit in preserving a plan that the code has disproved. Avoid regenerating the whole document when one assumption changed.

Give a reviewer evidence and a specific question

Add a reviewer when you can name a worthwhile challenge: could an older search response overwrite newer results, could a URL restore the wrong page, or could the change affect another caller? Review can be useful even when the plan was short.

Give the reviewer the original criteria, base and current revisions, full diff including relevant untracked files, exact check results, and known gaps. Ask for a reproduction or code-based explanation of each finding. A separate conversation can challenge the builder's reasoning; it does not guarantee different assumptions or a correct verdict.

If the question is whether the chosen behavior is right, review the criteria before building. If it is whether the code satisfies them, review the implementation. More reviewers are not a substitute for choosing the right question.

Proposed evidence handoff: criteria travel with the change; findings return to the builder; review and checks must describe the final revision.

A passing test is evidence about what it exercised. A test that never changes filters cannot establish that pagination resets. Ask the reviewer to identify the missing scenario rather than request “more tests” in general. For interface behavior, try the actual interaction as well.

After a fix, rerun the relevant checks and review the revised code. Stop the loop when the criteria have supporting evidence and material findings are resolved, or when a specific unresolved decision needs your attention. Report blocked checks plainly.

Keep the handoff visible in AgentGrid

AgentGrid supports visible agent and terminal panes. Its build-and-review workflow sets up a builder and a reviewer in separate conversations, with findings returned to the builder. Use that fuller setup when the task warrants coordination; a straightforward fix may need only one working conversation and your inspection.

Those separate conversations can still access the same files. Asking a reviewer not to edit is an instruction, not a filesystem boundary. The workflow's value depends on supplying and inspecting evidence; placing panes beside each other does not automatically trace requirements to correct behavior.

Download AgentGrid if you want the builder, review conversation, and test terminal together for your next consequential change. Start with one bounded slice and one review question you can actually answer.

Original article: Claude Code Plan Mode: When to Plan, When to Build, and When to Add a Reviewer.

Jev vs. Laya: Which AI Decision Model Should You Choose?

Souren Khetcho — Tue, 22 Sep 2026 22:51:54 +0000

This article was drafted with AI and reviewed for factual accuracy against primary sources. Any hands-on testing and its limitations are described in the article.

Sources checked September 21, 2026, Pacific time. This comparison combines documentation with a small local Laya smoke test on authored synthetic cases. We did not call the hosted Jev API or run a controlled head-to-head benchmark.

Start with Jev if you want a hosted service and your inputs fit its documented API. Start with Laya if running inference on your own infrastructure or adapting the weights is a requirement, and you can take on the deployment work. Those are recommendations about where to begin evaluating. Neither establishes which model will make better decisions on your tickets.

Imagine the same issue arriving in both systems: “The CSV export button does nothing.” You want a category, a judgment about missing reproduction details, and a suggestion for the review queue. A usable answer must preserve what the report says, respect your category definitions and arrive within your application's time budget. That is the comparison worth making.

The differences that should drive your choice

Both products expose typed decisions: choice for selecting an option, score for an ordered rating and noul for a yes/no probability. These can feed application logic without asking a chatbot to write and format a response. A correctly shaped answer can still be wrong. TypeSafe API, Laya model card.

Your constraint	Jev (`jev-1.13.0`)	Laya
Where inference runs	TypeSafe's hosted API	Your chosen local machine or server
What you must arrange	Account access, credentials and an HTTP client	Python environment, model files, compatible runtime and enough memory
Larger inputs	Documented 64k-token request budget, with a separate 32k limit for state plus the longest question	Much smaller default per-question budgets; inspect the selected checkpoint and preprocessing
Many candidate labels	Up to 255 options per Choice	Options compete for a limited prompt budget; the publisher recommends fewer than about 20 options at default settings
Domain adaptation	Change the supplied state, instructions and criteria	Change those inputs; you can also fine-tune an appropriate checkpoint
Cost to operate	Listed input-token charge, plus your integration costs	Compute, memory, storage and operating time; downloadable weights do not make those free

The Jev limits and customization details come from its model reference and API contract. Laya's repository documents the local runtime and tuning workflow; its benchmark limitations explain the option-budget constraint.

With Laya, name the checkpoint before discussing results

“Laya” refers to a family. The root checkpoint is aimed at English, a multilingual checkpoint serves other languages, and a separate checkpoint is fine-tuned for the typed-decisions benchmark workflows. Its router can choose a checkpoint for a request. Record what it actually selected rather than reporting every result under one model name. Laya family and router.

This matters because the publisher reports substantially different results for the base and fine-tuned versions. A result from the typed-decisions checkpoint is not evidence that the root English model will reproduce it on a new issue-triage task. The fine-tuned model card identifies that specialization. Start with the language and task you have, then evaluate that particular artifact.

There is a second trap: a model's architectural capacity is not the amount of text your current configuration uses. The pinned English configuration sets a 512-token sequence budget and a 192-token question/options budget. The bundled multilingual configuration uses 1,024 and 256 respectively. The remaining space must hold the state, including formatting overhead. Long descriptions and large option sets consume that budget quickly. English configuration, multilingual configuration.

For a short report with four categories, this is a manageable constraint to investigate. For a long incident history and 80 possible queues, I would evaluate Jev first or redesign the task into smaller decisions. That is an inference from the documented budgets, not a claim that Jev has won an 80-label test. A larger accepted input also does not guarantee better reasoning: TypeSafe explicitly warns that irrelevant context can reduce accuracy. Jev limitations.

The local run used a pinned Laya checkpoint on CPU. We checked the complete token sequences for these five cases; the Jev API was not called.

Local control comes with a runtime to manage

Laya's package requires Python 3.10 or newer and depends on PyTorch, Transformers and model-loading libraries. The inspected runtime supports CPU execution and accelerator selection, with CPU fallbacks in some failure cases. Log the device actually used; a requested GPU is not proof that inference stayed on it. Package requirements, runtime source.

Check available memory after loading the checkpoint, then measure your intended batch size. Model-file size alone is not a RAM or GPU-memory requirement: loading, intermediate computations and additional resident checkpoints need room too. Avoid choosing hardware from a download-size label.

Jev moves that model-serving work to TypeSafe. You still need working account access, network connectivity and error handling. The API documents authentication, rate-limit and overload failures. Confirm access before planning a launch around it. TypeSafe API errors.

What “local” means for privacy

Running Laya on infrastructure you control can keep inference inputs there. That does not automatically cover the surrounding workflow. A cloud coding agent reviewing a private ticket, a remote log collector or a hosted demo introduces another data path. Use synthetic tickets while setting up the comparison, and decide separately where real inputs may go.

TypeSafe says it does not train on customer data and offers zero data retention for enterprise customers. The latter is a separate offering, not a retention guarantee to assume for every account. Check the terms applicable to your account. TypeSafe data-handling documents.

Why the benchmark tables do not settle this

Laya's published comparison explicitly says its Jev figures come from third parties and that prompts and sample sizes differ. Its own checkpoint comparisons can be informative, but that does not turn the Jev column into a controlled head-to-head test. We would not use those figures to claim that Laya is a particular multiple faster or more accurate than Jev. Benchmark methods and limitations.

For speed, record the time the application actually waits: input preparation, local prediction or network request, and response validation. Separate first-load time from repeated predictions after loading. Keep the hardware, batch size, input lengths and number of repetitions with the result. Comparing a warm GPU forward pass with an end-to-end API request answers a different question from comparing two complete application paths.

For cost, TypeSafe currently lists Jev at $0.042 per million input tokens, with output tokens free. Laya's weights are listed under Apache 2.0, but self-hosting still consumes resources and staff time. Measure total cost for your expected workload before calling either cheaper. Jev pricing, Laya license.

Confidence needs its own evaluation

A model can be confidently wrong. Laya's multilingual card warns about overconfidence and recommends fitting calibration on representative held-out data. Calibration asks whether predicted probabilities line up with observed outcomes; it does not fix a model that routinely chooses the wrong category. Multilingual calibration limits.

TypeSafe's Choice and Score confidence values summarize the returned probability distribution. Noul does not have a separate confidence field. Laya's inspected implementation does return an additional Noul confidence value. Do not copy a threshold between providers just because fields have familiar names. TypeSafe confidence, Laya response implementation.

What our local Laya smoke test showed

We ran the root English checkpoint on five authored issue reports, twice each, using Laya 0.3.5 on Windows with Python 3.12, CPU PyTorch 2.8.0 and four processing threads. The model revision was pinned to 1c5edc17a7acd8701df6fc341c0d179f1c62c982. Expected labels stayed outside the model input. Checks found no additional truncation from the configured sequence budgets in these cases.

The category choices matched all five authored labels in both repetitions. The separate missing-reproduction question was less useful:

Authored report	Expected missing information?	Laya's probability of yes
Bug report with steps, expected and actual behavior, and environment supplied	No	0.8054
Bug report with steps and environment missing	Yes	0.8664

The other three cases also exceeded 0.5 despite an expected "no." Getting the category right did not make the second judgment reliable. These were five simple examples with one rubric, not a representative accuracy test; repeating them did not create five additional independent cases.

The illustrative policy kept all ten outputs in manual-triage, with human review required. Separately, eight adapter tests passed; their Jev transport checks used mocks. There was no hosted Jev result to compare.

This run supports a modest conclusion: the local inference path worked, and inspecting each question exposed a problem that a category-only check would have missed. Before using this rubric on real issues, we would investigate those false positives and evaluate revised criteria on fresh cases.

Laya matched the five category labels in both repetitions, but the missing-details question produced false positives. The example policy kept all ten outcomes in manual triage.

Compare one useful workflow in AgentGrid

Use the issue-triage scenario from our Jev getting-started guide. Its downloadable example separates question criteria from the code that suggests a review queue. The published run used synthetic responses; it is a starting point for integration work, not a Jev accuracy result.

Open a separate comparison project in AgentGrid. Keep the shared cases, provider adapters, coding-agent review and terminal results together. Jev and Laya are the decision components called by your scripts; this workflow does not require either to be a native AgentGrid coding-agent harness.

Before executing either model, write the expected outcome for each case:

Case to include	What you are checking
A clear feature request	New functionality stays distinct from a reported defect
A defect report with missing steps	Missing context triggers review rather than an invented explanation
A question about existing behavior	Help requests do not become bug reports by default
A report with competing intentions	The system can defer an ambiguous case
A long report or expanded label set	Relevant evidence and label descriptions survive preprocessing

Use separate examples for tuning criteria or calibration and for the final evaluation. Preserve the intended meaning across adapters, and record any difference in the actual serialized requests. Identical source JSON is not enough if one runtime truncates it or interprets fields differently.

This is a prompt you can give the coding agent to begin the work:

Build a reviewable Jev/Laya issue-triage comparison in this project.
Read project instructions first. Use synthetic cases with expected
categories and human-review actions recorded before model execution.

Keep provider adapters separate. Record package/model/checkpoint versions,
actual device, input limits and execution mode with every result.
Check that each adapter preserves the intended criteria and input text.
Show skipped, fixture, local-inference and hosted-API runs distinctly.

Start with offline adapter and policy tests. Do not read credentials,
download weights, call hosted inference or modify real issues yet.
Report what passed, what remains untested and the resources needed next.

That prompt is a suggested next step; it was not used to produce the smoke-test results above. When you add real model runs, retain the raw outputs and failures. A few successful examples establish that the path works, not that it is generally accurate. For this first comparison, keep every suggested action subject to human review.

Which should you try first?

Try Jev first when your priority is integrating a hosted component, especially when larger inputs or many options matter. Verify access, then test whether its decisions justify the dependency.

Try Laya first when local execution or control over the weights is central to the project. Budget time for checkpoint selection, deployment, input handling and calibration. A strong result for another checkpoint is a reason to investigate, not a result you have inherited.

If either option meets the deployment constraints, let the same-task evaluation decide. The useful winner is the one that handles your cases, makes acceptable mistakes and fits the cost of operating it.

Download AgentGrid to keep that comparison in one workspace. Start with the offline review, then use the build-and-review workflow when you are ready to implement and independently check the adapters.

Originally published on AgentGrid.

What Is Jev and How to Get Started

Souren Khetcho — Tue, 22 Sep 2026 22:43:12 +0000

This article was drafted with AI and reviewed for factual accuracy against primary sources. Any hands-on testing and its limitations are described in the article.

Documentation checked September 21, 2026. The example below passed local tests with synthetic responses. We have not tested it against the live Jev API.

An issue arrives: the CSV export button does nothing. Before anyone starts fixing it, someone has to decide what the report actually asks for—and whether it contains enough information to investigate.

That is a useful place to try Jev. You supply the issue and a few specific questions. Your program gets structured answers it can use to suggest a next step.

What is Jev?

Jev is TypeSafe's first System One model, introduced on September 15, 2026. TypeSafe uses that term for models built to make structured decisions that software can consume. You send the information to evaluate, called the state, along with typed questions. Jev returns decisions and probabilities rather than writing a chat response. TypeSafe's introduction, launch announcement.

For the issue above, the useful output could be a suggested category and a signal that reproduction details are missing. Your application decides what happens next: display the suggestion, ask a person to review it, or request more information.

A valid category can still be the wrong category. Restricting the output to known values helps the integration; it does not establish that the model understood the issue correctly. TypeSafe's own limitations page describes mistakes involving literal wording, numbers, irrelevant context and adversarial input. Jev 1.13 limitations.

Three kinds of questions

Choose the question type that matches the decision your code needs.

Type	Use it for	What comes back
Choice	Pick a category from options you supply	The selected option, a probability for each option, and confidence
Noul	Judge a yes/no question, such as whether reproduction details are missing	A number from 0 to 1 representing the probability of yes
Score	Rate something against ordered descriptions, such as relevance levels	A score along those levels, their probabilities, and confidence

Several questions can share one request, but each is evaluated independently against the state. A question cannot depend on another question's answer in that same call. Combine the answers in your code. How TypeSafe evaluates questions.

Where would you use it?

Start with a decision you can inspect quickly. These are possible applications, not results we have measured:

Issue or support intake: suggest a known category, then let a person confirm the destination and missing information.
Context selection: rate retrieved passages for relevance before passing them to a coding or answering agent. Check that useful evidence is not being discarded.
Workflow selection: suggest whether a request belongs in a bug-fix, documentation or research process. Keep the permission to start work in your application.

These fit the classification, relevance and routing patterns in TypeSafe's use-case examples. If the job is to draft a reply or implement a feature, a generative coding or writing agent still has work to do. Jev's contribution is the bounded judgment inside that larger process.

Start with a local project in AgentGrid

In this walkthrough, a regular coding agent reviews the client, a terminal runs it, and the client can call Jev. You do not select Jev as a native AgentGrid harness.

Download the starter project and extract it. In AgentGrid, set your project's folder to the extracted jev-starter directory. Open your configured coding agent and a terminal in that project. Keep the TypeSafe API reference nearby while you inspect the request. AgentGrid's Claude Code and Codex guide covers coding-agent setup if you need it.

The example needs Node.js 20 or newer and no package installation. We ran its local checks on Node 24.11.0 on Windows; Node 20 and a POSIX shell were not separately tested. TypeSafe also provides an official JavaScript SDK; this small example uses Node's built-in fetch so you can inspect the HTTP request directly.

You can use an ordinary terminal too. AgentGrid is useful here because the criteria, coding-agent review and test output stay together while you change the integration.

Give the coding agent this task:

Review this Jev issue-triage starter. Read any project instructions first.
Compare triage.mjs and client.mjs with https://docs.typesafe.ai/api.
Explain the label criteria and how reviewDecision handles uncertainty.
Run node --test __tests__/triage.test.mjs and report the actual result.
Keep API execution offline: do not read credentials, install packages,
call the API or change GitHub issues. Suggest changes before editing files.

This prompt is a starting point for your review. The test results below come from local command-line checks, not a live Jev call.

Review the client with a coding agent and run its checks in a project terminal. The Node script can call Jev through the TypeSafe API.

Read the decision before you run it

The starter has three main files:

triage.mjs defines the questions, validates the response and chooses a review queue.
client.mjs makes the HTTP request when live mode is selected.
cli.mjs lets you preview the request, use a fixture or call the API.

The synthetic issue is in fixtures/issue.json. It describes a failed CSV export but leaves the reproduction steps and environment empty. The category question distinguishes four intentions:

Category	What this example means by it
`bug`	A report that existing behavior differs from an explicit expectation; the defect is not yet verified
`feature`	A request for a new capability or intentional enhancement
`question`	A request for help with existing functionality
`needs-context`	Ambiguous, conflicting or insufficient evidence to identify one intention

A separate Noul question asks whether a reported defect lacks necessary reproduction information. Code uses that answer only on the bug branch. Missing steps should not turn every clear defect report into an unknown category.

Put the actual meaning in the question's instructions and criteria. The API's question IDs, such as missing_reproduction, identify answers in the response; they are not sent to the underlying model as instructions. API request format.

The request asks two bounded questions. Ordinary code chooses a review queue; every suggestion still requires human review.

Run the offline checks first

From the extracted project folder, these commands are the same in PowerShell and a POSIX shell:

node --version
node --test __tests__/triage.test.mjs
node cli.mjs --request
node cli.mjs --fixture

The 28 local tests cover the review rules, malformed responses and simulated HTTP failures. All passed in our Windows run. They do not measure Jev's accuracy or establish API access.

--request prints the planned request without sending it. --fixture uses hand-written response values to exercise the review logic. Its output explicitly says:

SYNTHETIC RESPONSE FIXTURE — NOT A JEV RESULT; no network call

For that fixture, the proposed category is bug and the review queue is request-context. The code reaches that branch because the fixture's category confidence is 0.85 and its missing-reproduction value is 0.95. Those numbers were chosen for the example; Jev did not produce them.

Local fixture output tests the review policy; it is not a Jev result.

Here is the policy the starter applies, in order:

Condition	Suggested queue
Category confidence below 0.8	`manual-triage`
Otherwise, category is `needs-context`	`request-context`
Otherwise, category is `bug` and missing-reproduction is at least 0.8	`request-context`
Otherwise, category is `bug` and missing-reproduction is above 0.2	`manual-triage`
Otherwise	`review-suggestion`

Every branch keeps requiresHumanReview: true. The script never labels, closes or comments on a GitHub issue.

The thresholds are illustrative, not tuned recommendations. Choice confidence summarizes its probability distribution; it is not interchangeable with the winning option's probability. Noul has no separate confidence field. Evaluate the decisions on your own labeled examples before treating a threshold as useful. TypeSafe's confidence documentation.

Make a live call when you have access

TypeSafe's launch announcement describes staged early access. Check your access in the TypeSafe console rather than assuming installing the client grants it. Early-access announcement.

The starter pins jev-1.13.0, the current version listed when we checked. TypeSafe lists input pricing of $0.042 per million tokens, with output tokens free. Check the current model and pricing page before running a batch. This walkthrough has no measured API cost or latency.

Set TYPESAFE_API_KEY privately in the terminal that will run the script, following the TypeSafe setup instructions. Keep the key out of the agent conversation, repository and screenshots. Once it is available in that terminal, run:

node cli.mjs --live

This sends the synthetic issue and its two questions to https://api.typesafe.ai/v1/systemone. The script prints the returned model, answers and usage alongside its review suggestion. Read the probabilities as well as the chosen category; a plausible label alone tells you little about the alternatives. HTTP API.

If the key is missing, the script stops before sending. Authentication, request or response errors also stop the run. It deliberately does not retry automatically: after a timeout, it cannot tell whether the server processed the request. Check the failure before trying again. We have not performed this live step, so there is no live result to reproduce yet.

Decide whether it helps on your issues

Try a clear feature request, an incomplete defect report and an ambiguous report with competing intentions. Write down your expected category and review action before making each call. Inspect disagreements, including confident wrong answers, and keep the input and model version with the result.

Change a criterion when it fails to express what you mean. Change the application policy when it allows a suggestion to go further than it should. Those are different problems. Keep exact arithmetic and permission checks in code; TypeSafe documents limitations in numerical tasks and adversarial input. Known limitations.

For this first prototype, a useful result is straightforward: you can explain the suggestion, see why it reached a particular review queue, and correct the criteria without losing track of what changed.

Build and review it in AgentGrid

Keep the issue fixture, question criteria, coding agent and terminal together while you work through those disagreements. When you are ready to change the client, use AgentGrid's Build with Claude. Review with Codex. workflow to have a separate reviewer check the implementation and tests.

Download AgentGrid and open the starter project. Begin with the offline review, then make a live call when you have TypeSafe access and a decision worth testing.

Originally published on AgentGrid.