DEV Community: Fillip Kosorukov

How I'm Applying Andrej Karpathy's AI Methods in Practice

Fillip Kosorukov — Wed, 08 Apr 2026 11:56:04 +0000

How I’m Applying Andrej Karpathy’s AI Methods in Practice

Over the last few months, I’ve been less interested in AI as a novelty and more interested in it as operating infrastructure.

A lot of that thinking has been sharpened by Andrej Karpathy’s recent work and essays. Not because I’m trying to copy his exact stack, but because his framing is unusually practical. He keeps coming back to a few ideas that matter in the real world: agency beats raw intelligence, small systems are easier to trust, good notes compound, and AI works best when it is embedded into repeatable workflows instead of treated like magic.

That maps closely to how I’m building.

1. I’m using AI as leverage, not theater

One of Karpathy’s points that stuck with me is that agency matters more than intelligence. I think that is even more true when you’re a solo founder.

The bottleneck is usually not whether a model can generate text or code. The bottleneck is whether you can turn that capability into shipped systems, useful decisions, and consistent output.

In practice, that means I use AI to increase execution speed across a portfolio of projects:

content and SEO systems
internal knowledge capture
product iteration
research synthesis
technical debugging

The goal is not to say “look, AI did this.” The goal is to reduce the drag between idea and implementation.

2. I’m building a compile-first knowledge system

Karpathy’s “LLM wiki” idea lines up with something I’ve been converging on: don’t just retrieve information on demand, compile it into a maintained knowledge base.

That distinction matters.

RAG is useful, but it often recomputes context every time you ask a question. A maintained wiki compounds. It becomes a durable operating layer.

So instead of letting insights disappear inside chat history, I’m organizing work into a structure with:

raw source material
compiled markdown knowledge
rules and hypotheses
changelogs and decision logs

That makes it easier to reuse insights across sessions, spot contradictions, and keep momentum when switching between projects.

3. I’m treating notes as a working system, not an archive

Another Karpathy idea I like is the append-and-review note.

The principle is simple: don’t over-design your note system. Keep capturing. Periodically review. Rescue the high-signal items. Let the rest sink.

That is a much better fit for speed than building elaborate folder structures you never maintain.

I’m applying that idea operationally:

append new findings quickly
review and promote only what keeps proving useful
turn recurring insights into rules
keep the system lightweight enough that it actually gets used

In other words, notes are not just memory. They are a filter for what deserves to become process.

4. I’m using agents for bounded work, with humans on judgment

Karpathy has also been clear that agents are getting much better, but they are still jagged. I think that’s exactly right.

An agent can feel brilliant one minute and strangely careless the next. That means the right pattern is not blind autonomy. It’s constrained autonomy.

So I’ve been using agents for:

background research
drafting and rewriting content
code edits and implementation passes
monitoring and checks
structured summarization

But I still keep human judgment on:

strategic direction
final publishing decisions
sensitive external actions
quality control when stakes are high

That has been a much better model than pretending full autonomy is already solved.

5. I’m favoring small, legible systems

One thing I appreciate about Karpathy’s work is that even when he talks about powerful systems, he still values inspectability.

That resonates with how I build.

I’d rather have a set of small scripts, explicit files, and clear handoffs than an opaque automation tower that nobody can debug. This matters even more when AI is involved, because the system has to be understandable when something goes wrong.

Legibility is not just an engineering preference. It’s a speed advantage.

6. I’m using AI across multiple operating contexts

A lot of the public discussion about AI still focuses on chat as a destination. For me, chat is just one interface.

The more useful pattern is embedding AI into a broader operating environment:

research workflows
knowledge pipelines
publishing systems
product support tasks
technical execution loops

That’s where it starts to feel less like a demo and more like infrastructure.

7. The biggest shift is compounding

The most important practical lesson I’ve taken from Karpathy is not a specific prompt or tool.

It’s that AI becomes much more valuable when you design for compounding.

A prompt is disposable.
A workflow is reusable.
A maintained knowledge base compounds.
A network of owned content compounds.
A system that gets slightly better every day compounds.

That is the lens I’m using now.

I’m not trying to use AI for isolated wins. I’m trying to build operating systems around it, where research, execution, memory, and publishing reinforce each other over time.

That shift has made AI much more useful in practice.

If you’re building with these tools seriously, that’s the question I’d ask: are you just generating outputs, or are you building compounding systems?

Automating Quora Answers With Python, GraphQL, and a Task Queue

Fillip Kosorukov — Sat, 04 Apr 2026 22:32:55 +0000

