DEV Community: Adam Poulemanos

AI Killed One Open Source Business Model; Not Open Source

Adam Poulemanos — Tue, 13 Jan 2026 19:06:34 +0000

The developer world panicked this week when Tailwind CSS—one of the most popular open source projects with 75M monthly downloads—announced an 80% revenue drop and questioned whether their business model can survive the AI era.

As someone building an open source company right now (Knitli), this hit close to home. I needed to know: is this the beginning of the end for open source, or something else entirely?

I spent the weekend digging into the data. Here's what I found: AI killed one specific business model. Meanwhile, other open source companies are having their best years ever.

The Winners Are Winning BIG

While Tailwind struggled, here's what happened to other open source companies over the past 12-18 months:

Databricks: Raised $10B at $62B valuation in Dec 2024, then another $4B at $134B in Dec 2025. Revenue hit $4.8B with 55% YoY growth.
Vercel (Next.js): Reached $9.3B valuation with 82% ARR growth. Their AI tool v0 attracted 3.5M users.
Supabase: Hit $2B valuation with revenue exploding from $20M to $70M—that's 250% growth.
Temporal: $2.5B valuation with 4.4x revenue growth in 18 months.
Hugging Face: Maintained $4.5B valuation, revenue grew from $70M to $130M.
HashiCorp: Sold to IBM for $6.4B.
PostHog: Just hit unicorn status at ~$1.2B valuation.

These aren't small wins. These are record-breaking valuations happening RIGHT NOW, during the supposed "death of open source."

What Actually Changed?

The difference isn't that Tailwind makes bad software. It's that AI fundamentally changed how people consume documentation-heavy products.

Tailwind's Model vs. AI

The Tailwind model:

Create amazing documentation
People visit your website
Convert some percentage to paid customers (UI Kit, Catalyst, etc.)

The content itself drives the business.

The problem: AI doesn't visit websites and doesn't click "buy." It caches documentation, extracts what it needs, and generates code without ever hitting your servers. The traffic disappears. The conversion funnel breaks.

The Winners' Models

The thriving companies? They're selling cloud services and enterprise contracts:

Databricks sells data processing
Vercel sells deployment infrastructure
Supabase sells hosted Postgres
Temporal sells workflow orchestration
Hugging Face sells model hosting and inference

These are services AI can't cache away. When a developer needs to deploy something or process actual data, they have to connect to the real service.

If your business model was "great documentation drives traffic drives sales," AI just killed your funnel. If your business model is "use our OSS locally, pay us to run it in production," you're probably having your best year ever.

The Hidden Problem: Contribution Quality

There's a second issue that's less talked about: AI is flooding popular open source projects with low-quality contributions.

Yesterday, I checked GitHub's Spec-Kit repo—a collection of markdown files and shell scripts to guide AI through spec-writing. Simple but effective, with ~62,000 stars.

One thing caught my eye: 507 open issues. For a repo with 14 markdown files and a handful of scripts.

I dove in:

Most issues are low-effort contributions or feature requests (only 10% are actual bugs)
The majority aren't issues at all—they're people asking questions already covered in docs
One third of the Contributing guidelines are dedicated to reducing low-quality AI contributions
73 open pull requests, mostly simple copy-paste additions

The problem isn't truly AI-generated contributions—it's people unfamiliar with repository norms who can't be bothered to read the docs themselves. A flood of "vibe coders" drowning out the signal.

Good Examples Already Exist

Many successful projects don't rely on mass contributions:

Django requires a Contributor License Agreement (CLA)
Caddy sets a high bar for contributions without being exclusionary
PostHog, Plausible Analytics, and others have clear guidelines: "contributions are welcome if they meet our standards and align with our goals"

The message is shifting from "you build it, they come, everyone wins" to "build in public, keep it open for good players, protect yourself and your time."

The Licensing Question

This brings me to something I'm personally wrestling with right now.

I'm building Knitli, which includes CodeWeaver (semantic code search) and Thread (real-time codebase intelligence). Thread is AGPL-3.0. CodeWeaver is currently MIT OR Apache-2.0.

I'm about 90% decided to move CodeWeaver to AGPL-3.0

Here's why the calculus has changed:

The old way:

MIT/Apache-2.0 were defaults for open source
Permissive licenses drove adoption
Get mass adoption, monetize later

The new reality:

AI companies train on your permissively licensed code
Large players fork and wrap your work
You have limited options to build a sustainable business

What I'm seeing now:

Big growth in projects with commercial intent choosing AGPL-3.0 (Firecrawl, MinerU, Daytona)
Projects with many stars using "fair use" (not open source) licenses (n8n, OpenHands)
Growing use of commons clause additions (dokploy, ReactBits)
More fully proprietary code in public repositories

I expect these trends to accelerate. We'll see more "open code, closed source" projects soon.

My Reasoning for CodeWeaver

It's a developer tool. Most developers can use or modify it without contributing back. AGPL-3.0 doesn't block that.
The main risk is AI companies using CodeWeaver as a feature without contributing back. AGPL-3.0 limits that risk.
AGPL-3.0 is still very much open source—it just requires anyone who modifies and hosts it to share their changes, keeping the ecosystem healthy.
It protects against large players taking core ideas and building proprietary versions.

