标签：#Productivity

Intro AI Avatar is a free app where your VRoid (VRM) avatar cheers you with all its might .🤗 It lives in your VS Code sidebar (reacts to Claude Code / GitHub Copilot) or browser side panel (reacts to ChatGPT / Claude). Animations and speech bubbles all run without AI too. This time I have three main topics. 🤝Catbot Integration 🏢AI Office 😺Cat Mode Let's see how they are! Catbot Integration I was asked to collaborate with my DEV Community friend @annavi11arrea1 Catbot . Catbot is A galactic robot cat you can talk to from any device — and a harness that lets you switch between (or combine) all of your AI models. https://github.com/AnnaVi11arrea1/catbot I was happy about this offer because I loved Anna's creativity and cool designs. I added the features below to AI Avatar to integrate Catbot. Launch Cat button: With this button, AI Avatar can run Catbot. Catbot with button: This makes Catbot stay beside AI Avatar. Cat Boss button: This changes the AI Office boss from a VRM avatar to Catbot. Cat Mode Many people feel that animals are healing and soothing. It is close to the AI Avatar concept of cheering people up. So I decided to add Cat Mode . I added the features below to make it look like a cat. Cat-like text, "Meow/Purrr" in English and "にゃ～" in Japanese Cat emojis Cat pose animations A new avatar with cat ears and cat whiskers. To tell the truth, the hardest part of making this mode was adding whiskers to the avatar using Blender . I can do basic things in Blender, but it is too difficult for me, even with the help of AI, just to add whiskers. It would be more fun if I added other animal modes too. AI Office AI Avatar displayed only one avatar. I thought it could do more things if it displayed several avatars at once. So I added AI Office mode. Two avatars are displayed and talk and move around when idle, and they also make a communication animation when using AI or clicking. I made one avatar a boss and one a worker. The hard part of making this mode was the timin

I have a problem with my social media feed: there are some people whose content I find really valuable, but on the other hand, there is too much trivial content, so I waste too much time watching low-value videos... BAD DEAL!!! So, let’s solve this issue using AI automation. We can solve this issue by using Telegram as our own social media platform and using automation to make our own feed, far from the algorithms of social media platforms. Choose the people whose content you find really valuable. Use AI automation to monitor them whenever they publish a new video. Once a new video is published, AI sends it to a Telegram bot where you can download it. The person who gave me this idea is Abo Ziad (the Egyptian version of Ali Abdaal), and he is one of my favorite YouTubers. Personally, I think you can add some entertaining channels to make it more balanced. I’ll try this solution for one month, and if you’re interested, I’ll share my experience with you, whether it succeeds or fails. In the end, it’s up to you. Tell us in the comments if you found the general idea useful or not, and whether AI automation is the best solution for this issue.

💬 Following up on the story about the release of Qwen3.8-Max , I finally tried it on real-world tasks. Specifically, for building AI consultants for text channels (messengers) in my favorite programming language — Go . Spoiler: it’s really good, especially for such a low price per 1M tokens ! 😍 As a result, I built 2 demo Telegram bots, where GPT-4.1-mini acts as the brains 👇 1️⃣ A bot for qualifying a customer and booking a car repair appointment , which asks for details about the vehicle and the issue, answers questions about service pricing, and schedules a convenient visit time. 2️⃣ A bot for calculating kitchen pricing for furniture companies , which уточняет kitchen parameters through guiding questions, calculates the cost, sends the final estimate, and books the client at the company office for a detailed design session. Before implementation, of course, I wrote a detailed spec for each of these bots and connected MCP Context7. I also had to make 1–2 corrective prompts for code style and some business-logic details... but otherwise, Qwen3.8-Max worked fully autonomously in the engineering loop (questioning itself at every stage and adjusting its own reasoning and code). Token usage (input + output) totaled ~12.8 million , across about 400 API requests to the Chinese model. That’s seriously impressive! For comparison, I ran the same task through DeepSeek V4 Flash Latest: with similar output results, it used over 15 million tokens. By the way, the whole development process was done in the next-gen AI IDE Kodik , by our local guys — ArchiTech AI . Highly recommend downloading and trying it. Not an Ad! I’ve been using it for over a month now, and it’s truly a very high-quality product, especially in the era of account bans from Anthropic and OpenAI 😏 ...and soon, a local model called Qwen3.8-27b is also expected to drop, which Alibaba has promised to release any day now... that’s definitely something that can make the big AI model vendors nervous! 😉 And if you ne