Automating Quora Answers With Python, GraphQL, and a Task Queue

I needed a repeatable way to post helpful answers on Quora without spending hours browsing questions manually. Here's the system I built — runs on a $6/month VPS, end to end.

Problem

Quora is great for organic traffic, but the workflow is manual and time-consuming: browse questions, evaluate which ones are worth answering, write something useful, post it, repeat. As a solo founder running four products, I don't have time for that daily.

Solution: A Five-Stage Pipeline

Stage 1: Question Discovery

find_quora_questions.py hits the Serper API (a Google search API) with queries like:

site:quora.com "how to" AI visibility local business
site:quora.com online reputation management
site:quora.com solo founder startup

Each result gets scored by:

Recency — newer questions get more weight
Answer count — fewer existing answers = more visibility
Relevance — keyword matching against topic pillars
Already posted — checked against quora_posted.json

Output: a ranked JSON list of question URLs.

Stage 2: Answer Drafting

An AI agent picks the top 3 questions and writes standalone answers. The constraint is quality — Quora's algorithm surfaces genuinely helpful answers, so the drafts need to provide real value, not just keyword-stuffed backlink attempts.

Each answer is saved as a markdown file.

Stage 3: Task Queue

Instead of posting directly, the agent runs queue_post.sh which writes a .json file per answer to ~/seo-publisher/queue/. Each task file contains:

{
  "url": "https://www.quora.com/How-do-you-get-your-business-featured-in-AI-search-results",
  "body_file": "articles/quora-new-2026-04-04-1.md"
}

This decouples "deciding what to post" from "actually posting." The agent never touches Quora's API directly.

Stage 4: Background Watcher

queue_watcher.sh runs as a background process, polling the queue directory every 30 seconds. When it finds task files, it executes publish_quora.py --api-only for each one.

Success → task moves to done/, URL added to quora_posted.json
Failure → task moves to failed/ (no infinite retries)

Stage 5: GraphQL API Posting

This is the interesting part. My first approach used Playwright with a headless browser. Cloudflare's Turnstile killed it.

The working approach uses curl_cffi — a Python library that impersonates real browser TLS fingerprints. The flow:

# Simplified version of the core logic
from curl_cffi import requests

session = requests.Session(impersonate="chrome131")
session.cookies.update(load_cookies("quora_state.json"))

# Fetch question page to extract form key + question ID
page = session.get(question_url)
formkey = extract_formkey(page.text)
qid = extract_qid(page.text)

# Convert markdown to Quora's internal format
sections = markdown_to_quora_sections(answer_body)

# Post via GraphQL
response = session.post("https://www.quora.com/graphql/gql-para-POST",
    json={
        "queryName": "AnswerEditorMutation_answerCreate_Mutation",
        "variables": {
            "input": {
                "questionId": qid,
                "content": json.dumps({"sections": sections}),
            }
        },
        "extensions": {"hash": mutation_hash}
    },
    headers={"quora-formkey": formkey}
)

Key details:

TLS fingerprinting via curl_cffi bypasses Cloudflare without running a browser
The mutation hash changes when Quora deploys. The script auto-discovers new hashes by parsing the page's webpack bundles
Markdown to Quora format conversion handles bold, paragraphs, and inline formatting
Browser-based fallback is preserved via --browser-only flag

Results

5 answers posted in one session
Zero Cloudflare blocks via the API path
Pipeline triggers with a single command
Runs alongside 4 other products on the same VPS

Takeaways for Developers

Skip the browser when you can. If the platform has a GraphQL or REST API under the hood, call it directly. Browser automation is a maintenance burden.
curl_cffi > requests for Cloudflare sites. Standard Python requests gets flagged immediately. curl_cffi with impersonate="chrome131" passes TLS fingerprint checks.
Task queues solve policy problems. Some AI models refuse to interact with third-party services. Having them write to a local queue instead keeps the pipeline working regardless of model constraints.
Track state. A simple JSON file of posted URLs prevents duplicate answers and wasted API calls.

Stack

Component	Tool
Question discovery	Python + Serper API
Answer drafting	AI agent
Queue management	Bash scripts
API posting	`curl_cffi` + Quora GraphQL
State tracking	`quora_posted.json`
Infrastructure	Vultr VPS, Ubuntu 24, $6/mo

Total: ~400 lines of Python, ~50 lines of shell.

I'm Fillip Kosorukov. I build LocalMention, SetupLens, FixMyRecord, and Resilience — all on one server. I write about solo founding, automation, and AI visibility.

