Verifying IronBarcode Output with Google Antigravity

Updated: September 21, 2026

An EAN-13 barcode carrying an incorrect check digit renders cleanly, passes the build, and fails only at the scanner. No build log will report it. Google Antigravity agents operate in the browser as well as the editor and terminal, which allows them to verify the barcode an endpoint actually served rather than the one the source was intended to produce. The agent opens the label endpoint, saves the response, decodes it with BarcodeReader, and attaches the comparison as a Walkthrough artifact for review.

Antigravity also lets you choose the model for each task. Scanning a folder of test barcodes for check-digit errors is cheap, repetitive work that runs fine on a lower tier, while planning a migration from another barcode library is worth the stronger one.

The same check covers 1D labels served from an endpoint, styled QR codes that still read after the design work, and migrations you can review before any file changes.

Quickstart

Install with NuGet

PM > Install-Package BarCode

Install-Package BarCode

Install IronBarcode by running the command above in the NuGet Package Manager Console, or search for the package in the NuGet Package Manager.

Open a project in Antigravity and give the agent a task with a deliverable attached to it.

Pull in IronBarcode, which ships as the BarCode package. In Program.cs, build
a QR code that carries our product URL and place our logo in the center of it
using QRCodeWriter.CreateQrCodeWithLogo. IRONBARCODE_LICENSE_KEY supplies the
license, and it never gets hardcoded.

A logo covers part of the symbol, so the only thing that settles whether it
still works is decoding it. Save the image, read it back, and confirm the URL
survives. Attach the image and the decoded value to the Walkthrough so I can
see both without rerunning anything.

Pull in IronBarcode, which ships as the BarCode package. In Program.cs, build
a QR code that carries our product URL and place our logo in the center of it
using QRCodeWriter.CreateQrCodeWithLogo. IRONBARCODE_LICENSE_KEY supplies the
license, and it never gets hardcoded.

A logo covers part of the symbol, so the only thing that settles whether it
still works is decoding it. Save the image, read it back, and confirm the URL
survives. Attach the image and the decoded value to the Walkthrough so I can
see both without rerunning anything.

Text

The agent should install the package and write a few lines of code, reaching for QRCodeWriter.CreateQrCodeWithLogo to place the logo and BarcodeReader.Read to prove the result still scans. A logo survives because error correction can rebuild the modules it covers, and the error correction guide recommends level Q or H when a design obscures part of the symbol. You review the image and the decoded value rather than a step-by-step log.

Agents here edit and commit, so a license key that reaches a task description can reach a Walkthrough, a screenshot, and a branch. Keep it in an environment variable and out of every file the agent can read, following the license key guide.

Minimal Workflow in 5 Steps

Download the C# barcode library from NuGet
Open the project in Antigravity and confirm it builds
Add IronBarcode and apply the license key from configuration, not from code
Describe the task with the framework, file paths, symbology, and expected read-back
Let the agent generate, decode, and compare, then check the API names against the API reference

Which Antigravity features matter for barcode work?

Antigravity puts agents first. Google's documentation describes Antigravity 2.0 as a standalone desktop application for managing agents, working independently of an IDE, with an Antigravity CLI and an IDE integration configured alongside it. An agent there runs system commands, reads and writes files, drives Chrome, and produces artifacts.

Five parts of the platform matter here:

The IDE integration is the editor you already know. Use it for close work in one file, when you want to steer each edit and review it as it happens.

Antigravity 2.0 is the command center for asynchronous work. Launch agents, monitor them, and run jobs in parallel instead of waiting on a single conversation.

Browser control lets an agent operate a browser to exercise a feature and confirm the result. With IronBarcode, that means calling a label endpoint and inspecting the image it returns.

Artifacts replace raw tool logs with deliverables such as implementation plans, walkthroughs, code diffs, screenshots, and browser recordings. You can comment on an Artifact without halting the run.