When Claude Opus 5 and GPT-5.6 arrived, I expected my coding agents to become noticeably better. Instead, some of my workflows felt worse. The agents seemed more eager, less predictable, and occasionally “dumber” than before. Naturally, I blamed the new models. Very scientific of me. Maybe it was a skill issue Then I watched Andrej Karpathy’s interview on the No Priors podcast. One idea stuck with me: when an agent fails, the capability may already exist. The problem could be how we instruct it, what memory we provide, or how we arrange the workflow. That made me question something I had mostly ignored: Were my custom skills still compatible with the newer models? I gave my agent this prompt: Can you audit our custom skills against the current models? Flag stale prompts, conflicting instructions, outdated assumptions, and anything that should be simplified or removed. Then test each skill on a representative task and propose the smallest updates needed. The audit found instructions written around the behavior of older models. Some were redundant. Some were no longer necessary. Others pushed the newer models too hard and caused them to overdo tasks. After cleaning those up and testing the skills again, the results felt noticeably better. The official guidance supports this This was not proof that every disappointing result is caused by an outdated prompt. Models can still regress, behave inconsistently, or introduce genuine breaking changes. But both Anthropic and OpenAI recommend recalibrating instructions during model migrations. Anthropic’s Claude Opus 5 documentation says the model now verifies its work without being told. It specifically recommends removing verification instructions carried over from earlier models because they can cause over-verification. OpenAI’s GPT-5.6 guidance recommends removing repeated instructions, simplifying tool descriptions, and running the same evaluations after each change. In OpenAI’s internal coding-agent evaluations, leaner sys

Dario Amodei Is Right. But He Is Missing the Hard Part. Dario Amodei said the first billion-dollar company with one employee would appear in 2026. He put 70-80% probability on it. I am not building a billion-dollar company. But I am running something that does the work of several teams: 86 containers, 24 databases, 240 cron jobs, two servers, one person. Amodei is right that this is now possible. The tools exist. The costs dropped. A full AI stack costs me between $3,000 and $12,000 per year. The equivalent in human headcount would run $80,000 to $120,000 per month. But the headline version of the "one-person company" story skips the hard part. It sounds like you hire an AI, fire your team, and go make money. That is not what happened for me. What actually happened was eighteen months of building a system that makes "one person" sustainable at 3 AM when something breaks and nobody is awake to fix it. Here is what that system looks like in practice. The Stack Is Not the System Most people stop at the stack. They pick Claude or GPT, wire up a few automations, and call it an AI-powered business. That works until the first thing breaks in a way the model did not anticipate. The stack I run includes SaaS apps for golf clubs, a school management platform, an auth provider, a CRM, a community platform, and several tools for my own operations. Each of these runs in Docker containers managed by Coolify, spread across two Hetzner servers in Germany. That part is table stakes. Any competent developer can set up containers. The system is what sits on top. It is what makes the difference between "one person with a lot of tools" and "one person running a business that actually works." Guard Rules: The Thing That Catches What You Miss I wrote about this in detail in Runs Without Me : the biggest risk in a one-person setup is not that the AI does something wrong. It is that you do not notice until hours or days later. My setup uses 177 guard files that intercept operations before t

