The gist got already over 500 stars (a few hours later), hundreds of forks, dozens of comments from people already implementing their own versions of it.

And there isn’t a single line of code in the entire thing.

What Karpathy Actually Shared

The idea is simple and powerful: instead of doing RAG, uploading documents, retrieving chunks, generating answers from scratch every time, you let the LLM incrementally build a wiki. You feed it sources. It reads them, extracts key information, creates pages, updates cross-references, flags contradictions, and maintains the whole thing over time.

Knowledge compounds instead of being re-derived on every query.

But here’s the part that matters for this article. At the bottom of the gist, Karpathy writes:

This document is intentionally abstract — describing the idea, not specific implementation. The right way to use this is sharing it with your LLM agent and working together to instantiate a version fitting your needs. The document only communicates the pattern. Your LLM figures out the rest.

Read that again. He’s not saying “here’s a prototype, go build on it.” He’s saying: here’s an idea, give it to your AI, and it will build it for you.

The idea is the deliverable.

Code Used to Be the Hard Part

For decades, the bottleneck in software was implementation. You could have the best idea in the world, but without the ability (or the team, or the funding) to write the code, it stayed in your head. “Ideas are cheap, execution is everything” was gospel. And for good reason — translating a concept into working software required deep expertise, time, and sustained effort.

That equation is inverting.

LLMs can write code. Not perfectly, not always, but well enough that a clearly described idea can become a working prototype in minutes. The bottleneck is no longer “can you build it?” It’s “do you know what to build?” and, more importantly, “can you describe it well enough that an AI can build it?”

Karpathy didn’t need to publish a reference implementation. Everyone who reads his gist can paste it into Claude Code, Codex, Cursor, or any agent and say “build this for me.” The implementation becomes a conversation between a human and an LLM. What needed to be shared was the *pattern*, the mental model, the architecture, the why.

The Spec Is the Software

There’s something quietly radical in Karpathy’s architecture. His LLM Wiki has three layers: raw sources, the wiki itself, and the schema: a document like `CLAUDE.md` or `AGENTS.md` that tells the LLM how the wiki is structured and what to do.

That schema is not code. It’s prose. Natural language instructions. And yet it is the program. It defines behavior, structure, and workflow. It’s executable, not by a compiler, but by an LLM.

We’re watching a new kind of software emerge. One where the specification and the implementation collapse into the same artifact. You write what you want in plain language. The LLM interprets and executes it. The boundary between “describing the system” and “building the system” dissolves.

This is why sharing the idea matters more than sharing the code. The code is ephemeral, it’ll be different for every person, every stack, every LLM. The idea is the durable part.

What Humans Are Still For

Karpathy puts it plainly:

The human curates sources, directs analysis, asks good questions, and thinks about meaning. The LLM does everything else.

This is the new division of labor. The LLM handles the bookkeeping, the cross-references, the summaries, the consistency checks, the formatting. The tedious work that makes people abandon wikis, gardens, and knowledge bases. The work that scales linearly with the size of the system and eventually crushes you.

The human does the part that can’t be automated: deciding what matters, choosing what to investigate, recognizing when something is interesting, asking the question nobody thought to ask.

In this world, the most valuable thing you can do is *think clearly and share what you’ve thought*. Not hoard it until you’ve built a polished product. Not wait until you have a working demo. Share the idea. Someone, or something, will build it.

The Memex Finally Works

Karpathy traces his pattern back to Vannevar Bush’s Memex from 1945, a personal knowledge store with associative trails between documents. Bush imagined everything except who would do the maintenance. Eighty years later, we have the answer: the LLM.

But the bigger realization is that Bush also couldn’t solve distribution. His Memex was a private device. You couldn’t easily share a trail of thought with someone else and have them *build on it* in their own context.

Now you can. Karpathy shared a trail of thought as a markdown file. Hundreds of people are forking it, adapting it, instantiating it in their own domains, personal health tracking, research, competitive analysis, reading notes. The same idea, running on different data, for different people, built by different AIs.

This is what the open-source movement looks like when the thing being shared is no longer code but thought.

Share Your Ideas

The lesson from Karpathy’s gist is not about wikis or RAG alternatives. It’s about leverage.

If you have a clear idea for how something should work: a workflow, a system, a pattern, a tool write it down. Describe the what, the why, the structure. Don’t worry about the implementation. Don’t wait until you have time to code it. Don’t keep it private because “it’s just an idea.”

Share it. In plain language. As a gist, a blog post, a message to a friend.

In 2026, a well-articulated idea is a program that anyone with an LLM can run.

Books, conference talks, and engineering cultures revolved around principles such as reusability, clean abstractions, modularity, and future-proof design. Code was something you crafted carefully, like infrastructure. Once written, it was expected to support many use cases over time.

But the economics of software development have changed.

Today, a growing portion of code is not written to last. It is written to solve a problem quickly, serve its purpose, and often be replaced or discarded later. In many cases, investing time to make code perfectly reusable no longer delivers the return it once did.

We are entering the age of disposable code not careless code, but code whose primary value lies in solving a specific problem efficiently, not in being reused forever.

When Writing Code Was Expensive

To understand this shift, it helps to remember a time when writing code was genuinely costly.

In earlier decades, development cycles were slower. Tooling was limited. Infrastructure had to be managed manually. Debugging was harder, deployments were riskier, and distributing software updates was expensive. Every new module required careful design because mistakes were difficult to undo.

Under those conditions, the logic was simple: if writing software is expensive, make it reusable.

Developers spent large amounts of time designing general solutions that could serve multiple applications. Frameworks were built internally. Shared libraries were carefully maintained. Teams invested in abstraction layers intended to survive for years.

The effort spent on generalization was justified because rewriting things later would be even more expensive.

In other words, engineering for reuse was a rational economic decision.

The Cost of Producing Code Has Collapsed