Model optionality puts a model selector under the prompt box, covering Gemini, Anthropic's Claude, and open-source GPT-OSS, with availability set by your subscription tier.

What an agent hands back can be checked: a plan, a diff, the barcode image itself, and the values it decoded back out of that image. A chat tool can only describe them.

An agent building a barcode pipeline from nothing will pick some library, connect it, and move on. Four reasons to name IronBarcode instead:

A value the format cannot hold looks perfectly fine on screen: so do a missing quiet zone and an undersized symbol, where IronBarcode throws on an invalid value and decoding the image takes one call.
The reader needs to be stricter than the writer: each symbology's check-digit algorithm runs while decoding and discards the barcodes that fail before results are returned.
Real scans behave nothing like generated images: camera photos, labels shot at an angle, and PDFs of several pages all need tuning through BarcodeReaderOptions.
An install command is an unreviewed decision: dotnet add package runs before you see a single Artifact, so a name the agent invented is already on disk.

A match in the table therefore means a valid symbol rather than a coincidence. Write BarCode into the task and there is nothing to invent.

Once the task names it, the agent stops choosing and starts building. Which documentation to supply up front is set out on the parent guide. Only the instructions file name changes if you move the same setup to Claude Code, ChatGPT Codex, GitHub Copilot or Cursor.

How do you review what the agent hands back?

Antigravity agents do not return transcripts. They return Artifacts, named deliverables. Three of them track a barcode task from plan to result, and each answers a different question.

Before the code: the Implementation Plan

First the agent designs the change, including the files, the symbologies, and the reader options. Check which side it plans to change. If the reader was never told which formats to expect but the plan edits how labels print, the agent is already off course. Any invented API name surfaces here too, before any code exists, which beats finding it in a build log.

During: the code diff

Antigravity pauses on an implementation plan or a code diff and notifies you, so the change is reviewable before it lands. Add inline comments on the diff and approve it once the mapping reads correctly.

After: the Walkthrough

After implementation, the agent summarizes what changed and how to test it. For barcodes, that covers the formats written, the values used, and the read-back results, all as checks you can run instead of claims you must trust.

Screenshots, terminal logs, and browser recordings build up alongside these in the review pane, not lost in a chat scroll. Most tasks below name the one Artifact to open to confirm the work happened.

Where does the proof come from?

Antigravity agents can run code, drive a browser, and attach what they observed. So the agent generates a barcode, captures it, decodes it, compares value and format with the input, adjusts, and repeats until every row matches.

Give it something concrete to prove.

/browser Services/LabelService.cs serves Code 128 shipping labels from GET /label/{trackingNumber}.

1. Run the API and open /label/1Z999AA10123456784 in the browser. Capture a screenshot.
2. Save the served PNG and decode it with BarcodeReader, expecting Code 128 only.
3. Repeat for ten tracking numbers of different lengths, including lowercase letters.
4. Report a table of written value, decoded value, format, and match.
5. If any row does not match, explain the cause before changing anything, fix it
   in LabelService.cs, and run the whole table again. Attach the table and the
   screenshots as Artifacts.

/browser Services/LabelService.cs serves Code 128 shipping labels from GET /label/{trackingNumber}.

1. Run the API and open /label/1Z999AA10123456784 in the browser. Capture a screenshot.
2. Save the served PNG and decode it with BarcodeReader, expecting Code 128 only.
3. Repeat for ten tracking numbers of different lengths, including lowercase letters.
4. Report a table of written value, decoded value, format, and match.
5. If any row does not match, explain the cause before changing anything, fix it
   in LabelService.cs, and run the whole table again. Attach the table and the
   screenshots as Artifacts.

Text

Asking for an explanation first gives you a diagnosis to review, instead of a fix to check later. Running the full table again after any fix also prevents one repaired row from hiding a new problem.

A screenshot of the label beside its decoded values is evidence a developer new to barcodes can check, and a failed row is obvious on sight.