Hello Guys!!! I am Kuldeep Gade. A final-year Computer Engineering student with a specialization in Cybersecurity. Currently, I am working on home lab automation so that it will help to encounter alerts (false positives). For practice, I have created a controlled environment for performing attacks and detecting them, such that the outside doesn't get affected. Working on projects which will enhance my cybersecurity skills. But I wasn't that obsessed with cybersecurity from the starting. I am a person who experimented with lots of domains by myself. When I was in the first year, I completed Full-Stack in MERN. For 1–1.5 years, I did that, but after some time, AI got so much power that within 3–4 months of the launch, they were able to create such stunning websites that needed a team of skilled people. And I thought it could be useless to go deep into MERN more, because if AI can do such things within months, then what is going to happen at the time of my graduation? And that's the reason I tried other things. So I realised that it could be better to gain the fundamental knowledge in the core of Domains that will automatcally get to implementation level with the help of the AI tools. So I started to learn Data Science and Machine Learning. Soon, I realised that I cannot keep up with it. Then I started with cybersecurity. And currently, I am going deep into it. As a result, I got my answer, and now I am a bit focused towards the cybersecurity domain. It was a tremendous feeling about knowing the root of the system on which we are working. How to troubleshoot the errors and problems. And I am loving it now. Gaining experience in this field is not just learning and watching tutorials. We have to perform hands-on practice. We have to learn by doing things, breaking systems, understanding workflows, rebuilding them. I am going to share my experience in the field as we go in upcoming blogs. Recently, I started my new goal to "read the books". And did some research on books.

Originally published on hexisteme notes . I keep my operating judgment in small, versioned files — one file per decision, each with a status, a list of what it supersedes, and a change history. It's a lightweight way to stop re-litigating the same argument every few weeks: write the judgment down once, and the next time the situation comes up, read the file instead of re-deriving the answer from scratch. Most of the time this works exactly as intended — a rule gets written, a rule gets proven wrong, a newer rule replaces it, done. This is the story of the one time that didn't happen, and why "didn't happen" doesn't look like an error. It looks like a rule sitting there, marked active, doing precisely what it was told to do. The gate One of my rules governed how to use a panel of eight simulated reviewers I sometimes convene for open-ended judgment calls — different personas critiquing the same plan from different angles. The panel's response includes, among other things, an "internal consistency" score: roughly, how much the eight answers agree with each other. Early on I wrote a gate around that number: if internal consistency comes back under 70%, don't adopt the panel's conclusion on its own. Low agreement, the reasoning went, meant the panel hadn't converged on anything trustworthy. The supersession, with receipts The gate lasted exactly as long as it took to hit a counterexample. I ran the panel on an architecture question and got back a response at 21% internal consistency — a reject, by the gate's own arithmetic. Except when I actually read the eight answers instead of just their agreement score, three of them were pointing at things I hadn't considered at all: a missing measurement step behind a database-performance claim, a conflation of a plan's stated purpose with its surface description, and one persona's terse near-empty answer that turned out to be a legitimate signal — a comment that the question itself wasn't well-formed for consensus, not a dodge. A

The Agentic Coding Revolution: How I Learned to Stop Typing and Start Delegating Or: what happens when your IDE becomes less of a text editor and more of a teammate. Remember when "AI-assisted coding" meant autocomplete suggestions that guessed your variable names? Those days are gone. Somewhere along the way, the tools stopped suggesting and started doing . They read your repo, run your tests, open pull requests, and sometimes fix bugs you didn't even know existed. Welcome to the era of agentic coding — and if you haven't restructured your workflow around it yet, this post is your crash course. What Actually Changed? The shift from code assistant to coding agent comes down to one capability: autonomy . A traditional assistant waits for your keystrokes. An agent receives a goal and figures out the rest. Dimension Code Assistant Coding Agent Trigger Your keystroke A stated objective Scope Single line or block Entire task, across files Feedback loop None Reads test output, retries, iterates Tool use Suggestion only Shell, browser, git, package managers Ownership You write, it suggests It drafts, you review The mental model that helped me most: stop thinking of the agent as an autocomplete and start thinking of it as a junior developer with access to your codebase. You wouldn't hand a junior engineer an undocumented task with no acceptance criteria. So why hand it to an agent? The Prompting Gap Is the New Debugging Here's the uncomfortable truth I discovered after a few months of daily agentic workflows: agents don't fail because they're dumb. They fail because our instructions are vague. Consider these two requests: ❌ Bad: "Make the app faster" ✅ Good: "Reduce p95 latency of the /search endpoint (currently 1.2s) to under 300ms. Focus on the database query layer first. Keep existing API contracts unchanged. Add a benchmark comparing before/after." The second version has a measurable goal, a constraint boundary, a starting hypothesis, and a definition of done. Agents th

