AWSD

Conductor, not Coder

Unknown — Sun, 07 Jun 2026 00:00:00 +0000

I've never produced as much as I have since I started using AI. And yet, some days, after six commits and seven hours of work, I feel like I've done nothing.

For two months, I've been building Yog-Sothoth alone — an analytics and observability tool for the Meteora DeFi protocol on Solana. Architecture, Rust backend, Next.js frontend, database, CI/CD, Docker, UX, content, documentation — that's me on all of it. A project of this complexity normally requires a team: a backend developer, a frontend developer, a DevOps engineer, a product manager, occasionally a designer or a data analyst. The cost can climb to €10,000 a month.

And yet I'm doing it alone. Does AI replace a team? After two months of intensive development, my answer is no. But it fundamentally changes the size of the team you need, and the role of each person in it.

How it actually goes

At the start of the project, Claude proposes a three-piece architecture: a Rust daemon for the indexer, Next.js for the frontend, Node.js for the API. It's coherent, I approve it, I move on.

Then comes the day I start the API. I write code, and I realize I'm about to rewrite in Node everything that already exists in yog-core, my shared Rust crate: schemas, SQL queries, repositories, contracts. It's all there, cleanly separated between the domain and the persistence layer in a standalone yog-persistence crate. And I'm about to maintain two implementations of the same domain.

I stop. I reopen the discussion with Claude. Its first answer: building the API in Rust will take much more work. That's wrong — it doesn't see that the domain factoring in yog-core makes the operation trivial. I decide: it will be a yog-api crate in Rust. Two days later, the API is in place.

A week later, same story. The API works but it's hand-rolled. I restart the conversation, I identify the problem, Claude proposes, I choose: switch to axum. The implementation takes a day. Acceptable, because I'd spent time up front cutting the project along DDD and SRP lines, and any one piece can be swapped without touching the rest.

What AI does better than I do

I barely write any code anymore. But no line is added without my approval. Claude writes and proposes; I approve, reject, redirect.

At pure coding, AI is better than I am. It produces higher-quality code, faster, without syntax errors. Repetitive tasks become a formality: Zod schemas, DTOs, unit tests. It codes, I verify.

Shipping a feature used to take time: reading documentation, searching StackOverflow or GitHub, then trial and error. The cycle is different now: I lay out the problem and the context, I have a technical discussion with Claude, we explore several paths and weigh complexity against relevance, the code gets generated once the context is solid, I verify, I integrate.

It's much less sexy than the vibe-coding fantasy. It's also much more effective.

Then what am I for?

If Claude writes the code, what am I for?

Whatever the exact nature of what AI is doing, it doesn't carry the consequences of its proposals. It doesn't know which problem is important and which can wait. It doesn't know what actually adds value to the product. It proposes, I live with it.

A concrete example. At the start, Yog-Sothoth was pool-centric: the project was built around pools, like most DeFi observability tools. That's what the words "DeFi" and "observability" naturally evoke, and it's exactly what an AI proposes — a weighting of probabilities over related vocabulary.

An AI would never have made the decision to switch to protocol-centric. And yet that's the project's best decision, the one that gives it its whole point. Because this isn't a technical problem: it's a problem of market understanding and product positioning.

To the AI, option A and option B are two probability distributions. To me, they're choices I'm committed to — I'm the one who'll pay the cost of the wrong one. I'm the only one guaranteeing the project's long-term coherence. I'm the only one with the full picture: product, architecture, constraints, future evolutions.

And before anyone tells me "you're not giving it enough context": Yog-Sothoth is a complex project split into multiple subsystems. The context isn't complex in itself — what's complex is the different contexts and their interactions. No AI can hold that load yet.

Is it still my product?

If all I do is direct, without producing anything myself, is Yog-Sothoth my product, or an assemblage of fragments written by others and recycled by the AI?

Flip the question: a developer who copies a snippet from StackOverflow and pastes it into their project — do they still own that project? Yes. Because the value of a project has never been in the syntax of the code. It's in the understanding of the domain, in the ability to translate a business need into a program.

The value of Yog-Sothoth isn't in the Rust syntax, the React components, or the SQL queries. It's in the choice of which data to observe, which metrics to compute, which architecture to set up, which tradeoffs to accept. Those are my choices, my responsibilities.

Conclusion

