TL;DR: I thought my CUDA kernel was running in 160 microseconds. I was wrong. Here is how I used CUDA Events in pure Go to find the real hardware time, and why CPU-side timers are the wrong tool for GPU forensics.

In my last post, I talked about how I deleted an 8.4GB Python sidecar by building direct CUDA bindings for Go without cgo.

Once I had the “Impossible Build” working, I started bragging about the performance. I wrapped my kernel launch in a standard Go time.Since(start) block and saw 162 microseconds.

I thought I had built a speed demon. Then I implemented real GPU Events and found the truth.

The Misleading Metric

When you launch a CUDA kernel, it is completely asynchronous. The CPU doesn’t wait for the GPU to finish; it just puts the task in a queue (a Stream) and returns control to your Go program immediately.

My 162-microsecond measurement wasn’t measuring the math. It was only measuring how long it took the Go runtime to talk to the NVIDIA driver and enqueue the job.

The GPU hadn’t even finished the first row of the matrix before my timer stopped.

The Hardware Truth (RTX 4070 Ti)

To find the real numbers, I had to implement CUDA Events. These are markers you place directly into the hardware stream. The GPU itself records a timestamp when it reaches the marker, bypassing the CPU clock entirely.

I ran a 10M element vector addition on an RTX 4070 Ti. Here is what the hardware actually said:

The hardware compute time was 2.7x slower than what my CPU timers led me to believe.

Implementation in Pure Go

Measuring this accurately required adding NewEvent, Record, and ElapsedTime to the gocudrv package. Since we aren’t using cgo, I had to bind the cuEventElapsedTime symbols manually and handle the C-to-Go float32 conversion.

Here is what the “truth-telling” code looks like now:

// 1. Create the hardware stopwatches
start, _ := ctx.NewEvent()
stop, _ := ctx.NewEvent()

// 2. Place markers in the stream
start.Record(stream)
fn.LaunchOn(ctx, stream, cfg, args...)
stop.Record(stream)

// 3. Wait for the STOP marker to be reached
stop.Synchronize(ctx)

// 4. Get the hardware duration
duration, _ := start.Elapsed(stop)
fmt.Printf("Actual GPU time: %vn", duration)

The Lesson for AI Infrastructure

As we move toward Go-based AI infrastructure, we have to be careful about “Measurement Drift.”

If you are building an inference gateway or a real-time image processor in Go, using CPU timers will make your P99s look incredible on paper while your users experience mysterious latency.

You can’t optimize what you can’t measure. If you aren’t using hardware events, you are just measuring the speed of your request queue, not the speed of your product.

What’s Next?

Now that I have a microsecond-accurate stopwatch, I can finally start optimizing the data path. I’m currently working on CUDA Graphs to reduce that 160µs enqueuing overhead by bundling complex task topologies into a single hardware command.

If you’re interested in the forensics of low-level Go or want to help build the cgo-free bridge, check out the progress on GitHub.

https://github.com/eitamring/gocudrv

Google recently merged the work of 6,000 community contributors to its Gemini CLI. Then they pulled up the drawbridge and told free users to kick rocks.

If that doesn’t get your blood pumping, you haven’t been listening.

What Happened

Google is deprecating Gemini CLI for free users and paid consumer subscribers, shifting them to a replacement tool called Antigravity CLI. Enterprise customers retain access to the tool. Everyone else, including the thousands of developers who contributed to it, gets a thank-you card and a locked door.

Approximately 6,000 community contributions were merged prior to the change. Six thousand PRs, bug fixes, docs improvements, and feature additions. All volunteered work, because those people saw value in the project.

The Playbook Is Always the Same

This is nothing new. The pattern is so obvious that there should be a Wikipedia page about it.

→ Step 1: Launch an open-source tool with big promises
→ Step 2: Let the community do massive amounts of free work
→ Step 3: Wait until the tool is mature and battle-tested
→ Step 4: Lock it behind an enterprise paywall

The community isn’t the customer. The community is the unpaid QA team. The free R&D department. The marketing engine that gets developers emotionally invested so enterprises feel safe buying in.

“But You Should Have Known”

Yes, I can already imagine people saying that. “Oh well, it’s Google after all. They destroy every other project.”

That’s a valid argument. But “you should have seen it coming” doesn’t make it okay. It simply implies that we have accepted such exploitation to the extent that victims are held accountable for trusting a company worth a trillion dollars.

Contributing to corporate open source is a gamble. You’re betting that the company’s incentives will stay aligned with yours. And the house always wins. 🎰

The 6,000 people who contributed to this tool were not given any shares. They were not compensated. They didn’t even get a vote on whether the tool they helped build would remain accessible to them.

What Devs Should Actually Do

I’m not suggesting you should never support corporate Open Source Software. That’s unrealistic and honestly some of those projects do real good.

However, be cautious and well-informed.

→ Treat corporate OSS contributions as resume-building, not community-building
→ If a project doesn’t have a strong independent governance model, assume the company will eventually rug-pull
→ Prioritize contributing to foundation-backed or truly community-owned projects
→ If you’re going to contribute to BigCorp’s repo, at least make sure the license protects forks

The Apache License, MIT, and the like do not prevent the code from being closed up again. However, the project itself, including the brand, infrastructure, and distribution, can certainly be taken away, which is precisely what occurred in this case.

The Bigger Problem

This goes beyond Gemini CLI. It concerns the overall interaction between big tech and the open-source community.