What Psychology Research Taught Fillip Kosorukov About Behavior Change in the Real World

Fillip Kosorukov — Fri, 03 Apr 2026 12:09:37 +0000

What Psychology Research Taught Fillip Kosorukov About Behavior Change in the Real World

A lot of advice about behavior change sounds tidy in theory and disappointing in practice.

People are told to be more disciplined, more motivated, more consistent, and more committed. Some of that advice is not wrong. It is just incomplete. It treats behavior change as if it were mostly a matter of information or willpower. In real life, it is usually more complicated than that.

Studying psychology pushed me toward a more grounded view.

Behavior change is rarely just about deciding once and then following through forever. It is shaped by context, reinforcement, identity, stress, environment, timing, and the stories people tell themselves about what their actions mean. Once you see that clearly, a lot of simplistic advice starts to fall apart.

Motivation is unstable, structure is underrated

One of the easiest mistakes people make is overvaluing motivation.

Motivation matters, but it is volatile. It rises when the goal feels emotionally vivid, when early progress is visible, or when someone feels hopeful and energized. It drops when life becomes messy, when progress stalls, or when competing pressures take over.

If a person builds a plan that only works when motivation is high, the plan is fragile by definition.

That is why structure matters so much. Environment design, friction reduction, implementation cues, and routine scaffolding often matter more than inspiration. People like to believe major change begins with a dramatic inner shift. More often it begins with a practical reduction in the number of decisions required.

Identity shapes behavior more than most people realize

Behavior is not just mechanical. It is interpretive.

People are constantly assigning meaning to what they do. A missed workout becomes evidence that they are undisciplined. A relapse becomes proof that they never really changed. A good week becomes permission to relax completely. Those interpretations matter because they alter what happens next.

Psychology research helped me appreciate that behavior change is partly about helping people adopt more functional narratives about themselves. Not fake narratives — functional ones.

A person who sees themselves as someone capable of repair behaves differently from someone who treats every setback as a final verdict.

That distinction matters in health, recovery, work, money, and relationships.

Small wins matter because they change feedback loops

People often underestimate how much momentum can come from visible, credible progress.

A small win does not matter only because of the immediate outcome. It matters because it changes expectations. It makes another attempt feel more plausible. It weakens learned helplessness. It creates evidence.

That is one reason behavior change efforts should not only be judged by the scale of the result. They should also be judged by whether they create a more constructive loop.

If a system helps someone do one useful thing consistently, that may be more valuable than a dramatic short-lived burst of performance.

Stress changes the whole equation

A lot of self-improvement advice quietly assumes people are operating under decent conditions. But many people are trying to change behavior while dealing with uncertainty, shame, financial pressure, sleep issues, unstable routines, or emotional overload.

Under stress, people narrow their time horizon. They become more reactive, more relief-seeking, and less able to hold abstract long-term plans in working memory. That does not mean change is impossible. It means the design of change has to account for the actual state the person is in.

This is one reason compassion and precision can belong together. You can be rigorous about behavior while still recognizing that context changes what is realistic.

Good interventions reduce friction and increase clarity

The practical lesson I keep coming back to is that good behavior-change systems usually do a few things well:

they make the desired action obvious
they reduce friction around starting
they provide fast feedback
they create visible progress
they make recovery from lapses easier

That is true whether you are trying to build healthier habits, improve productivity, reduce avoidance, or support recovery.

The system does not need to be elaborate. It needs to make the next right action easier to take.

Why this still matters to me

The reason this framework still feels important is that it respects human behavior as something dynamic rather than moralized.

People do not fail to change only because they are lazy or weak. Very often they are trying to change inside systems, environments, and self-concepts that make the desired behavior hard to sustain. Once you understand that, the question becomes less judgmental and more useful.

Not “Why can’t this person just do the right thing?”

But “What conditions would make the better action more likely?”

That is a much more practical question.

My biggest takeaway

If I had to compress the lesson into one idea, it would be this:

lasting behavior change usually comes less from intensity and more from designing conditions that make repetition possible.

That may sound less dramatic than the language of sudden transformation, but in practice it is more durable.

Psychology taught me to pay attention not just to what people intend, but to what their environments reward, what their identities permit, and what their stress makes harder. Once you understand those forces, behavior change stops looking like a mystery and starts looking more like a system you can influence.

Fillip Kosorukov writes about psychology, behavior change, entrepreneurship, and decision-making under pressure. More at fillipkosorukov.net.

What Momentum Trading Taught Fillip Kosorukov About Risk, Patience, and Process