The decision is harder for CodeWeaver than Thread. Thread is infrastructure—it always needed strong copyleft protection. CodeWeaver is more of a developer tool, where permissive licenses traditionally made sense.

What This Means for Maintainers

If you're maintaining an open source project as a business, the rules have changed:

Re-evaluate your licensing strategy. Permissive licenses that once drove adoption may no longer protect your business. Consider AGPL-3.0 or fair use licenses that align with your goals. Don't let philosophy override practicality.
Tighten contribution guidelines. Make low-effort contributions difficult. Set clear standards, require CLAs, and be prepared to reject contributions that don't meet your criteria.
Focus on building services, not just code. If your business relies on documentation-driven traffic, pivot. Offer hosted services, enterprise features, or other value AI can't replicate.
Transparency still matters. Even with restrictive licenses or proprietary code, keeping your repository public builds trust.

The Bottom Line

Watching Tailwind struggle while Databricks raises $14B has clarified something:

Open source isn't dying. One business model is dying. The companies that adapt are thriving.

I'm still figuring this out in real time. But the data are clear: if you're building open source software as a business, the path forward isn't about abandoning open source—it's about choosing the right model and protecting what you build.

I'm Adam, founder of Knitli. I'm building AI context management tools and figuring out open source business models in real time. If you're wrestling with similar questions, I'd love to hear from you on Bluesky, Twitter, or LinkedIn.

CodeWeaver is in alpha and I need users! Try it out, break it.

This post originally appeared on the Knitli blog at https://blog.knitli.com/ai-killed-one-open-sorce-business-model-not-open-source/

When it's all you have, bad code review is better than no code review. ... but please don't let this be the future.

Adam Poulemanos — Mon, 12 Jan 2026 18:15:42 +0000

I let four AI code reviewers fight over my PRs

Adam Poulemanos ・ Jan 12

#ai #vibecoding #coding #githubcopilot

I let four AI code reviewers fight over my PRs

Adam Poulemanos — Mon, 12 Jan 2026 18:11:08 +0000

AI code reviewers are annoying

Many developers complain about AI code review. It's noisy. It's repetitive. It misunderstands context. It suggests bad patterns. It never shuts up.

Four AI systems review every push I make, and they will not shut up.

GitHub Copilot. Sourcery. GitHub Code Quality. Claude. All via CI. Every push.

Every pull request becomes a battlefield of automated opinions. My most recent architectural PR had 72 comments. I'm the only human participating.

This is annoying. I'm going to tell you why I do it anyway.

The solo developer's dilemma

I'm building CodeWeaver, an open-source MCP server for semantic code search. It's just me. No co-founder, no team, no code review buddy.