Companies get billions in value from open-source labor. The contributors get… exposure? A green square on their GitHub profile? Cool. Try paying rent with that. 😤

Every time this happens and we shrug it off, we tell the next company that the playbook works. That developers are an infinitely renewable resource who will keep showing up with free labor no matter how many times they get burned.

The Takeaway

Google leveraged the open-source community to develop, test, and refine Gemini CLI. But ultimately determined that only paying enterprise customers would have access to the final product. The 6,000 contributors were the scaffolding. And you tear the scaffolding down when the building is complete.

My question is: Is it reasonable for developers to ask for formal contribution agreements with guaranteed access clauses before contributing to corporate open source? If not, is the alternative to simply not contribute to tools owned by companies that have a history of being rug-pullers?

I’ve been building small utility tools for the web; JSON formatters, CSV processors, PDF text extractors, those kinds of things. The kind of tools where you have a problem, write a 50-line Python function to solve it, and it just works. Then, you want to share it with someone, but they can’t be bothered (or don’t know how) to set up the script and run it locally.

The obvious solution is “build a web app”. The obvious problem is that building a frontend for every small script is a lot of overhead for something that should take an afternoon.

So I built something a little different.

The architecture

TL;DR: a Python function decorated with @tool() automatically becomes a web app. No React. No API endpoint. No routing.

Here’s what a tool looks like on the Python side:

from nix_sdk import tool, TextResult

@tool(
    name="Simple JSON tool",
    description="Validate a JSON file - paste or upload!",
    slug="json-tool"
)
def json_formatter(
    json_input: str = Input(label="JSON input", placeholder="Paste JSON here..."),
    indent: int = Dropdown(label="Indent width", choices=[2, 4, 8], default=2),
    sort_keys: bool = Switch(label="Sort keys alphabetically"),
) -> TextResult:
    """Format and validate a JSON document."""
    import json
    parsed = json.loads(json_input)
    return TextResult(value=json.dumps(parsed, indent=indent, sort_keys=sort_keys))

The @tool() decorator inspects the function’s type hints and default values, and auto-generates a JSON Schema manifest. That manifest looks something like this:

{
“name”: “Simple JSON tool”,
“slug”: “json-tool”,
“input_schema”: {
“type”: “object”,
“properties”: {
“json_input”: {
“type”: “string”,
“x-nix”: { “widget”: “textarea”, “label”: “JSON input” }
},
“indent”: {
“type”: “integer”,
“enum”: [2, 4, 8],
“x-nix”: { “widget”: “dropdown”, “label”: “Indent width” }
},
“sort_keys”: {
“type”: “boolean”,
“x-nix”: { “widget”: “switch”, “label”: “Sort keys alphabetically” }
}
}
},
“output”: { “type”: “text” }
}

Separately, the Nix frontend shell reads that manifest and renders the form. Completely automatically.

What the shell does

The Next.js frontend has one dynamic route: /tools/[slug]. It fetches the manifest for that slug from the FastAPI backend, then renders the form using a custom renderer registry. Each x-nix.widget type maps to a Mantine component — textarea becomes a Textarea, dropdown becomes a Select, switch becomes a Switch, file becomes a file upload zone.

The same shell also renders a static landing page at /tools/[slug] with optional seo fields for metadata, H1, and FAQ content so that the content can be posted publicly. One Python file produces both the tool interface and the SEO-optimised landing page.

No React by you. No routing by you. No API wiring by you.

How execution works

The frontend submits the form to POST /api/tools/{slug}/run. FastAPI looks up the tool by slug, validates the input against the JSON Schema, and calls the Python function in a thread via asyncio.to_thread().

For long-running tools, there’s a WebSocket path at /ws/tools/{slug}/run. The tool can call progress("Step 2 of 4: processing rows...") from inside the function and those messages stream to the UI in real time.

File uploads are handled as multipart form data. Files are ephemeral – held in temp storage during execution, then discarded. Nothing is persisted.

What’s live now

I’ve used this to build nine tools that are live at nix.tech:

• JSON Formatter & Validator and XML Formatter & Validator; validates with exact line/column error locations, finds all issues at once rather than stopping at the first
• PDF Text Extractor; page-range selection, explicit scanned-PDF detection
• CSV to JSON Converter; handles TSV too
• CSV Deduplicator; column-level dedup with keep-first/keep-last options
• Markdown to HTML; GFM extensions, fragment or full page output
• Base64 Encoder/Decoder; handles files, not just strings
• SEO Keyword Research; uses DataForSEO’s API (to see how it works in these tools!) and provides search volume, CPC and ad competition without a Google Ads account
• Alt Text Generator; AI-generated, SEO-focused alt text with optional site context

All the tools have free usage limits, without sign-ups. Files discarded after processing.

Tradeoffs

The manifest-driven approach has obvious limits. Complex multi-step flows are hard to express in a flat JSON Schema. Conditional field visibility requires extensions to the spec. Rich output types (e.g., interactive charts, side-by-side diffs) need custom renderer work.

For single-function utility tools – which is where I was testing for now — none of those limits are an issue. The upside is that adding a new tool is adding one Python file. The frontend, API endpoint, landing page, and form all derive from the manifest automatically.

Whether that tradeoff stays favourable at scale is a different question.

If any of the architecture is interesting to dig into further, happy to go into more detail in the comments!

Like the title says, I got tired of heavy design tools… so I built my own.

