Coding agents are getting very good at writing SVG.
That does not mean they are automatically good at making icons.
An SVG can be syntactically valid, structurally clean, and still look wrong when rendered at 24 pixels. A path can be perfectly legal XML and still feel off-center. A stroke can be consistent in code and still look too heavy next to the rest of an icon set.
That is because SVG has two representations at once:
A reliable workflow needs both.
The useful loop is not:
prompt → SVG → done
It is:
choose → render → inspect → adjust
For vector assets, visual feedback is part of correctness.
Agents are naturally good at checking things that can be verified from markup.
They can inspect:
viewBox
paths
groups
fills
strokes
IDs
transforms
masks
gradients
metadata
They can also enforce system rules such as:
grid: 24×24
stroke: 1.5
linecap: round
linejoin: round
color: currentColor
Those checks matter. They reduce structural errors and make automated workflows safer.
But they do not answer the most important visual question:
Does the icon actually look right?
Two icons can use the same grid and stroke width while feeling completely different.
One may look too heavy. Another may appear too small. A mathematically centered symbol may still look optically off-center.
Markup can tell you how the icon is built.
It cannot fully tell you how the icon feels when rendered.
Some problems become visible only after the SVG is turned into pixels.
A circle, triangle, arrow, and asymmetric symbol occupy space differently.
Good icon design often needs optical correction rather than purely geometric alignment.
The same stroke width does not guarantee the same perceived weight.
Dense geometry can look heavier than open geometry.
An icon that looks fine at 128 px may fail at 16 px.
Gaps disappear. Details collapse. Thin features lose clarity.
Icons are rarely judged alone.
A new icon needs to fit the set around it:
[ search ] [ settings ] [ new icon ] [ user ] [ close ]
That means comparing occupied area, stroke density, negative space, corner treatment, and visual center.
These are visual checks, not XML checks.
A better agent workflow looks like this:
1. Retrieve or create the SVG
2. Inspect the structure
3. Apply the change
4. Render the result
5. Inspect the rendered image
6. Compare it with system rules
7. Adjust if needed
8. Validate the final SVG
The key difference is simple:
rendering is not the final step.
Rendering becomes part of the reasoning loop.
Instead of asking:
Did I produce valid SVG?
the agent can ask:
Did I produce the right SVG?
For icons, a single preview is usually not enough.
A practical check should include common interface sizes:
16 px
20 px
24 px
32 px
This is where subtle problems become obvious.
An agent may discover that:
This matters especially when the SVG was:
The file can be valid while the geometry still needs work.
A production-oriented pipeline can stay simple.
Start from an existing icon whenever possible.
Keep its context:
set
icon ID
source
license
version
Check the SVG structure:
viewBox
path count
stroke model
fills
IDs
groups
transforms
Apply the smallest necessary change.
Keep the source flexible. Avoid flattening geometry unless the delivery target requires it.
Generate previews at the sizes used by the product.
Place the result next to icons from the same system.
Look for visual drift.
Fix geometry, spacing, or stroke behavior.
Then render again.
Run structural checks one more time, then generate the final asset or framework-specific output.
That gives you a clean separation:
source SVG
→ visual validation
→ delivery output
For code, we already accept layered validation.
A change may need to:
compile
pass tests
pass linting
pass type checks
SVG needs the same mindset.
For an icon, correctness might mean:
SVG parses ✓
structure is acceptable ✓
system rules are respected ✓
render looks correct ✓
small-size preview works ✓
The visual check is not an optional polish step.
It is part of validation.
That becomes even more important when agents generate or modify assets without constant human supervision.
For SVG, correctness has two layers.
The markup has to be valid.
The rendered result has to be right.
Agents can inspect the first directly.
For the second, they need to see.
choose → render → inspect → adjust
That loop is what turns SVG generation into a reliable vector workflow.