The job is changing. I code less, I produce more, I'm cognitively tired. The satisfaction metric is no longer the number of lines shipped but the number of decisions made correctly. I'm no longer a coder — I'm a conductor, and it's far more demanding.

I don't know what the developer job will look like in five or ten years. What I am convinced of, though, is this: AI doesn't replace responsibility. Someone still has to set the direction, arbitrate the choices, understand why the product exists, and own the consequences.

AI hasn't turned me into a team of ten. It's let me concentrate my time on the decisions that matter, by delegating execution.

For now, the one who decides is still the developer.

Yog-Sothoth: How a Simple Question Changed the Nature of the Product

Unknown — Fri, 01 May 2026 00:00:00 +0000

The starting point

Yog-Sothoth is a real-time liquidity analysis engine for Meteora pools, a decentralized exchange protocol on Solana. The tool ingests the on-chain transaction stream, reconstructs pool state, computes financial metrics, and will eventually expose alerts and visualizations through a web dashboard. It's not a block explorer like Solscan: it's an analysis and signal tool, somewhere between Dune Analytics and Nansen, focused on Meteora liquidity.

By the time I asked the question, I had two weeks of code behind me: the ingestion pipeline was working, DAMM v2 swap decoding was in place, PostgreSQL persistence too. What I had never done, however, was seriously check whether other tools already occupied this space.

The review

I started with what I should have done at the outset: typing "Meteora analytics", "Meteora LP tracker", "Solana DEX flow analyzer" and reading what came back. Within an hour, I had a reasonable map of the landscape.

The first group is dense. UltraLP, TrackLP, MetLab, Tokleo, MetEngine, Cleopetra, Liquid Nova, Starseed. All built around the same proposition: my positions, my P&L, my copy trading. The user shows up with a wallet, the tool tracks what that wallet does in pools. The pool is the unit of subscription, the position is the unit of analysis.

The second group is more disparate. Bitquery offers Solana flows specific to DEXes, with explicit Meteora support and several delivery channels (WebSocket, Kafka, gRPC). It's powerful, but their product remains a structured data service: you subscribe to pairs, wallets, aggregated trades. The user is still the one defining what to observe. Shyft, on the other hand, sells Yellowstone gRPC streaming with DAMM v2 examples in Rust — technically very close to what I'm building, but positioned as an infrastructure provider. They sell the pipe, not what flows through it. Alongside these two, Blockworks Research exposes aggregated dashboards on Meteora (fees by pool, volumes), but on consolidated historical data for research use, not on the live flow.

What I'm looking for in this list is a tool that observes Meteora as a whole. One that doesn't ask the user to designate which pools to watch. One that doesn't reason in terms of individual positions but in terms of protocol flow — which pools concentrate activity, where liquidity moves, what patterns emerge at the scale of the entire protocol.

I don't find it. The LP tools are user-centric. The infrastructure providers are transport-centric. Nobody, in this list, positions themselves as an analytical observer of the protocol.

That's enough to convince me there's a space. Not a huge market, maybe not a market at all — but an angle that isn't taken.

The pivot

Yog-Sothoth is not an LP tool. It's a flow observer that watches Meteora as a whole.

This sentence sounds harmless. It changes everything.

In the previous version, the base unit was the pool. The user declared which pools to follow, the system subscribed to each one, and all the analysis was built pool by pool. The pool was the entry key of the domain — the thing you subscribe to, index, store.

In the new version, the base unit is the protocol. You subscribe to Meteora as a whole. Pools become data emitted by the flow: they're discovered as transactions arrive, recorded along the way, never declared in advance. Analysis happens at the protocol level, and individual pools are just one dimension among others for slicing that flow.

The name takes on its meaning at that point. Yog-Sothoth, in Lovecraft's cosmogony, is the entity that sees everything simultaneously — past, present, future, all planes of existence at once. If the tool bears that name, it has to see everything happening on Meteora, not a selection. The pivot makes the project consistent with its own name.

And it places it in a space that the competitive review showed to be sparsely occupied.

What this changes in the code

I had two weeks of code behind me, written with the pool as the key everywhere. The conceptual translation into code wasn't a detail — it touched the spine of the domain. Four changes capture the essentials.