Fillip Kosorukov — Fri, 03 Apr 2026 12:00:46 +0000

What Momentum Trading Taught Fillip Kosorukov About Risk, Patience, and Process

A lot of people think trading is mostly about prediction. I do not see it that way.

The deeper I have gotten into momentum trading, the more I have come to view it as a discipline of selection, timing, and self-regulation. The market always contains noise, temptation, and reasons to act too early or too aggressively. The edge comes less from constant action and more from waiting for the right setup, defining risk clearly, and executing without emotional drift.

That is one reason I think momentum trading teaches lessons that extend far beyond markets.

Risk is not a side note

Many people say they care about risk, but in practice they spend most of their time thinking about upside. That is understandable. Upside is exciting. Risk feels like friction.

Trading has a way of correcting that fantasy quickly.

If a trader consistently enters positions without a clear invalidation point, sizes too large, or rationalizes weak setups, the market eventually delivers the lesson. It may not happen on the first trade or the fifth trade, but it happens. The bill always arrives.

Momentum trading sharpened my respect for a basic truth: if you do not define downside before the trade, you are not really making a decision. You are outsourcing the decision to stress.

That lesson applies almost everywhere. In business, in product bets, and even in relationships, people often confuse optimism with discipline. They are not the same thing.

Patience is active, not passive

One of the most underrated parts of trading is the ability to do nothing.

That sounds trivial until you try it. There is always a chart moving, a headline breaking, a stock extending, a pullback tempting you, or someone online posting gains. The pressure to participate is constant.

Momentum trading forces a distinction between being engaged and being reactive. Watching carefully without forcing action is a real skill. It requires a plan and enough confidence to let weak opportunities pass.

I have found that patience in trading is rarely about being relaxed. It is usually about being selective.

The same pattern shows up in entrepreneurship. Not every feature deserves to be built. Not every idea deserves to be pursued. Not every opportunity deserves your calendar. Good process often looks slower than impulse, but it compounds better.

Process protects you from mood

A trader who acts differently depending on confidence, frustration, boredom, or social influence does not really have a process. They have a rotating set of moods.

That is why repeatable process matters so much.

For me, process means knowing what kind of setup qualifies, what disqualifies it, where the risk is, what the position size should be, and what evidence would prove the trade is wrong. Process narrows the room available for emotional improvisation.

This does not eliminate mistakes. It just makes them more diagnosable.

That is a huge advantage. A bad outcome with a good process can be studied. A bad outcome with a sloppy process usually just becomes a story.

The same is true outside markets. If you are building products, running experiments, or allocating time, process gives you feedback that is cleaner than memory and less flattering than instinct.

Good setups are often obvious in hindsight and hard in real time

Another lesson trading reinforces is that clarity and comfort are different things.

Many of the best trades feel psychologically awkward when they first appear. A proper entry may require buying strength after a constructive setup rather than “getting a deal.” It may require cutting a trade quickly even when the original thesis still feels emotionally available. It may require holding a winner longer than your nerves prefer.

The market does not reward comfort. It rewards alignment between behavior and evidence.

That is part of why I think trading can be such a useful mirror. It exposes the gap between what a person says they value and what they actually do under pressure.

Why this matters beyond trading

I do not think everyone needs to become a trader. But I do think the framework has value outside finance.

Momentum trading trains a few habits that are broadly useful:

define risk before action
wait for quality instead of forcing motion
build repeatable rules
review outcomes honestly
separate identity from any one result

Those habits matter in startups, product development, decision-making, and personal growth. They also matter in a world that constantly rewards speed, stimulation, and performative certainty.

My biggest takeaway

If I had to reduce the whole lesson to one sentence, it would be this:

process is what keeps conviction from turning into self-deception.

That is true in trading, and I suspect it is true in most other domains that involve uncertainty.

Momentum trading did not just teach me about charts and setups. It taught me to respect timing, to define risk before desire takes over, and to trust process more than adrenaline.

Those lessons have turned out to be useful far beyond the market.

Fillip Kosorukov writes about trading process, AI, entrepreneurship, and decision-making systems. More at fillipkosorukov.net.

Why Local Businesses Are Losing Leads in AI Search — and What Fillip Kosorukov Thinks Will Matter Next

Fillip Kosorukov — Fri, 03 Apr 2026 12:00:34 +0000

Why Local Businesses Are Losing Leads in AI Search — and What Fillip Kosorukov Thinks Will Matter Next

Local business SEO used to revolve around a familiar playbook: rank your website, optimize your Google Business Profile, collect reviews, and keep your directory listings clean. That still matters. But it is no longer the whole game.

