By pairing OpenCode (an alternative to Claude Code and Codex) with Obsidian (a local-first, Markdown-based knowledge base), you can build a unified, human-readable, and machine-actionable SoT.

When you layer Agentic Driven Development (ADD) on top of this stack, the documentation stops being a passive diary and becomes an active participant in building your software.

The Stack: Git + OpenCode + Obsidian

Using proprietary, siloed tools for project management creates platform lock-in and fragmented context. Here is why the open, local-first combination wins:

• Everything is Markdown: Obsidian stores files as plain Markdown documents. OpenCode projects produce text files. Because everything is text, your code and your documentation can live in the exact same Git repository.

• Bi-Directional Linking: Obsidian’s core strength is linking notes together. You can link a feature request to a specific technical design document, which links directly to local code snippets.

• Version-Controlled Truth: When documentation lives inside your project repository, changes to documentation are tracked via Git commits alongside the code. A feature pull request updates the code and the documentation simultaneously.

Why Agentic Driven Development is the Perfect Match

While Behavior-Driven Development (BDD) is excellent for turning user stories into automated tests, Agentic Driven Development (ADD) is far more appropriate for this specific stack.

ADD views AI agents as autonomous collaborators rather than just autocomplete tools. Agents require structured, highly contextual, and easily readable data to operate effectively. An Obsidian vault hosted on an open repository acts as the perfect cognitive map for an AI agent.

1. The Context Engine for AI Agents

AI agents struggle with massive, disorganized codebases. By structuring your project architecture, business logic, and roadmap inside Obsidian using clear Markdown hierarchies and tags, you create a map the agent can instantly scan. The agent reads your Obsidian notes to understand why a feature is being built before it touches the code.

2. Autonomous Documentation Sync

In an ADD workflow, the agent doesn't just write code; it maintains the SoT. When an agent refactors a backend service, it can autonomously update the corresponding architectural diagrams (using Mermaid.js inside Obsidian) and API endpoints documented in your vault.

3. Executable Roadmaps

With your project source code and Obsidian, your project roadmap is just a text file. An AI agent can parse your Roadmap.md or Todo.md, identify the next highest-priority task, spin up a new git branch, write the code, test it, and submit a pull request—all while updating the task status in your vault

How to Set It Up

1. Initialize a Unified Repo: Create an open-source repository. Inside it, create a /src folder for your code and a /docs folder for your Obsidian vault.

2. Link the Vault: Open the /docs folder as a new vault in Obsidian.

3. Define Agent Prompts: Instruct your development agents (like Cline, Roo Code, or custom LLM scripts) to always check the /docs folder first for context before writing code, and to update those docs when a feature changes.

The Verdict

When your code is open, your documentation is a local-first network of Markdown files, and your primary developer is an AI agent, you eliminate project friction. You no longer write documentation for a dusty corporate wiki; you write it to program your AI agents.

With advanced, low-cost AI models like DeepSeek, a company can build its own basic customer service bots, data analysis tools, and writing assistants.

Instead of buying ten different software tools, you route your workflows through one AI system and pay pennies for the actual computing power used.

The Cost Breakdown: SaaS vs. AI

Let’s look at a realistic scenario for a mid-sized company with 50 employees using standard tools for copywriting, customer support, and CRM data management.

1. The Traditional SaaS Route

• Average SaaS cost: £40 per user, per month (across 3 essential tools)
• Monthly bill: £2,000
• 6-Month Cost: £12,000
• 12-Month Cost: £24,000

2. The DeepSeek AI API Route

Using DeepSeek's highly efficient API models, you only pay for the volume of text generated (measured in tokens). For a team of 50 heavily using AI daily, they might process 100 million tokens a month.

• Average AI data cost: £100 per month
• Internal setup & hosting: £150 per month
• Total monthly bill: £250
• 6-Month Cost: £1,500
• 12-Month Cost: £3,000

The Catch: Upfront Investment

While the operational savings are massive, you must consider the initial setup. You will need to hire a developer or use an agency to build the internal interface for your staff.

If building a custom dashboard costs your company £5,000 upfront:

• Your 6-month savings adjust to £5,500
• Your 12-month savings jump to £16,000

From Year 2 onwards, the software is completely yours, and the ongoing savings go straight to your bottom line.