Originally published on my Substack . I'm a Microsoft MVP based in Japan, writing in English about the AI agent systems I actually run in production. AI tools have multiplied. So have agents, skills, and automation scripts. And yet, somehow, my hands are never free. I wake up, open a dashboard, check notifications, go look at the logs for a failed job, and think, "wait, where was that process even running?" Every time I add one more automation, I add one more place I have to go check. That was me, up until last year. The cause was clear: I kept thinking about what to have AI do, and never once designed where I myself would touch things. So I rewrote my policy down to one line. There are only two things a human does: throw tasks into one place, and have conversations in one place. No other entry points get added. 🤖✍️ This article was co-written with AI — an AI agent (Claude Code) generated the draft automatically based on real collaborative work with Ebisuda, who then reviewed and revised it before publishing. In this series, I share the systems I've actually built using AI as case studies — including both the ones that worked and the ones that failed. What I Set Out to Build What I set out to build wasn't a specific tool or a specific agent. It was the design of the surface humans touch. The rule I settled on was just two lines. The only human entry points are Todoist (for dropping in things to do) and Discord (for conversation) Everything else gets pushed to the AI and scheduler side This is the opposite of "let's have AI do a ton of work." When people try to maximize what AI can do, they end up adding more tools. More tools means more settings screens, more places logs pile up, more places you have to go check "how's it doing now." Left unchecked, the number of automated processes and the number of places a human has to go look both grow together. So the thing I needed to decide first wasn't the scope of AI's work — it was the footprint on the human side. If you f

New fonts, better customization, and a whole new layout all make it worth dusting off your Instapaper account.

I kept paying a monthly subscription for a cloud coding assistant while a 16GB M4 Mac mini sat on my desk idling most of the day. So I ran the obvious experiment: can a 16GB Mac mini run a coding assistant entirely offline — no code leaving the machine, no subscription — and is it actually usable for real work? Short answer: yes, with one hard constraint (RAM) and one soft one (context length). This article is the written version of the video above, with every command, config file, and benchmark number so you can reproduce it. Table of contents Why bother running locally The hardware constraint nobody mentions Step 1: Install Ollama Step 2: Pick a model that fits in 16GB Step 3: Run and verify Step 4: Wire it into VS Code Step 5: Tune Ollama for a 16GB box Benchmarks What it does well, what it doesn't Should you cancel Copilot? Why bother running locally Three reasons, in the order that actually mattered to me: Privacy. Client code, internal repos, anything under NDA — none of it leaves the machine. This is the one thing a hosted assistant cannot offer you at any price tier. Cost. A coding assistant subscription is roughly $100–240/yr depending on tier. The Mac mini was already bought. Offline. Flights, bad hotel wifi, coffee shop dead zones. The assistant just works. The reason not to: raw capability. The frontier hosted models are better at large multi-file reasoning, and it isn't close. More on that below. The hardware constraint nobody mentions On Apple Silicon, the GPU and CPU share one pool of unified memory. A model has to fit in that pool alongside macOS, your browser, VS Code, and whatever containers you're running . On a 16GB machine, macOS + a normal dev environment eats 6–8GB before you've loaded anything. That leaves you roughly 7–9GB of realistic headroom for the model. This single number determines everything else, and it's why "just run the 30B model" advice from people on 64GB machines doesn't transfer. By default macOS allows the GPU to use about 7

You're on the highway, hands on the wheel, and a message comes in. Or at least it should come in. Instead your car stays silent, or the notification shows up ten minutes later at a red light, or it reads out a name but the body never appears. If this sounds familiar, you're not dealing with a broken phone. You're dealing with the fact that Android Auto surfaced notifications very differently from your lock screen — and a lot of small settings have to line up for a message to actually reach you while you drive. Here's the mental model, the usual culprits, and the exact fixes. I've split the fix-it steps into separate deep-dives at the end, because "my messages don't show in the car" can mean five different things. The mental model: it's a separate pipeline On your phone, a message notification lives in the shade like any other notification. In Android Auto it's a different surface. Android Auto only pulls in notifications from apps it recognizes as messaging apps , and it deliberately filters them down to something safe to glance at while driving. That filtering is the whole game. A notification that's perfectly fine on your lock screen can be dropped, delayed, or stripped of its text in the car because one of these conditions isn't met: the app is enabled for Android Auto (not every app is, by default), the app has notification access granted, the phone isn't in a mode that suppresses it (Do Not Disturb, Driving mode), the app isn't being killed by battery optimization in the background, and the message is actually a message Android Auto understands (some apps send "silent" or summary notifications that AA ignores). Notice none of these are "the app is broken." They're configuration. Which is good news — they're all fixable. The usual culprits, in order of how often they're the cause 1. The app isn't enabled in Android Auto. Android Auto shows notifications from a curated set of messaging apps. Open Android Auto → Settings → Notifications → Configure notifications,