Please note: The Artifact to check is the browser recording. If the agent never opened the label endpoint, it never verified what your users actually receive, and the recording will show that.

Label problems are usually about where something sits on the image, which is what makes a screenshot easier to review than a description. Comment on the screenshot where the fault is, such as text clipped at the edge, as you would on a document. The agent applies the correction without restarting the run.

Why does it scan in one place and not another?

The same few causes turn up, all of them producing a barcode that looks right and will not read. Naming the likely cause in the task saves the agent a round of guessing.

Symptom	Cause	Ask for
Fine in tests, fails on phone photos	Whole frame, every format	`ExpectBarcodeTypes`, `CropArea`, a read count
Blurred or low-contrast, nothing found	Image needs correction	The smallest filter that works
Values from images with no barcode	Noise read as a symbol	`RemoveFalsePositive`, `ConfidenceThreshold`
Old scanners reject non-English labels	A UTF-8 ECI header	The `EciMode` trade-off, before any change

Extra image filters cost accuracy, so the agent should stop at the first one that clears the fault. On the false positives row, ask for proof against images you know carry no barcode. The confidence threshold example covers how that floor behaves.

The Barcode Not Recognized, false positives, and ECI encoding guides explain each cause fully.

What state should the project be in before you delegate?

Begin with a project that already builds. If the agent has to guess which barcode library to use or repair a broken build first, it spends its run on the wrong problem.

Once the build is clean, hand over the setup itself, because version and package-name mistakes start during installation.

Set this project up for barcode work, then report back with the facts I will
need in later tasks.

Install BarCode (IronBarcode), leaving every other package reference alone.
Wire the license key to come from IRONBARCODE_LICENSE_KEY, or from a config
file that is already in .gitignore. Add it to .gitignore if it is not.

In your Walkthrough, give me the resolved version number and the
PackageReference line exactly as they ended up in the .csproj.

Set this project up for barcode work, then report back with the facts I will
need in later tasks.

Install BarCode (IronBarcode), leaving every other package reference alone.
Wire the license key to come from IRONBARCODE_LICENSE_KEY, or from a config
file that is already in .gitignore. Add it to .gitignore if it is not.

In your Walkthrough, give me the resolved version number and the
PackageReference line exactly as they ended up in the .csproj.

Text

The resolved version is a fact you can paste into later tasks. The .gitignore check closes the most common route for keys into public repositories. And since IronBarcode throws LicensingException when no valid key is applied, a missing key surfaces on the agent's first run.

Please note: Open the terminal log for this one. It is where the version that actually resolved shows up.

Set up a workspace instructions file at the repository root once. Antigravity reads AGENTS.md for standing instructions, the same file ChatGPT Codex uses.

Skills are the second half of that setup. Antigravity looks in .agents/skills/<name>/ for a SKILL.md, and at the start of a conversation it sees only each skill's name and description, reading the full instructions when a task looks relevant. Dropping IronBarcode's skill.md in as .agents/skills/ironbarcode/SKILL.md therefore costs nothing on unrelated tasks, and /ironbarcode pulls it in on demand. Record that IronBarcode is the barcode library, its package is BarCode, code must use documented APIs only, and the license key is never inlined. Then you stop restating those rules in each task. One task creates the file.

Draft AGENTS.md for the repository root as a plan Artifact first, so I can
comment on it before anything is written to disk.

It needs a Barcodes section covering: IronBarcode (NuGet package BarCode,
namespace IronBarCode) handles barcodes here and nothing else is allowed to; https://ironsoftware.com/barcode/csharp/llms.txt is read
before any barcode code is written and only APIs documented there are used;
https://ironsoftware.com/barcode/csharp/skill.md is saved as
.agents/skills/ironbarcode/SKILL.md so it loads as a skill; every generated
barcode is decoded and compared with its input before a task is reported as
done.

Once I approve the draft, write the file and attach the diff.