Here's what you need to know:

1. Mixture-of-Experts (MoE)

DeepSeek uses Mixture-of-Experts to balance model capacity with computational efficiency.

• Specialized Experts: Each feedforward block is divided into multiple "experts" (e.g., V3: 256 experts). Instead of every token passing through all parameters, only a few top-ranked experts (2–4 per token) are activated by a routing mechanism that scores token embeddings against expert embeddings.
• Routing Mechanism: A sigmoid gating function with learnable expert biases dynamically selects which experts are engaged for each token. This resolves load-imbalance problems common in MoE architectures without adding auxiliary-loss terms.
• Compute Savings: MoE allows DeepSeek to behave like a 671B parameter dense model on training while activating only ~5.5% (37B) of parameters during inference. This reduces both GPU memory usage and runtime costs, enabling long-context capabilities without prohibitive expenditure.
• Shared Experts & Redundancy: Certain popular experts can be duplicated across GPUs in deployment to avoid bottlenecks. This ensures throughput remains high under uneven token distribution.

2. KV Cache and Multi-Head Latent Attention (MLA)

Transformer models rely on storing Key (K) and Value (V) tensors for each token to compute attention efficiently over long contexts—this is the KV cache. For extremely long sequences (e.g., 128K tokens in DeepSeek), naive caching would cause memory usage to skyrocket.

MLA tackles this:

• Low-Rank Compression: Instead of caching all K/V tensors at full precision, DeepSeek projects them into a smaller latent space (c_t), drastically reducing storage (sometimes >90% memory savings).
• Query Compression: Although queries are ephemeral, MLA also compresses them slightly to maintain consistency without burdening cache memory.
• Separation of Content and Position: Rotary Positional Embeddings (RoPE) are applied independent of content representations. Keys are split into a compressed content component and a RoPE-aware positional component, ensuring positional info is preserved while keeping most KV tensors compressed.
• Decompression-on-Demand: During attention computation, latent representations are projected back to full dimensions through a lightweight reconstruction, effectively providing the same representational power at a fraction of the memory cost.
• Inference Impact: MLA enables long-context inference while keeping GPU memory requirements practical. In V3, KV cache memory was reduced by over 93% without degrading quality.

3. Cache Optimization Strategies

DeepSeek’s architectural approach not only compresses KV tensors but complements this with efficient caching strategies:

Absorb vs Naive Modes:

• Naive: Stores all expanded K/V tensors. Highly memory-intensive.
• Absorb: Stores only compressed latent representations, expanding them dynamically when needed. Reduces cache usage by nearly 98–99% in practice.
• Dynamic Context Scaling: For sequences exceeding base context lengths, attention scaling factors and positional embeddings are adjusted to preserve numerical stability while maximizing effective receptive field.

4. Synergy Between MoE and MLA

• Memory-Efficient Activation: Since only a subset of experts is active for every token (MoE), the memory saved by MLA complements this sparse computation, enabling model deployments with both enormous capacity and manageable resource usage.
• Preservation of Model Quality: Unlike grouping heads arbitrarily (e.g., GQA) or quantizing caches aggressively, MLA provides low-rank compression while still allowing attention heads to access distinct representations for diverse heads.
• Scaling to 1T Parameters (V4): With upcoming V4 models, MoE and MLA together permit ultra-high parameter counts (1T) while reducing active parameters per token (32B) and keeping memory and compute costs feasible.

5. Practical Implications

• Fine-Tuning: LoRA-like adapters can be inserted post-training into attention layers to adapt MoE and MLA without retraining the full model, balancing capacity, efficiency, and accuracy.
• High-Context Applications: For tasks like multi-document reasoning or long-session chat, MLA ensures long token histories remain manageable in GPU memory, while MoE delivers computational efficiency.
• Inference Cost: The combination allows DeepSeek to offer API pricing that is significantly lower than dense models of comparable capability while maintaining competitive performance.

These innovations make DeepSeek AI suitable for research, enterprise applications, and long-form reasoning tasks where both speed and context depth are paramount.

What can you realistically expect?

I wanted to build a project that would use enough tokens to realistically benchmark typical usage for a project. As I work for a warehouse and logistics company I decided to build a project that allow users to manage typical equipment found in a warehouse.

