Most of this README is generally "hey, you can do tricks with a README on your profile on GitHub". However, first:
As of Aug 2026, I don't quite like LLM-generated things. They have uses. Using LLM generation can be a good shortcut. It can be a learning tool; I can learn about a possible approach if I don't have time to actually find a good example (or if it might not exist! because how many people write DirectPlay or COBOL code?). Or for short scripts, fine.
I will use LLM generation for my entertainment in so-called 'agentic' mode, and I may use it for work, to execute operational things under heavy supervision. And I think LLMs can be really nice as fancy autocompletion engines (which is what they technically are). I'll even throw it at the cloud if the access is free or near-free, as long as it's not otherwise an ethically problematic situation and there's no risk if or when an LLM API operator chooses to "help themselves" to the code for training or other examination purposes.
But -- I don't really like reviewing LLM-generated code. Code sent to a human reviewer needs to be reviewed by the sender, and it should not be copious. I know, a crazy idea, but if I am reviewing something and putting my LGTM / Approval / merge commit on it, I would like to actually understand what is happening in code and in unit tests (if applicable).
A small change to the codebase that is LLM generated can be fine. A medium-size or larger change may be ok when the sender applies greater scrutiny than they would to a human commit / PR / CL. And it may benefit from a rewrite: a human learning from the generated code and then judiciously applying the change to the codebase themselves (through a rewrite or careful copy-pasting while minimizing the changes to review) will both ensure the human has actually read the code, and slow the pace of change so that a reviewer can review it.
Since I don't like reviewing LLM generated code (unless above applies), I don't expect others to read it when I do it.
I will also, for the time being, avoid publishing slop in public repositories on my account, unless it satisfies some of the above criteria. It may happen, I just want to avoid it.
I already have some (mostly) auto-generated repositories marked as private. They have fun things in them. They're fun experiments and/or prototypes. I don't think they're worth publishing as they stand.
LLMs and "agentic" stuff can be timesavers, but holding them un-judiciously does have impact on both our craft and our hobby. I have played with LLMs and "agents" and "MCPs" enough that I have uses for them, but as far as publicly visible code goes, I want to try to keep the slop to a minimum. Not zero (it'll seep through, I suspect, and some prototypes might be fun to put out as-they-are at some point), but also curbing the enthusiasm seems like a responsible thing to do.
Tip
ivucica/ivucica is a ✨ special ✨ repository because its README.md (this file) appears on your GitHub profile.
ivucica/ivucica is a ✨special ✨ repository that you can use to add a README.md to your GitHub profile. Make sure it’s public and initialize it with a README to get started.
The name of the repo matches the username.
There are more tricks with READMEs.
- For organizations, the profile-wide readme goes into a repo named
.github. - Alerts syntax
- README information
- Rendering maps and 3D models
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"id": 1,
"properties": {
"ID": 0
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[-90,35],
[-90,30],
[-85,30],
[-85,35],
[-90,35]
]
]
}
}
]
}
{
"type": "Topology",
"transform": {
"scale": [0.0005000500050005, 0.00010001000100010001],
"translate": [100, 0]
},
"objects": {
"example": {
"type": "GeometryCollection",
"geometries": [
{
"type": "Point",
"properties": {"prop0": "value0"},
"coordinates": [4000, 5000]
},
{
"type": "LineString",
"properties": {"prop0": "value0", "prop1": 0},
"arcs": [0]
},
{
"type": "Polygon",
"properties": {"prop0": "value0",
"prop1": {"this": "that"}
},
"arcs": [[1]]
}
]
}
},
"arcs": [[[4000, 0], [1999, 9999], [2000, -9999], [2000, 9999]],[[0, 0], [0, 9999], [2000, 0], [0, -9999], [-2000, 0]]]
}
solid cube_corner
facet normal 0.0 -1.0 0.0
outer loop
vertex 0.0 0.0 0.0
vertex 1.0 0.0 0.0
vertex 0.0 0.0 1.0
endloop
endfacet
facet normal 0.0 0.0 -1.0
outer loop
vertex 0.0 0.0 0.0
vertex 0.0 1.0 0.0
vertex 1.0 0.0 0.0
endloop
endfacet
facet normal -1.0 0.0 0.0
outer loop
vertex 0.0 0.0 0.0
vertex 0.0 0.0 1.0
vertex 0.0 1.0 0.0
endloop
endfacet
facet normal 0.577 0.577 0.577
outer loop
vertex 1.0 0.0 0.0
vertex 0.0 1.0 0.0
vertex 0.0 0.0 1.0
endloop
endfacet
endsolid