This is a problem. Not because I need validation (though that's nice), but because code review serves a specific function: it creates friction. Someone else looks at your work and asks "why?" before it ships. That friction catches bugs. It surfaces assumptions. It forces you to defend decisions you might have made on autopilot.

When you're solo, that friction disappears. You write code, you merge code. Nobody asks questions. Your bad habits calcify into architectural decisions.

So I outsourced the friction to robots.

What AI code review actually looks like

Let me be clear about what I'm dealing with here.

On a recent PR introducing daemon architecture (17 commits, 2000 lines changed), I got 37 comments from Copilot alone. Add in the other reviewers and we're at 60 line-level comments plus 12 general PR reviews. One PR.

Most of them are about:

Unused imports and variables
Empty except blocks missing explanatory comments
Health check loops that sleep before checking instead of after
Parameter names that could be "clearer"

The same suggestions, repeated by three different reviewers

It's a lot. Most of it is noise. The signal-to-noise ratio is genuinely terrible.

But here's the thing about noise: it takes two seconds to dismiss. I scan a comment, think "no, that's intentional," and move on.

The cognitive overhead is low once you accept that most suggestions won't matter.

The .variable vs .value war

I have a custom enum pattern in CodeWeaver. Instead of accessing enum values with .value (Python's default), I use a custom .variable property on my BaseEnum class. There are good reasons for this — it gives me more control over serialization and string representation and not all BaseEnums are strings.

Copilot flags this. Every time. In one PR, it flagged the same .value → .variable pattern ten times across different files.

"Consider using .value for consistency with Python enum conventions."

This is maddening. It's an intentional design decision. I've made it. I'm committed to it. BaseEnum actually has a .variable property — Copilot just doesn't know about my custom base class.

But.

The first time I saw this comment, it made me stop and think. Why am I using .variable? Is there actually a good reason? I spent a few minutes writing up the justification in my head. Turned out yes, there was a good reason. But I hadn't consciously articulated it until the robot asked.

That's the value buried in the annoyance. Being forced to defend a decision — even to a machine that won't understand your defense — clarifies your own thinking.

The catches that matter

Buried in the noise, real bugs surface.

In the daemon PR I mentioned, I had a stop command that was supposed to kill the daemon process. The code was:


os.kill(os.getpid(), signal.SIGTERM)

That kills the CLI process itself, not the daemon. Multiple AI reviewers caught this. I'd have shipped a command that literally did nothing useful.

GitHub Code Quality caught me using asyncio.suppress(asyncio.CancelledError) — which doesn't exist. The correct form is contextlib.suppress(). I use the latter all the time, but an AI assistant suggested the former and I missed it in my review. Would have caused a runtime error. My AI reviewers caught my AI developers' mistakes.

Copilot flagged an inverted conditional:


if not (project or not isinstance(project, Path) or not project.exists()):

The logic was backwards. I'd have been showing warnings when I shouldn't and staying silent when I should have warned.

Sourcery caught that my systemd service file generator wasn't quoting paths. Any user with a space in their home directory would have had a broken service file.

In another PR, Copilot found a format string error — %r% s%r instead of %r, %s, %r — and a type error where I was dividing a boolean by an integer instead of dividing lengths.

None of these were catastrophic. All of them would have wasted my time later. Some would have reached users before I noticed.

Why multiple reviewers?

If AI code review is annoying, why run four of them?

Coverage. They catch different things.

Looking at the actual data, each reviewer has a distinct personality:

Copilot generates the highest volume (37 comments on one PR) but has the lowest signal-to-noise ratio. About 55% of suggestions get implemented. It's good at catching unused code, potential AttributeErrors, and logic issues. It's also the most repetitive — it'll flag the same pattern ten times if it appears ten times.

Sourcery is the opposite: fewer comments (12 on that same PR), but nearly all of them matter. About 90% implementation rate. It catches security issues like path quoting, architecture problems, and it tracks which suggestions you've addressed with a "✅ Addressed" marker, which is nice.

GitHub Code Quality goes deep on static analysis. It caught the asyncio.suppress misuse that no other reviewer flagged. It also provides autofix capabilities — click a button and the fix is applied.

Claude (via CI) writes comprehensive architectural reviews. Good for cross-cutting concerns. The downside: I had 11 nearly identical reviews on one PR because my CI workflow triggers it multiple times. That's a configuration problem, not a Claude problem.

The enum .variable thing gets flagged by Copilot every time. The asyncio.suppress bug? Only Code Quality caught that one.

Running multiple reviewers also creates a consensus signal. When all of them flag the same thing, it's probably worth a closer look.

This isn't for everyone

I want to be honest: this approach requires a specific temperament.

You have to be okay with noise. Lots of it. If seeing "wrong" suggestions irritates you, this will drive you crazy. You need to be able to scan, dismiss, and move on without getting emotionally hooked by bad advice.

You also have to be solo (or nearly solo). On a team, AI code review creates a different dynamic. Human reviewers might feel their feedback is redundant. The comment threads become unreadable. The value proposition changes entirely.

And you have to accept that you're trading time for coverage. Reading through 60 comments takes time, even if most are quick dismissals. That's time you could spend actually coding.

For me, the trade is worth it. I don't have teammates to catch my mistakes. The AI reviewers are bad teammates, but they're the teammates I have.

The real point

Here's what I've learned from this experiment: AI code review isn't good. The tools are noisy, repetitive, and often wrong about intent. Developers who find it annoying are correct.

But "not good" isn't the same as "not useful."

When you're a solo developer, your options are:

No code review at all
Annoying, imperfect, robotic code review

I pick option two. Not because it's good, but because it's better than nothing. It creates friction where there would otherwise be none. It catches some bugs that would otherwise ship. It forces me to articulate decisions I might otherwise make unconsciously.

Is this the future of code review? God, I hope not. Human reviewers who understand context and intent will always be better than pattern-matching robots.

But until I have those human reviewers, I'll keep letting the robots fight over my PRs.

I'm building CodeWeaver, semantic code search for AI agents. If you want to see what 60+ AI comments on a PR looks like, check out PR #184. It's not pretty, but it works.

Post originally appeared on the Knitli blog at https://blog.knitli.com/i-let-four-ai-code-reviewers-fight-over-my-prs/

A beginner's level introduction to context engineering and context management.

Adam Poulemanos — Tue, 06 Jan 2026 16:02:13 +0000

Context Engineering: How We Work Around the Goldfish Problem

Adam Poulemanos for Knitli ・ Jan 6

#contextengineering #mcp #ai #development

A beginner's level introduction to context engineering and context management.

Adam Poulemanos — Tue, 06 Jan 2026 15:52:04 +0000

Context Engineering: How We Work Around the Goldfish Problem

Adam Poulemanos for Knitli ・ Jan 6

#contextengineering #mcp #ai #development

Context Engineering: How We Work Around the Goldfish Problem

Adam Poulemanos — Tue, 06 Jan 2026 15:50:43 +0000

Originally published at blog.knitli.com

tl;dr

Context engineering is the practice of deciding what information goes into a large language model's (LLM's) context window and when
The dominant approach today is summarization: using an LLM to compress context when the window fills up
Summarization works well for some tasks but loses critical details in others, forcing agents to re-retrieve the same information repeatedly
Other approaches like RAG and fine-tuning exist, each with real tradeoffs
Understanding these tradeoffs helps you choose the right tools and know when to trust them

If Context is King, Context Engineering is Kingmaking

In my last post, I explained that LLMs are goldfish. They can only see what fits in their context window, and they forget everything else. I also showed how context poisoning happens when you dump too much irrelevant information into that window, making it harder for the model to find what matters.

So how do engineers actually deal with this? That's where context engineering comes in.

Context engineering is the practice of deciding what information an LLM sees, when it sees it, and how much of it gets included. It's the difference between an AI that gives you useful answers and one that hallucinates or misses obvious details.

The Summarization Approach (What Most Tools Do Today)

Here's how most AI coding tools handle context limits:

The agent starts working on your task. It reads files, makes changes, runs commands, and accumulates history. All of this fills the context window.

When the window approaches its limit—usually around 95% full—the system needs to make room for more.

The standard solution: call another LLM to summarize everything that's happened so far. The summarization LLM gets the entire conversation history and a prompt like "compress this to save tokens." It produces a shortened version, the system discards the original details, and the agent continues with this compressed summary as its only record of what came before.

This is called "auto-compact" or "context compression" or "hierarchical summarization," but it's all the same basic idea. Claude Code does it. Cursor does it. Most agent frameworks do it.

Why is this approach so common? Because it's a reasonable response to a hard constraint. Context windows are finite. Work sessions aren't. Something has to give, and summarization is cheap to implement and works surprisingly well for many tasks.

But it has real limitations.

Where Summarization Works and Where It Doesn't

Summarization works well when:

The task is mostly linear (do step A, then B, then C)
Earlier details genuinely don't matter once completed
The agent won't need to revisit specific information from early in the session

Summarization struggles when:

The task involves debugging or iterative refinement
The agent needs to compare current state to earlier state
Specific details (exact error messages, variable names, code snippets) matter more than general narrative

Here's a concrete example of the second case:

An agent is debugging a function. It reads the function definition, identifies a bug, makes a fix, tests it, sees a new error, and reads the function again to understand the new error.

Then the context window fills up. The system summarizes.

The summary might say: "Fixed bug in calculate_total function, encountered new error."

But it doesn't include the actual function code, the specific error message, or the change that was made. That detail is gone.

Two turns later, the agent needs to understand why the new error is happening. It doesn't have the function code anymore—that got summarized away. So it re-reads the file, re-retrieving context it already had.

This happens often in debugging workflows. Agents spend time and tokens re-reading information they've already seen because summarization discarded the details they need.

It's like taking notes during a meeting by writing "discussed the budget" and then, when someone asks you what the actual numbers were, having to go back and re-watch the recording.

The deeper problem: summarization is lossy in unpredictable ways. The LLM doing the compression has to guess what's important. Sometimes it guesses wrong. When that happens, the agent either fails or has to backtrack and reconstruct context from scratch.

Other Approaches and Their Tradeoffs

Summarization dominates because it is easy and often 'good enough.' There are other approaches, each with their own pros and cons:

RAG: Retrieval Augmented Generation

RAG treats your codebase (or other data) like a searchable database. It breaks everything into chunks, converts them into numerical representations called embeddings (essentially coordinates in a high-dimensional space where similar content clusters together), and stores them. When the agent needs information, it searches for relevant chunks and adds them to the context.

The appeal: RAG lets you work with massive codebases without loading everything at once. You retrieve only what's relevant for each query.

The tradeoff: The quality of RAG depends entirely on how you implement it. Naive implementations use simple similarity matching—essentially asking "which chunks of text sound most like this query?" This works okay for documentation but breaks down for code. A function definition might have low textual similarity to a query about debugging an error that function causes. Dependencies three files away don't "sound like" the immediate problem, even when they're critical to understanding it.

More sophisticated RAG systems understand code structure: they know about function calls, imports, type definitions, and can traverse these relationships. This makes retrieval much more accurate but is significantly harder to build.

The practical result: RAG quality varies enormously between tools. When evaluating a tool that uses RAG, the question isn't "does it use RAG" but "how smart is its retrieval?"

Caching: Remember What You've Already Seen

Some systems cache frequently-accessed context so they don't have to re-retrieve or re-process it. If an agent reads the same file five times during a session, caching means you only pay the retrieval cost once.

The appeal: Caching directly addresses the re-retrieval problem that summarization creates.

The tradeoff: Caches take memory. They can become stale if files change. And deciding what to cache (and when to invalidate it) adds complexity.

Agents: Let the Model Search for Itself

Agent systems give the LLM tools to retrieve its own context. Instead of pre-selecting information, you let the model search files, run commands, or call APIs to find what it needs.

The appeal: Agents can adapt. They search for what they need in the moment and course-correct based on what they find.

The tradeoff: Agents are slower and more expensive. Every search is another API call (called an "inference call"), which means more tokens—the basic units that AI providers charge you for—and more compute. Agents also make mistakes: they search for the wrong things, miss obvious information, or get stuck in loops. And because the model has to reason about what to retrieve at each step, the whole process uses tokens fast.

Fine-tuning: Bake It Into the Model

Fine-tuning means retraining the model on your specific codebase or domain so it "learns" your patterns and doesn't need them in the context window.

The appeal: Once fine-tuned, the model already "knows" your code. No retrieval needed.

The tradeoff: Fine-tuning is expensive and inflexible. You need GPU time, training data, and constant retraining as your codebase changes. Fine-tuned models also aren't great at specific details—they learn general patterns but still hallucinate function names or recent changes. For fast-moving projects, fine-tuning can't keep up.

The Real Challenge: Context Engineering is a Hard Problem

Good context engineering for coding tasks requires several things that are genuinely difficult:

Understanding code structure: What depends on what? Which files matter for which tasks? How does information flow through the system? This requires parsing and analyzing code, not just treating it as text.

Dynamic decision-making: Different questions need different context. Understanding what a function does requires different information than debugging why it crashes, which requires different information than refactoring it for performance.

Precision: Pulling the right information without including noise. Every irrelevant token makes it harder for the model to find what matters.

Most tools make pragmatic tradeoffs here. They use approaches that are cheap to implement and work well enough for common cases, even if they break down on complex tasks. That's not incompetence—it's engineering under constraints.

But it does mean that for complex, real-world work, context engineering is often the limiting factor. Not model capability. Not prompt quality. Whether the model has the right information to work with.

The Hidden Costs of Poor Context Engineering

When context engineering breaks down, the costs show up in three places:

Money: Every token you process costs money. When you re-retrieve the same information repeatedly, you're paying to process those tokens over and over. When you include irrelevant context "just in case," you're paying for all of it. For teams using AI at scale, this can significantly increase infrastructure costs.

Speed: Processing large contexts takes time. The more tokens you feed the model, the longer it takes to respond. When agents have to search repeatedly for information they've already seen, tasks stretch out.

Reliability: When the model has to work with lossy summaries or sift through irrelevant information, it makes mistakes. It latches onto the wrong details, misses important nuance, or hallucinates. This is why AI coding tools sometimes confidently suggest fixes that break your code or miss bugs that are obvious if you have the right context.

What You Can Do About It

If you're using AI coding tools, here are some practical things to keep in mind:

Watch for re-retrieval patterns. If you notice an agent reading the same file multiple times in a session, that's a sign that context is being lost. Some tools handle this better than others.

Match tools to tasks. Summarization-based tools work fine for straightforward, linear tasks. For debugging or iterative work, look for tools with smarter context management.

Ask about context strategy. When evaluating AI coding tools, ask: How do they handle long sessions? What happens when the context window fills up? Do they use RAG, and if so, how sophisticated is the retrieval?

Keep sessions focused. Shorter, focused sessions are less likely to hit context limits than sprawling multi-hour sessions. If you're doing complex work, sometimes starting fresh with targeted context is more effective than continuing a bloated session.

Provide explicit context. Don't assume the tool will find what it needs. If you know a specific file or function is relevant, mention it directly.

How I'm Trying to Fix It

With Knitli, I'm working on context engineering that understands code structure—tracking dependencies, call graphs, repository patterns, and type relationships so retrieval is precise and adaptive rather than approximate and sweeping. My goal: assemble exactly the context each task needs, avoiding both the re-retrieval problem and context pollution.

My first attempt at that is CodeWeaver, which you can try today. It's rough around the edges and doesn't achieve that goal yet, but it's much more capable at attacking the problem than existing tools. It's also fully open source and free.

I'm not claiming I've solved context engineering. It's a genuinely hard problem. But I think current approaches leave a lot of room for improvement, and I'm focused on closing that gap.

If you're interested in following along, you can learn more at knitli.com, or try CodeWeaver and get involved in making something better.

What context engineering challenges have you run into with AI coding tools? I'd love to hear your experiences in the comments.

From Intelligence Expert to AI Business Leader: A Surprising Path

Adam Poulemanos — Thu, 09 Oct 2025 02:34:40 +0000

Tinker, Tailor, Soldier, Spy

I've been a lifelong technologist and tinkerer. Linux CLI user for 25 years. Built a web design business at 13 (long before JavaScript existed). Even assembled a basic Linux distro from scratch once.

Despite decades of solving computer problems and writing the occasional bash script, I never quite broke through to serious programming. I'd tried to learn a few times and failed - the learning curve couldn't hold my interest long enough with the tools available.

And I didn't work in tech. I was an 18-year intelligence officer and senior leader of a global workforce. My work was spying (well, leading it).

The Philosophy That Shaped Everything

My entire leadership ethos came down to one principle: remove barriers so people can do their best work.

Let the people in the field--the doers--do what they do best. Give them the safety and decision space to succeed. Make innovation feel safe, not risky.

I was obsessive about plain language because anything else created uncertainty, and uncertainty breeds caution. When people aren't sure if they're allowed to try something, they don't try it.

As a heavily regulated 'business', law and policy are deeply linked to intelligence outcomes. I dug deep into every law and policy that could impact our work and systematically questioned everything that might be a myth. "We can't do that" barriers often turned out to be misunderstandings (or complete fabrications), not rules or laws. My job was finding those barriers and destroying them, along with any others that kept good people from doing good things.

This philosophy worked. We turned around failing teams, made a (relatively) small $50M program into a blockbuster that garnered White House attention -- attention that exceeded programs 100x our size and got me a couple of surprise phone calls that skipped about 8 layers of management.

AI Solved a Problem and Changed Everything

Two things happened in close proximity that changed my path.

First, I found ChatGPT right after its first public release and when it was powerful enough to fuel my insatiable appetite for deep learning. As someone with ADHD who learns by diving deep into problems, this was transformative. ChatGPT could work with my hands-on, tinkering style and accelerate my learning process dramatically.

Second, I hit a recurring data problem at work that I couldn't shake. I was managing operations for a 300+ person global organization, constantly frustrated that I couldn't get solid analysis of workforce activity and performance when all the data I needed was there. It just wasn't in a usable form. I tried to find expertise to help, but it didn't exist or wasn't available.

I did what came naturally: I learned to do it myself in Python, using AI-accelerated learning to iterate and solve real problems.

The limitations of AI were actually a hidden benefit. AI could help me dig deep into complex problems - like building and automating feature extraction and inference pipelines - but couldn't quite dig me out or debug it. It forced me to understand the fundamentals, to learn to shape my questions and context for better outcomes, to understand the 300-ish things I'd skipped along the way.

I was hooked. The AI-driven programming loop was incredibly powerful. I was already a fast learner, but AI let me accelerate that by 3x (maybe 10x...).

I spent every spare moment coding, learning, iterating. Literally every week I'd look back at my code and think "what was I thinking? This is amateur hour stuff." Three years later, I still have that experience, though now it's more like a month or two.

By February 2025, I was professionally proficient in Python and TypeScript, with some Rust under my belt.

When You Can't Lead Authentically Anymore

Then came the crisis. The new administration issued executive orders that conflicted with my core leadership principles - the ones that had made me effective for 18 years.

I believe deeply in what Amazon calls "have backbone; disagree and commit" - if I don't like a decision, I'll tell you why and try to convince you to change it. If I fail to change your mind, I'll turn around and champion it completely.

That's how effective organizations work, with leaders who put outcomes before themselves.

But this was different. I couldn't do that anymore without sacrificing who I was.

I couldn't lead genuinely while being asked to implement policies that contradicted the values I'd built my career on. Transparency. Psychological safety. Empathy. Speaking truth to power. The same values that made me effective at removing barriers and enabling people to do their best work.

In my mind, I had to go. There was no choice. I could stay and compromise my principles - either by championing values I deeply disagreed with or by breaking my commitment to effective followership. Or I could leave, keep my principles, and use them to build something.

When the administration offered its infamous "fork in the road" deferred resignation initiative - continue receiving salary and benefits until September 30th in exchange for resigning - I jumped.

Same Values, Different Problem

At the same time, I'd been watching something troubling: AI was creating a new divide. The technical few who understood prompt engineering, context windows, and model selection were getting incredible value. Everyone else was struggling.

All the most powerful AI tools required high technical expertise to use effectively. This bothered me. It was the same barrier problem I'd spent 18 years solving - just in a different domain. So, I started building Knitli with a clear mission: democratize AI for normal people. Remove the barriers between technical and non-technical users.

Then I hit the wall myself.

As I was building, I kept getting frustrated by how AI coding tools were simultaneously powerful and really, really dumb. They'd generate code that ignored my architecture, my patterns, my existing conventions, my dependencies. A quick conversation about this problem, and a lot of reflection, ballooned over a couple days into a realization: the fundamental issue was context.

AI agents needed carefully tailored context that shifts and adapts throughout interactions. The "dump all the context" approach everyone was using made agents both ineffective and unnecessarily expensive. What was missing was a context layer - systematic, intelligent, adaptive.

The insight clicked: this was the same problem I'd been trying to solve for non-technical users, just one level deeper. And solving it for developers first would actually enable the broader vision later.

Building With the Same Philosophy

Now I'm building Knitli to solve the fundamental context problem in AI-driven software development.

We're building tools that help AI agents understand codebases the way I helped my teams understand their mission space: deeply, systematically, and with enough context to be confident.

Thread provides intelligent, adaptive context to AI agents so they understand your architecture, patterns, and existing code. CodeWeaver makes code navigation and comprehension actually pleasant for humans.

My philosophy hasn't changed: remove barriers. Make complex things accessible. Use plain language. Question assumptions about what's possible. Enable people--and AI--to do their best work without friction.

The vision evolved, but the values stayed constant.

The journey from intelligence executive to AI entrepreneur wasn't planned. But it makes perfect sense in hindsight. I'm solving the same problems I've always solved - just in a different domain, with the freedom to practice my values without compromise.

Sometimes the best solutions come from understanding problems from multiple angles. And sometimes you need uncomfortable realities to force the leap.

(I'm not immune to the problems I'm trying to solve, either. I had to completely scrap the first versions of Thread and CodeWeaver. The speed of using AI produced code that would have been impossible to maintain, I now assign AI agents much smaller tasks while I deliberately shape their context to get what I need from them -- a process Thread and CodeWeaver hope to eventually automate.)

I'd like to hear about similar decisions other people made - when did you realize the only way forward was to do something completely different?

]]>

