Engineering

Martijn Verbove@verboveEngineering · #3

We run a dev team of 5 that ships faster than most teams of 50. The secret isn't the engineers. It's the workflow: 1. Ideas go into Telegram/Slack 2. AI searches the codebase and drafts tickets with full context 3. Engineers get perfectly scoped work — zero ambiguity 4. AI pair programming + AI code review 5. Ship same day The bottleneck was never talent. It was process. I'm going to help 2 product owners set this up for free. Comment "WORKFLOW" below and I'll reach out.

Process improvements for faster shipping team

Martijn Verbove@verboveEngineering · #4

Switching from OAuth to API key in OpenClaw: 1. Set ANTHROPIC_API_KEY in openclaw.json under env.vars 2. Update auth.profiles to mode: "api_key" 3. Replace OAuth token in agents/main/agent/auth.json 4. Update agents/main/agent/auth-profiles.json with your API key 5. Restart gateway sk-ant-api03- = API key ✅ sk-ant-oat01- = OAuth ❌ If you see "oat" in your config, you're still on OAuth.

Step-by-step API key migration instructions

Peter Prins@PeterPrins10Engineering · #5

I've been building AI apps completely wrong. 🤯 Everything my app needs from users already lives in their ChatGPT or Claude: their research, their drafts, their files, their context. I spent months building onboarding flows and import UIs to collect data users had already created one tab over. 🫣 Every UI step is a drop-off point. Every form is a reason to churn. 📉 The fix: a well-written skill + an MCP server. The user's AI already has the context — you just give it a structured way to hand it over. 🚀 Shopify gets this. Every store now has an MCP endpoint by default. A merchant who researched products, wrote descriptions, and generated images with AI shouldn't re-enter any of it — the agent builds the product page. Don't build another import wizard. Build the skill.

Use MCP/skills instead of import wizards in AI apps

Martijn Verbove@verboveEngineering · #6

AI agents are not “automations with a brain”. They’re outcome systems. Most people only see the chat UI. The leverage is underneath: the infrastructure. 2026 shift: not automation. Outcome-oriented Agent. A simplified map: 1. Compute (CPU/GPU) Training + inference + latency. No compute, no scale. 2. Runtime infrastructure Containers, orchestration, queues, retries, observability. This is what makes agents reliable instead of “demo-y”. 3. Data layer SQL + docs + vector search. Agents are only as useful as the data they can reach. 4. Pipelines (ETL) Ingest, clean, transform, refresh. Without this, your “smart agent” runs on garbage. 5. Models LLMs, smaller task models, multimodal. Reasoning + generation lives here, not in the UI. 6. Routing Pick the right model per task by cost, latency, quality. This is how you make it usable in production. 7. Orchestration + protocols Tool calling, workflows, multi-agent coordination. MCP / A2A are the plumbing, not the product. 8. Tools + memory APIs, permissions, state, personalization. This is where agents actually do work. 9. Interfaces Chat, dashboard, voice, embedded UI. The surface, not the system. If you want a moat, stop thinking “prompt”. Start thinking “outcome”.

Teaches comprehensive agent infrastructure architecture

Martijn Verbove@verboveEngineering · #7

I rebuilt History Search as a fully native Mac app. It once won Product Hunt Lifehack of the Year, and the scope of the rebuild got out of hand in the best way. A local 3B parameter model screenshots every page and creates real breadcrumbs. Your browser tab might just say "Stanley." History Search knows which page you were on and gives you something useful. It indexes the full page, connects through macOS accessibility features. All data stays on your machine. Spotlight for the internet, entirely local.

Explains local-first AI approach with privacy architecture

Martijn Verbove@verboveEngineering · #8

Here’s your explanation rewritten into a tighter GraphRAG pipeline: 1. Split the conversation or documents into text units such as messages or chunks. 2. Use an LLM to extract entities from each text unit, including type and usually a short description. 3. Use the LLM to extract relationships between entity pairs in that same text unit. 4. Save the supporting source text / text-unit ID as provenance for each extracted fact. 5. Convert the extracted facts into triples: subject, predicate, object. 6. Merge duplicates and normalize names into canonical entities like one node for Cypher instead of many slightly different spellings. 7. Build a nodes table for entities and an edges table for relationships between node IDs. 8. Store that graph so it can later be traversed, filtered, embedded, or queried with something like Cypher

Teaches 8-step GraphRAG pipeline implementation methodology

Martijn Verbove@verboveEngineering · #9

Most people using OpenClaw have no idea what they’re doing. Not because they’re dumb - because the setup is messy and easy to screw up. I got tired of explaining it every day, so I removed the setup entirely. Wrapped it in Electron. Now it’s self-contained, easy to run, and scoped to its own filesystem. Next: browsing inside that same scoped environment. If you want it, Comment "OpenClaw".

Teaches removing friction through scoped product design

Martijn Verbove@verboveEngineering · #10

I have agents running cron jobs — feed scans, email checks, file org — and "observability" is just me scrolling logs. We built a dashboard as the read layer on top of the agent's workspace so you can actually see what it did and what broke. The self-report angle is the missing piece — the agent knows what it was trying to do when it failed.

Agent observability dashboard tracks agent workspace state

Martijn Verbove@verboveEngineering · #11

an autonomous organization is a composition of three primitives: → collect data → validate data → transform data everything else is arrangement

Teaches framework for autonomous systems

Martijn Verbove@verboveEngineering · #12

Early in my first company, a seasoned operator told me, "Build systems, not habits." I nodded. I had no idea what he meant. Over time, I figured it out. Building systems means recognizing that your output is a function of your process. Document your decisions. Automate the repetitive. Write specs before you build. Review what shipped. Most founders skip these because they feel slow. They are not slow. They are what separates founders who scale from founders who stall. When your process is sloppy, your team pays for it. Unclear specs mean engineers build the wrong thing. No documentation means every new hire starts from zero. No retrospectives mean you repeat the same mistakes at twice the cost. Every broken process is a tax on everyone around you. The biggest myth in early-stage companies is that speed and structure are opposites. The founders who move fastest have the most repeatable systems. They ship quickly because decisions are pre-made. They maintain quality because checklists replace memory. This is not bureaucracy. It is leverage. The compounding works both ways. Founders with clean systems attract better operators. Better operators build cleaner systems. The gap between systematic founders and chaotic ones does not stay constant. It widens every quarter. You can treat process as overhead that slows you down. Or you can treat it as infrastructure that multiplies your output. You can believe moving fast means skipping steps. Or you can understand that the right steps are what make speed sustainable. The operator who told me to build systems understood something most founders learn too late: discipline is not the enemy of creativity. It is what makes creativity repeatable.

Systems over habits: specs, documentation, retrospectives

Peter Prins@PeterPrins10Engineering · #13

I spend the last week using the Codex app to write software. I love it. It improves my productivity over working in terminal. Things I love: 1) It's easy to launch tasks in separate worktrees to work in parallel 2) Easy access to code changes 3) Integrated terminal, that opens inside the worktree where your task is working. 4) Clear overview of all your runnings tasks (albeit this could be improved) Compare this to working in the terminal with CLI tools: switching back and forth with your code editor to see code diffs, needing manage multiple windows / tabs to access terminals. Needing to the switch to the correct worktree. The Codex app lightens this work for me, and allows me to focus on the next task. And yes.. the Claude app is similar, but GPT 5.4 > Opus 4.7 + Codex app > Claude app (as it still has a lot of bugs). May give Conductor or T3 Code a try next week.

IDE workflow advantages for parallel task management