Blog de Joe Freeman

In freemansoft/Flutter-AdaptiveCards a demonstration Dart chat server hands a question to a local Ollama model, asks for the answer as Adaptive Card JSON, and a Flutter client app renders the reply. Everything below is an attempt to make that card generation more reliable and more faithful to what was asked. The figures are transcribed from ModelBehavior.md , a lab notebook in that repository. Giving the explanation a place in the card worked; banning prose did not qwen2.5-coder:7b  answered a request to explain a snippet of code with a valid Adaptive Card, then appended the explanation after it. A reply is either a card or prose, with nothing in between: the client renders a card only when the entire reply is one, so appending the explanation demoted the whole thing to text and the user saw raw JSON. The obvious repair was to tell the model harder not to write anything after the card. That did not work. It scored the same and stopped producing cards at all,...

freemansoft/Flutter-AdaptiveCards is a Flutter renderer for Adaptive Cards. The project includes a demonstration Flutter chat client and Dart chat server. Enter a question in the client. It goes to the Dart server, which asks a local model running on Ollama to answer in Adaptive Card JSON. The server decides whether the reply is a card or ordinary text and forwards the card body; the client renders it as a server-driven UI (SDUI) whose payload was generated by a language model rather than by a backend programmatic service. It is a demo architecture and not a production one. A production system would more likely use the model for intent detection, which would then be mapped to an API call that returns structured domain data, with a deterministic mapping layer turning that into a card. The demo is thin without any real application tier, instead relying on the model for JSON card creation. The model's reply is the UI, not text about it Adaptive card generati...

The overhead that made teams skip internationalization and accessibility is exactly the kind of work coding agents do best. Here is how we set ours up to carry it. Localization and accessibility have been the features teams “get to later” and never do, not out of malice, but out of friction. Localizing strings means tracking and extracting every label and every string. Every change means touching every language file, keeping them in parity, finding an authentic translation, and regenerating bindings. Accessibility means writing labels that no sighted reviewer will ever see, for a screen reader that no one on the team uses. Both are tedious, both are invisible in a demo, and both are the easiest thing on the board to defer under deadline. So they get deferred. Forever. Coding agents change that. The exact qualities that made these tasks skippable — mechanical, repetitive, rule-bound, easy to sp...

Documentation rots because updating it is manual, tedious, and easy to skip. An agent removes the first two problems — it will happily update every page that names a symbol it just renamed. It does nothing about the third. Nobody, human or machine, updates documentation they were never asked to update. So ask. Every change, automatically, as part of the review you already run. This is the mechanical companion to a longer argument I made about design-time and run-time documentation . You do not need to have read it. You need three things: a way to tell which documents are supposed to be true, a rule that fires when they stop being true, and somewhere to write that rule down where the agent will actually read it. 1. Only some documents owe the code the truth Rename a class and grep your docs for the old name. You will get hits in two very different kinds of documentation files. Your reference and how-to pages describe the library as it stands. They are ...

You Have No Excuse for Undocumented Code. Every engineer knows the three excuses, because every engineer has used them. Documentation is too expensive. Writing it well takes hours that could go into features, and it is never the thing that ships. Nobody reads it anyway. You spend a day on a beautiful design doc, and it goes to the wiki to die. Nobody opens it again. Ever. Documentation rots. You write it, the code moves, and within two quarters, the docs are lying to people. A wrong document is worse than no document. All three were true. This was not laziness but a rational response to a real cost-benefit problem. The math did not work. The math has flipped because of LLMs. Documentation stopped being a message from engineers to engineers and became the substrate that the machines building your software run on . LLMs are voracious consumers of documentation — and, it turns out, tireless producers of it. All three excuses are now dead, and here is the sh...