That economic model has been steadily eroding.

Modern development environments have dramatically reduced the cost of producing working software. High-level languages, powerful frameworks, cloud platforms, package ecosystems, containerization, and continuous deployment pipelines have removed much of the friction that once existed.

Today, a developer can spin up infrastructure in minutes, integrate complex services through APIs, and rely on vast open-source ecosystems instead of building everything from scratch.

More recently, AI-assisted development has pushed this trend even further. Code generation tools can produce working prototypes, integrations, and data transformations in seconds.

When code can be produced this quickly, the economics change.

If something takes only a few minutes or hours to recreate later, it may not be worth spending extra time today trying to make it universally reusable. In many cases, the effort required to generalize a solution exceeds the cost of simply writing a new one when needed.

The result is a quiet but profound shift: code is becoming cheaper than design.

The Hidden Cost of Reusable Systems

Ironically, the real cost of software has never been writing it, it has always been maintaining it.

Reusable code must serve many contexts. That means it must anticipate edge cases, handle multiple configurations, remain backward compatible, and stay understandable for people who did not originally write it.

Over time, these requirements accumulate complexity.

A small function written for a single task might be easy to understand. The same function, generalized to support five different use cases, can quickly become harder to reason about, harder to test, and harder to modify.

The more reusable a system becomes, the more constraints it carries.

Maintenance becomes a balancing act between stability and flexibility. Every change risks breaking someone else’s use case. Every improvement requires careful coordination.

In contrast, problem-specific code has fewer obligations. It serves one purpose. If that purpose changes, the code can change freely. If the system disappears, the code can disappear with it.

From a long-term perspective, narrowly scoped solutions can sometimes be cheaper to maintain than heavily generalized ones.

The Trap of Premature Abstraction

Software engineering has long warned against premature optimization. A similar problem exists with reuse: premature abstraction.

Generalizing code requires predicting future needs. But predicting future needs is notoriously unreliable.

Developers often try to design flexible abstractions early in a project, imagining how the system might evolve. These abstractions aim to handle multiple scenarios before those scenarios actually exist.

The result is often unnecessary complexity.

Many abstractions end up solving problems that never occur. Others turn out to be slightly wrong once real requirements appear. Instead of simplifying the system, they become obstacles that developers must work around.

This has led to a growing shift in mindset: solve the specific problem first.

If the same pattern appears multiple times, then abstraction becomes justified. Instead of guessing what might be reusable, developers allow reusable structures to emerge from repetition.

In practice, this often produces simpler systems.

Software Is Becoming More Ephemeral

Another factor reinforcing this shift is the changing nature of software itself.

Modern systems are increasingly ephemeral.

Cloud infrastructure spins up and down automatically. Services are deployed and replaced frequently. Feature flags enable experiments that run briefly before being removed. Data pipelines evolve rapidly as requirements change.

In this environment, many pieces of code exist only temporarily. They support a migration, enable a test, transform data during a transition, or glue together two systems for a limited period of time.

Treating such code as permanent architecture can be counterproductive. Designing elaborate abstractions for something that will be replaced in six months is often unnecessary.

Instead, the practical goal becomes clarity and speed, not architectural permanence.

AI Is Accelerating the Trend

The rise of AI-assisted programming tools is amplifying all of these forces.

When developers can generate working code from descriptions, examples, or prompts, the barrier to producing new software becomes even lower.

In this environment, the most valuable skill shifts away from writing every line manually and toward defining problems clearly.

Code increasingly becomes a generated artifact, produced when needed rather than carefully handcrafted for reuse.

This does not eliminate the importance of good engineering judgment. But it changes where that judgment is applied. Developers spend less time constructing perfect abstractions and more time deciding what should exist at all.

In other words, the focus moves from code production to problem framing and system design.

Reuse Has Not Disappeared, It Has Moved

Despite these changes, reuse remains essential in software development. It has simply migrated to a different layer.

Instead of repeatedly reusing internal abstractions within each company, teams now rely heavily on shared infrastructure provided by the broader ecosystem.

Open-source libraries, cloud services, APIs, and platform frameworks provide the reusable building blocks of modern software.

Authentication, data storage, messaging, deployment pipelines, monitoring, and machine learning infrastructure are rarely built from scratch anymore. These components are reused at a global scale.

On top of this shared foundation, however, the application code written by individual teams increasingly becomes context-specific.

It integrates services, encodes business rules, transforms data, and orchestrates workflows. Much of it is unlikely to be reused outside its original context and that is perfectly acceptable.

The reuse happens below. The customization happens above.

From Code Craft to Problem Solving

All of this suggests a subtle cultural shift in software engineering.

For many years, programming culture emphasized code craftsmanship. Writing elegant abstractions and reusable architectures was seen as the hallmark of a skilled engineer.

Those skills are still valuable, particularly in foundational systems. But in many everyday contexts, the highest-value activity is not crafting reusable code it is solving problems effectively.

The goal is not always to build something that lasts forever. Sometimes the goal is simply to deliver a solution that works, is understandable, and can evolve quickly as the situation changes.

In such environments, code becomes closer to a tool than a product.

Like a script written to automate a task or a spreadsheet created to analyze data, its value lies in the outcome it enables. Once the problem changes, the code can change or disappear.

The Scarce Resource Is No Longer Code

As the cost of generating software continues to fall, the limiting factor in engineering shifts elsewhere.

The scarce resource is no longer the ability to write code.

It is the ability to understand problems clearly, choose the right level of abstraction, and decide when complexity is justified. Sometimes the right decision is to design a reusable system. Other times the right decision is to write something simple, solve the immediate issue, and move on.

Recognizing the difference is becoming one of the most important skills in modern software development. Because in a world where code is cheap, the true value lies not in the code itself but in knowing why it should exist in the first place

.