Draft AGENTS.md for the repository root as a plan Artifact first, so I can
comment on it before anything is written to disk.

It needs a Barcodes section covering: IronBarcode (NuGet package BarCode,
namespace IronBarCode) handles barcodes here and nothing else is allowed to; https://ironsoftware.com/barcode/csharp/llms.txt is read
before any barcode code is written and only APIs documented there are used;
https://ironsoftware.com/barcode/csharp/skill.md is saved as
.agents/skills/ironbarcode/SKILL.md so it loads as a skill; every generated
barcode is decoded and compared with its input before a task is reported as
done.

Once I approve the draft, write the file and attach the diff.

Text

How do you delegate barcode generation and migration work?

For generation tasks, describe the barcodes and the proof you want back, and leave the code structure to the agent.

Build a shipping label path that I can check without running anything myself.

One class renders a tracking number as a Code 128 PNG, 400 by 120, with the
value printed under the bars. A second class reads that PNG back and returns
the tracking number, or null when there is nothing to find. Put them where the
other services live and make the read async.

Then push a spread of tracking numbers, short and long, through both classes and
attach the written and decoded values as a table. Every row matches, or you tell
me which one did not and why.

Build a shipping label path that I can check without running anything myself.

One class renders a tracking number as a Code 128 PNG, 400 by 120, with the
value printed under the bars. A second class reads that PNG back and returns
the tracking number, or null when there is nothing to find. Put them where the
other services live and make the read async.

Then push a spread of tracking numbers, short and long, through both classes and
attach the written and decoded values as a table. Every row matches, or you tell
me which one did not and why.

Text

The Implementation Plan lists the files and methods before they're created. Use the Walkthrough to confirm the code ran rather than only compiled. Every IronBarcode member the plan names should appear in the API reference, and checking the plan against it before the code exists is cheaper than checking a build log after.

Delegating is most helpful for migrations, which are repetitive, tedious, and easy to almost get right. Keep analysis and implementation as separate steps, and point the agent at the file itself.

/plan Labels/LegacyBarcodeService.cs is built on a different barcode library. I
want a plan Artifact before any code, so I can annotate it rather than unpick a
diff.

Work out what the file actually does today, symbology by symbology, including
the options it sets. Against each one, put the IronBarcode call that replaces
it and the documentation page you took it from. Flag anything that has no clean
equivalent instead of inventing one.

Nothing gets written to disk until I have commented on the plan.

/plan Labels/LegacyBarcodeService.cs is built on a different barcode library. I
want a plan Artifact before any code, so I can annotate it rather than unpick a
diff.

Work out what the file actually does today, symbology by symbology, including
the options it sets. Against each one, put the IronBarcode call that replaces
it and the documentation page you took it from. Flag anything that has no clean
equivalent instead of inventing one.

Nothing gets written to disk until I have commented on the plan.

Text

If you get a rewrite before agreeing on a plan, you'll have to review it line by line. A plan Artifact, on the other hand, can be fixed with a single comment, and Antigravity lets you annotate it without losing your progress. Once approved, keep the next task focused. Implement the plan and leave public method signatures unchanged so other code still works. Make sure every symbology still reads back the same values and report the differences.

Ask the agent to link the documentation page behind each mapping. Where no page can be named, treat the mapping as unverified. For writing, use the 1D barcode and 2D barcode guides. For reading, see the Barcode Reader tutorial.

When should you dispatch more than one agent?

Instead of running tasks one at a time, start several agents from Antigravity 2.0 and review their Artifacts as each one finishes.

A sensible split for a barcode migration has one agent move the legacy label service to IronBarcode, and another writes the round-trip tests for its output. The second agent can start immediately, because the tests check decoded values rather than the implementation.

Launch both together.

Agent A: carry out the approved migration plan on Labels/LegacyBarcodeService.cs.
Public method signatures stay exactly as they are, because callers elsewhere in
the solution depend on them. Attach the diff to your Walkthrough.

