[{"data":1,"prerenderedAt":202},["ShallowReactive",2],{"notes":3,"profile":45,"note-developer-tools-for-normal-teams":200},[4,13,21,28,34,40],{"slug":5,"title":6,"topic":7,"status":8,"published":9,"summary":10,"minutes":11,"href":12},"developer-tools-for-normal-teams","Developer tools for normal teams","AI","published","2026-09-24","Every team using AI is about to hit problems software teams solved years ago. The fix is the same four tools, in plainer clothes.",4,"\u002Fnotes\u002Fdeveloper-tools-for-normal-teams",{"slug":14,"title":15,"topic":16,"status":8,"published":17,"updated":9,"summary":18,"minutes":19,"href":20},"ai-makes-software-cheaper","AI makes software cheaper. Systems thinking becomes more valuable.","Software","2026-09-23","Models make code cheap to write. They don’t make systems cheap to own, and that gap is where the valuable work moves.",2,"\u002Fnotes\u002Fai-makes-software-cheaper",{"slug":22,"title":23,"topic":24,"status":8,"published":17,"updated":9,"summary":25,"minutes":26,"href":27},"jev-tiny-models-strange-interfaces","JEV, tiny models and strange new interfaces","Experiments","Small, fast models that pick one option from a fixed set don’t chat. They decide, and that invites interfaces that don’t look like chat at all.",1,"\u002Fnotes\u002Fjev-tiny-models-strange-interfaces",{"slug":29,"title":30,"topic":7,"status":8,"published":17,"summary":31,"minutes":32,"href":33},"what-i-learned-giving-agents-memory","What I learned giving agents memory","Memory is not a transcript. On selection, lifetimes, forgetting and what persistent agents change about software.",6,"\u002Fnotes\u002Fwhat-i-learned-giving-agents-memory",{"slug":35,"title":36,"topic":37,"status":8,"published":17,"updated":9,"summary":38,"minutes":19,"href":39},"when-software-becomes-an-actor","What finance looks like when software becomes an actor","Finance","When software can act on money, not just record it, the hard questions stop being technical and become about permission and accountability.","\u002Fnotes\u002Fwhen-software-becomes-an-actor",{"slug":41,"title":42,"topic":16,"status":8,"published":17,"updated":9,"summary":43,"minutes":19,"href":44},"why-i-still-prototype-things-myself","Why I still prototype things myself","Building the first version myself is still the fastest way I know to find out what a product should be, and where it will break.","\u002Fnotes\u002Fwhy-i-still-prototype-things-myself",{"name":46,"meta":47,"statement":48,"lede":51,"description":52,"readout":53,"current":69,"work":113,"trajectory":145,"notes":171,"about":174,"contact":184},"Chris Wijnia","Engineer · Founder · Bali \u002F 2026",{"text":49,"accent":50},"I build software and companies.","companies.","I’m a Dutch engineer and co-founder of Agio Digital. Since the early 2000s I’ve designed, built and shipped products across the web, financial technology and whatever came next.","Dutch engineer and co-founder of Agio Digital. I design, build and ship products across the web, financial technology and AI.",[54,57,60,63,66],{"label":55,"value":56},"Base","Bali",{"label":58,"value":59},"Origin","Netherlands",{"label":61,"value":62},"Current","Agio Digital",{"label":64,"value":65},"Work","Software \u002F Finance \u002F AI",{"label":67,"value":68},"Status","Building",{"title":70,"accent":71,"records":72},"What I’m working on.","working on.",[73,88,102],{"id":74,"label":75,"headline":76,"accent":77,"paragraphs":78,"facets":81,"period":87},"agio","01 \u002F Agio Digital","Building financial software.","financial software.",[79,80],"I co-founded Agio Digital, where I’m Chief Innovation Officer.","I work across product, engineering and R&D, from financial infrastructure and digital assets to automation and AI. I still write code and stay close to the systems we ship.",[82,83,84,85,86],"Financial software","Digital assets","Product","Engineering","R&D","2019–Now",{"id":89,"label":90,"headline":91,"accent":92,"paragraphs":93,"facets":96,"period":101},"ai","02 \u002F AI & software","Finding useful things to do with new models.","new models.",[94,95],"I spend a lot of time on agents, developer tools, automation and new ways of building software.","I’m less interested in demos than in what holds up once real users, existing systems and messy constraints get involved.",[97,98,99,100],"Agents","Developer tools","Automation","Applied AI","2024–Now",{"id":103,"label":104,"headline":105,"accent":106,"paragraphs":107,"facets":110,"period":112},"independent","03 \u002F Independent work","Building things to see where they go.","where they go.",[108,109],"Small software projects, open-source work, trading systems, strange interfaces and ideas that start as a repository before they have a business case.","Some become useful. Some answer a question. That’s enough.",[16,111,24],"Open source","Ongoing",{"title":114,"accent":115,"outro":116,"projects":117},"A few things I’ve worked on.","worked on.","The work has changed a lot over the years. The habit of making things hasn’t.",[118,122,127,133,139],{"no":119,"name":62,"area":120,"period":87,"slug":121},"01","Financial software \u002F Digital assets","agio-digital",{"no":123,"name":124,"area":125,"period":101,"slug":126},"02","AI systems","Agents \u002F Automation \u002F Developer tools","ai-systems",{"no":128,"name":129,"area":130,"period":131,"slug":132},"03","1GRAM","Blockchain \u002F Wallet infrastructure","2018","1gram",{"no":134,"name":135,"area":136,"period":137,"slug":138},"04","MVRDV","Digital platform \u002F Team Foster","2016","mvrdv",{"no":140,"name":141,"area":142,"period":143,"slug":144},"05","Archive","Products \u002F Websites \u002F Design \u002F Software","2005–2023","archive",{"title":146,"accent":147,"eras":148},"Moving down the stack as the web evolved.","evolved.",[149,153,155,157,160,164,167],{"year":150,"name":151,"line":152},"2000s","Design","Learning the web by making things.",{"name":84,"line":154},"Design became code.",{"name":85,"line":156},"Code became systems.",{"year":131,"name":158,"line":159},"Crypto","Programmable ownership and money.",{"year":161,"name":162,"line":163},"2019","Financial infra","Building systems where software meets regulation.",{"year":165,"name":7,"line":166},"2024","Software that increasingly builds and operates software.",{"year":168,"name":169,"line":170},"Now","Convergence","What happens when these things converge?",{"title":172,"intro":173},"Notes","Things I’m working on, learning or trying to understand.",{"title":175,"accent":176,"paragraphs":177},"I’ve been making things on computers for most of my life.","life.",[178,179,180,181,182,183],"I grew up in the Netherlands and started building for the web as a teenager.","I began as a designer. Design pulled me into frontend development, then engineering, product architecture and eventually company-building.","Over the years I’ve worked on websites, consumer products, blockchain infrastructure, financial systems and now AI. I don’t draw hard lines between design, engineering and product. They’re different ways of looking at the same problem.","At Agio Digital I spend most of my time building, prototyping, reviewing systems and figuring out what we should do next.","I like small teams, ambitious projects, good engineering and people who can disagree without making it tedious. I still enjoy opening an empty repository and figuring something out.","I’m based in Bali and work internationally. Outside work I train Muay Thai, like [chess](\u002Fexperiments\u002Fchess960), and build things that occasionally have no sensible commercial purpose.",{"title":185,"accent":186,"intro":187,"links":188},"Making something interesting?","interesting?","For companies, collaborations, technical discussions, speaking, new ventures, or a good reason I haven’t thought of.",[189,191,194,197],{"label":190},"Email",{"label":192,"href":193},"LinkedIn","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fchris-wijnia-1364a29b",{"label":195,"href":196},"GitHub","https:\u002F\u002Fgithub.com\u002Fcwdx",{"label":198,"href":199},"X","https:\u002F\u002Fx.com\u002FChrisWijnia",{"slug":5,"title":6,"topic":7,"status":8,"published":9,"summary":10,"minutes":11,"href":12,"html":201},"\u003Cp>Every team that uses AI seriously runs into the same wall. It isn’t the price of tokens. It’s that once several agents are doing real work, nobody can say for certain what they did or whether it was right.\u003C\u002Fp>\n\u003Cp>Software teams have had that problem for decades, with people instead of agents, and they solved it with a handful of tools. I think those tools are about to leave engineering. This is the argument I made at the Canggu AI Meetup tonight; the slides are at the end.\u003C\u002Fp>\n\u003Ch2 data-no=\"01 \u002F 09\">The wall is trust, not tokens\u003C\u002Fh2>\n\u003Cp>Starting an agent is easy. Anyone can point one at an inbox or a spreadsheet in an afternoon.\u003C\u002Fp>\n\u003Cp>The hard part comes afterwards. An agent rarely fails loudly. It summarises a little less carefully, skips a field in the CRM, drafts a proposal that is nearly right. If nothing checks the work and nothing records it, you find out weeks later, from a customer.\u003C\u002Fp>\n\u003Cp>So the question worth asking isn’t “which agent?” It’s “how would I know?”\u003C\u002Fp>\n\u003Ch2 data-no=\"02 \u002F 09\">How a small team runs millions of lines\u003C\u002Fh2>\n\u003Cp>The codebase I work in every day is a little over five million lines, spread across 84 apps and services. A small team maintains it. Nobody reads it all, and nobody needs to.\u003C\u002Fp>\n\u003Cp>It works because the agents that do much of the work operate inside a few rules we wrote down, and because nothing they produce lands without being checked. There are 253 written playbooks (we call them skills) and 48 specialised agents for planning, coding, reviewing and shipping. None of that is exotic. It’s mostly the standard toolkit of any well-run engineering team, applied to agents instead of people.\u003C\u002Fp>\n\u003Ch2 data-no=\"03 \u002F 09\">Four tools, in plainer clothes\u003C\u002Fh2>\n\u003Cp>Each of these exists in software because many hands working in one system break things in ways nobody notices until later. Agents are many hands.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Checks the agent can run itself.\u003C\u002Fstrong> Developers have tests: code that fails when something breaks. For everyone else it’s a checklist, a sample to compare against, or a number that has to move. An agent that can check its own work improves without you. One that can’t makes you the test.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>A record of everything.\u003C\u002Fstrong> Developers have version history: every change, who made it, and a way back. For everyone else it’s Linear, Drive or Notion, as long as the agent writes where people already read.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Know-how written down once.\u003C\u002Fstrong> Developers have runbooks. For agents, the same idea is a skill: a short instruction loaded when the task needs it. The useful ones come from watching an agent fail at the same thing twice.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Gates sized to the mistake.\u003C\u002Fstrong> Developers have code review. For everyone else it’s approval: light for a draft email, heavier for a payment or a contract.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of these need a developer. They need the habits developers have.\u003C\u002Fp>\n\u003Ch2 data-no=\"04 \u002F 09\">Keeping track is the one to start with\u003C\u002Fh2>\n\u003Cp>If I had to pick one, it’s the record. Every agent, whatever it does, writes to the same place: what it did, and whether its check passed.\u003C\u002Fp>\n\u003Cp>That’s also how you catch the quiet failure. A shared log turns “the agent seems fine” into something you can see. If it isn’t tracked, it didn’t happen, and if it didn’t happen you can’t tell whether it went wrong.\u003C\u002Fp>\n\u003Ch2 data-no=\"05 \u002F 09\">The steps are about guardrails, not tokens\u003C\u002Fh2>\n\u003Cp>Boris Cherny, who built Claude Code, \u003Ca href=\"https:\u002F\u002Fx.com\u002Fbcherny\u002Fstatus\u002F2077929379661844559\" target=\"_blank\" rel=\"noopener\">describes five steps of AI adoption\u003C\u002Fa>: gated, then assisted (about one agent per person), parallel (about ten), supervised autonomy (about a hundred), and AI-native (a thousand or more). His point, which matches what I’ve seen, is that tokens alone don’t move a team up a step. Removing the next bottleneck and building the next guardrail does.\u003C\u002Fp>\n\u003Cp>The four tools above are those guardrails. Most teams outside engineering are on the first or second step, and the jump to the third is where they start to matter: at ten agents per person, nobody can supervise every output by eye.\u003C\u002Fp>\n\u003Ch2 data-no=\"06 \u002F 09\">One install for the whole team\u003C\u002Fh2>\n\u003Cp>Habits spread badly by memo. What worked for us was packaging them. The team gets one plugin for Claude Cowork, installed once, with no terminal involved. It holds the skills, the connections to our own systems and the checks:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Skills.\u003C\u002Fstrong> For example, an inbox assistant that learns your tone from your sent mail and drafts replies on a schedule, or one that produces year-end investor statements.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Connectors.\u003C\u002Fstrong> Links to the company’s docs, CRM and data, so a question in plain words gets an answer from the real source.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Checks.\u003C\u002Fstrong> For example, a fact-checker that re-derives every claim in a draft before it goes out.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The plugin is built from what we actually run, so when someone adds a skill or a connection, everyone has it on the next update. Nobody maintains a list, which is the only reason the list stays true.\u003C\u002Fp>\n\u003Ch2 data-no=\"07 \u002F 09\">Can normal teams run this?\u003C\u002Fh2>\n\u003Cp>The meetup asked. Yes, with the tools, and none of them require writing code. Package the habits once and everyone installs them. Agents break things quietly only when there’s no check and no record; with both, a problem shows up in the log the same day.\u003C\u002Fp>\n\u003Ch2 data-no=\"08 \u002F 09\">The slides\u003C\u002Fh2>\n\u003Cfigure class=\"deck-embed\">\u003Ciframe src=\"\u002Fslides\u002Fcanggu-ai-meetup\u002F\" title=\"Slides\" loading=\"lazy\" allowfullscreen>\u003C\u002Fiframe>\u003Cfigcaption>\u003Ca href=\"\u002Fdecks\u002Fcanggu-ai-meetup\">Open the deck ►\u003C\u002Fa>\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Ch2 data-no=\"09 \u002F 09\">Open questions\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>How small can the record be before it stops being useful? A spreadsheet works for one team; I don’t know where it stops working.\u003C\u002Fli>\n\u003Cli>Who writes the skills in a team with no engineers, and who decides when one is wrong?\u003C\u002Fli>\n\u003Cli>Checks are easy for numbers and hard for judgement. What’s the checklist for “is this a good proposal”?\u003C\u002Fli>\n\u003C\u002Ful>\n",1790246170961]