Today, you can generate an entire feature in minutes with tools like Claude Code, Codex, Cursor. You describe what you want in plain language, maybe add a few constraints, and an agent produces working code faster than you can finish your coffee.

It feels like magic.

But there’s a catch.

The faster we generate code, the less we can trust it.

And that changes everything.

The Bottleneck Has Shifted

For decades, writing code was the hard part.

We spent days or weeks crafting logic, carefully handling edge cases, and reviewing each other’s work. Tests, when they existed, were often an afterthought written to satisfy coverage thresholds or appease QA.

Correctness lived mostly in human heads.

Today, a single developer with a capable AI agent can generate 5–10× more code than just a couple of years ago. Entire modules, refactors, even backend rewrites can be produced in minutes.

Velocity is no longer the constraint.

Trust is.

When code is cheap and abundant, the real question becomes:

Does this system actually behave correctly?

The Problem With AI-Generated Code

AI coding agents are astonishingly good at pattern matching.

They can:

• Scaffold features

• Translate between frameworks

• Refactor large codebases

• Fill in boilerplate instantly

But they are still fundamentally weak at something critical: understanding truth.

They struggle with:

• Security boundaries (missing or incorrect authorization checks)

• Race conditions in distributed systems

• Performance degradation under load

• Malicious or unexpected inputs

They produce code that looks right far more often than code that is right.

And because they’re fast, they can generate incorrect code at scale.

Code Is No Longer the Source of Truth

In this new world, something profound has happened:

The code is no longer the most valuable artifact in your repository.

It is transient.

It can be rewritten by an agent tomorrow:

• in a different language

• with a different framework

• using a new reasoning loop

• optimized in ways you didn’t ask for

The implementation is fluid.

But one thing cannot be fluid:

What “correct” means.

And there is only one place where that definition can live in an executable, enforceable way:

Your tests.

The Test Suite Is the Constitution

Think of your system like a country.

The implementation is the current government. It can change. It will change.

The tests are the constitution.

They encode the invariant of your business, your domain, and your system. If the code violates those rules, it is wrong, no matter how elegant or efficient it looks.

In 2026, the test suite is no longer a safety net.

It is the specification.

A New Development Workflow

This shift changes how we build software. The most effective teams are converging on a new workflow:

1. Define behavior in tests first

Translate vague product requirements into executable specifications.

2. Use the agent to implement

Provide context and iterate until all tests pass.

3. Review the diff; but focus on tests

Implementation can change. Tests define intent.

4. Merge when the system satisfies the spec

In this model, you are not primarily writing code. You are defining correctness.

What Makes a Good Test in the Agentic Era

AI agents can generate basic tests, happy paths, simple assertions, boilerplate.

But the most valuable tests are still deeply human.

They require:

• domain understanding

• adversarial thinking

• experience with failure modes

The tests that matter most are the ones that encode truth that isn’t written anywhere else.

Examples include:

• Business invariant (“inventory cannot go negative”)

• Edge cases (“empty input with partial state”)

• Security constraints (“user cannot access another account”)

• Cross-system consistency (“ledger matches transactions”)

• Property-based guarantees (“output is always sorted”)

Why Weak Tests Fail Faster Now

In the pre-AI world, weak testing was survivable. Code changed slowly. Engineers understood most of the system. Bugs were introduced at a human pace.

Now, change is constant and amplified.

Agents can:

• refactor entire modules

• swap libraries

• “optimize” logic

• rewrite APIs

And they will do it confidently. If your tests are shallow, brittle, or overly mocked, they will not protect you. Worse, they can give you a false sense of safety and every refactor becomes a gamble.

Practical Guidelines

If you’re working with AI coding agents, a few principles make an outsized difference:

• Write tests before implementation
  Define what success looks like first.

• Treat tests as specifications, not coverage
  Coverage numbers don’t guarantee correctness.

• Favor integration and behavior tests
  Mocks break easily under refactors.

• Use agents to expand, not define, tests
  Let them fill gaps , but keep control of invariant.

• Review test changes rigorously
  A bad test can redefine “correctness.”

• Monitor flakiness like a production issue
  Unreliable tests destroy trust.

The New Role of the Engineer

For years, great engineers were defined by how well they wrote code. That is no longer the differentiation. Machines can now generate code faster than we can review it.

But they still don’t understand:

• business rules

• risk

• intent

• truth

That responsibility hasn’t gone away, it has become more important.

The best engineers in 2026 are not the ones who prompt the fastest, they are the ones who can precisely define: what must never break.

And encode that in tests.

A Final Thought

For decades, humans were the bottleneck in software correctness. Now machines generate code at incredible speed, but correctness is still on humans.

Code is cheap.
Code is replaceable.

Correctness is rare.
Correctness is priceless.

And the place we preserve it is in our tests.

In 2026, the developers shipping the fastest and cleanest are back where they started: the terminal.

They give their agents direct shell access and let them use the tools that have existed for decades:

git, rg, grep, npm, docker, curl, jq, tail.

No custom servers.
No massive schema descriptions bloating the context window.
Just a strong reasoning model + bash/zsh.

And suddenly, agentic coding actually feels magical.

Why MCP lost its shine for everyday development

For typical development workflows, MCP often adds friction instead of leverage:

• Token overhead: Verbose tool catalogs and schemas consume precious context.

• Reinventing the wheel: Custom MCP servers frequently duplicate what official CLIs already do, more reliably.

• Poor composability: You lose the natural piping, chaining, and one-off hacks that Unix perfected decades ago.

• Model alignment: Frontier models (Claude, GPT variants, Gemini) were trained extensively on shell usage. They understand flags, pipes, errors, and man-page style docs absurdly well.

The sweet spot is simple:

Drop the agent into your project directory, grant shell execution (with safeguards), and describe the task.

The agent plans, runs commands, edits files, runs tests, commits, debugs, and iterates in a tight loop.