More customers are asking ChatGPT, Google’s AI results, Gemini, and Perplexity for recommendations directly. They are not always clicking through ten blue links. Often, they just want one answer. That changes how local discovery works.

I have been paying close attention to that shift while building tools around visibility, search behavior, and reputation. My view is simple: local businesses are starting to lose leads in AI search not because they are bad businesses, but because they are still optimizing for an older distribution system.

AI search is compressing the decision set

Traditional search gave businesses multiple ways to win attention. A user could compare sites, check reviews, skim map listings, and open several tabs before deciding. AI search compresses that process. The interface often summarizes, recommends, or narrows the field before the user ever visits a business website.

That means the competitive battle is moving upstream.

If an AI system already decided which three plumbers, dentists, med spas, attorneys, or roofers deserve mention, the businesses outside that set lose visibility before the buying journey fully starts. In a practical sense, they become less discoverable even if their website still ranks decently in organic search.

Why good businesses get left out

A lot of local business owners assume that if they rank on Google Maps or have a respectable website, AI platforms will naturally pick them up. Sometimes they do. Often they do not.

There are a few reasons for that.

First, different AI systems draw from different blends of sources. One may lean more on review patterns and directory coverage. Another may weight structured data, entity consistency, or citation overlap more heavily. Another may rely on broad web patterns that have little to do with a business’s own website quality.

Second, many small businesses have fragmented digital footprints. Their name, address, services, categories, reviews, and third-party mentions may all be slightly inconsistent across the web. Humans can tolerate that mess. Machines are worse at it.

Third, many sites still publish content that is technically present but not especially useful for AI systems trying to infer trust and relevance. Thin service pages, generic city pages, weak about pages, and boilerplate copy do not build much confidence.

The businesses that win tend to look more like entities

The businesses most likely to win in AI search tend to create a stronger, clearer entity footprint.

That means they are not just “a website plus some reviews.” They look like a well-referenced business across multiple trusted surfaces. Their information is consistent. Their service descriptions are specific. Their reviews provide useful language. Their profiles across directories and platforms reinforce one another.

In other words, they become easier for AI systems to understand and safer to recommend.

This is why I think local businesses should stop thinking only in terms of rankings and start thinking in terms of recommendation readiness.

What matters more going forward

If I had to bet on what matters most over the next stage of AI search for local businesses, I would focus on five things.

1. Stronger entity consistency

Your business should look like the same business everywhere. Name, category, location, phone, service set, and positioning should not drift from one platform to another.

2. Better structured information

Schema, service clarity, FAQ coverage, and readable site structure all help reduce ambiguity. AI systems reward clarity.

3. Review language that actually says something

A high review count helps, but descriptive reviews help more. If customers repeatedly mention the service, neighborhood, speed, professionalism, or outcome, AI systems get better raw material.

4. Directory and citation coverage that matches your niche

Not every citation is equal. The right industry and local sources matter more than random volume.

5. Content that mirrors how real people ask for help

A lot of businesses still write pages as if search users only type fragments. AI search often begins with fuller, natural-language questions. Businesses that answer those questions clearly are better positioned.

This shift is still early

That is the encouraging part.

Most local businesses have not adapted yet. Many agencies are still selling an older SEO stack with a fresh layer of buzzwords on top. The actual operational work is more specific than that. It is about making a business legible, trustworthy, and recommendation-worthy across the sources AI systems seem to rely on.

The gap between businesses that understand this and businesses that ignore it will probably widen.

My practical takeaway

If you run a local business, do not wait until traffic drops to care about AI search. Start by asking a more direct question:

If someone asked an AI platform for the best option in my category and city, would my business actually deserve to be mentioned based on the digital evidence available today?

That question is much harder than “Do I rank for a keyword?” But it is also the one that will matter more going forward.

The local businesses that win the next wave of search will probably be the ones that treat visibility as a cross-platform trust problem, not just a website ranking problem.

That is where I think the market is going. And I do not think it is going back.

Fillip Kosorukov writes about AI visibility, local search behavior, entrepreneurship, and digital trust systems. More at fillipkosorukov.net.

Claude Code Is Silently Burning 10-20x Your Token Budget — Here's the Fix

Fillip Kosorukov — Wed, 01 Apr 2026 11:19:20 +0000

If you're on Claude Max and wondering why your usage cap disappears in an hour, you're not alone. I went down this rabbit hole after burning through my entire daily quota in a single coding session.

The Problem