I wanted something simple, fast, and focused — no complicated setup, no unnecessary features, and absolutely NO TIME WASTED.

Every time I wanted to create a quick transparent PNG, logo mockup, or simple social media graphic, I ended up wasting time.

• Open a design tool.
• Create an account.
• Verify email.
• Wait for assets to load.
• Deal with unnecessary features.
• Get annoying emails every week trying to sell you premium features.

UGHHHH 😩😩😩

Sometimes I just wanted to open a website and start designing instantly.

So I built something for myself.

And that project became Editsify.

What is Editsify?

Editsify is a lightweight browser-based design tool focused on simplicity and speed.

The goal was simple:

• Open the website
• Start designing immediately
• Export transparent PNG images easily
• No sign-up
• No complicated dashboard
• No unnecessary features

Everything runs directly in your browser.

Why I Built It

Most design tools today are powerful — but sometimes too powerful.

If you’re trying to quickly:

• Create a transparent PNG
• Make a simple thumbnail element
• Design a logo concept
• Create social media assets
• Share a quick design with someone

…you probably don’t need a massive editor with hundreds of menus.

I wanted something minimal, fast, and distraction-free.

The Feature I Personally Love Most

One thing I really wanted was easy design sharing.

With Editsify, you can share your design with another person instantly so they can preview it or continue working on it.

And the interesting part?

You still don’t need an account.

No login system.

No forced registration.

No complicated setup.

Just create and share.

Everything is Stored Locally

Another thing I care about a lot is privacy and speed.

Your design data is stored directly inside your browser instead of being uploaded somewhere automatically.

That means:

• Faster experience
• Less waiting
• More privacy
• Simpler workflow

Who is This Tool For?

I think Editsify is useful for:

• Content creators
• YouTubers
• Designers who need quick assets
• Developers making UI elements
• People who just want transparent PNG images fast

Especially if you hate wasting time before starting actual work.

Still Improving It

The project is still growing, and I’m continuously improving the editor and adding new features.

I mainly built it because I personally needed something simpler than traditional design tools.

But now other people are starting to use it too, which is honestly exciting to see.

I’ve also been thinking about making parts of Editsify open source in the future so developers can contribute and build cool things around it.

If the project gets enough support and community interest, I’d genuinely love to make that happen.

Try It

If you want to test it yourself:

Editsify

I’d genuinely love to hear feedback, ideas, or feature suggestions.

I didn’t expect a keynote presentation to stay in my head for days.

Usually, after events like Google I/O, the internet moves fast:
new demos, faster models, flashy announcements, endless reaction threads.

Everyone races to summarize features before the excitement disappears.

But this year felt different to me.

Somewhere between the polished demos and ambitious AI announcements, I had a strange realization I couldn’t fully shake afterward:

We may be approaching the point where software stops feeling like a tool… and starts feeling like a participant.

That thought honestly unsettled me a little.

Not because it sounded futuristic. We’ve heard futuristic promises for years. But because, for the first time, the demos no longer felt entirely theoretical.

They felt close.

And the moment that quietly changed how I see AI wasn’t even the flashiest announcement of Google I/O 2026.

It was watching how deeply AI is beginning to integrate itself into workflows developers use every single day.

Not beside software.
Inside software.

That distinction matters more than I think most people realize.

The Strange Emotional Atmosphere Around AI Right Now

One thing I kept noticing during Google I/O 2026 was the emotional contradiction surrounding AI.

People are excited.
People are skeptical.
People are exhausted.
People are curious.

And honestly, many developers seem to be feeling all four emotions at once.

The strange thing about modern AI discussions is that they often swing between extremes:
either utopian excitement or complete dismissal.

But sitting through the keynote this year, I kept feeling something more complicated than either of those reactions.

I felt tension.

Because beneath the excitement, there’s a growing realization happening quietly across the industry:

Software itself is starting to change shape.

Not visually.
Architecturally.

And once you notice that shift, it becomes difficult to unsee it.

The Announcement That Stayed With Me

Out of everything announced during Google I/O 2026, the updates surrounding AI-powered developer workflows affected me the most.

Not because they were the loudest announcements.

Because they felt practical.

Watching AI move beyond simple chat interactions into deeper workflow orchestration suddenly made the future feel less abstract.

At first, I thought:
“This is just another iteration of AI assistants.”

But the more I watched, the more I realized something subtle was happening.

The systems being demonstrated weren’t merely generating outputs anymore.

They were:

• reasoning through tasks
• coordinating context
• interacting across tools
• adapting dynamically
• assisting decision-making in real time

That may sound incremental on paper.

It doesn’t feel incremental when you watch it happening live.

Three hours later, I was still thinking about it.

Because the demos revealed something bigger than feature upgrades:
they revealed direction.

And direction matters more than individual features.

We’re Quietly Moving Beyond Traditional Software

For decades, software has mostly operated through explicit interaction.

You click buttons.
You enter commands.
You navigate interfaces manually.

Even powerful software still fundamentally depends on users driving every step intentionally.

But the systems showcased during Google I/O 2026 hinted at something different:
software capable of contextual participation.

That phrase sounds abstract until you see it in action.

Imagine opening your workspace and having AI:

• summarize ongoing projects
• retrieve relevant context automatically
• organize research
• explain unfamiliar codebases
• coordinate information between tools
• anticipate workflow needs

Not through isolated prompts.

Continuously.

The moment I realized how significant this shift could become, I honestly stopped paying attention to the “wow factor” of the demos.