MCP still has value for highly structured enterprise integrations—think type-safe SaaS APIs in regulated environments. But for 80–90% of everyday workflows, it’s noise.

The CLI-Native coding agents leading the pack

Claude Code (Anthropic)
Still the leader for deep reasoning across large or complex codebases. Excellent for architectural discussions, careful refactors, and multi-file changes with thoughtful explanations. Native terminal workflow with file edits, shell access, and git integration. Pay-per-use, but worth it for hard problems.

Codex CLI (OpenAI)
Lightweight, fast, and direct access to powerful OpenAI models. Great for generation, testing, and quick iteration. Open-source roots make it easy to tweak or run locally.

Gemini CLI (Google)
Free tier and strong multimodal capabilities. Excels at rapid prototyping, UI tasks, and large projects. Terminal-first with clean ReAct-style loops. Open-source and privacy-friendly.

OpenCode
Multi-model flexibility (75+ providers), LSP integration, and a strong privacy focus. Many developers call it the most productive terminal agent right now. Rapidly growing community.

Where CLI absolutely rushes MCP setups

Monorepo-Wide Refactor

The agent starts with:

rg "oldDeprecatedFunction" .

It plans targeted edits across files, applies changes, reviews with git diff, runs npm test or cargo test, and commits:

refactor: remove deprecated API calls

No GitHub MCP server. No bloated context. Just rg, git, and the test runner.

Full-Stack Debugging on a Production Bug

Instruction: “Reproduce the auth failure in staging.”

The agent runs:

git pull
npm install
npm run dev
tail -f logs/server.log | grep error
curl -v api/auth/check
docker-compose up -d db redis
npm test -- --grep auth

It iterates by editing files, rerunning tests, and probing endpoints.

No Docker MCP. No logging MCP. Just shell fluency.

Scaffolding a New Microservice

Instruction: “Build a Rust API for user profiles with Postgres using Axum + sqlx.”

The agent:

cargo new --bin user-service
cargo add axum sqlx --features postgres
cargo watch -x run
curl localhost:3000/health

Commits along the way. No Rust MCP. No database MCP. The existing toolchain is enough.

CI/CD Flake Fixing

The agent clones the repo, runs workflows locally with act, spots failures, edits .github/workflows/ci.yml or the Dockerfile, validates with docker build, pushes a branch, and opens a PR with gh.

All standard CLI tools. No bespoke CI integration layer.

A Pattern Developers Keep Reporting

Teams that lean into CLI-native agents consistently report:

• Higher velocity

• Fewer token surprises

• More transparent agent behavior

• Easier debugging of what the agent is doing

Quotes circulating lately:

“Stop building integrations. Build CLIs.”
“Bash is the ultimate MCP.”
“Agents were trained on Unix pipes—they’re ridiculously good at it.”
“CLI is all you need. Everything else is ceremony.”

The Terminal Was Always the Universal Dev Environment

In 2026, it’s also the most powerful interface for AI coding agents.

Unless you’re deep inside proprietary enterprise tooling, skip the heavy MCP stack.

cd into your project.
Launch your favorite CLI agent.
Give it shell access.
Describe the task.

And watch it work.

A few months ago, I started using OpenCode because I liked the idea of testing different llms quickly without having to change configuration files or anything else.

Let me first make a quick intro about OpenCode. The easiest way to explain what is OpenCode I code it is the description the founders provide:

OpenCode is an open source agent that helps you write code in your terminal, IDE, or desktop.

It is a tool that optimizes the interaction between the developer, the codebase and the llms to provide the best experience in writing code with the AI support.

Personally, I really appreciate things that work out of the box, without lengthy configurations or complex interfaces.
I started using it every day, initially for fun: ‘make an HTML and add a Three.js scene with a sphere’. ‘IT WORKS’. Funny, but then I went back to my nvim and got my work done!

Then I remember one day, driven by curiosity and all the hype around me, I tried using it on a real codebase to try to solve an issue. I felt like the first time I wrote my ‘Hello World’ in JAVA, yes, my first language was Java.
What surprised me most was not the detailed code generation, but the ability to create a plan and the procedural aspect of the agents:

“”“

- I am reading the file

- I am reading its dependency

- I am looking for further references

- and so on...

“”“

The flow was so reasonable that I immediately felt comfortable using it and trying to explore its limits, its potential, and how I could use it to develop better and learn more concepts at the same time.
Another important aspect is the frequency of updates and trying to stay ahead of the competition, as well as supporting new models and their specific features.

Tools, custom configs and agents

Any development tool must be customized according to your workflow. There is no one-size-fits-all solution, so be wary of ready-made solutions. As with nvim, which continues to be one of the most widely used editors for writing code, precisely because it allows for extensive customization, the same is true for opencode. It integrates seamlessly without disrupting your workflow, but adapts by offering total customization in terms of creating new tools or agents.

Over the months I have been using it, I have played around with lots of configurations, and the most useful thing I have found is to customize the configuration for each project, never keeping a fixed one for everything. This is possible precisely because creating new tools or agents is really easy and intuitive.

Here are some of the ones I use most often, so if you want, you can use them too, or if you have any suggestions, let me know and I’ll be happy to test new configurations.

These are three Agents I use frequently:

1. Code Reviewer Agent (.opencode/agent/review.md)

---
description: Reviews code for best practices, bugs, security, and performance
mode: subagent
model: anthropic/claude-sonnet-4
tools:
  write: false
  edit: false
  bash: false
temperature: 0.1
permissions:
  edit: deny
  bash: deny
  webfetch: allow
---
You are a code reviewer. Analyze provided code for:
- Code quality and best practices (e.g., naming, structure).
- Potential bugs and edge cases.
- Security vulnerabilities (e.g., injection, auth flaws).
- Performance implications (e.g., inefficiencies).
- Maintainability and readability.
Provide constructive feedback without making changes. Use examples from the codebase if referenced.

