I will be publishing content in 4 separate tracks
1. ANTik / public assembly
a real log of my product development
architecture, browser runtime, profiles, proxies, fingerprinting, sync mode, extensions, bugs, rewrites, ai agents, bad decisions and fixes.
! more like:
what was built -> what broke -> what changed -> what did I learn
2. vibecoding/ai workflows
practical ai workflows for operations, business, marketing, research, learning, content, and automation.
no operational fees
! actual processes:
input -> aiwork -> verification -> output -> human decision
3. laboratory of personal artificial intelligence tools
little tools that I want to create and use myself
- wallet monitors
- telegram bots.
- x/telegram/discord analytics
- dashboards
- alerts
- exchange agents are read-only
- open source mini tools
! essence:
manual monitoring -> small system -> useful signal
4. ai radar/market notes
fresh themes from the market
- ai agents
- ai coding
- new tools
- open source repositories
- ai x web3, defi
- security
- crypto stories
! not just news
the goal is to find something that is actually worth thinking about and turn it into a useful post
the same idea in all tracks:
- more systems
- more workflows
- more real examples
gmgn readers, about me:
I’m 40. I’m from KZ🇰🇿
Married for 18 years, proud father of two adult children
I have two bachelor's degrees - one in programming and one in accounting and financial auditing
Over the years, I've had many careers, from a warehouse security guard to the head of a design firm with 100 employees
I've worked in retail, government procurement, agricultural accounting, construction, and even as an architect specializing in architectural details and elements
I have developed, launched and sold various goods, products and services
Then Web3 happened
I’ve been in Web3 and IT for the last 5 years. About 3.5 of them very deeply
Testnets, liquidity farming, trading, memecoins, nft , multi-accounting, automation for 5000+ accounts
I wasn’t watching Web3 from the outside. I lived inside it, with my hands on the keyboard
The funny part is that I have a programming degree, but I never really liked coding
I understood logic, systems, business, and how products should work. But writing code by hand always felt like a wall
AI broke that wall for me
For the last 3 months, I’ve been almost fully inside vibe coding. 16–18 hours a day
Sleep <-> Food <-> Build
I tried building 8 products:
-> 3 were thrown away
-> 1 was built, sold, and implemented
-> 2 are in active development
-> 2 are parked for later
- The first one that worked was a B2B system for restaurant supply automation. It’s already running, the client is happy, and now I’m thinking about how to carefully add AI into it
- Another project I started is AI OS Library. For me, it’s a readable library for AI - somewhere between RAG, a personal knowledge base, and a self-learning assistant
Not just a place to store text, but a system that structures information so AI can actually use it with clear logic
But my main focus now is ANTik - An anti-detect browser
I’ve used AdsPower for about 4 years. It’s good. It works. But when you use a tool every day for years, you start seeing the pain too
At some point I started thinking
“why don’t I build my own?”
~ Not because the market is big
~ Not because AI will write everything
~ Not because I urgently need a SaaS
! Because I’ve been the user of these tools for years
ANTik is around 30% ready now
I want part of it to be open source, so anyone can download it, install it, and Use it for FREE
There will probably be a paid version later, but I don’t want to run ahead
Right now I care more about building something useful, and clear
- I’m not trying to look like a classic dev
- I’m more like a person who spent years inside markets, systems, processes, and chaos
And now, with AI, I can finally turn that experience into real products
aisama.code (@on_punchman) is my stage character
- A profile about vibe coding, AI, and a bit of Web3
The texts, images, and videos are made with AI
Even this post
! But the experience behind it is real
every personal AI tool needs an Audit Log
*if I cannot see what the tool did, I cannot trust it
log fields:
run_id / time / source / input_hash / tool_version / prompt_version / model / action / output_summary / status / error / human_override / linked_record
! it makes the tool debuggable
example:
a wallet bot sends an approval warning
the log should show:
? which RPC/source returned the event
? which contract was decoded
? which rule fired
? which prompt summarized it
? which Telegram message was sent
? whether I marked it useful or noise
now I can improve the system
~ if alerts are noisy, check which rule fires too often
~ if summaries are vague, check prompt version
~ if data is wrong, check source
useful commands:
/log last
/log errors
/log source wallet_monitor
/log run <id>
/log noise
tool shape:
action -> structured log -> searchable console -> manual correction
! a small log console is often more important than a pretty dashboard
A personal alert system needs a Router
Not every event deserves a Telegram message
i would keep an alert_rules table:
- source
- event_type
- severity
- threshold
- cooldown
- route
- summary_format
- requires_action
- expires_after
routes can be different:
- instant Telegram alert
- daily digest
- research queue
- watchlist update
- silent log
- ignore
example:
> wallet approval from watched wallet -> instant alert
> small token transfer -> daily digest
> same X narrative repeated 20 times -> research queue
> known spam airdrop mention -> ignore
! the AI layer writes context
! the rules decide routing
! AI summaries are cheap to generate but expensive to read all day
a useful alert answers the questions:
? what happened,
? why it passed the rule,
? source link,
? what changed,
? what action is expected,
? button or command for next step.
tool shape:
event -> rule match -> route -> AI context -> alert/log
the first version can be small
~ one table
~ one Telegram bot
~ five alert rules
~ no chaos
AI Research gets stronger when it records contradictions
*most research workflows collect supporting evidence - that is the weak version
for serious research I want a contradiction log:
- claim
- source
- date
- who says it
- what evidence supports it
- what evidence conflicts with it
- what is still unknown
- confidence
- next check
example:
> claim: this product has strong developer adoption
> support: GitHub activity, docs updates, X discussion, integrations
> conflict: low issue activity, small Discord, few production case studies, mostly founder-driven content
now the memo is different, It says:
"visible attention, but adoption evidence is still weak"
the useful workflow:
research question -> source list -> claim extraction -> contradiction log -> memo
! сode is good at assembling text
! AI is good at comparing disparate text
! human is good at determining which contradictions are significant
*without a contradiction log, AI research becomes a confident summary of whatever it found first
back-office AI starts with the queue
for invoices, contracts, receipts, CRM exports, support reports and internal requests, the first useful object is a triage ledger
fields I would keep:
- item_id
- source
- document_type
- received_at
- extracted_fields
- confidence
- validation_errors
- owner
- status
- review_note
- final_record_id
the workflow becomes simple:
new item -> extract fields -> validate rules -> route exception -> approve -> write to database
Example: invoice processing
> AI extracts vendor, amount, date, tax fields, currency and payment terms
> rules check duplicates, missing tax id, wrong currency, strange amount and unknown vendor
> only exceptions go to a human
! the important part is reducing the queue from 100 manual checks to 12 real exceptions
Back-office AI becomes useful when it has:
- clear input
- fixed fields
- validation rules
- exception routing
- record of what changed
*that is the system I would build first
from the ANTik build log: Fingerprints
*user agent ~ screen ~ timezone ~ locale ~ WebGL ~ fonts ~ hardware ~ language
randomly distributing fields can easily lead to incorrect fingerprint generation
! the result may seem unique, but unique is not enough
! the profile also has to be coherent
! modern anti-fraud systems detect conflicts between signals
examples:
# browser version must fit the engine
# OS must fit platform and user agent
# locale must fit language and timezone
# WebGL vendor must fit device class
# hardware claims must look plausible
# proxy geo must not fight timezone
# automation layer must not expose obvious artifacts
! in ANTik, a fingerprint is considered as a set of related signals
the profile spec starts with presets:
win11... win10... macos... linux... iphone... android... auto
> auto picks desktop presets only
*mobile fingerprints must be explicit because touch, viewport and device behavior are different
the hard part is not generating values
! the hard part is keeping the profile possible
from the ANTik build log: Profiles
the profile is the main domain object in ANTik
it connects the parts that make the product useful:
- fingerprint
- group
- tags
- accounts
- audit log
- proxy
- runtime state
- cookies
- extensions
- automation
the first profile spec fixed several important decisions
> every profile must have one fingerprint
> profile without fingerprint is invalid
> the fingerprint is stored as a separate structured entity, not embedded as random JSON inside the profile row
> one profile can belong to one group
> one profile can have many tags
> accounts belong to profiles
> passwords and TOTP secrets are encrypted
> profile names, notes, groups, tags and fingerprint metadata stay readable
> audit log records profile operations without sensitive fields
! this gave the product a clear center
when later modules appear, they attach to profile:
- proxy assignment
- browser launch
- cookies
- extensions
- sync
- automation
*if the profile model is weak, every next module becomes harder to connect
So this stage was about defining the object that the whole product revolves around
A personal alert system needs a Router
Not every event deserves a Telegram message
i would keep an alert_rules table:
- source
- event_type
- severity
- threshold
- cooldown
- route
- summary_format
- requires_action
- expires_after
routes can be different:
- instant Telegram alert
- daily digest
- research queue
- watchlist update
- silent log
- ignore
example:
> wallet approval from watched wallet -> instant alert
> small token transfer -> daily digest
> same X narrative repeated 20 times -> research queue
> known spam airdrop mention -> ignore
! the AI layer writes context
! the rules decide routing
! AI summaries are cheap to generate but expensive to read all day
a useful alert answers the questions:
? what happened,
? why it passed the rule,
? source link,
? what changed,
? what action is expected,
? button or command for next step.
tool shape:
event -> rule match -> route -> AI context -> alert/log
the first version can be small
~ one table
~ one Telegram bot
~ five alert rules
~ no chaos
a personal AI tool needs storage
because without storage the tool has no memory
+ it can only react
- it cannot compare
- it cannot show history
- it cannot explain what changed
for small tools, storage can be simple:
- SQLite
- postgres
- JSON files
- markdown notes
- folder structure
the choice depends on the data
> events -> database
> long notes -> markdown
> raw files -> folder
> fast queries -> SQL
> daily summaries -> notes
example:
wallet transaction -> raw event -> parsed fields -> risk tag -> alert status -> human decision
or:
telegram post -> source channel -> topic -> summary -> saved signal -> used in content / ignored
the storage layer should keep both:
! raw input
! processed output
raw input lets you check the AI
processed output lets you use the system
source -> raw storage -> parsed record -> AI summary -> decision -> history
! that is the base layer for a useful personal tool
back-office AI starts with the queue
for invoices, contracts, receipts, CRM exports, support reports and internal requests, the first useful object is a triage ledger
fields I would keep:
- item_id
- source
- document_type
- received_at
- extracted_fields
- confidence
- validation_errors
- owner
- status
- review_note
- final_record_id
the workflow becomes simple:
new item -> extract fields -> validate rules -> route exception -> approve -> write to database
Example: invoice processing
> AI extracts vendor, amount, date, tax fields, currency and payment terms
> rules check duplicates, missing tax id, wrong currency, strange amount and unknown vendor
> only exceptions go to a human
! the important part is reducing the queue from 100 manual checks to 12 real exceptions
Back-office AI becomes useful when it has:
- clear input
- fixed fields
- validation rules
- exception routing
- record of what changed
*that is the system I would build first
documents to DataBase is one of the most practical AI Workflows
lot of business work still looks like this:
- PDF
- invoice
- receipt
- contract
- statement
- email attachment
- manual copy-paste
- spreadsheet
! AI is useful when it turns this into structured notes
~ workflow:
document -> text extraction -> field detection -> validation -> database row -> review queue -> report
! don't trust every extracted field
! the important part is the validation
you need:
- original file
- extracted text
- parsed fields
- confidence
- missing fields
- human review statu,
- final structured record
TaxHacker is a good reference for this kind of direction
It is a self-hosted AI tool for receipts, invoices and PDF documents
repo: https://t.co/mGU0rZUcZY
! the useful idea:
documents -> extracted fields -> structured database owned by the user
this is not flashy AI
It is boring automation that removes real back-office work
from the ANTik build log: Profiles
the profile is the main domain object in ANTik
it connects the parts that make the product useful:
- fingerprint
- group
- tags
- accounts
- audit log
- proxy
- runtime state
- cookies
- extensions
- automation
the first profile spec fixed several important decisions
> every profile must have one fingerprint
> profile without fingerprint is invalid
> the fingerprint is stored as a separate structured entity, not embedded as random JSON inside the profile row
> one profile can belong to one group
> one profile can have many tags
> accounts belong to profiles
> passwords and TOTP secrets are encrypted
> profile names, notes, groups, tags and fingerprint metadata stay readable
> audit log records profile operations without sensitive fields
! this gave the product a clear center
when later modules appear, they attach to profile:
- proxy assignment
- browser launch
- cookies
- extensions
- sync
- automation
*if the profile model is weak, every next module becomes harder to connect
So this stage was about defining the object that the whole product revolves around
From the ANTik build log: Security Layer
the product processes sensitive data:
- profile accounts
- passwords
- 2FA secrets
- proxy credentials
- cookies and browser state later
*I added a master password early
The crypto design is simple at the product level:
- master password unlocks the app
- sensitive fields are encrypted with a random 256-bit DEK.
! the DEK is never stored raw
DEK is wrapped by:
- password-derived key
- ecovery-seed-derived key
so there are two recovery paths:
- master password
- recovery seed
technically the stage includes:
- Argon2id for password KDF
- AES-256-GCM for encryption
- BIP-39 recovery seed
- optional system keychain
- lock / unlock / status API
- middleware that blocks business endpoints while the app is locked
at this stage there was no UI for it yet
setup and unlock worked through REST / MCP
that is not convenient for a user, but it is correct for the architecture
if security comes after profiles, accounts and cookies, then every old field has to be revisited
i wanted the product to treat secrets correctly before the useful modules started to grow
a personal AI tool needs storage
because without storage the tool has no memory
+ it can only react
- it cannot compare
- it cannot show history
- it cannot explain what changed
for small tools, storage can be simple:
- SQLite
- postgres
- JSON files
- markdown notes
- folder structure
the choice depends on the data
> events -> database
> long notes -> markdown
> raw files -> folder
> fast queries -> SQL
> daily summaries -> notes
example:
wallet transaction -> raw event -> parsed fields -> risk tag -> alert status -> human decision
or:
telegram post -> source channel -> topic -> summary -> saved signal -> used in content / ignored
the storage layer should keep both:
! raw input
! processed output
raw input lets you check the AI
processed output lets you use the system
source -> raw storage -> parsed record -> AI summary -> decision -> history
! that is the base layer for a useful personal tool
sometimes, and quite often for many personal AI tools, a Telegram bot is a better first interface than a control panel
telegram is great for:
- alerts
- quick commands
- manual approval
- short summaries
- status checks
- simple entrances
example:
new wallet transaction -> AI summary -> Telegram alert -> approve/ignore/save
or:
new GitHub release -> changed files -> AI summary -> submit to bot
or:
new Telegram/X signal -> categorize -> send only important elements
telegram bot is just an interface, but there's a real system behind it:
data sources -> worker -> database -> AI summary -> bot message -> human action
*this is useful because it allows you to reduce the size of the tool
> no heavy user interface
> no dashboard, no data yet
> no feeling of a fake product
! just a work cycle that I can use every day
documents to DataBase is one of the most practical AI Workflows
lot of business work still looks like this:
- PDF
- invoice
- receipt
- contract
- statement
- email attachment
- manual copy-paste
- spreadsheet
! AI is useful when it turns this into structured notes
~ workflow:
document -> text extraction -> field detection -> validation -> database row -> review queue -> report
! don't trust every extracted field
! the important part is the validation
you need:
- original file
- extracted text
- parsed fields
- confidence
- missing fields
- human review statu,
- final structured record
TaxHacker is a good reference for this kind of direction
It is a self-hosted AI tool for receipts, invoices and PDF documents
repo: https://t.co/mGU0rZUcZY
! the useful idea:
documents -> extracted fields -> structured database owned by the user
this is not flashy AI
It is boring automation that removes real back-office work
comments are sometimes Raw Sales Data
~ people ask questions
~ raise objections
~ compare alternatives
~ describe the pain
~ ask for price
~ ask to set it up
~ ask if this is suitable for their case
most of this disappears under the post
a useful AI workflow looks like this:
comment/DM -> categorize intent -> extract problem -> enrich profile -> create interest -> draft response -> person approves
! the important part is not missing the signal, not automation for the sake of automation.
AI can help separate:
> real purchase intention
> curiosity
> support issue
> objection
> spam
> idea of content
then the output might go somewhere useful:
- CRM
- task list
- content lag
- support line
- follow-up project
! this is where marketing and sales come together through a cycle:
publish -> listen -> categorize -> reply -> save -> improve next post
health ep. = status check for the infra. the mcp tool provides the agent with a structured way to ping the system and get a clear go/no-no signal before and after performing sensitive actions like db migrations
from the ANTik build log: Foundation Stage
the first real stage was not visible in the UI
it was backend foundation
what went into it:
- PostgreSQL database
- Alembic migrations
- FastAPI backend
- Health endpoint
- MCP server with health tool
- Pytest setup
- Dev run scripts
- Environment config
~ no profiles yet
~ no browser launch yet
~ no proxy logic yet
~ no useful user feature yet
ANTik needs many modules later:
- profiles
- fingerprints
- proxies
- browser runtime
- cookies
- extensions
- sync mode
- agent API
all of them need the same base:
> database access
> migrations
> settings
> tests
> API structure
> way for agents to talk to the system
! if this layer is weak, every next feature starts inventing its own shape
but it gave the project a place where the next modules could be attached cleanly
ANTik is developed with AI agents, but the project cannot live inside chat history
! I use three working layers:
1. specs - describe what a module must do
- profiles, proxies, browser engine, cookies / storage, sync mode, extensions - each part needs its own expected behavior
2. audit docs record what was checked
- what passed, what failed, what was not tested, what needs live browser verification
3. journal records the development path
- stages, decisions, bugs, rewrites, open problems
This matters because AI agents often work across several sessions
~ one agent implements
~ another reviews
~ another continues later
*If the reason for a decision stays only in one chat, it is lost
Examples from ANTik:
- custom proxy logic broke because saved proxy and inline proxy were treated too similarly
- sync UI had to be rewritten because the first version worked technically but felt wrong in use
- extensions exposed a product issue: installed and enabled are not the same state
- browser runtime can pass tests and still behave differently in a real Camoufox window
*that is why every important stage needs a written trail
! spec for target
! audit for verification
! journal for what actually happened
From the ANTik build log: Security Layer
the product processes sensitive data:
- profile accounts
- passwords
- 2FA secrets
- proxy credentials
- cookies and browser state later
*I added a master password early
The crypto design is simple at the product level:
- master password unlocks the app
- sensitive fields are encrypted with a random 256-bit DEK.
! the DEK is never stored raw
DEK is wrapped by:
- password-derived key
- ecovery-seed-derived key
so there are two recovery paths:
- master password
- recovery seed
technically the stage includes:
- Argon2id for password KDF
- AES-256-GCM for encryption
- BIP-39 recovery seed
- optional system keychain
- lock / unlock / status API
- middleware that blocks business endpoints while the app is locked
at this stage there was no UI for it yet
setup and unlock worked through REST / MCP
that is not convenient for a user, but it is correct for the architecture
if security comes after profiles, accounts and cookies, then every old field has to be revisited
i wanted the product to treat secrets correctly before the useful modules started to grow
from the ANTik build log: Foundation Stage
the first real stage was not visible in the UI
it was backend foundation
what went into it:
- PostgreSQL database
- Alembic migrations
- FastAPI backend
- Health endpoint
- MCP server with health tool
- Pytest setup
- Dev run scripts
- Environment config
~ no profiles yet
~ no browser launch yet
~ no proxy logic yet
~ no useful user feature yet
ANTik needs many modules later:
- profiles
- fingerprints
- proxies
- browser runtime
- cookies
- extensions
- sync mode
- agent API
all of them need the same base:
> database access
> migrations
> settings
> tests
> API structure
> way for agents to talk to the system
! if this layer is weak, every next feature starts inventing its own shape
but it gave the project a place where the next modules could be attached cleanly
sometimes, and quite often for many personal AI tools, a Telegram bot is a better first interface than a control panel
telegram is great for:
- alerts
- quick commands
- manual approval
- short summaries
- status checks
- simple entrances
example:
new wallet transaction -> AI summary -> Telegram alert -> approve/ignore/save
or:
new GitHub release -> changed files -> AI summary -> submit to bot
or:
new Telegram/X signal -> categorize -> send only important elements
telegram bot is just an interface, but there's a real system behind it:
data sources -> worker -> database -> AI summary -> bot message -> human action
*this is useful because it allows you to reduce the size of the tool
> no heavy user interface
> no dashboard, no data yet
> no feeling of a fake product
! just a work cycle that I can use every day
Most personal tools must start with a Data Source
> in front of the dashboard
> before the bot
> before the agent
You need to understand:
- where does the data come from
- how often does it change
- which fields are stable
- what can break
- what limitations does the API have
- what needs to be stored
- what should trigger the warning
! for a small tool, this is more important than the interface
Example:
> wallet address -> transactions -> approvals -> risk flags -> Telegram alert
or:
> Account X -> new messages -> topic classification -> save useful signals -> daily digest
or:
> repository -> new releases -> changed files -> AI summary -> library note
there is a data pipeline
AI becomes useful once the tool can reliably collect and store raw events
> source -> parser -> storage -> AI layer -> alert -> check
! this is the basic form
@ApplyWiseAi I obsess over idempotent and handle rollbacks via alembic, but the key is the automated test suite that runs post-migration. If pytest flags an issue, the pipeline reverts
comments are sometimes Raw Sales Data
~ people ask questions
~ raise objections
~ compare alternatives
~ describe the pain
~ ask for price
~ ask to set it up
~ ask if this is suitable for their case
most of this disappears under the post
a useful AI workflow looks like this:
comment/DM -> categorize intent -> extract problem -> enrich profile -> create interest -> draft response -> person approves
! the important part is not missing the signal, not automation for the sake of automation.
AI can help separate:
> real purchase intention
> curiosity
> support issue
> objection
> spam
> idea of content
then the output might go somewhere useful:
- CRM
- task list
- content lag
- support line
- follow-up project
! this is where marketing and sales come together through a cycle:
publish -> listen -> categorize -> reply -> save -> improve next post
CRM + AI is a small part
CRM working memory is a useful part
*not just - name, email address, company, deal stage
A:
? where did the lead come from
? what they asked
? what problem do they have
? what was promised
? what's the next action
? what has changed since last contact
? what should not be forgotten
the workflow is simple:
> Lead appears -> AI enriches context -> CRM stores facts -> AI prepares summary -> human checks -> follow-up actions/tasks are created
! CRM must maintain the source of truth
AI should help with:
- classification
- resume
- next step
- draft response
- leading scorer
- pipeline updates
- missed follow-ups
*this is why open source CRM tools like Twenty are interesting
~ custom fields
~ API
~ webhooks
~ automation of work processes
~ self-hosted data
! this helps make simple CRM the foundation for AI-enabled business processes
rep: https://t.co/6YCkmrgb5Q
@ApplyWiseAi before. you can't build a skyscraper on a foundation you haven't st-tested. the testing pipeline was there from day one to ensure migrations actually lead to progress, not technical debt