September 2026. Between code and outcome

The September issue of ArkTelos Lab did not settle around one package or fashionable technology. Across twelve articles, the same question kept returning: what does working code actually establish, and what remains the responsibility of the application, the team, or the person even after a library reports success?

There is no single answer repeated twelve times. Sometimes the boundary lies between screen state and a UI action; sometimes between an AI agent's proposal and permission to change data. In the experiments with get_it, cached data, JSON and dependency upgrades, the boundary only becomes visible after the ordinary path appears to work.

Here is the September contents. Each link opens the full article, including code, sources and the limits of what was tested.

AI and agents: a tool does not decide for the application

• Genkit Dart 0.16: when a tool result becomes part of the protocol — what changed in the Tool contract, and why the integration still owns its boundaries.
• AI proposed a change. What did the user actually approve? — approval of a displayed proposal cannot be carried over to a task that has since changed without checking it.
• Package skills in Dart: giving AI agents the context to use a library — instructions can travel with a package; whether the agent uses them and what happens to a locally edited copy are separate questions.
• The agent has read the instructions. How can it inspect a running Flutter app? — code analysis and observing the screen establish different things. An available MCP tool does not mean the agent used it.

Architecture: name the responsibility before choosing the mechanism

• Error, state, and effect: three different contracts in a Flutter application — why an operation result, rereadable screen state and a UI action should not be folded into one signal.
• The screen closed, but the operation did not: ownership of asynchronous work in Flutter — removing a route does not automatically cancel the underlying work or its late result.
• The error was caught. Who decides what happens next? — a global handler can aid diagnosis, but it cannot decide on behalf of a particular scenario whether to retry or what to show the user.
• Cached data is not necessarily current data. What should a repository report? — visible content, the age of its last confirmation and a failed refresh need not collapse into a single “loaded” state.

Lifetimes and upgrades: work does not end at the API call

• The user signed out. What is still alive in get_it? — a dependency scope can close while retained references and asynchronous initialization remain relevant.
• Upgrade a dependency or stay on the old version: what is the team actually deciding? — an intermediate flutter_secure_storage release does not guarantee that every device will pass through it.

People and performance: decide what is being improved

• JSON parsing moved to an isolate. Which problem did that solve? — the result may arrive later even as the screen stops stalling. Those are different optimization criteria.
• Beyond the screen: helping people understand and act — typography, accessibility, gesture alternatives and feedback require different kinds of checks; local AI does not replace those contracts.

These articles do not offer one universal architecture. They show where “it works” stops being sufficient evidence — and which question the code needs to answer next.

ArkTelos Lab · ArkTelos · Telegram EN · Telegram RU