There are two independent bugs inflating Claude Code token usage right now:

Bug 1: Broken prompt caching in the standalone binary

The standalone Claude Code binary (installed via claude.ai/install.sh or npm install -g) ships with Anthropic's custom Bun fork. Baked into this fork is a native-layer string replacement that modifies the JSON request body after serialization but before TLS encryption. It targets a billing attribution sentinel (cch=24b72) and replaces it with a 5-character hash.

The issue: it replaces the first occurrence in the serialized body. Since messages[] comes before system[] in the JSON, if your conversation history contains the sentinel string (from discussing billing, reading CC source, or having it in your CLAUDE.md), the wrong instance gets replaced. This changes the message content on every request, breaking the cache prefix and forcing a full rebuild — roughly $0.04-0.15 per request wasted.

Bug 2: MCP connector tool schema injection

Cloud MCP connectors (Ahrefs, Supabase, Similarweb, etc.) inject their complete tool definition schemas into every API call, regardless of whether you're using them. Ahrefs alone adds 100+ tool definitions. That's tens of thousands of tokens of overhead on every single message.

The Fixes

Switch to npx to bypass the Bun binary:

# One-time alias setup
echo "alias claude='npx @anthropic-ai/claude-code'" >> ~/.bashrc
source ~/.bashrc

This runs Claude Code through Node instead of the custom Bun fork, sidestepping the sentinel replacement bug entirely. Only downside is slightly slower startup (npx checks the registry each time).

Disconnect unused MCP connectors from Claude Settings → Connectors. Keep only what you actively use. Disconnected connectors show "Needs authentication" and stop injecting tool schemas.

Other mitigations:

Use /compact to compress context mid-session
Avoid --resume (can inherit broken cache from previous sessions)
Start fresh sessions frequently
Keep your CLAUDE.md lean

Status

Anthropic is aware of both issues. The cache bug is tracked at anthropics/claude-code#24147 and #40524. No public fix date yet, but the word is it's coming.

Credit to Paweł Huryn and Alex Volkov for surfacing this publicly on X.

How I Built an AI Visibility Audit Tool as a Solo Founder With No Programming Background

Fillip Kosorukov — Tue, 31 Mar 2026 11:49:01 +0000

A year ago, I had never written a line of code. My background was in psychology research — I spent time at the University of New Mexico's MATEO Lab studying decision-making and behavioral patterns, and co-authored work published through Taylor & Francis. The idea of building a SaaS product from scratch felt impossibly far away.