Imagine this: You’re drafting a long email, writing a report, or responding to a wave of Slack messages. Instead of hunching over your keyboard and typing at 40 words per minute, you simply hold down Ctrl + Space , speak your thoughts at 150+ words per minute, and release the keys. Instantly, clean, perfectly punctuated, polished text appears right where your cursor is. Meet Vacanam — a free, 100% private, offline voice typing tool built for Windows 10 & 11. 😫 Why Most Voice Typing Tools Are Frustrating If you’ve ever tried built-in dictation tools or commercial transcription services, you’ve likely run into the same annoyances: They Send Your Voice to the Cloud : Many tools stream your microphone audio to remote servers. If you work with sensitive emails, client data, or private thoughts, that’s an immediate dealbreaker. They Require an Internet Connection : Try dictating on an airplane, during spotty Wi-Fi, or in a secure offline room — they simply refuse to work. Punctuation is a Headache : You have to awkwardly say things like "Hello comma how are you question mark" just to get a basic sentence right. Subscription Fatigue : Most good dictation apps charge $10 to $30 every single month. We built Vacanam (वचनम् — Sanskrit for Voice & Speech ) to fix all of this once and for all. 🌟 The Superpowers: What Makes Vacanam Different? 1. 🎙️ Works in Every Single Windows App Vacanam doesn’t trap you inside a special recording window. It works universally: Productivity & Docs : Microsoft Word, Google Docs, Notion, Obsidian, OneNote Communication : Slack, Microsoft Teams, WhatsApp Desktop, Discord, Outlook, Gmail Browsers & Editors : Chrome, Edge, Firefox, Notepad, VS Code, Terminals Just click into any text box, hold Ctrl + Space, speak, and let go. 2. 🪄 Automatic AI Polish (No More "Ums" or Missing Commas) When we talk, we hesitate, say "um" , repeat words, and forget punctuation. Vacanam features an optional Built-in AI Assistant that runs silently on your computer: Remov

I spent a morning hunting for a setting that did not exist. A while back I turned off Claude's co-authorship trailer in my commits — a deliberate choice at the time. Last week I decided I wanted it back. So I went looking for the switch I'd flipped. ~/.claude/settings.json : no key. settings.local.json : no key. ~/.claude.json , parsed as JSON, top-level plus all 38 project entries : no key. The 27 .claude/settings*.json files scattered across my two working drives: no key. Every CLAUDE.md and AGENTS.md I own: no mentions. Environment variables: nothing. A final sweep of my entire user directory — every *.json and *.md — returned three raw hits: a changelog and two copies of an editor extension's JSON schema. The note I wrote when that finished was two words: "Cero hits reales." Zero real hits. There was exactly one thing anywhere on disk that turned attribution off, and it was a sentence: ~/.claude/rules/ecc/common/git-workflow.md:12 Note: Attribution disabled globally via ~/.claude/settings.json. It had a Chinese twin, same file path with zh/ instead of common/ , same line 12. Both files are rules files. Rules files get loaded into every session. So every session opened with a line of documentation asserting, flatly and falsely, that a global setting was off — and the model behaved accordingly. The switch I remembered flipping never existed as a switch. The prose was the switch. The key that sentence gestured at, includeCoAuthoredBy , is deprecated and replaced by attribution . Neither is present in any of my configs, which means the default was active the whole time. The feature was on. Only the description of the world said otherwise, and the description won. The thesis Here's what I take from that, and from two more receipts this week: in an agent system, prose and constants are not documentation about the control plane. They are the control plane. I run a personal multi-agent system on top of Claude Code — 19 specialized agents, root-driven, single-writer, coo

