Dr Milan Milanović

Do you use Claude Code with the current best practices? What you probably do is use Claude Code in VS Code or the desktop app as a chat window that edits files, and tell it what to do. Everything here is still in the context. Here is how to clear this: 𝟭. 𝗥𝗲𝘄𝗶𝗻𝗱 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗰𝗼𝗿𝗿𝗲𝗰𝘁𝗶𝗻𝗴. If you prompt Claude with "don't do it this way", it will leave that approach in context. If you do Esc Esc on an empty prompt (or /rewind), it is going to roll back code and conversation to a previous point (you can pick). 𝟮. 𝗖𝗼𝗺𝗽𝗮𝗰𝘁 𝗮𝘁 𝗺𝗶𝗹𝗲𝘀𝘁𝗼𝗻𝗲𝘀. If you wait for auto-compaction of your context, this happens only when the context is almost full. It is better to use /compact with an instruction when you hit an important milestone. 𝟯. 𝗖𝗵𝗲𝗰𝗸 𝗮𝗻 𝗲𝗺𝗽𝘁𝘆 𝘀𝗲𝘀𝘀𝗶𝗼𝗻. Before starting anything, run /context so you can see what you have in your prompt, such as skills, MCP servers, etc. Also /usage can show you how many tokens you have spent. 𝟰. 𝗛𝗼𝗼𝗸𝘀 𝗳𝗼𝗿 𝗿𝘂𝗹𝗲𝘀 𝘁𝗵𝗮𝘁 𝗺𝘂𝘀𝘁 𝗿𝘂𝗻. One of the most interesting features that Claude Code has are hooks. You can add them for Edit/Write. And some examples are: running a formatter, linter or even a whole test suite after each edit. Running the hook costs no tokens; only the output it sends back to Claude does. 𝟱. 𝗩𝗲𝘁𝘁𝗶𝗻𝗴 𝗖𝗟𝗔𝗨𝗗𝗘 .𝗺𝗱. Keep it small and simple, because it is used in every task. If something can be read from code, remove it from CLAUDE .md. 𝟲. 𝗘𝘅𝗽𝗹𝗶𝗰𝗶𝘁 𝗲𝘅𝗶𝘁 𝗰𝗿𝗶𝘁𝗲𝗿𝗶𝗮. If you enter e.g. /goal dotnet test exits 0, or stop after 20 turns, Claude keeps working until the tests pass or it hits 20 turns. Back to you, what commands do you use on a daily basis?

AI, ML and Data Engineering Trends Report by InfoQ is out Here are the key takeaways: 🔹 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀 𝗮𝗻𝗱 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 (Early Adopters, up from Innovators). Last year was mostly about helping individuals with AI agents, and this year it’s about helping teams and even entire organizations with them. In 2025 it was all about learning to build AI agents. This year companies are figuring out how to run them. 🔹 𝗛𝗮𝗿𝗻𝗲𝘀𝘀 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 (Innovators, new on the graph). The “harness” is the code around the model that orchestrates the agent loop, manages memory, and gives the model access to tools. Agent SDKs started by just providing the loop, and are now expanding to offer memory, code execution, file tools, and hosting for agents. 🔹 𝗔𝗜 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻𝘀 (Early Adopters, new on the graph). This is the process of verifying that an agent completed the task correctly and in the right way. 🔹 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 (Early Majority). Context pollution, when irrelevant content is not separated from useful information, is the biggest problem in context engineering, says Arthur Casals. 🔹 𝗦𝗽𝗲𝗰-𝗱𝗿𝗶𝘃𝗲𝗻 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗮𝗻𝗱 𝗔𝗜 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗳𝗮𝗰𝘁𝗼𝗿𝗶𝗲𝘀 (Innovators). You can use spec-driven development by writing the spec and discussing it with your coding agent before having it implement it. AI software factories aim to automate most of the development process, for example taking a bug from analysis to a fix and a PR, which people then review and test. Knowledge Graphs went from Innovators to Early Majority. AutoML went from Early Adopters to Late Majority. Both of these have “crossed the chasm” and jumped a whole category in just 12 months. Delegation is the new hotness, but the things that make delegation safe and measurable, agent security, observability, and evals, are all in Innovators or Early Adopters. When you delegate, you still own the decisions about: 🔹 what the agent can see and change, 🔹 what context it should have access to, 🔹 how its output will be tested and evaluated, 🔹 how much an agentic session is going to cost. Delegate to an agent only the work you can evaluate. Read the full report in the comments. Image credits: InfoQ.