Today, I run LocalMention.io, an AI visibility audit platform that helps local businesses understand how they show up (or don't) in AI-generated search results. I also built FixMyRecord.io, an automated personal reputation audit and data broker removal tool. Both products run on a single VPS, and I built them almost entirely with AI coding assistants.

Here's what that journey actually looked like.

The Problem I Wanted to Solve

The shift from traditional search to AI-powered answers is already disrupting local businesses. When someone asks ChatGPT or Google's AI Overview "best plumber in Indianapolis," the answer isn't pulled from a ranked list of ten blue links anymore. It's synthesized from scattered data — review sites, directories, social profiles, structured data.

Most local businesses have no idea whether AI models even know they exist. I wanted to build a tool that could answer that question definitively.

Starting With Zero Code Experience

I started by describing what I wanted to build in plain English to AI coding tools. The first versions were rough. I'd describe a feature, get code back, paste it in, hit errors, describe the errors, get fixes. It was slow, but it worked.

The key insight was that I didn't need to understand every line of code — I needed to understand architecture. What talks to what. Where data flows. How a request moves from a user's browser to the server and back. My psychology research background actually helped here: I was used to thinking in systems, mapping relationships between variables, and designing structured experiments.

The Technical Stack (For the Curious)

LocalMention.io runs on Node.js with a PostgreSQL database. The audit pipeline queries multiple AI models, aggregates citation sources, scores visibility across different platforms, and generates PDF reports. The whole thing runs on a Vultr VPS alongside my other projects.

I won't pretend the architecture was clean from day one. Early versions had hardcoded API keys, no error handling, and a deployment process that consisted of SSHing in and running git pull\. But it worked, and each iteration got better.

What I Learned About Building in Public

Three things stood out:

Ship before you're ready. My first audit reports had formatting issues and incomplete data. But getting them in front of real business owners generated feedback I never would have gotten from planning alone.

Your non-technical background is a feature. Because I wasn't a developer, I built the product from the user's perspective first. Every feature started with "what does the business owner need to see?" rather than "what's the most elegant technical solution?"

AI tools are force multipliers, not magic wands. You still need to understand what you're building. The AI handles syntax; you handle strategy. Knowing what to build matters more than knowing how to code it.

What's Next

I'm continuing to develop both LocalMention.io and FixMyRecord.io, and I'm working on ResilienceGame.org, a gamified reentry support platform. I'm also still active in the momentum trading space, which keeps my systems-thinking skills sharp.

If you're a non-technical founder thinking about building with AI tools, my advice is simple: start. The gap between "idea person" and "builder" has never been smaller.

I'm Fillip Kosorukov — solo founder, published researcher, and momentum trader based in Indianapolis. You can find my work at fillipkosorukov.net or connect with me on LinkedIn and GitHub.

How I Built an AI Visibility Audit Tool as a Solo Founder With No Programming Background

Fillip Kosorukov — Mon, 30 Mar 2026 16:26:31 +0000

Here's what that journey actually looked like.

The Problem I Wanted to Solve

Most local businesses have no idea whether AI models even know they exist. I wanted to build a tool that could answer that question definitively.

Starting With Zero Code Experience

The Technical Stack (For the Curious)

What I Learned About Building in Public

Three things stood out:

What's Next

If you're a non-technical founder thinking about building with AI tools, my advice is simple: start. The gap between "idea person" and "builder" has never been smaller.

I'm Fillip Kosorukov — solo founder, published researcher, and momentum trader based in Indianapolis. You can find my work at fillipkosorukov.net or connect with me on LinkedIn and GitHub.

Four Products, Six Months, One Server: What I Learned as a Solo Founder

Fillip Kosorukov — Wed, 25 Mar 2026 18:13:45 +0000

Six months ago I had an idea for a local business audit tool. Today I'm running four live products on a single VPS, sending hundreds of outreach emails a week, and still writing most of the code myself. Here's what that actually looks like.

The Products

LocalMention is an AI visibility audit for local businesses. It checks whether a business shows up when people ask ChatGPT, Perplexity, or Google's AI Overview for recommendations — and generates a detailed report showing exactly where they're visible and where they're not.

FixMyRecord is a personal reputation scanner. It checks data broker sites, background check databases, and court record aggregators for personal information exposure, then automates the removal process.

Resilience is a gamified reentry support platform — quest systems, skill trees, and mentor oversight designed to make the transition from incarceration to stability feel achievable. Built on React and Supabase.

SetupLens is a stock scanner that runs five different trading methodology lenses against the market every day and surfaces the highest-conviction setups.

The Stack

Everything runs on one Vultr VPS:

Reverse proxy: Nginx
Process management: systemd services
Scheduling: cron jobs for daily scans, email sends, backups
Databases: SQLite (simple, no server overhead)
Backups: Nightly to Backblaze B2, weekly offsite
Backend: Python (Flask), Node.js
Frontend: React, Vite, Tailwind
Auth/DB (Resilience): Supabase with Row-Level Security
Browser automation: Playwright (FixMyRecord scans)
Email: Resend (transactional), Instantly (cold outreach)

When you can't throw money at scaling problems, you learn to write efficient code. Every decision gets scrutinized: does this need a database? Can this run as a cron job instead of a daemon? Is this complexity serving users or just my ego?

What the Data Taught Me About Cold Outreach

Over 600 cold emails sent for LocalMention. Open rate: 4.5%. Replies: 1. The numbers are humbling, but they're data.

Business Type	Open Rate
Law firms	75%
Home cleaning	50%
Plumbers	33%
Dentists	25%

Cold outreach isn't a marketing problem — it's a product problem. The emails that get opened are the ones where the audit report reveals something the business owner genuinely didn't know.

Applied Behavioral Science

My academic background is in behavioral science — University of New Mexico, MATEO Lab, health behavior change interventions. Every product I build uses the same principles: reduce friction, make the next action obvious, show progress visually.

FixMyRecord's live results page updates in real-time as the scan runs. Resilience uses quest chains that break overwhelming goals into daily actions. LocalMention's PDF report is designed to create an "aha moment" in the first 30 seconds.

What I'd Do Differently

Fewer products. More depth. If I could rewind six months, I'd pick one product and go all-in: more verticals, more cities, a real sales process, testimonials from the first ten customers before building anything else.

But the cross-pollination between projects is real — FixMyRecord's scan architecture informed LocalMention's pipeline, trading methodology shaped how I think about signal-to-noise in outreach, and Resilience keeps me grounded in the human impact behind the code.

One server, four products, and a lot of coffee.

I'm Fillip Kosorukov — solo founder, UNM grad, and builder. Find me at fillipkosorukov.net or LocalMention.io.

Building with Claude Code: What a Non-Developer Learned About AI-Assisted Development

Fillip Kosorukov — Tue, 17 Mar 2026 12:29:25 +0000

I'm not a developer. I have a psychology degree and I run a real estate company and a trading firm. But over the past few months, I've built and deployed a full SaaS product using Claude Code as my primary development tool.

This isn't a tutorial. It's an honest account of what worked, what didn't, and what I think the implications are for people who have product ideas but not programming backgrounds.
The Setup

I run a Vultr VPS (Ubuntu) with a Flask backend, Nginx reverse proxy, Redis caching, and systemd services. I also have a separate stock scanning tool running on the same server with its own cron jobs and a Discord webhook integration.

All of this was built through Claude Code — a command-line tool that lets you delegate coding tasks to Claude directly from your terminal. I use Claude.ai as the planning and advisory layer, and Claude Code as the execution layer.

The split matters. Claude.ai is where I think through architecture decisions, debate approaches, and plan features. Claude Code is where the code gets written, tested, and deployed. Trying to do both in one tool leads to context problems — the planning context is different from the implementation context.
What Actually Works

Iterative problem-solving. The biggest unlock was learning to break problems into small, testable pieces. Instead of asking "build me an audit pipeline," I'd work through it step by step: "parse this API response," then "normalize these business names," then "compare against these queries," then "generate a PDF from these results." Each step was testable on its own.

Error handling and debugging. When something breaks, pasting the error into Claude Code and asking it to fix the issue works surprisingly well. The AI can read stack traces, identify the problem, and propose a fix faster than I could learn to debug it myself. This is probably where I saved the most time.
Deployment and infrastructure. Setting up Nginx configurations, SSL certificates, systemd services, cron jobs — this is the kind of work that would have taken me weeks to learn from
documentation. Claude Code handles it in minutes. The migration from Caddy to Nginx, for example, was a single session.
Security. We did a full security audit that identified 14 issues including a command injection vulnerability. I wouldn't have known to look for these things. The AI caught them, explained why they were dangerous, and fixed them.
What Doesn't Work

Assuming the AI verified its own work. This is the biggest gotcha. Claude Code will report a task as complete without actually verifying that it works. I learned to always test the output myself — run the script, check the output, verify the deployment. Trust but verify isn't just a saying; it's a survival strategy when building with AI assistance.

Long context sessions. After extended sessions, the AI can lose track of earlier decisions or introduce inconsistencies. I deal with this by keeping a MEMORY.md file that documents key architectural decisions, and by starting fresh sessions for new features.

Complex multi-file refactors. When changes need to touch many files simultaneously, the AI sometimes creates inconsistencies between files. Breaking these into sequential single-file changes works better.

The Non-Developer Advantage
Here's something counterintuitive: not knowing how to code might actually be an advantage in some ways.
Experienced developers have strong opinions about architecture, frameworks, and best practices. Those opinions are usually right — but they can also slow down the prototyping phase. I don't have opinions about whether to use Flask or FastAPI. I describe the problem, the AI picks an approach, and we build it. If it works, great. If not, we try something else.

This isn't better than having deep technical knowledge. It's different. It optimizes for speed of iteration at the cost of architectural elegance. For an early-stage product where the priority is validating whether anyone cares about what you're building, that tradeoff makes sense.
Numbers
Some concrete metrics from the build:

Audit pipeline execution time: reduced from ~7 minutes to ~35 seconds through async optimization
API cost reduction: ~90% through query caching on repeat industries
Security issues found and fixed: 14 in one audit session
Reports sent: 117+ across Indianapolis and Albuquerque markets
Time from idea to first outreach email: approximately 3 weeks

Who Should Try This
If you have domain expertise in a specific industry, you understand a real problem that people would pay to solve, and you're comfortable working iteratively through problems rather than having a complete mental model of the solution upfront — AI-assisted development can get you from zero to a deployed product faster than any other path I'm aware of.
The skill that matters most isn't programming. It's the ability to clearly articulate what you want, test whether you got it, and adjust. That's a research skill, a product management skill, and a communication skill. The code is just the output.

Fillip Kosorukov is the founder of LocalMention.io, an AI visibility audit platform for local businesses. He also runs Resilient Capital LLC and Resilient Properties. He holds a summa cum laude degree in Psychology from the University of New Mexico, with published research in the Journal of Substance Use (Taylor & Francis).