A small library is easy to hand to an agent.

For application work, point the agent at README.md, include/json.h and the relevant tests. For parser changes, include HANDOVER.md so synchronization and evidence requirements are not reconstructed from Git diffs.

For users integrating Jsonic++

An assistant usually needs very little context: the header defines the complete public API and implementation, while the API reference explains the intended calling patterns. Ask it to use explicit type checks when JSON is not already structurally trusted and to preserve your application's own error policy rather than inventing a wrapper framework.

json::Document config;
std::string error;
if (!json::Document::parse(text, config, error)) {
    return fail("config.json: " + error);
}

if (!config.has("port") || !config["port"].is_number()) {
    return fail("config.json: 'port' must be a number");
}

Good maintenance tasks for agents

• generate adversarial valid/invalid JSON families;
• compare behavior against established parsers and conformance corpora;
• run sanitizer/fuzz campaigns and minimize failures;
• review serialization and Unicode edge cases;
• search for parser/writer asymmetries;
• synchronize vendored copies and run downstream integration tests.

A useful prompt shape

Ask for evidence in the answer

A good agent completion should say which files changed, what behavioral guarantee changed or stayed fixed, what focused tests were added, which broader suites ran, and what remains unproven. “Implemented successfully” is not enough for parser work.

Keep the human in the loop

Human direction remains valuable for deciding which guarantees matter, whether added complexity is justified, and whether a “fix” accidentally turns a tiny JSON parser into a general serialization framework. The best agent workflow makes those decisions more informed; it does not outsource the project's identity.