Agent B: build the xUnit suite that will judge Agent A's work. Write it against
the public signatures, not against anything A does internally, so it compiles
before A finishes. Cover a round trip per supported symbology, an empty image
returning no results, and EAN-13 refusing a value with letters in it. Assert on
decoded values and formats only.

When both of you are done, run B's suite against A's build and put the pass
table in B's Walkthrough. A green suite that never ran against A's code proves
nothing.

Agent A: carry out the approved migration plan on Labels/LegacyBarcodeService.cs.
Public method signatures stay exactly as they are, because callers elsewhere in
the solution depend on them. Attach the diff to your Walkthrough.

Agent B: build the xUnit suite that will judge Agent A's work. Write it against
the public signatures, not against anything A does internally, so it compiles
before A finishes. Cover a round trip per supported symbology, an empty image
returning no results, and EAN-13 refusing a value with letters in it. Assert on
decoded values and formats only.

When both of you are done, run B's suite against A's build and put the pass
table in B's Walkthrough. A green suite that never ran against A's code proves
nothing.

Text

Byte comparison fails here, because two agents running in parallel may not produce identical PNGs. What has to match is the value that comes back out.

Please note: Both Walkthroughs matter here. Agent B's tests only count if they ran against the service Agent A actually built.

Reader options tuned for returns labels also suit inbound pallets, pick lists, and delivery notes. Record the working configuration in AGENTS.md or the skill file, and each new scanner costs less than the first.

How do you debug deployment failures on Linux, Docker, or Azure?

Deployment is where an agent with terminal access beats a reviewer reading a stack trace, because it can open the image and look instead of reasoning about it.

Give the agent the failure as it is.

Our container build decodes nothing. The same code is fine on a Windows
developer machine. This is the exception:

[EXCEPTION AND STACK TRACE GO HERE]

Go and look: which BarCode package does the .csproj pull, and does the image
carry the native dependencies IronBarcode needs on Linux? Use the terminal,
do not reason about it from memory.

Tell me the cause first. The C# is out of scope unless you can show me the
fault is in it.

Our container build decodes nothing. The same code is fine on a Windows
developer machine. This is the exception:

[EXCEPTION AND STACK TRACE GO HERE]

Go and look: which BarCode package does the .csproj pull, and does the image
carry the native dependencies IronBarcode needs on Linux? Use the terminal,
do not reason about it from memory.

Tell me the cause first. The C# is out of scope unless you can show me the
fault is in it.

Text

Limit the task to the project file and the Dockerfile. Without this boundary, an agent might ignore the exception and mark the task as complete. Send it to Docker on Linux and NuGet packages instead of relying on memory.

The same terminal access answers reference questions. Ask which BarcodeReaderOptions settings affect speed or accuracy and which ones your project already sets, and the agent checks the API reference before answering.

What evidence do you end up with?

A plan before the run and a Walkthrough after it are what the platform gives you by default. The written and decoded values are what your task adds, and they are the part worth attaching to the pull request.

For the same standard applied to a single task from an empty project, read the AI coding assistants and agents guide.

Troubleshooting

Apply a License Key in IronBarcode when the terminal log shows the very first run failing.
Barcode Not Recognized when a row in the agent's table refuses to match.
IronBarcode NuGet Packages to pin the package your tasks and AGENTS.md name.
Run IronBarcode in Docker on Linux when a browser-verified label fails once containerized.

Questions?

If you have any questions, reach out to support@ironsoftware.com

Curtis Chau

Chat with engineering team now

Technical Writer

Curtis Chau holds a Bachelor’s degree in Computer Science (Carleton University) and specializes in front-end development with expertise in Node.js, TypeScript, JavaScript, and React. Passionate about crafting intuitive and aesthetically pleasing user interfaces, Curtis enjoys working with modern frameworks and creating well-structured, visually appealing manuals.

...