AI
The Real AI Threat Isn’t Sci-fi (It’s So Much Worse)
- I appreciate that Dave reads the comments and takes a pragmatic approach. Engineering content is worth creating, yet we cannot ignore the elephant in the room.
- “The impact of the changes that have already taken place are enough to completely change our relationship with software, and more generally, information. … I am convinced that this change will impact the world more than the Internet or the World Wide Web did for good or ill, so dismissing this as only commercial hype or as some kind of market-driven over-hyped bubble — while probably true — may also risk missing the importance of the broader societal impact.”
- Our societies were built on the idea of intelligence being a scarce, expensive thing.
- In 2023 several AI experts and CEOs (The Center for AI Safety) expressed concerns about mitigating the risk of extinction from AI. It’s not a prediction; it’s a statement of concern. If the people with commercial reason to be optimistic about this technology are asking for regulation, that says something.
- “You don’t need a machine to be conscious or awake or evil for software to hurt people at enormous scale.”
- Capability + autonomy + carelessness raises concerns.
- “You don’t really care whether a heat-seeking missile is conscious or not; you care that it’s coming toward you. Whether the software understands what it’s doing is a philosophy seminar question. Whether it can do damage is an engineering question.”
- Up until now, engineers could explain how systems worked. Because LLMs are non-deterministic they are not fully explainable. “If I can’t specify a system’s behavior, I can’t properly test it. … If I can’t predict it’s behavior, I can’t give you any guarantee about what it will or won’t do.”
- “We already know how poorly understood non-deterministic components can be — and now we’re busy building them on purpose and calling it progress.”
- Open models tend to trail the frontier models by a few months, so things like Mythos that only exist in a few well-resourced labs could be on its way to anyone who wants it very soon.
- I agree with Dave that banning research is unenforceable, and that eliminating risk is unlikely. Move the risk to where we can better manage it. Engineering discipline is the safety (testing, feedback, safety culture, accountability, black boxes, incident reviews). The people writing the rules don’t understand these technologies; it’s not a dig, it’s a description.
- “Part of our job as technical people must be to help keep people like this better informed of the consequences of their choices right now.”
New Skills! v1.2 brings /wait-what, /writing-for-agents, and fixes /grill-me
- There’s now documentation for using the skills system: https://www.aihero.dev/skills
- The collection is in the Claude Code Marketplace.
- /wait-what tells the agent to clarify things in Simplified Technical English (ASD-STE100) and your ubiquitous language
- /grill-me now uses question rounds instead of one at a time
- /writing-for-agents helps you write content used in agent definitions
- /wizard generates a Bash wizard-style UI to walk a human through steps only they can perform
- /to-questionnaire take the questions answered during a grilling session so that you can walk someone else through them
- (This is a presentation given by one of my work colleagues; we were both AI coaches at the same client.)
- Topics
- Model choice, token efficiency
- Skills (instead of prompts or agents) because they’re more modular, maintainable, and shareable
- Frameworks (e.g., Spec Kit) only work if everyone on the team uses them
- Custom status lines for CLI
- Parallel work with Git worktrees
- Get Copilot to look at docs to make new skills (rather than downloading another tool), Matt Pocock’s skills, Context7 for docs likely not in the LLM training data, Playwright MCP, Copilot CLI
- CLI goodies (/ask an unrelated question, /rubberduck to review work with a different model, /chronicle to get spending optimizations, /tips to learn how to use it better, /improve to learn how to make instructions better, /fleet to do work in parallel, /research for deep research, /share to export sessions for sharing)
- Workflow: plan the work, give Copilot a way to do the work (run tests, use browser, access resources, commands to accomplish sub-tasks), try to work from the terminal (because that’s what Copilot does), give it a way to check its work, give it guardrails (must build, tests must pass), look for ways to prevent it from making the same mistakes, review and revise its work (work in small chunks and review every line)
Software engineering
Build Async Messaging in .NET with Azure Service Bus
- Azure Service Bus supports both queues and topics. Queues are for point-to-point, and topics are for multi-subscriber scenarios (one-to-many).
- Create one namespace per environment (dev, prod).
- Namespaces can have both queues and topics.
- You can create access policies (manage, send, listen). These give you connection strings.
- When you create topics, you’ll need at least one subscription to listen to the topic. (Subscribers only see messages put on the topic once they subscribe.)
- Subscriptions are virtual queues (https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions).
- Topics and subscriptions let you put filters in place; queues do not.
Systems thinking
The first 50 pages of this book are outstanding by covering the nine core concepts: interconnectedness, feedback loops, stocks and flows, delays, nonlinearity, emergence, boundaries, perspectives, and leverage points. The remainder of the book is dedicated to workshop-style activities to help people think in systems. In my opinion these range from excellent to ice breakers. Many are missing key details to make them truly useful to practitioners. Many of the “virtual” options seem to be poorly considered. 5/5 for being thorough and well-referenced; 3/5 overall for applicability and usefulness.