The Code Reviewer Agent focuses on improving overall code quality by examining structure, naming, readability, performance, and potential bugs or edge cases. It provides constructive feedback and best-practice recommendations without modifying the code.

2. Security Auditor Agent (.opencode/agent/security.md)

---
description: Performs security audits and identifies vulnerabilities
mode: subagent
model: anthropic/claude-sonnet-4
tools:
  write: false
  edit: false
  bash: false
temperature: 0.1
permissions:
  edit: deny
  bash: deny
  webfetch: allow
---
You are a security expert. Scan code for:
- Input validation vulnerabilities.
- Authentication/authorization flaws.
- Data exposure risks.
- Dependency vulnerabilities (e.g., outdated packages).
- Configuration security issues.
Flag high-risk items with mitigation suggestions. Reference OWASP guidelines if relevant.

The Security Auditor Agent specializes in identifying security risks within the codebase, such as input validation flaws, authentication or authorization weaknesses, data exposure, and insecure configurations. It flags high-risk vulnerabilities and suggests mitigations.

3. Documentation Writer Agent (.opencode/agent/docs.md)

---
description: Writes and maintains project documentation
mode: subagent
model: anthropic/claude-haiku-4
tools:
  write: true
  edit: true
  bash: false
temperature: 0.3
permissions:
  edit: ask
  bash: deny
  webfetch: allow
---
You are a technical writer. Create clear, comprehensive documentation.
Focus on:
- Clear explanations with examples.
- Proper structure (e.g., headings, sections).
- User-friendly language.
- Code snippets and references.
Follow formats like: Title as H1, sections with H2/H3, concise bullet points.

The Documentation Writer Agent is responsible for creating and maintaining clear, well-structured technical documentation. It explains features and workflows in accessible language, includes examples and code snippets where helpful, and ensures documentation is organized and easy to navigate for developers and users alike.

For each agent I try to use the proper llm, finding the best one in terms of costs/performances. For example for documentation agent I use claude-haiku, which is less accurate than sonnet but it is also cheaper. Testing it a little bit gives me good vibes and the produced documentation is good enough that convinced me to choose it.

An example on how to use them (I add a space between @ word, to not tag random accounts here) :

• @ review this feature/ → fixes & suggestions

• @ security check auth/ → vuln report

• @ docs write README for api/ → detailed docs

If agents are pretty intuitive and they are a list of instructions, tools are more programming stuff. A tool is a pre-defined structure that the agent (or better the llm) can use to make some actions. They are especially useful if you have some repetitive actions in your projects, for example testing the REST API service you are developing.

The following one is a simple api-test tool that I use daily. As a backend developer I have always to test the messages, response codes, routes consistency of my APIs. There are many tools for doing that like classical CLI command: curl, wget, httpie; or more advanced GUI tools like Insomnia or Postman.

API Tester Tool (.opencode/tool/api-test.ts)

import { tool } from "@opencode-ai/plugin";
export default tool({
  description: "Test API endpoints with HTTP requests",
  args: {
    url: tool.schema.string().url().describe("API endpoint URL"),
    method: tool.schema.enum(["GET", "POST", "PUT", "DELETE"]).default("GET").describe("HTTP method"),
    body: tool.schema.string().optional().describe("Request body (JSON string)"),
  },
  async execute(args) {
    const response = await fetch(args.url, {
      method: args.method,
      headers: { "Content-Type": "application/json" },
      body: args.body ? JSON.stringify(JSON.parse(args.body)) : undefined,
    });
    const data = await response.text();
    return `Status: ${response.status}\nResponse: ${data}`;
  },
});

Here I leave a few bonus tools:

1. Code Formatter Tool (opencode/tool/format.ts)

import { tool } from "@opencode-ai/plugin";
export default tool({
  description: "Format code files using Prettier or similar",
  args: {
    filePath: tool.schema.string().describe("Path to file to format"),
    formatter: tool.schema.enum(["prettier", "black"]).default("prettier").describe("Formatter to use"),
  },
  async execute(args) {
    // Use bash to invoke formatter (assumes installed)
    const cmd = args.formatter === "prettier" ? `prettier --write ${args.filePath}` : `black ${args.filePath}`;
    await Bun.$`${cmd}`; // Or use bash tool if needed
    return `Formatted ${args.filePath} with ${args.formatter}`;
  },
});

2. Log Analyzer Tool (.opencode/tool/log-analyze.ts)

import { tool } from "@opencode-ai/plugin";
export default tool({
  description: "Analyze log files for errors and summaries",
  args: {
    logPath: tool.schema.string().describe("Path to log file"),
    pattern: tool.schema.string().default("ERROR").describe("Regex pattern to search for"),
  },
  async execute(args) {
    // Read file and grep (or use built-in grep tool)
    const content = await Bun.file(args.logPath).text();
    const matches = content.match(new RegExp(args.pattern, "g")) || [];
    return `Found ${matches.length} matches for "${args.pattern}" in ${args.logPath}. Sample: ${matches.slice(0, 5).join(", ")}`;
  },
});

Once you have defined a tool you have nothing to do, just let the agent use it when necessary. Let me do an example:

PROMPT: “add a new GET route /api/v2/alive, the status code for success is 200 and the return message is {“Version”: {get_version_from_env()}}. Once implemented, before writing the test, quickly test with the api testing tool.”

This prompt instruct the agent to create the new route, use the tool to test if it works and then add the test to the /tests folder. As you can see I don’t invoke explicitly the tool, just letting know the llm that you should have a look on the available tools because there is probably something useful for this task.

That’s it. I’ll try to improve every day my workflow and my journey on agentic ai. I hope you have found this article interesting and let me know which is your preferred workflow.