Tree-Sitter Grammars Explained: Leveraging Data for Clarity

Adam Poulemanos — Mon, 06 Oct 2025 14:22:20 +0000

How a Week of Jargon and 25 Languages Resulted in Creating the Parser I Needed

Clarity Engineering

TL;DR: If You're Here Because Tree-sitter's `node-types.json` Makes No Sense

You're not alone. Tree-sitter's terminology is confusing because it evolved from internal implementation details, not developer clarity.

The Core Problems

"Named" doesn't mean "has a name" (everything has a name). It means "corresponds to a named grammar rule" an internal detail that's noise for most use cases.
"Fields" and "children" are both parent-child relationships but the distinction is unclear. Fields are semantic ("this node's condition"), children are positional ("this node's first child").
Everything is a "type" : Nodes, edges, and abstract categories all use the same terminology, obscuring the differences that matter.

This post uses formatting unsupported by dev.to, please view the rest at our website

Context and Context Windows: What You Need to Know

Adam Poulemanos — Fri, 26 Sep 2025 18:17:18 +0000

Why Your AI is a Goldfish

Part 2 of Knitli's 101 introductions to AI and the economics of AI

tl;dr

Large language models (LLMs) use a fixed-size context window to process input and generate responses, but they don't have memory like humans.
The context window contains all the information the model can consider at once, and when it overflows, older information is lost.
LLMs are trained on outdated data, leading to a preference for older information and potential hallucinations when asked about unknown topics.
Context management is crucial, as including too much or irrelevant information can hinder response accuracy.
Engineers use techniques like prioritizing recent information and filtering out irrelevant details to manage context effectively.