My research topic from 2007 is the AI buzzword of 2026 From 2005 to 2010 I did research on 𝗼𝗻𝘁𝗼𝗹𝗼𝗴𝗶𝗲𝘀 and rules for the Semantic Web. My master's thesis in 2007 was on that topic. In 2009 I co-wrote a chapter in Springer's Handbook on Ontologies. Then I moved to industry and did not hear the word "ontology" in a business meeting for about 15 years. The promise back then was simple. Data would carry its meaning with it, so a machine reading "customer" would know exactly which kind. Tim Berners-Lee described it in 2001, and OWL became a W3C standard in 2004. In business it was not used so much, because mostly the reader of the data was a human. A person looking at a report knows which "customer" it means from their own experience. Now the reader is an AI agent, and an agent cannot walk over to a colleague and ask. An LLM is fluent in English but it doesn't know what "customer" or "load" means in your company. It will use the most likely meaning with full confidence (yes :). This is where ontologies come back. In plain words, an ontology is a written agreement on what exists in your business. It also says how each thing relates to the others. For example, in our transportation apps: 🔹 Concepts: Shipment, Load, Carrier, Driver 🔹 Relationships: a Carrier hauls a Load, a Load belongs to a Shipment 🔹 Properties: a Load has a pickup date and a weight 🔹 Rules: a Load without a Driver 24 hours before pickup is at risk 🔹 Identifiers: one ID per thing, the same in TMS, CRM and billing Your data tells the model what happened. Your ontology tells it what it means. The big platforms have already started to use it. Palantir's Foundry puts an Ontology layer on top of its datasets and models. In November 2025 Microsoft added an ontology item (preview) to Fabric, where it can import OWL files (used to define ontologies). It can also build a first version from your Power BI semantic models. Some things we invent are not usable at the time, only later, when another technology needs them. Ontologies are a great example.

𝗪𝗵𝗮𝘁 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗲𝘀 𝗱𝗿𝗲𝗮𝗺𝗲𝗿𝘀 𝘃𝘀 𝗱𝗼𝗲𝗿𝘀? Steve Jobs said that one choice in life usually separates the doers from the dreamers and that one thing is asking for help. But, he said: "𝘔𝘰𝘴𝘵 𝘱𝘦𝘰𝘱𝘭𝘦 𝘯𝘦𝘷𝘦𝘳 𝘱𝘪𝘤𝘬 𝘶𝘱 𝘵𝘩𝘦 𝘱𝘩𝘰𝘯𝘦 𝘢𝘯𝘥 𝘤𝘢𝘭𝘭. 𝘔𝘰𝘴𝘵 𝘱𝘦𝘰𝘱𝘭𝘦 𝘯𝘦𝘷𝘦𝘳 𝘢𝘴𝘬, 𝘢𝘯𝘥 𝘵𝘩𝘢𝘵'𝘴 𝘸𝘩𝘢𝘵 𝘴𝘦𝘱𝘢𝘳𝘢𝘵𝘦𝘴 𝘵𝘩𝘦 𝘱𝘦𝘰𝘱𝘭𝘦 𝘸𝘩𝘰 𝘥𝘰 𝘵𝘩𝘪𝘯𝘨𝘴 𝘧𝘳𝘰𝘮 𝘵𝘩𝘰𝘴𝘦 𝘸𝘩𝘰 𝘥𝘳𝘦𝘢𝘮 𝘢𝘣𝘰𝘶𝘵 𝘵𝘩𝘦𝘮." And this is true. In my career, I saw that 𝗳𝗲𝗮𝗿 𝗶𝘀 𝗮 𝘀𝗶𝗴𝗻𝗶𝗳𝗶𝗰𝗮𝗻𝘁 𝗯𝗮𝗿𝗿𝗶𝗲𝗿 𝘁𝗼 𝗮𝘀𝗸𝗶𝗻𝗴 𝗳𝗼𝗿 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝘄𝗮𝗻𝘁 and asking for support from peers and colleagues in so many companies today. So the question is, does your company allow employees to exercise this freedom and safety? Most successful people are 𝗳𝗲𝗮𝗿𝗹𝗲𝘀𝘀 𝗶𝗻 𝗮𝘀𝗸𝗶𝗻𝗴 𝗳𝗼𝗿 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝘄𝗮𝗻𝘁. Video: Silicon Valley Historical Association, 1994