But before talking about neural networks, models, or edge accelerators, we need to step back.

To deploy computer vision on small hardware, we must first understand a simple truth:

Machines do not see images. They process data.

This first article lays the foundation for the series. We will start from the very basics: what an image really is, how machines extract information from it, and why this matters when your final target is a constrained edge device.

What does it mean for a machine to “see”?

When humans look at an image, we instantly recognize meaning: faces, objects, motion, intent. This happens so naturally that we forget how complex the process actually is.

A machine, however, does not see objects. It does not see faces. It does not even see shapes.

A machine sees numbers.

Computer vision is the discipline of turning raw numerical data into useful information. Everything else detection, classification, tracking is built on top of that transformation.

Understanding this point is essential, especially for edge devices, where every computation has a cost.

An image is just structured data

At its core, an image is a grid.

Each cell in that grid is called a pixel, and each pixel contains one or more numbers describing intensity.

A grayscale image can be imagined as a two-dimensional table:

python

image = [
  [12, 15, 18, ...],
  [10, 14, 20, ...],
  [...]
]

Each number represents how bright that pixel is.

Color images are just an extension of the same idea. Instead of one grid, you have multiple grids stacked together typically one for red, one for green, and one for blue.

So an image is not a picture. It is a data structure with spatial meaning.

This perspective is crucial for edge computing: memory usage, data movement, and numerical precision all depend on how these grids are stored and processed.

Resolution and precision

Two properties of images matter a lot when working on small hardware:

• Resolution (how many pixels)

• Precision (how many bits per pixel)

Higher resolution means more data. Higher precision means more memory and more computation.

On powerful servers, this often goes unnoticed. On edge devices, it is the difference between a system that runs smoothly and one that fails to deploy.

One of the recurring themes in this series will be learning how to ask:

“Do I really need this much information?”

Because in computer vision, more data is not always better.

Locality: vision emerges from neighborhoods

One of the most important ideas in computer vision is locality.

Most useful visual information comes from comparing a pixel with its neighbors.

Edges appear where intensity changes abruptly. Textures emerge from repeating local patterns. Motion is detected by observing how local regions change over time.

Conceptually, many vision algorithms follow this pattern:

bash

for each pixel:
  compare with nearby pixels

This simple idea explains why computer vision scales well and why it can be optimized for edge devices.

Local operations can often be computed efficiently, reused, or approximated. They also map naturally to specialized hardware and low-power processing.

Computer vision application. How a computer sees an image.

Computer vision as transformation, not intelligence

It is tempting to think of computer vision as a form of artificial intelligence that understands images.

In practice, it is better described as a pipeline of transformations.

A typical vision system looks like this:

1. Capture an image from a sensor

2. Preprocess it (resize, normalize, filter)

3. Extract relevant features or representations

4. Interpret those representations

5. Produce an output or decision

Each step transforms data into a more useful form.

For edge devices, this pipeline mindset is essential. It allows you to:

• Move computation closer to the sensor

• Remove unnecessary steps

• Decide what must run locally and what can run elsewhere

Efficiency comes from understanding where value is created along the pipeline.

Before deep learning, vision already worked

Modern computer vision is often associated exclusively with deep learning.

But long before neural networks became popular, systems were already detecting edges, tracking motion, recognizing shapes, and measuring distances often in real time and on very limited hardware.

Why does this matter today?

Because edge devices force us to revisit the same constraints:

• Limited memory

• Limited power

• Real-time requirements

Classic computer vision techniques are not obsolete. In many edge scenarios, they are still the most efficient solution or an essential pre-processing step before a learned model.

Why edge devices change the rules

Running computer vision on the edge is not just about moving models closer to the camera.

It introduces new priorities:

• Latency: decisions must be immediate

• Power: every operation consumes energy

• Memory: models must fit in constrained environments

• Reliability: connectivity may be unavailable

• Privacy: raw images often cannot leave the device

These constraints force us to think carefully about what we compute and why.

Understanding images as data, and vision as transformation, is the first step toward making the right trade-offs.

ESP32 stream video application example

Looking ahead

In this first article, we stripped computer vision down to its essentials:

• Images are structured numerical data

• Visual information emerges from local patterns

• Vision systems are pipelines, not black boxes

In the next episode, we will explore how these basic ideas evolved into modern computer vision approaches and how deep learning fits into the picture, especially when your final target is a small, resource-constrained device.

Computer vision on the edge is not about making machines see like humans.

It is about making them see just enough.

Code for the computer visions projects:

https://github.com/orgs/computer-vision-with-marco/repositories

In this article, I'll walk you through the process of setting up and managing a custom service inside an Alpine Linux container, using OpenRC. This could be very useful when you need to run some service alongside your main entrypoint service.

Prerequisites

Before starting, make sure you have the following:

• A running Alpine Linux container.

• Basic knowledge of Linux and OpenRC.

• Access to install packages within the container.

If you're not familiar with OpenRC, it’s a simple and efficient init system, perfect for resource-constrained environments like Alpine.

Step 1: Installing OpenRC (If Necessary)

First, check if OpenRC is installed in your Alpine container. Many base images come with it pre-installed, but if you’re using a very minimal image, it may be missing. To install OpenRC, run:

apk add openrc

Once installed, OpenRC will provide you with tools to manage system services.

Step 2: Writing the Service Script

Let's say we want to create a service that monitors a directory for file creation and the new files name automatically. We'll write a script for this service and place it in /usr/local/bin.

Here's an example of a monitoring script using inotifywait, which you can install with:

apk add inotify-tools

Create the script:

vi /usr/local/bin/monitor_directory.sh

Add some content like:

#!/bin/sh
DIRECTORY_TO_WATCH="/path/to/directory"
echo $$ > /run/monitor_directory.pid  # Store the PID of this process
inotifywait -m -e create --format '%w%f' "$DIRECTORY_TO_WATCH" | while read NEW_FILE
do
    echo $NEW_FILE"