LLMs and Their 'Memories'

When people talk about 'AI' today, they usually mean ChatGPT, Claude, or Gemini. These tools all use large language models (LLMs). LLMs consist of billions of parameters_think of each parameter as a number in a massive mathematical equation. The model combines these parameters with your input to generate responses. Its a huge statistical machine: predicting the most _likely output based on its training parameters and the context you gave it (intentionally or otherwise).

The Context Window 'Container'

LLMs don't remember like humans do (or at all). Instead, they work with a fixed-size container called a context window. Everything you send the model every word, file, or bit of data_and_ all of the model's previous responses fill this container. When the container overflows, the oldest information disappears. The model can no longer see it, even if you can still see it on your screen.

Think of it this way: the context window contains all the information the LLM can consider at once. Any information not in the window, or that doesn't fit in it, doesn't exist to the model.

Time Bias: Why LLMs Live in the Past

The context window is the only way to provide LLMs with recent or specific information. Companies train these models on huge datasets, but collecting and processing this data takes years. Most of the training data is 2-3 years old or even older. A model might say it was trained up to a month or two ago, but recent information is only a tiny part of its overall training data. Most of what it knows is outdated.

For instance, if you ask an LLM about a programming framework released last month, it won't know about it unless you include the documentation in your context window. The model's training data just doesn't have that recent information. This leads to a strong preference for older information, even when newer details might be more important.

