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:
- code the agent can inspect
- an image the agent needs to judge
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.
Valid SVG is not the same as a good icon
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.
What only rendering reveals
Some problems become visible only after the SVG is turned into pixels.
Optical balance
A circle, triangle, arrow, and asymmetric symbol occupy space differently.
Good icon design often needs optical correction rather than purely geometric alignment.
Visual weight
The same stroke width does not guarantee the same perceived weight.
Dense geometry can look heavier than open geometry.
Small-size legibility
An icon that looks fine at 128 px may fail at 16 px.
Gaps disappear. Details collapse. Thin features lose clarity.
Consistency with neighboring icons
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.
The missing step: render before you trust
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?
Render at the sizes that matter
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:
- a gap closes at 16 px
- a detail becomes noisy at 20 px
- an icon feels heavier than its neighbors
- the visual center shifts at small sizes
This matters especially when the SVG was:
- generated by AI
- traced from a raster image
- converted from another icon set
- simplified automatically
- converted from stroke to outline
The file can be valid while the geometry still needs work.
A practical workflow for SVG icons
A production-oriented pipeline can stay simple.
1. Retrieve
Start from an existing icon whenever possible.
Keep its context:
set
icon ID
source
license
version
2. Inspect
Check the SVG structure:
viewBox
path count
stroke model
fills
IDs
groups
transforms
3. Modify
Apply the smallest necessary change.
Keep the source flexible. Avoid flattening geometry unless the delivery target requires it.
4. Render
Generate previews at the sizes used by the product.
5. Compare
Place the result next to icons from the same system.
Look for visual drift.
6. Adjust
Fix geometry, spacing, or stroke behavior.
Then render again.
7. Validate and export
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
Visual feedback is part of correctness
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.
Final thought
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.
Top comments (0)