Engineering at @xgeeksio | thinking about where machines should end and humans should begin.
Joined September 2009
- Tweets338
- Following1.2K
- Followers173
- Likes428
Pinned Tweet
you don't design an agentic system. you distill it from real production. designers who work upfront produce the wrong categories because they don't know yet what production will reveal.
this isn't content-specific.
CLAUDE.md files across 7 engineering projects i've documented all emerged the same way: distilled from caught failures. a bug that recurred 3 times. a deployment convention that stabilized.
different domain, same discipline.
teams that design agentic systems upfront produce wrong categories.
someone builds a skill file with 15 sections before using the system. production makes corrections that don't fit. the file bloats, categories overlap, and it becomes an inheritance everyone works around.
the commit that encodes an agentic system's structure is cheap.
the judgment to recognize when a layer is ripe is expensive.
and it compounds only for someone doing real production work. not for someone thinking about the shape of the system in the abstract.
designers who work upfront produce the wrong categories. they don't know yet what production will reveal.
"ai-sounding patterns" is a useful category only because 16 of them got produced in real writing. the abstraction came from the output. it did not precede the output.
three signals for when to extract a rule from production:
1. same correction happening 3+ times
2. workflow proving stable across sessions
3. implicit conventions getting referenced explicitly
each is weak. together they mean a layer is ripe.
what actually costs.
the commit encoding the extraction is cheap. the judgment to recognize when a layer is ripe is the expensive part. and it compounds only for someone doing real production work, not for someone thinking about the shape in the abstract.
the readable architecture in someone's blog post is the artifact.
the discipline that produced it is the work.
this is piece 2 of 2 on ai-native content engine architecture.
full writeup: goncalves.me/posts/you-dont-…
generic ai content is a commodity. anyone with a claude subscription can prompt the same model and get fluent output.
first-party data isn't a commodity.
neither is the operator's voice.
an ai-native engine compounds on both. that's the architecture.
five design choices make an engine ai-native:
1. agentic memory (4-layer context)
2. distilled structure (not pre-designed)
3. multi-tool deployment (non-git ok)
4. feedback-accumulating rules
5. source decomposition
none are emergent. all are design decisions.
"ai-assisted" and "ai-native" are not synonyms.
ai-assisted: bolt ai onto traditional publishing. structure unchanged.
ai-native: architect publishing as an agentic system from first principles.
different categories. different outputs. different moats.
same model. different architecture. different output.
12 pieces shipped:
11 on a personal blog.
1 enterprise piece split into 5 linkedin posts as "AI leaders that ship."
same source file. different containers per channel.
voice is a second moat.
persona file + drafting skill + editorial pass enforce one specific voice. swap the persona, same model, same data, different engine.
ai-native content resists replication on two axes at once: the data and the operator identity.
models keep getting better. the specific data and the specific voice don't get replaced by better models.
they compound alongside them.
full writeup: buff.ly/gpaXAEg