It's also important to note that if you ask LLMs to provide information on something they haven't been trained on and have no context for, they will likely produce hallucinations. A hallucination occurs when the LLM generates false or made-up information that can sometimes sound real or nearly true. This happens because you asked it to provide information about something it can't, so it creates something similar based on its training.

Model training is permanent. Context is temporary.

Your AI Friend is a Goldfish: It Has No Memory

Models can't save their context between messages. The system that feeds data to the LLM rebuilds and reprocesses the entire context history every single turn. This process of generating output from input combined with the models training is called inference.

Here's what actually happens: You send "hey there" to ChatGPT. Your buddy ChatGPT replies with a friendly response. When you send your second message, the model doesn't just process that new message it processes your first message, its first response, AND your second message all at once. This context grows with each exchange.

The model treats this entire conversation thread as one giant input until the window reaches its limit and forces older turns to drop. Thats why responses can change tone or forget earlier details as conversations grow longer.

The Context Window Paradox

Context window sizes have grown dramatically. A few years ago, models handled only a few thousand words (8,192 or 16,384 tokens). Today's top models can process 128,000 to 2 million tokens worth of information.

Bigger windows allow more context, but they create new problems. Fill a window with irrelevant information, and you're giving the model junk data that makes accurate responses harder. Processing large contexts also takes more time and costs more money.