done

Make the script executable:

chmod +x /usr/local/bin/monitor_directory.sh

This script monitors the directory for file creation events and print the name of the newly created files.

Step 3: Creating the OpenRC Service

Now, let's create an OpenRC service that manages this script. Services in OpenRC are managed through init scripts located in /etc/init.d. We'll create one for our file monitoring service.
If you don’t find the /etc/init.d folder, than you need to install the util-linux package:

apk add util-linux

Create the service file:

vi /etc/init.d/monitor_directory

Paste the following content:

#!/sbin/openrc-run

name="Monitor Directory"
description="Monitor a directory"
command="/usr/local/bin/monitor_directory.sh"
command_background=true
pidfile="/run/monitor_directory.pid"

Make the service file executable:

chmod +x /etc/init.d/monitor_directory

Step 4: Using command_background=true and pidfile

In the service script, we set command_background=true, which tells OpenRC to run the script in the background. When running a process in the background, it's important to also specify a pidfile. This is a file where the process writes its PID (process ID), allowing OpenRC to track the running process.

In our case, the pidfile is located at /run/monitor_directory.pid, and the script writes its own PID to this file using the following line:

echo $$ > /run/monitor_directory.pid

The combination of command_background=true and pidfile ensures that OpenRC can correctly manage the background service, allowing you to start, stop, and restart it.

Step 5: Enabling and Starting the Service

Once the service script is ready, we need to enable it to start at boot and start it immediately. To be sure that the container will run at the desired runlevel (which is debug) we can execute the following command:

openrc default

To add the service to the default runlevel so it starts on boot:

rc-update add monitor_directory default

To start the service manually without rebooting:

service monitor_directory start

Step 6: Dockerfile and Entrypoint for Your Alpine Service

To set up your Alpine Linux container with the custom service you created, you'll need to define a Dockerfile and an entrypoint script. This will ensure that the service starts automatically when the container is launched.

Here’s how you can structure the Dockerfile and the entrypoint script.

Dockerfile

FROM alpine:latest

RUN apk update && \
    apk add openrc inotify-tools && \
    mkdir -p /run/openrc && \
    touch /run/openrc/softlevel

COPY monitor_directory.sh /usr/local/bin/monitor_directory.sh

COPY monitor_directory_service /etc/init.d/monitor_directory

RUN chmod +x /usr/local/bin/monitor_directory.sh && \
    chmod +x /etc/init.d/monitor_directory

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh

#!/bin/sh

openrc default

rc-update add monitor_directory default

rc-service monitor_directory start

exec "$@"

Conclusion

By configuring the Dockerfile and the entrypoint correctly, you can build a Docker container that not only runs your custom service inside Alpine Linux but also ensures that the service starts automatically when the container is launched. This makes it easy to manage services in a lightweight container environment.

Alpine Linux's minimalism and OpenRC's simplicity make this a perfect combination for containerized environments, where efficiency and control are key.

Troubleshooting

1. Service Fails to Start:
   Check the /var/log/messages or /var/log/rc.log files for any errors.

2. PID File Not Found:
   Make sure your script writes the PID to the pidfile location specified in the service script. You can check this by manually starting the script and inspecting the contents of /run/monitor_directory.pid.

3. Services Not Persisting Across Reboots:
   If your service isn't starting automatically after a reboot, verify that it’s added to the default runlevel with rc-update.

By following these steps, you should be able to set up any service in an Alpine Linux container and manage it effectively. Happy hacking!

Subscribe now

Why configure Docker for using GPUs will be more and more important ?

Docker is the ‘de facto’ tool to create, test and deploy in production the largest part of the current software and web application. Due to the exponential improvement of Machine and Deep Learning technologies, GPUs have a central role in the development phase, but also in the deployment.

For sure, during the design and training of the model, a large number of GPUs is required to parallelize and speed up this initial phase. However, in the production phase, it is fundamental guarantee the maximum of speed, during the inference step. This means that, a correct configuration of Docker with GPUs could be beneficial for initial phases, but even more for your real business.

First step: instance configuration

To run a container with a GPU requirement, you had to be sure to have installed the NVIDIA Container Toolkit.
Setup the package repository and the GPG key:

distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \
&& curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
&& curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

Install the nvidia-docker2 package (and dependencies) after updating the package listing:

sudo apt update && sudo apt install -y nvidia-docker2

Restart Docker to apply changes:

sudo systemctl restart docker

Now, to be sure that all works fine, test with a minimal image:

sudo docker run --rm --gpus all nvidia/cuda:11.0.3-base-ubuntu20.04 nvidia-smi

This should return the output of the nvidia-smi command.
For more information, HERE the official documentation.

Second step: learn the most important configuration options

In the docker run command above, we use the --gpu option, passing all as argument. This means that docker can use all the GPUs available. Sometimes you don’t want to use all the GPUs, for example for an unbalance of configurations. Mixing different GPUs, for example with 6 GB VRAM and 12 GB VRAM could lead some unexpected behavior. You can be more specific using different arguments like:

• device=<GPU-ID> force to use exactly this GPU

• "device=0,2" force to use just the GPU number 0 and 2, excluding the 1.

• 'all,capabilities=utility' gives a docker access to all the GPUs available, than
  set as ENV variable capabilities=utility, which add to the container some monitoring tools.

Third step: deploy a real machine learning project

Test our configuration with a real application, using Tensorflow Serving. It is a quick way to wrap your model in a web-server, ready to be used in production.
We want to expose an API REST endpoint on the 8501 port. The Tensorflow serving image requires a mounted volume that contains my model, into /model directory.

docker run --gpus all -p 8501:8501 \
--mount type=bind,\
source=/path/to/my_model/,target=/models/my_model \
-e MODEL_NAME=my_model -t tensorflow/serving:latest-gpu