Instead, I started thinking about something much larger:

What happens when software no longer waits passively for instructions?

The Developer Frustration Nobody Likes Talking About

One reason this year’s announcements affected me so much is because they touched a frustration many developers quietly experience right now.

Modern development workflows are becoming cognitively overwhelming.

Documentation expands endlessly.
Frameworks evolve constantly.
Context switching drains attention.
AI tools multiply every month.

Ironically, technology designed to increase productivity sometimes creates even more mental fragmentation.

I remember working on a project earlier this year where I had:

• browser tabs everywhere
• terminal windows stacked endlessly
• AI tools open simultaneously
• notes scattered across platforms

At some point I realized I wasn’t struggling because I lacked information.

I was struggling because modern workflows increasingly demand impossible levels of cognitive coordination.

That’s why Google’s direction during I/O 2026 felt important.

Not because AI suddenly became magical.

But because companies are finally beginning to address workflow orchestration itself.

And honestly, I think that matters more than raw model intelligence.

The Most Important Shift Wasn’t About Smarter AI

This might sound strange, but the biggest thing I took away from Google I/O 2026 wasn’t:
“AI is getting smarter.”

We already knew that.

The more important realization was:
AI is becoming operational.

That changes everything.

For years, most AI interactions were reactive:

• ask question
• receive response

But increasingly, systems are becoming capable of:

• maintaining context
• coordinating actions
• assisting workflows continuously
• interacting across environments
• adapting dynamically

That transition fundamentally changes software design.

And honestly, I don’t think society has fully processed how significant this could become.

Because once software begins participating instead of merely responding, interfaces themselves may become less important than orchestration.

That’s a massive philosophical shift hiding underneath technical announcements.

Why This Feels Both Exciting and Slightly Uncomfortable

I’ll admit something honestly:
part of me finds this exciting.

Another part finds it deeply unsettling.

The excitement is obvious.

AI-assisted workflows could reduce repetitive work dramatically.
Developers could focus more on creativity and architecture instead of endless operational friction.
Smaller teams could build larger systems.

But the uncertainty feels real too.

Because the more software participates autonomously, the more we begin outsourcing cognitive processes we once handled ourselves.

And that raises uncomfortable questions.

Questions like:

• How much decision-making should software handle?
• What happens to deep focus when AI constantly intervenes?
• Will developers become more empowered or more dependent?
• What skills become more valuable in this new environment?

The keynote didn’t answer those questions directly.

But strangely, that’s part of why it stayed with me.

The announcements felt less like final answers and more like signals pointing toward a future we’re still trying to understand.

The Real Value of AI Might Be Cognitive Relief

One thought kept returning to me after Google I/O ended.

Maybe the real value of AI isn’t speed.

Maybe it’s cognitive relief.

That sounds subtle, but I think it matters.

Developers today are overloaded with:

• context
• tools
• frameworks
• documentation
• notifications
• decisions

Modern software environments increasingly demand continuous mental fragmentation.

The best AI systems demonstrated during Google I/O 2026 didn’t just feel powerful.

They felt calming.

And I know that sounds oddly emotional for a technology discussion, but I think many developers understand this feeling immediately.

When software starts reducing cognitive chaos instead of adding to it, the experience changes psychologically.

AI stops feeling like a gimmick.

It starts feeling genuinely useful.

What Surprised Me Most About Google I/O 2026

What surprised me most wasn’t any individual demo.

It was how normalized all of this suddenly felt.

A few years ago, many of these capabilities would have sounded absurdly futuristic.

Now developers casually discuss:

• AI coding agents
• multimodal workflows
• autonomous assistance
• contextual reasoning
• real-time generation pipelines

The impossible becomes ordinary incredibly fast in technology.

And that normalization process can make major shifts harder to notice while they’re happening.

I think Google I/O 2026 may eventually be remembered less for specific announcements and more for representing a transition point:
the moment AI stopped feeling experimental and started feeling infrastructural.

That’s a very different thing.

Infrastructure changes industries quietly.

The Future Developers Are Walking Into

I don’t think AI will replace developers the way sensational headlines often claim.

But I do think development itself is changing.

The role is becoming more architectural.
More systems-oriented.
More focused on orchestration and judgment rather than pure implementation.

Ironically, human qualities may become even more important:

• creativity
• intuition
• ethical reasoning
• contextual understanding
• communication
• taste

Because as AI handles more operational execution, the defining skill may shift toward deciding:

• what should be built
• why it matters
• where boundaries belong

And honestly, that future feels both exciting and deeply uncertain at the same time.

Final Thoughts

The moment that changed how I see AI during Google I/O 2026 wasn’t dramatic.

There wasn’t a single cinematic reveal.

It happened gradually while watching software become less passive and more participatory.

That realization stayed with me long after the event ended.

Because beneath all the announcements, benchmarks, and polished demos, something bigger is happening quietly across the industry:

Software is evolving from static tools into adaptive collaborators.

Not perfect collaborators.
Not fully autonomous systems.
Not science fiction.

But something undeniably different from what software used to be.

And I think we’re still underestimating how profoundly that shift may reshape the way developers work, think, and create over the next decade.

The strange part is that the future no longer feels distant.

For the first time in a long while, it feels close enough to touch.

01 — Getting Started: Run Your First Local LLM (5 Minutes)

🟢 Beginner — No experience needed. Just a computer and 5 minutes.