This creates a paradox: any information you exclude might be crucial, but including too much information can poison the model's ability to respond accurately.

The Context Poisoning Problem

Most current tools don't handle context well. For coding tasks, many systems add everything that might be relevant into the model's context without careful selection. They might include:

Entire codebases when only a few functions are needed
Outdated documentation along with current specs
Error logs mixed with successful runs
Multiple conflicting examples

This adds more confusion than clarity, making it difficult for the model to find useful information among irrelevant details.

Why This Matters for You

Understanding context windows helps explain common AI frustrations:

Why an AI assistant "forgets" something you mentioned earlier in a long conversation
Why providing too much background information sometimes makes responses worse
Why the same prompt can give different results depending on what else is in the context (since models are probabilistic, meaning they create output based on statistical likelihood, even the exact same context can lead to different results).
Why AI coding tools sometimes suggest outdated approaches despite having access to current documentation

Working Around the Limitations

Engineers use several techniques to manage context effectively, like prioritizing recent information, summarizing older exchanges, and filtering out irrelevant details. But these approaches have their own trade-offs and limitations.

The bottom line: "context is king" for LLMs. Feeding the right amount of the right information in the right order matters more than raw context window size. This makes context management the central engineering challenge for anyone building with LLMs.

Our next post in this series will explore current solutions to these context problems including their strengths, weaknesses, and why even the best approaches today aren't quite "good enough" for complex, long-running tasks.