The pipeline's entry point. RpcListener used to store a set of watched pools and open one WebSocket subscription per pool. It now stores a HashSet<Protocol> and opens one subscription per Meteora program. Concretely, the system shifts from N subscriptions (one per configured pool) to a handful of stable subscriptions (one per protocol variant). The system no longer asks the user what to watch: it watches Meteora.

The data flowing between ingestion and indexing. The typed channel connecting RpcListener to IndexerService used to carry (WatchedPool, Signature) — the pool was needed to know what to decode. It now carries (Protocol, Signature). It's a single line of code, and it's the boundary between the two versions of the project: before, the pool identifier preceded the transaction; now, the transaction reveals it.

Parsers that discover pools instead of receiving them. Previously, parsers were instantiated with a pool_address argument — they were told in advance which pool they would decode. Now, they're instantiated without any address, and a helper extract_pool_address reads position 1 in the accounts of the outer DAMM v2 instruction to derive it from the transaction itself. It's a complete reversal of the flow: the pool is no longer an input to the parser, it's an output.

A new domain model, Pool, as a discovery registry. Where there was WatchedPool (declarative, created by the user), there's now Pool (descriptive, upserted on every incoming event). It's the database trace of the fact that nothing is configured anymore: we record what passes through.

The rest of the refactor follows mechanically from these four points. SQL migration redone from scratch without foreign keys to align the schema with the new domain. reserve_a/b renamed to reserve_in/out in SwapEvent because the swap direction now matters more than the stable convention of the old model. Removal of WatchedPool, WatchedPoolService, PgWatchedPoolRepository — all the machinery of the old world, now dead. The full diff is on the repo for anyone who wants to look.

Mainnet test, that same evening

The refactor took a day. By the end, what remained was finding out whether the pipeline held up under real data. WebSocket connection to api.mainnet-beta.solana.com, subscription to the DAMM v2 program (cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG), execution. Signatures arriving in real time.

First observed behavior: no swaps decoded. The DAMM v2 instruction detector consistently returns false. Diagnosis: program_id_str was passing the string "meteora_damm_v2" instead of the actual on-chain identifier — a leftover from the pool-centric model where the label was sufficient. One-line fix, the detector starts working again.

Second behavior: the detector now recognizes DAMM v2 transactions, but extracting the associated transfers fails every time. extract_swap_transfers was looking for the DAMM v2 instruction inside the inner instructions, whereas in the new protocol-centric model it's an outer instruction that needs to be identified as such, with transfers then read from its inner group. Fixed by tracking the outer's index instead of doing blind matching. Extraction works.

After these two fixes, DAMM v2 swaps are decoded live against mainnet. Amounts come out correct, mints come out correct, pools appear in the discovery table as transactions arrive — without any of them having been declared in advance. The pipeline holds end to end.

Not everything is resolved. The public RPC is heavily throttled on getTransaction: acceptable for validating the architecture, untenable for continuous use — switching to Yellowstone gRPC (Shyft, Helius, Triton) will be necessary before claiming production readiness. Liquidity events, for their part, don't persist correctly to the database yet; swap decoding works, liquidity event decoding still needs work. And the pool-centric machinery isn't entirely removed — there are still zombie structs to clean up.

But the essential is validated. The pivot didn't stay a sketch on paper: it runs against mainnet on the same evening.

What this day shifted

The lesson I take from this day isn't "check your competitors before coding". If I had done it at day zero, I would have had nothing concrete to compare against — no domain in mind, no sketched architecture, no intuition of what would be easy or hard to build. The review would have stayed abstract.

What this day shifted is my understanding of when the question becomes useful. Checking that what you're building has an angle isn't a business plan step to tick off before writing the first line. It's an architecture step: it gets asked at the moment when you have enough code to understand what you're doing, and not yet enough for pivoting to cost too much. Two weeks, for this project, was about the right moment. Three months would have been too late.

The raw cost of the pivot is easy to count: a day of refactoring, two bugs caught during the run, some zombie code left to clean up. The cost of having continued without doing it is harder to quantify but more important. I would have shipped a product that already existed under eight other names, better funded and better distributed. Yog-Sothoth would have been a portfolio exercise, not an attempt at a product.

The question I leave open, and which has no clean answer, is one of frequency. How often should you reopen this question on an ongoing project? Every month? At every phase change? When you sense something doesn't fit, without knowing what? I don't have the answer. But I now know that asking it on a Sunday evening, almost out of boredom, can change the nature of a project in twenty-four hours.