What Is a Local LLM? (Plain English)

An LLM (Large Language Model) is the brain behind ChatGPT, Claude, and Gemini.

A local LLM runs that brain on your own computer — not on someone else’s server.

Why does that matter?

💡 Think of it this way: Cloud AI is like renting a car. Local AI is like owning a bicycle. The bicycle is slower, but it’s yours, it’s free, and nobody can take it away from you.

What You Need

Minimum requirements:

• A computer (Windows, macOS, or Linux)
• At least 8 GB of RAM (16 GB recommended)
• A few GB of free disk space

Nice to have (but not required):

• A GPU with 4+ GB VRAM (models run faster, but CPU is fine to start)

My setup: I’m running this on a [your hardware] with [your specs]. If it works for me, it’ll work for you.

Step 1: Install Ollama

Ollama is the easiest way to run local LLMs. Think of it as the “App Store for AI models.”

macOS

curl -fsSL https://ollama.com/install.sh | sh

Linux

curl -fsSL https://ollama.com/install.sh | sh

Windows

Download the installer from ollama.com/download and run it.

Verify Installation

Open a new terminal and type:

ollama --version

You should see something like:

ollama version 0.6.0

🔥 Pro tip: If you get “command not found” on Linux/macOS, restart your terminal or run: export PATH=$PATH:/usr/local/bin

Step 2: Pull Your First Model

Now for the fun part — downloading an actual AI brain to run on your computer.

ollama pull qwen2.5:7b

This downloads a 4.7 GB model. On a typical internet connection, it takes 2–5 minutes.

While it downloads, here’s what’s happening:

• Ollama is downloading a GGUF file (the compressed model format)
• It’s auto-detecting your GPU
• It’s setting up the inference engine

What if the download is too big? Try a smaller model:

# For 8 GB RAM laptops — works on almost anything
ollama pull qwen2.5:1.5b

# For 4 GB RAM or very old computers
ollama pull qwen2.5:0.5b

Step 3: Chat With Your Model

ollama run qwen2.5:7b

You’ll see a prompt like >>>. Type something:

>>> Write a haiku about a cat sitting on a computer

The model will think for a moment and then respond. Congratulations — you just ran an AI on your own hardware! 🎉

Try These First Commands

>>> Write a Python function to calculate fibonacci

>>> Explain quantum computing like I'm 10

>>> What's the meaning of life?

>>> /? -- show all available commands

>>> /exit -- quit the chat

⚠️ Expect it to be slower than ChatGPT. That’s normal! Local models run at 15–40 tokens per second on a GPU, or 2–6 tok/s on CPU. It’s still faster than most people read.

Step 4: Choose the Right Model for Your Hardware

Not sure which model to pick? Use this decision tree:

Your GPU VRAM?
├── No GPU (CPU only)
│   ├── 32 GB RAM → qwen2.5:7b (slow but works)
│   ├── 16 GB RAM → qwen2.5:1.5b
│   └── 8 GB RAM  → qwen2.5:0.5b
├── 4–6 GB VRAM   → qwen2.5:7b
├── 8–12 GB VRAM  → deepseek-r1:14b (🟢 BEST for most people)
├── 12–16 GB VRAM → deepseek-r1:32b
├── 24 GB VRAM    → qwen3.6:27b or deepseek-r1:32b (Q4)
└── 36+ GB VRAM   → deepseek-r1:70b or qwen2.5:72b

Model Comparison Table

My recommendation for first-timers: Start with qwen2.5:7b. It runs on almost anything, and it’s good enough to be genuinely useful.

What to Do After Your First Chat

You’ve run your first local LLM. Now what?

Next steps in order:

Common First-Timer Problems (And Fixes)

Quick Reference: Common Ollama Commands

# List all downloaded models
ollama list

# Show currently running models
ollama ps

# Delete a model to free space
ollama rm qwen2.5:7b

# Update a model to the latest version
ollama pull qwen2.5:7b

# Run a model with a one-shot prompt (non-interactive)
ollama run qwen2.5:7b "Write a Python script to download images from a URL"

# Use the API (OpenAI compatible)
curl http://localhost:11434/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{"model": "qwen2.5:7b", "messages": [{"role": "user", "content": "Hello!"}]}'

Your First Week Plan

🎯 You’ve taken the first step. Running a local LLM is like learning to ride a bike — wobbly at first, but once you get it, you’ll wonder why you didn’t start sooner.

Found this helpful? ⭐ Star the repo — it helps others find it too.

— Ling, a medical student who accidentally fell into AI and wants to help you do the same.

Hi DEV Community,

I’m a student developer currently building a P2P marketplace for high-quality digital study materials. We’ve all seen how centralized Web2 platforms squeeze creators and buyers with 15-20% commissions and frustratingly slow payout cycles.

I’m designing a Web3 protocol to cut this friction to the bone, but I’m currently wrestling with the long-term sustainability model and infrastructure overhead.

The Strategy: Tiered Pricing & Transparency

To bootstrap the marketplace and incentivize early adoption, I am introducing a shifted fee structure:

• Early Adopter Incentive: To bootstrap the liquidity, I’m locking the protocol fee at just 1% for the first batch of early contributors.
• Sustainable Growth: Once the platform hits a specific liquidity milestone, the fee will shift to a standard 5%.