I called it EquipIt and you can visit the project on GitHub: (https://github.com/techno-yeti/equipit).

For EquipIt I used less than £2 of tokens, I believe this is due to the above mentioned reasons but mostly hitting the cache.

I wanted to show some screenshots for the EquipIt app to showcase the style and detail the AI came up with. I believe that DeepSeek v4 Pro is usable for commercial use (see project screenshots below):

Planned Requests Dashboard: shows the current requests planned for that day (the day can be changed with the calendar select widget).

Listing All Requests: shows all requests stored in the app (good for planning days and weeks ahead).

Printable Delivery Advice Notes: shows printable delivery advice note for the driver to give to the security gate on exiting the yard, this can only be used once).

Limiting Email Addresses: to stop other companies using the app there is an email restriction function.

There are other features that are not shown here: trailer templating, listing equipment types, user management and the help center.

Conclusion

DeepSeek’s architectural elegance lies in orchestrating sparsity (MoE) and efficient attention caching (MLA) to enable high-parameter, long-context LLMs that remain economically and operationally feasible. By compressing what needs to be stored and sparsifying what needs to be computed, DeepSeek achieves a remarkable balance between scale, speed, and accuracy, representing a state-of-the-art approach to large language model design.

After having launched my own blog and an equipment management web app as a realistic practice project I will tell you how to get the most out of your AI assistant.

It all boils down to defining exactly what the AI assistant should do. By doing this the AI is laser focused on the task at hand and you'll no longer have to worry about token burn rate. But what does a spec actually look like?

I have posted a set of spec files for a MERN-based project on my GitHub account (link can be found above next to my avatar picture).

Feel free to edit it for your own projects and if you would like to, post a link to an update in the comments section below.

Bearing in mind I used this format before I heard of agent skills. The downside is you'll have to change the spec files everytime you wish to build something.

I've also gotten into the habit of getting the AI model I'm working with to generate a set of specs in case I wish to regenerate the source code with certain changes (for example if a client decides to go with an alternative CSS framework), I usually include this with the project so that I don't lose context.

If you're looking for something more generic that can work across multiple projects then this GitHub repo might be something to test:

https://github.com/addyosmani/agent-skills

My experience of using AI has always been with using a fully fledged IDE with an agent being used as nothing more than Intellisense on steroids. At the same time of deciding to use an AI coding tool I also decided to try a new text editor.

After installing Zed I clicked around to get an overall feel of what Zed is capable of and I saw an agent panel that spanned half of the width of the app indicating that Zed is giving AI agents first class support.

I then signed up for Zed Pro to enable the agents selection panel and decided to use Claude Sonnet as this AI model was recommended by Zed. I saw very quickly that Claude Sonnet was eating up a chunk of money and I looked at other AI models that I thought performed just as good, but are cheaper and that's when I tried Gemini 3.5 Flash.

(see below the pricing table from Zed Industries' website)

For those who have yet to try out AI agents, I would estimate that Gemini 3.5 Flash costs ~£50 per day for 8 hours of continuous use. Bearing in mind users won't be running AI models continuously due to code refactoring and feature evaluating, but I think ~£50 per day is acceptable for fair use.

I hope that better frontier AI models will make the likes of Gemini 3.5 Flash cheaper in the future and perhaps even offer capped pricing at 4-6 hours of continuous use for £100 per month.

I guess you're wondering what features I planned for, right? Although I prompted Gemini 3.5 Flash with features, it came up with some interesting implementations:

The first one was a Google SEO Optimizer.

The second one was a cookies banner directly generated from its own CORS code.

The third one was a cover image uploader, which has allowed me to re-use already existing images should I have a long running post series, for example writing a weekly news post.

You're probably wondering if I would recommend using agentic AI for coding projects...

Yes, but it comes with a couple of caveats, the output code is around 95% useful, meaning the AI agent will write comments very similar to the way humans would, this makes sense if the AI models have been trained on OSS projects being hosted on places like GitHub, also you need to have a good idea of what features your app would need and this can only come from experience.

To prevent token overburn I would start off by implementing small projects at first and build up to more complicated projects after you feel confident with the tools. 😉

This blogging software was created with agentic AI models. In a later post I describe how I used AI to design and implement this project and the reasons why I chose this method.

If you have yet to dip your toes in generative coding then I hope to inspire you to start your own projects.