aisama.code

Considering... Tinkering... Building... Wrangling... Shipping... Iterating... Synthesizing... Scaling... Vibing... Vibe Code Builder
From chaos to systems

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

@m13v_ It looks very interesting

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

@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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

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

[aisama.code @aisama_code]

@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

[Satya Nadella @satyanadella]

https://t.co/vLmiBKTtX3

[aisama.code @aisama_code]

@bryanonchain very interesting, I'll definitely check it out