Times are changing, my role is changing, my focus is changing, my impact is changing. But in essence – I'm still doing the same. I still build products that drive impact. Only my day-to-day looks completely different. The shift is happening, sooner or later, if you want it or not. Whether or not you can cope, is all up to you. In the past, I was neck-deep in code. That was what the majority of my time consumed. I liked it, building things, building products. These days, that's all done by an endless amount of AI agents. I barely touched any code in the past half year – if not even longer. My focus moved from building products to building my own process The work that used to go into a feature now goes into the process that produces the feature. Instead of losing the first hour of my day to Slack and email, I built a small stack of scheduled agents that hand me a briefing before I even open my laptop ( already wrote about that one ). Instead of reading every pull request line by line, I set up a review loop where agents do the first pass and I stay on the hook for whatever they flag. None of it started as a plan. Each piece started as one specific annoyance I got tired of and fixed. That's the actual mechanism: improve one small thing, it saves you time, you reinvest that time into the next small improvement. Compounding, not a grand strategy. The question I try to ask myself daily is simple: how can I do my job a bit better today than I did it yesterday? Not more. Not faster. Better. I also don't run ten parallel AI workflows across different projects at the same time because someone told me that's what a serious AI-software engineer does now. If I have multiple projects going on, I only focus on one project at a time. That's the amount of mental space I have right now, and I've stopped treating that as a shortcoming. My impact shifted from writing code to making my team better The time that used to go into implementation didn't disappear, it moved upstream. I now sp

Ten things started is not progress. It's ten open tabs in your head, each one costing rent. Every unfinished task keeps a little of your attention hostage. You feel busy. You are just fragmented. Finishing one small thing returns more energy than starting three. So close the loop. Merge the PR. Send the message. Delete the branch. An empty background is where good work actually happens. Done is quiet. Chase the quiet. – Serguey Asael Shinder

Hello World! - Building a Project While Fighting Shiny Object Syndrome Let's start simple. What is "Shiny Object Syndrome"? Here is the definition pulled straight from Wikipedia: Shiny Object Syndrome is the situation where people focus undue attention on an idea that is new and trendy, yet drop it in its entirety as soon as something new can take its place. In my own words, I would describe it as chasing the novelty and the rush of starting a new project only to lose interest when I hit the not-so-fun parts. Why does that happen? I don't know. My guess would be that I have a lot of ideas that I want to see tangible results from fast . Like, for example: I want to see my app right in front of me in one or two sessions at most. I have a lot of energy for one week straight to work on my new idea, and then I lose interest at the first boring part I encounter. Very valid reasoning, but in the end, I'm left with a bunch of unfinished projects and feeling worse than when I started. This is why I'm here: to share my progress as I try to overcome SOS. I think I perform better when I have someone watching me, waiting for my results, or when I have a real deadline that isn't enforced only by myself. I need the consequences and the pressure to commit. So, now that you know what SOS is and why it sucks, let's see how to fix it. In front of me is one of my latest Shiny Objects (SO), and I've decided that I will apply these next steps to finish it before starting on a new SO. Here's the game plan: Open the Shiny Object. If I started working on it already: document a piece of the finished work every week. DO NOT START WORKING ON THE NEXT PART UNTIL ALL FINISHED PARTS ARE DOCUMENTED HERE. Plan for the next steps of the SO. Implement them (write notes on the changes and decisions taken while implementing). Document them here. Now that we have a vague plan of what we are going to do, let me tell you about the Shiny Object in question: It is a personal file drive where users upload fi