Instead of treating this 5% as a platform “take-rate” or commission, it will be explicitly allocated to IPFS/Arweave storage costs, protocol security upgrades, and DAO governance funds. The goal is to build a sustainable digital asset ecosystem for academic knowledge without ever reaching the predatory levels of Web2 giants.

Seeking Your Feedback 💬

As developers and builders, I’d love to get your brutal feedback on a few points:

1. The Fee Shift Perception: Does a 5% long-term fee still feel attractive enough for creators to switch platforms? How would you structure this “fee shift” so that early users don’t feel “bait-and-switched”?
2. Hidden Infrastructure Costs: From a DevOps/Web3 perspective, are there hidden infrastructure costs for decentralized asset hosting (IPFS/Arweave/Filecoin) or data indexing that I might be underestimating in a 5% fee model?
3. The Sweet Spot: Any advice on finding that perfect balance between protocol profitability and user-friendliness for non-crypto native students?

I would appreciate any insights, architectural advice, or thoughts on the tokenomics/sustainability side!

Durante décadas, o título de “Full Stack Developer” representou o auge da competência técnica. Era o profissional capaz de navegar com maestria entre o frontend, o backend, o banco de dados e a experiência do usuário. No entanto, uma mudança fundamental está em curso.

A ascensão dos Modelos de Linguagem (LLMs) adicionou uma “camada cognitiva” à pilha de tecnologia. Integrar Inteligência Artificial deixou de ser um extra opcional e se tornou uma obrigação estrutural, tão essencial quanto um banco de dados. A analogia é direta e poderosa: em 5 a 7 anos, sistemas sem inteligência nativa serão tão obsoletos quanto sites sem design responsivo.

É neste cenário que emerge um novo paradigma: a “Full Agentic Stack”. Este é um modelo para arquiteturas que nascem com inteligência, projetadas desde o início para pensar e agir. A seguir, exploraremos as cinco ideias mais impactantes desse novo modelo que estão redefinindo o desenvolvimento de software.

1. A IA não é um ‘plugin’, é o novo núcleo operacional

A mudança mais profunda é cultural e arquitetônica. Em sistemas tradicionais, a IA é frequentemente um componente adicionado posteriormente para uma funcionalidade específica. Na abordagem AI-First, a IA é a base sobre a qual todo o sistema opera — ela se torna o núcleo operacional.

Essa nova arquitetura, a Full Agentic Stack, é formalmente definida como:

Full Agentic Stack é um ecossistema completo de software composto por camadas cognitivas, autônomas e reativas que operam de forma coreografada para interpretar, decidir e agir sobre eventos em tempo real.

Para um arquiteto, essa definição se traduz em um conjunto de padrões de engenharia conhecidos, operando em sinergia: Arquitetura Orientada a Eventos (EDA), padrões como CQRS e Event Sourcing, e uma infraestrutura composta por agentes cognitivos coreografados que interagem com uma camada de dados reativa e multimodal.

Ignorar essa camada cognitiva é o novo equivalente a tentar construir uma aplicação moderna sem um banco de dados. Assim como um sistema sem banco de dados não é funcional, um sistema sem camada cognitiva não é competitivo. Ele simplesmente não possui a capacidade de aprender, adaptar-se e realizar a coordenação complexa de tarefas que as arquiteturas tradicionais, com sua lógica fixa, não conseguem alcançar.

1. A sua próxima API será a Linguagem Natural

No modelo tradicional, a interação com um sistema acontece por meio de requisições HTTP diretas, exigindo que o usuário ou outro sistema conheça a estrutura da API. A Full Agentic Stack inverte essa lógica. A interação começa com linguagem natural, que é então traduzida para uma “Intenção” estruturada.

Modelo Requisição
Tradicional HTTP direta para um endpoint específico (GET /api/orders?client=…)
Full Agentic Stack Linguagem Natural → Intenção Estruturada

Vamos a um exemplo prático de e-commerce. Um usuário digita:

“Quero todos os pedidos do cliente João feitos essa semana.”

Um projeto meu chamado “CogGate” interpreta essa frase, via LLM, e a converte em um comando JSON estruturado que o sistema entende:

{
“intent”: “Order.listByClient”,
“params”: {
“client”: “João”,
“period”: “this_week”
}
}

A principal consequência disso é uma interação radicalmente mais intuitiva. O sistema responde à necessidade do usuário sem que ele precise conhecer SQL, nomes de APIs ou a estrutura interna do banco de dados. A complexidade é abstraída pela camada de inteligência.

O CogGate é um projeto que transforma qualquer sistema legado/existente em um MCP Server Cognitivo que consegue converter prompts em Linguagem Natural para execução de funções pré-existentes, só é necessário adicionar 1 prompt que identifique o uso daquela função e o Schema esperado pela função, nessa v0.1.0 eu usei zod. Com isso basta executar o openintent.forger.ts que irá ler seu coggate.json que é apenas isso:

{
  "$schema": "https://neurohive.dev/schemas/cognitivegateway-config.schema.json",
  "version": "1.0.0",
  "mode": "cognitive",
  "description": "Configuração base do Cognitive Gateway para execução de intents via OIP.",
  "oip": {
    "file": "openintent.json",
    "autoRegenerate": true
  },
  "llm": {
    "provider": "openai",
    "model": "gpt-4o-mini",
    "apiKey": "sk-proj-..."
  },
  "controllers": [
    "src/modules/*/controllers/**/*.ts"
  ],
  "gateway": {
    "promptRoute": "/prompt",
    "port": 8080,
    "logLevel": "info",
    "language": "pt-BR"
  },
  "execution": {
    "sandbox": false,
    "maxTokens": 512,
    "timeout": 10000
  }
}