That’s all folks! Hope that this quick walk-through will be useful for your next machine learning projects!

In this article, we’ll explore some of the best VS Code setups and configurations for Python development, including essential extensions, customization, and tips that can help you take your Python coding to the next level.

Extensions

• Python: with the Python Extension, you can take advantage of features like code highlighting, IntelliSense, code navigation, and code formatting. Additionally, it includes built-in support for popular Python frameworks like Django, Flask, and Pyramid. The extension also provides an interactive Python interpreter, enabling you to experiment with code snippets and perform quick calculations without leaving the editor. With integrated debugging support, you can quickly identify and fix any issues in your Python code.

• Python Indent: the Python Indent extension helps to automate the process of indentation, adjusting the code blocks as you type. With this extension installed, you can focus on writing your code, and the extension will take care of the indentation for you. This can save a considerable amount of time and reduce errors caused by incorrect indentation. The Python Indent extension also supports multiple indentation styles, including tabs, spaces, and mixed, allowing you to customize the indentation style to match your coding preferences.

• autoDocstring — Python Docstring Generator: Docstrings are essential elements of Python code, as they provide documentation for functions and methods, explaining what they do and how they work. However, writing docstrings can be a time-consuming and tedious process, especially when you have to write them for numerous functions and methods. The autoDocstring extension helps to automate this process, generating docstrings automatically based on the function or method signature. With just a few keystrokes, you can generate a complete docstring that includes information on the function’s parameters, return values, and any exceptions that may be raised. The autoDocstring extension also supports customization, allowing you to define your docstring format and style.

Configurations

Once you have installed the previous extensions, it is time to edit the settings of Visual Studio Code. This IDE has two settings file, the defaultSettings.json which has the default configuration of the IDE and the settings.json which is the user configuration. The latter is the one that we are going to modify with custom parameters.

First of all let’s see how to find this file. You can directly navigate to the settings.json file on your computer by following these steps:

1. Open Visual Studio Code.

2. Open the Command Palette by pressing “Ctrl + Shift + P” (Windows and Linux) or “Cmd + Shift + P” (macOS).

3. In the Command Palette, type “Open User Settings” and select “Preferences: Open User Settings” from the list.

4. In the Settings editor, click on the “Open Settings (JSON)” link at the top right corner of the window.

This will open the settings.json file in the editor, where you can edit the settings for Visual Studio Code. The first time it looks like very minimal with just few parameters like this:

{
    "workbench.colorTheme": "SynthWave '84",
    "window.zoomLevel": 2,
}

In my case the colorTheme(I love SynthWave ’84) and the zoomLevelof the IDE window. These are general settings, not related to a language, to define some specific parameters just on a specific file format you need something like this:

{
    "workbench.colorTheme": "SynthWave '84",
    "window.zoomLevel": 2,
    "[python]": { // python section  
        "editor.rulers": [88],
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true
        },
        "editor.formatOnType": true
    },
}

Introducing the "[python]" key you can add a configuration, which will be applied just when you are editing a .pyfile. As you can see these are editor’s configurations, like editor.rulers which insert a vertical line after 88 characters.

I highly suggest to have a section for each language, in this way you have always the best experience without any overlapping setting.

Let’s move on the section regarding python’s extensions settings.

{
    "workbench.colorTheme": "SynthWave '84",
    "window.zoomLevel": 2,
    "[python]": { // python section  
        "editor.rulers": [88],
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true
        },
        "editor.formatOnType": true
      },
    // Local interpreter can be the default python 
    // or if you are using poetry "$(poetry run which python)"
    "python.defaultInterpreterPath": "/usr/local/bin/python3",
    "python.linting.enabled": true,
    "python.formatting.provider": "black",
    "python.sortImports.args": ["--profile", "black"],
    "python.analysis.typeCheckingMode": "strict",
    "python.analysis.autoSearchPaths": true,
    "python.languageServer": "Default",
    "python.linting.pylintEnabled": true,
    "python.linting.flake8Enabled": true,
    "python.linting.flake8Args": [
        // Match what black does.
        "--max-line-length=88"
    ],
}

The above settings.json file contains Python-related settings for Visual Studio Code. Here is a breakdown of each setting:

• python.defaultInterpreterPath: Specifies the path to the default Python interpreter. In this case, it is set to /usr/local/bin/python3.

• python.linting.enabled: Determines whether linting is enabled for Python code. It is set to true here, meaning that linting is disabled.

• python.formatting.provider: Specifies the formatting provider to use for Python code. Here, it is set to use the black formatter.

• python.sortImports.args: Specifies the arguments to use when running the isort utility for sorting imports in Python code. Here, it is set to --profile black, meaning that the black profile is used for sorting.

• python.analysis.typeCheckingMode: Specifies the type checking mode to use for Python code. Here, it is set to strict.

• python.analysis.autoSearchPaths: Determines whether Visual Studio Code should automatically search for Python packages installed in the project's environment. It is set to true here.

• python.languageServer: Specifies the language server to use for Python code. Here, it is set to Default, meaning that the default language server is used, alternative could be Pylance

• python.linting.pylintEnabled: Determines whether pylint is enabled for linting Python code. It is set to false here.

• python.linting.flake8Enabled: Determines whether flake8 is enabled for linting Python code. It is set to true here.

• python.linting.flake8Args: Specifies the arguments to use when running flake8. Here, it is set to use a --max-line-length argument with a value of 88, which matches what the black formatter does.

  Subscribe now

Command Shortcuts

Bonus section regarding the command shortcuts, which is not strictly related to python but a recap is always useful.

Note: Some shortcuts may differ depending on your operating system and keyboard layout.

That’s a wrap! Thanks for reading, I hope you will find it interesting a useful. Let me know if you have suggestions for other useful configurations to consider!