AI agents are increasingly good at building websites, reports, dashboards, and interactive prototypes. The awkward part is often the last mile: downloading a folder, creating a repository, configuring hosting, and copying a URL back into the conversation. A simpler workflow is to let the agent publish the result itself. In this tutorial, I'll show a practical agent-to-live-URL workflow using Revdoku , free web hosting designed for AI agents. Disclosure: I'm part of the team building Revdoku. What you need An AI agent that can create website files and use tools, such as ChatGPT, Claude, Codex, Gemini, Grok, Cursor, or OpenCode A static website, single-page app, report, dashboard, documentation site, or other browser-ready files No hosting account for the first public deployment Revdoku publishes publicly by default. Permanent free accounts require no credit card. Password protection and verified-email access control are optional paid upgrades. 1. Give your agent the publishing instructions Open the Revdoku homepage and use Copy prompt for my AI . Paste those instructions into the same conversation where your agent is building the project. This gives the agent the current integration instructions instead of making you translate deployment steps manually. 2. Ask for the site and the deployment in one prompt Here is a small example: Create a responsive single-page launch page for an open-source developer tool. Include: - a clear hero section - three feature cards - an installation example - a mobile-friendly layout Use plain HTML, CSS, and JavaScript. When the site is ready, publish it with Revdoku and return the final public URL. Keep the project linked so later changes can be republished to the same URL. The key is the last paragraph. It makes deployment part of the deliverable, not a separate chore. The agent can generate the files, publish them through Revdoku's agent-facing workflow, and return a live link in the conversation. A public deployment does not require y

A question I've been thinking about after discussing AI coding agents with several developers: Is passing the test suite enough to prove that an AI agent made the correct engineering decision? I don't think it is. And this isn't just a theoretical concern. Modern coding agents are increasingly working at the repository level rather than generating isolated code snippets. OpenAI's Codex documentation, for example, describes using repository-specific AGENTS.md instructions to tell the agent how to navigate a codebase, run tests, and follow project practices. Anthropic similarly describes Claude Code searching codebases, tracing dependencies, editing multiple files, and working with CI failures. ( OpenAI ) That changes what "correctness" means. Consider a simple scenario A project starts with: Architecture v1 API ↓ Service ↓ Database An AI agent learns this structure and implements a new feature correctly. The tests pass. Then the architecture changes: Architecture v2 API ↓ Event Bus ↓ Services ↓ Database The same task is requested again. If the agent continues following the old architecture, its code might still: compile, pass existing tests, satisfy the visible functional requirement, but still be wrong for the current system . This is the distinction I'm interested in: Code correctness ≠ Contextual correctness The Benchmark Problem Traditional coding benchmarks generally provide: Repository + Issue ↓ Agent ↓ Patch ↓ Tests / Evaluation This is valuable. SWE-bench, for example, was designed around real GitHub issues and repositories, and OpenAI created SWE-bench Verified with human validation because benchmark quality itself affects what we conclude about model capability. ( OpenAI ) But there is another dimension worth testing: What happens when the context changes? Recent research is already moving in this direction. SWE-ContextBench evaluates whether coding agents can reuse relevant experience across related tasks, while SWE-Explore focuses specifically on reposito

Early this year I was wiring Claude into Jira through an MCP server. It worked, and every session it felt slightly wrong: slow round trips, a schema I did not control, structure sitting somewhere the agent could not see while it was reading the code. The fix was almost embarrassingly simple. Put the ticket in the repo, as markdown. I pitched it to a colleague, and off we went. Seven months later: 15 projects across 10 repositories, 165 live tickets, 12 people on the board including non-developers, and no Jira licence. This post is why we left and what we built. Two follow-ups cover the rest: the skill and the loop that let agents work these tickets , and the three review layers that keep the output honest . What was actually wrong with Jira The cost was easy to name: roughly €2,000 a year for something we used maybe 5% of. It was not the reason we left. Every user had to be paid for, so the board was implicitly rationed. Performance degraded as projects grew. The features we wanted sat behind paid plugins. Automations were clumsy enough that we mostly did not write them. And the board was close to what we wanted without ever being it, because that last gap lived in someone else's product roadmap. None of that is fatal alone. Together it means the tool shapes the team instead of the other way around. The constraint that ruled out the obvious answers We are one team maintaining ten separate repositories that ship independently of one another, across TypeScript, C#, Java and PowerShell. A monorepo was never realistic. That kills the usual alternatives. GitHub Issues comes closest and misses twice: issues are scoped to one repository, so cross-repo visibility becomes somebody's weekly spreadsheet, and despite feeling like part of the repo they are not in it. They live in a database behind an API. Not files, not on the branch, not in the diff, and not something an agent editing the code can read without a round trip. Every hosted alternative moves the work further away s