How to continue if we disagree with something? Most of us have done it after a decision we didn't like in the first place. I have led teams for 20 years and what I found is that behind many bad decisions there was always someone who defended them. And sometimes that person was me. What is important here is when we discuss options and have arguments, everyone should join and participate. But when we decide, we should back it up fully. Even if we don't agree with it. Here is how I would do it: 𝟭. 𝗦𝗽𝗲𝗮𝗸 𝘂𝗽 𝗶𝗻 𝘁𝗵𝗲 𝗿𝗼𝗼𝗺 Ask one honest question first. Then state your position once, with your reasons. If the decision is yours, talk with the people it affects before you make it. People can accept even a hard call when they had a say in it. 𝟮. 𝗔𝗴𝗿𝗲𝗲 𝘂𝗽𝗳𝗿𝗼𝗻𝘁 𝘄𝗵𝗮𝘁 𝘄𝗼𝘂𝗹𝗱 𝗿𝗲𝗼𝗽𝗲𝗻 𝗶𝘁 Pick a date, a number or a failure that would make the team look again. Later, bring only that. Repeating the old objection will not add anything. 𝟯. 𝗖𝗼𝗺𝗺𝗶𝘁 𝗮𝘀 𝗶𝗳 𝗶𝘁 𝘄𝗲𝗿𝗲 𝘆𝗼𝘂𝗿 𝗶𝗱𝗲𝗮 Don't work at half speed on it just because it wasn't your pick. Jeff Bezos did it as the boss. His team wanted to make an Amazon Studios original he doubted. He wrote back: "I disagree and commit and hope it becomes the most watched thing we've ever made." Do all three and your team gets 𝘆𝗼𝘂𝗿 𝗷𝘂𝗱𝗴𝗺𝗲𝗻𝘁 𝗮𝗻𝗱 𝘆𝗼𝘂𝗿 𝗳𝘂𝗹𝗹 𝗲𝗳𝗳𝗼𝗿𝘁. Back to you, when were you last overruled, and did you make it work?

Codex is not working for some time now in my VS Code It's updated to the newest version

𝗔 𝘃𝗶𝘀𝘂𝗮𝗹 𝗴𝘂𝗶𝗱𝗲 𝗼𝗻 𝗵𝗼𝘄 𝘁𝗼 𝗰𝗵𝗼𝗼𝘀𝗲 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 With so many options around, choosing the right datastore can be confusing. Even with AI today. In this diagram, we can see a selection choice for a datastore based on a use case. Data can be: - 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 (𝗦𝗤𝗟 𝘁𝗮𝗯𝗹𝗲 𝘀𝗰𝗵𝗲𝗺𝗮) - 𝗦𝗲𝗺𝗶-𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 (𝗝𝗦𝗢𝗡, 𝗫𝗠𝗟, 𝗲𝘁𝗰.) - 𝗨𝗻𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 (𝗕𝗹𝗼𝗯) In the case of structured they can be relational or columnar, while in the case of semi-structured there is a wide range of possibilities, from key-value to graph. Which database have you used for which workload?

𝗔𝗴𝗲𝗻𝘁 == 𝗟𝗟𝗠 + 𝗛𝗮𝗿𝗻𝗲𝘀𝘀 An agent is just an LLM and some additional scaffolding aka harness. This harness can be split into: 1. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁: your prompt, system prompt, additional instructions (e.g. in CLAUDE .md), possibly other context like files, …, conversation history 2. 𝗧𝗼𝗼𝗹 𝗰𝗮𝗹𝗹 𝗳𝗼𝗿𝗺𝗮𝘁: agreed format in which the LLM specifies the tool it wants to run and with which arguments (e.g. read_file, edit_file, bash, search, …) 3. 𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀: rules and permissions that are enforced by the harness (some actions are always ok, some are never ok, some require confirmation) 4. 𝗥𝘂𝗻𝘁𝗶𝗺𝗲: code that actually executes the tool call and passes the results back to the LLM as additional context. This runtime can also contain MCP clients to talk to external tools (databases, …). 5. 𝗖𝗵𝗲𝗰𝗸𝘀: when the LLM thinks it is done, the harness can run configured checks (aka hooks), for example run the test suite or type checker. If any of these checks fail, this information is passed to the LLM and it can try again. Only when the checks pass will the harness indicate success in the interface. The interface can be a terminal app (such as Claude Code), GUI app (e.g. Codex), etc. In principle an interface can use multiple harnesses and a harness can be used from multiple interfaces. So what is actually the LLM's job? To generate text! Nothing more. The LLM cannot actually do anything on your computer, it just generates text, some of which may trigger actions in the harness. This is the core loop of an agent: the LLM wants to call a tool, the harness executes it and passes the results back to the LLM. This means when you're switching between coding agents you're not just using a different LLM, but a different harness!