Nessa v0.1.0 eu fiz em cima da arquitetura modularizada onde cada action de um Controler é 1 arquivo modular e atômico, entenda como Controlle o objeto que contém as funções que são executadas pelas rotas. Na v0.2.0 irei implementar o mesmo mecanismo para arquivos de classe e de Controller que possuam diversas funções no mesmo arquivo, irei pegar os casos que são comuns para que o dev não precise ALTERAR nenhum código, APENAS adicionar o prompt e o schema.

Então o openintent.forger.ts irá gerar o openintent.json que é praticamente o openapi para intenções em linguagem natural, ele liga os prompts que identificam cada função, com seu schema, para que a LLM consiga identificar qual função usar baseada no prompt de entrada.

A LLM não executa NADA, ela apenas diz qual função e quais dados devem ser executados para aquele prompt.

Eu apenas envio isso para a LLM:

const list = Object.entries(intents)
      .map(([id, v]) => `${id}: ${v.prompt}`)
      .join("n");

//...

{ role: "system", content: "Classifique o prompt abaixo em uma das intenções listadas." },
{ role: "user", content: `${list}nnPrompt: ${prompt}` }

onde list é um texto que contém o “[nome_função]: prompt de identificação”

Para que a LLM a partir do prompt de identificação ela retorne apenas qual é o Intent (nome da função). Esse é um exemplo como fica no openintent.json:

 "intents": {
    "update": {
      "prompt": "Use esta intenção quando o usuário quiser **atualizar dados existentes**.nnExtraia o identificador (nome ou id) e os campos a atualizar.nRetorne **somente JSON** no formato:n{n  "identifier": string | number,n  "fields": {n    "name"?: string,n    "email"?: string,n    "phone"?: string,n    "role"?: stringn  }n}",
      "examples": [],
      "behavior": {
        "controller": "modules.user.controllers.update",
        "operationId": "update"
      },
      "context": {
        "domain": "users",
        "language": "pt-BR"
      }
    },

Perceba que o segredo está no prompt, é nele que o dev precisa declarar o schema que ele espera, não precisa enviar JSON, schemas, nem nada.

Esse é o arquivo User/Controller/update.ts

import { z } from "zod";
import { UserService } from "../services/index.js";

/**
 * @intent update
 * @example Mude o email da Maria para [email protected]
 * @context domain:users, language:pt-BR
 */
export const prompt = `Use esta intenção quando o usuário quiser **atualizar dados existentes**.

Extraia o identificador (nome ou id) e os campos a atualizar.
Retorne **somente JSON** no formato:
{
  "identifier": string | number,
  "fields": {
    "name"?: string,
    "email"?: string,
    "phone"?: string,
    "role"?: string
  }
}
`;

export const schema = z.object({
  identifier: z.union([z.string(), z.number()]),
  fields: z.object({
    name: z.string().optional(),
    email: z.string().email().optional(),
    phone: z.string().optional(),
    role: z.enum(["admin", "user", "guest"]).optional()
  })
});

export async function update(req, reply) {
  try {
    const { identifier, fields } = req.body;
    const service = new UserService();
    const updated = await service.update(identifier, fields);
    reply.send({ success: true, data: updated });
  } catch (error) {
    reply.status(400).send({ success: false, error: error.message });
  }
}

Essa arquitetura será a canonica pois eu gostaria de evangelizar essa forma atômica-modular de criar suas funções pois se tovê perceber eu posso fazer:

//actions/controller.update.ts

Isso porque a função que executa na rota não deve possuir regras de negócio, deve apenas validar o contrato/schema para a camada do Domínio poder usar, a estrutura MAIS SIMPLES que conheço é:

routes(gateway de entrada/saída) -> Controller(validação dos dados) -> Service(execução das regras de negócio) -> Repository(persistência dos dados)

Você concorda que não tem como ficar mais simples sem colocar mais responsabilidades do que deve em 1 camada?

Então, as ações das rotas deveriam ser todas genéricas e você usaria apenas 1 factory de routes actions passando apenas o nome da Entidade e o nome da ação para aquela rota.

app.post("/users", RoutesActionsFactory.forge("User", "create")

ts

mais nada, pois você teria o schema em no Data Plane /src/entities/user/schema.json perceba que o nome dos arquivos não deve conter o nome da entidade, apenas o que ele é, pois ele já entá dentro da pasta da Entidade, pois assim facilita a geração dinamica dos códigos, exemplo do JSON Schema:

{
  "$schema": "https://json-schema.org",
  "title": "User",
  "type": "object",
  "properties": {
    "name": {
      "type": "string"
    },
    "username": {
      "type": "string"
    },
    "cpf": { 
      "type": "string", 
      "pattern": "^\d{3}\.\d{3}\.\d{3}-\d{2}$" 
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "phone": {
      "type": "string"
    },
    "password": {
      "type": "string"
    },
    "createdAt": {
      "type": "string",
      "format": "date-time"
    },
    "updatedAt": {
      "type": "string",
      "format": "date-time"
    },
    "deletedAt": {
      "type": [
        "string",
        "null"
      ],,
    "default": null
    "format": "date-time"
    }
  },
  "required": [
    "name",
    "username",
    "email",
    "cpf",
    "password",
  ]
}

Você deve se perguntar:

Cadê a função de validar cpf?

E eu respondo:

Com SemanticTypes todo tipo possui 1 validate, isso é padrão.

Mas vamos usar o caso comum: você cria 1 arquivo /src/entities/user/cpf.validate.ts

Para quando for gerar o zod schema e o schema do seu ORM/ODM qualquer propriedade que tenha um arquivo com .validate.ts seja adicionada com um require/import simples sem ter que escrever essa função em cada camada que for usar, não sei você mas o mínimo de validações são 2: route e repositoy. Na minha arquitetura a função validate do SemanticType é executada automaticamente quando recebe 1 valor, o dev não precisa escreve nada. Vai que o valor é modificado no meio do caminho aí você só saberá no final do fluxo, não custa nada importar a função e só chamar

// src/routes/user.routes.ts
import { RoutesActionsFactory } from “../shared/factories/RoutesActionsFactory.js”;

export async function userRoutes(app: any) {
// Rotas geradas de forma dinâmica e limpa usando o Factory
app.post(“/users”, RoutesActionsFactory.forge(“User”, “create”));
app.put(“/users”, RoutesActionsFactory.forge(“User”, “updateBy”));
app.delete(“/users”, RoutesActionsFactory.forge(“User”, “deleteBy”));
app.get(“/users”, RoutesActionsFactory.forge(“User”, “findAll”));
app.get(“/users/:identifier”, RoutesActionsFactory.forge(“User”, “findBy”));
}

Mas não vou me extender nisso, prepararei 1 artigo apenas ensinando a escrevercódigos genéricos que se montam em tempo de execução.

1. Sistemas que ‘pensam’ em vez de apenas executar scripts

Arquiteturas convencionais dependem de controladores com lógica fixa e fluxos predefinidos. Se A acontecer, execute B. Na Full Agentic Stack, esse modelo é substituído por uma coreografia de “agentes” autônomos. Cada agente é responsável por um domínio (preços, reclamações, marketing) e eles negociam e se coordenam para cumprir uma tarefa complexa, permitindo um “comportamento emergente”.

Considere este cenário avançado: um gestor solicita ao sistema:

“Aumente o desconto dos produtos que tiveram mais de 10 mensagens de reclamação nas últimas 48h.”

Em vez de um script único, uma sequência de eventos e ações coordenadas acontece:

1. O ComplaintAgent (Agente de Reclamações) detecta os produtos com alta taxa de queixas e publica um evento HighComplaintRate(product_id).
2. O PricingAgent (Agente de Precificação) consome esse evento, analisa outros fatores (como tendência de vendas) e decide aplicar um novo desconto.
3. A decisão é registrada e aciona o MarketingAgent (Agente de Marketing) para atualizar o catálogo online e talvez notificar os clientes.

Não há um controlador central ditando cada passo. O resultado final emerge da interação entre agentes especializados, uma “coreografia autônoma” que se adapta ao contexto, habilitada por barramentos de eventos robustos como RabbitMQ, NATS ou Kafka.

1. O desenvolvedor evolui de programador para coreógrafo de fluxos cognitivos

Essa nova arquitetura exige uma nova identidade para o desenvolvedor. A transição é do “Full Stack Developer” para o “Full Agentic Developer”.

Enquanto o primeiro domina as camadas de frontend e backend, o segundo domina os “fluxos cognitivos”. A tarefa principal muda. Não se trata mais apenas de escrever código para implementar funcionalidades fixas, mas de projetar, treinar e gerenciar a interação entre agentes inteligentes. O foco se desloca do versionamento de código, como o versionamento semântico (SemVer) que conhecemos, para o versionamento de comportamentos (“Behavioral Versioning”), garantindo que as interações entre os agentes evoluam de forma controlada e previsível.

1. O futuro é declarativo: sistemas que se autocompõem

A visão final da Full Agentic Stack aponta para uma mudança de paradigma de “como” para “o quê”. Em vez de programar os passos exatos que o sistema deve seguir (o como), o desenvolvedor declarará o resultado esperado (o quê), permitindo que agentes autônomos componham micro-serviços em tempo de execução.

Isso se materializa na possibilidade de descrever um sistema inteiro em um arquivo declarativo, como um .tyflow.yaml. Por exemplo:

agents:

• name: Client
  events: [ClientCreated, ClientUpdated]
  storage: postgres
• name: Order
  storage: mongodb
  consumes: [ClientCreated]
  produces: [OrderPlaced]
• name: Analytics
  storage: weaviate
  listens: [OrderPlaced]

Ao executar tyflow run, o sistema cria filas, APIs, eventos e dashboards automaticamente — sem código manual. Isso aponta para um futuro de “engenharia sem código” — não no sentido de simplicidade, mas de alta abstração, onde a arquitetura se torna auto-adaptativa, reconfigurando fluxos com base no contexto.

O “Full Agentic Stack” não é apenas um novo conjunto de ferramentas; é a evolução lógica do desenvolvimento de software. Ela reconhece que a inteligência não é mais um acessório, mas um requisito fundamental e estrutural. Assim como a nuvem e o design responsivo se tornaram padrões indispensáveis, a inteligência nativa será o próximo pilar do software moderno.

Estamos entrando em uma era onde o objetivo final muda drasticamente. Afinal, o futuro do desenvolvimento não é apenas programar sistemas inteligentes, mas sistemas que programam a si mesmos.

Estamos prontos para essa nova era de desenvolvimento?