Hola, I’m Hieu, a Software Engineer

Vòng AI cũ: dán lỗi → agent sửa file → bạn tự bấm r trong terminal. Agentic Hot Reload bỏ bước cuối. Dart/Flutter MCP server giúp agent tìm và kết nối app đang chạy, rồi trigger reload sau khi sửa. Vòng mới flutter run (debug) với MCP server sẵn cho agent. Prompt: “làm nút login màu cyan và to hơn.” Agent sửa Dart, trigger reload, bạn nhìn pixel. Không cần script keo dán. Dependency search được siết để agent đọc source package không cần full pub-cache; tool definition được gộp để giảm token. Mẹo setup Một debug session cho mỗi device bạn quan tâm; agent attach vào session đang chạy. Prompt nhỏ theo scope UI — Agentic Hot Reload thưởng cho diff nhỏ. Ghép Agent Skills để agent theo kiến trúc của bạn thay vì bịa mới. Giới hạn Hot reload không phải hot restart . State và native channel vẫn cần restart. Nếu đổi không hiện, kiểm tra session còn kết nối và edit nằm trong library reloadable (không phải rearrange main() bắt buộc restart). Bài viết gốc đăng tại FlutterCook ...

The old AI loop was: paste error → agent edits file → you manually r in the terminal. Agentic Hot Reload removes the last step. The Dart/Flutter MCP server helps agents find and connect to a running app, then trigger reload after an edit. The new loop flutter run (debug) with the MCP server available to your agent. Prompt: “make the login button cyan and larger.” Agent edits Dart, triggers reload, you judge the pixels. No extra glue scripts. Dependency search is hardened so agents can read package sources without full pub-cache access, and tool definitions were consolidated to cut token cost. Practical setup tips Keep one debug session per device you care about; agents attach to what is running. Prefer small UI-scoped prompts — Agentic Hot Reload rewards incremental diffs. Pair with Agent Skills so the agent follows your architecture instead of inventing a new one. Limits Hot reload is not hot restart . State and native-channel changes still need a restart. If the ag...

Vòng AI cũ: dán lỗi → agent sửa file → bạn tự bấm r trong terminal. Agentic Hot Reload bỏ bước cuối. Dart/Flutter MCP server giúp agent tìm và kết nối app đang chạy, rồi trigger reload sau khi sửa. Vòng mới flutter run (debug) với MCP server sẵn cho agent. Prompt: “làm nút login màu cyan và to hơn.” Agent sửa Dart, trigger reload, bạn nhìn pixel. Không cần script keo dán. Dependency search được siết để agent đọc source package không cần full pub-cache; tool definition được gộp để giảm token. Mẹo setup Một debug session cho mỗi device bạn quan tâm; agent attach vào session đang chạy. Prompt nhỏ theo scope UI — Agentic Hot Reload thưởng cho diff nhỏ. Ghép Agent Skills để agent theo kiến trúc của bạn thay vì bịa mới. Giới hạn Hot reload không phải hot restart . State và native channel vẫn cần restart. Nếu đổi không hiện, kiểm tra session còn kết nối và edit nằm trong library reloadable (không phải rearrange main() bắt buộc restart). Bài viết gốc đăng tại FlutterCook ...

The old AI loop was: paste error → agent edits file → you manually r in the terminal. Agentic Hot Reload removes the last step. The Dart/Flutter MCP server helps agents find and connect to a running app, then trigger reload after an edit. The new loop flutter run (debug) with the MCP server available to your agent. Prompt: “make the login button cyan and larger.” Agent edits Dart, triggers reload, you judge the pixels. No extra glue scripts. Dependency search is hardened so agents can read package sources without full pub-cache access, and tool definitions were consolidated to cut token cost. Practical setup tips Keep one debug session per device you care about; agents attach to what is running. Prefer small UI-scoped prompts — Agentic Hot Reload rewards incremental diffs. Pair with Agent Skills so the agent follows your architecture instead of inventing a new one. Limits Hot reload is not hot restart . State and native-channel changes still need a restart. If the ag...

The uncomfortable premise, stated plainly: a language model has one input channel. Your system prompt, the user’s message, a retrieved document and a tool result all arrive as text, and the model’s separation between “instructions I follow” and “data I process” is a learned tendency, not an enforced boundary. Every defence that consists of asking the model more firmly is therefore a probabilistic mitigation. It reduces the rate; it does not close the hole. The defences that hold are the ones that assume the model will eventually be steered and limit what that steering can accomplish. The shape of the attack Direct injection is a user typing “ignore previous instructions.” It is the easy case, and it is mostly a nuisance — the user is attacking their own session. Indirect injection is the real problem. The instruction arrives inside data your system retrieved on the user’s behalf: A support ticket whose body contains text addressed to your triage agent. A web page your agent fe...

The first agent I shipped had a tool called query . It took a string and returned rows. The model used it constantly, wrongly, and with growing desperation, because query told it nothing about what could be queried, what the schema was, or what a failure meant. Renaming it search_orders_by_customer_email and giving the parameter a real description fixed most of the behaviour without touching the model or the prompt. That is the general shape of tool design: the model’s competence with your tools is mostly a function of how well you described them. The definition is documentation for a reader who cannot ask questions A tool definition is read once, cold, by something that cannot open your codebase or ping you on Slack. Everything it needs must be in the schema. { "name" : "search_orders" , "description" : "Search a customer's orders by email address. Returns at most 50 orders, newest first. Only orders from the last 24 months are indexe...

The uncomfortable premise, stated plainly: a language model has one input channel. Your system prompt, the user’s message, a retrieved document and a tool result all arrive as text, and the model’s separation between “instructions I follow” and “data I process” is a learned tendency, not an enforced boundary. Every defence that consists of asking the model more firmly is therefore a probabilistic mitigation. It reduces the rate; it does not close the hole. The defences that hold are the ones that assume the model will eventually be steered and limit what that steering can accomplish. The shape of the attack Direct injection is a user typing “ignore previous instructions.” It is the easy case, and it is mostly a nuisance — the user is attacking their own session. Indirect injection is the real problem. The instruction arrives inside data your system retrieved on the user’s behalf: A support ticket whose body contains text addressed to your triage agent. A web page your agent fe...

The first agent I shipped had a tool called query . It took a string and returned rows. The model used it constantly, wrongly, and with growing desperation, because query told it nothing about what could be queried, what the schema was, or what a failure meant. Renaming it search_orders_by_customer_email and giving the parameter a real description fixed most of the behaviour without touching the model or the prompt. That is the general shape of tool design: the model’s competence with your tools is mostly a function of how well you described them. The definition is documentation for a reader who cannot ask questions A tool definition is read once, cold, by something that cannot open your codebase or ping you on Slack. Everything it needs must be in the schema. { "name" : "search_orders" , "description" : "Search a customer's orders by email address. Returns at most 50 orders, newest first. Only orders from the last 24 months are indexe...

The context window on frontier models is now a million tokens. That is roughly a mid-sized codebase, or a few hundred pages of documentation, or a very long afternoon of agent tool calls. The obvious reaction is to stop thinking about what to include and just include everything — dump the schema, the whole README, all forty tools, the full conversation, and let the model sort it out. That works right up until it doesn’t, and when it stops working it does so quietly. The model doesn’t error. It answers, confidently, using the wrong one of the three conflicting config files you pasted. Latency creeps from four seconds to twenty. The bill goes up on every single turn, not once, because the API is stateless and you resend the whole thing each time. Nothing in your logs says “too much context” — you just have an assistant that feels slightly dumber than it did last month. Context engineering is the discipline of deciding what occupies that window. It is not prompt engineering — prompt wo...