visit us at knitli.com to learn how we're fixing the context problem, and sign up for our waitlist!

Understanding Tokens: What They Are and Why They're Important

Adam Poulemanos — Fri, 26 Sep 2025 02:08:14 +0000

Part 1 of Knitli's 101 introductions to AI and the economics of AI

Tokens are Parts of Words

Most people think AI, like ChatGPT, reads words. It doesn't.

It reads tokens invisible chunks of text that power every interaction.

When you type something like:

Hello, world!

The model doesn't see two words. It sees four tokens:

Hello 1 token
, 1 token
world (note the space) 1 token
! 1 token

That simple greeting is 4 tokens , not 2 words. Code fragments break into even more tokens because punctuation, brackets, and symbols all get split up. (What is and isn't a token and what becomes one actually depends on the model, so our example isn't exact.)

Tokens Aren't Expensive. Processing them is.

When you send your tokens to get processed, each one must be run through billions of math operations on very expensive GPUs every single time. Thats where the cost comes from:

Power-hungry hardware
Data center space
Cooling
Staff to maintain and secure it

More tokens more GPU time higher costs.

Fewer tokens less GPU time lower costs.

Right now, you probably don't see the meter running. You pay a flat subscription; someone else covers the token bill.

Under the hood, tokens are the biggest driver of compute costs at every AI company.

Tokens are the Foundation for Everything Else

Context windows , or how much a model can see at one time, are measured in tokens.
API pricing is per million tokens (API access is when companies or developers access an AI model to provide their own service, like a chatbot on a website, or just for internal use).
Memory , efficiency, and much of prompt engineering are all about how tokens are used.

If you want to understand AI, and how it really works, or why it sometimes costs so much. You have to start with tokens.

Learn more about how Knitli is tackling the hidden economics of AI at the source, visit us at knitli.com and subscribe to our waitlist for updates!

DEV Community: Adam Poulemanos

AI Killed One Open Source Business Model; Not Open Source

The Winners Are Winning BIG

What Actually Changed?

Tailwind's Model vs. AI

The Winners' Models

The Hidden Problem: Contribution Quality

Good Examples Already Exist

The Licensing Question

I'm about 90% decided to move CodeWeaver to AGPL-3.0

My Reasoning for CodeWeaver

What This Means for Maintainers

The Bottom Line

When it's all you have, bad code review is better than no code review. ... but please don't let this be the future.

I let four AI code reviewers fight over my PRs

Adam Poulemanos ・ Jan 12

I let four AI code reviewers fight over my PRs

AI code reviewers are annoying

The solo developer's dilemma

What AI code review actually looks like

The .variable vs .value war

The catches that matter

Why multiple reviewers?

This isn't for everyone

The real point

A beginner's level introduction to context engineering and context management.

Context Engineering: How We Work Around the Goldfish Problem

Adam Poulemanos for Knitli ・ Jan 6

A beginner's level introduction to context engineering and context management.

Context Engineering: How We Work Around the Goldfish Problem

Adam Poulemanos for Knitli ・ Jan 6

Context Engineering: How We Work Around the Goldfish Problem

tl;dr

If Context is King, Context Engineering is Kingmaking

The Summarization Approach (What Most Tools Do Today)

Where Summarization Works and Where It Doesn't

Other Approaches and Their Tradeoffs

RAG: Retrieval Augmented Generation

Caching: Remember What You've Already Seen

Agents: Let the Model Search for Itself

Fine-tuning: Bake It Into the Model

The Real Challenge: Context Engineering is a Hard Problem

The Hidden Costs of Poor Context Engineering

What You Can Do About It

How I'm Trying to Fix It

From Intelligence Expert to AI Business Leader: A Surprising Path

Tinker, Tailor, Soldier, Spy

The Philosophy That Shaped Everything

AI Solved a Problem and Changed Everything

When You Can't Lead Authentically Anymore

Same Values, Different Problem

Building With the Same Philosophy

Tree-Sitter Grammars Explained: Leveraging Data for Clarity

How a Week of Jargon and 25 Languages Resulted in Creating the Parser I Needed

Clarity Engineering

TL;DR: If You're Here Because Tree-sitter's node-types.json Makes No Sense

The Core Problems

Context and Context Windows: What You Need to Know

Why Your AI is a Goldfish

tl;dr

LLMs and Their 'Memories'

The Context Window 'Container'

Time Bias: Why LLMs Live in the Past

Your AI Friend is a Goldfish: It Has No Memory

The Context Window Paradox

The Context Poisoning Problem

Why This Matters for You

Working Around the Limitations

Understanding Tokens: What They Are and Why They're Important

Tokens are Parts of Words

Tokens Aren't Expensive. Processing them is.

Tokens are the Foundation for Everything Else

TL;DR: If You're Here Because Tree-sitter's `node-types.json` Makes No Sense