My AI Wishlist A developer's wishlist for AI tooling includes business logic verification that ties requirements back to source documents, AI systems capable of design thinking and subjective UX evaluation, and an AI-first programming language with static verification, memory safety, and short iteration loops, though these requirements often conflict. My AI Wishlist Compared to my post on AI coding milestones https://diverging.run/checkpoints/ai-coding-milestones/ , this is a bit more general on tooling + interfaces that might exist someday… I just wish they existed today. Business Logic Verification Many people are interested in formal verification, like TLA+, Lean, or Rocq. That’s great for proofs, cryptography, and llm training data, but not useful for most engineers. What I actually need, day-to-day, is verifying business logic. This is much harder because “business logic” is famously squishy. Even if you did translate all your business logic into Lean, few would be able to read it let alone debug it. In an ideal world, “tests” would look like business requirements that are evaluated regularly across code and perhaps proactively on metrics . You could imagine executive summaries expanded out to a laundry list of features that are meticulously validated by an agent. The trick here is to tie the requirements back to the source, like a PRD, Slack message, Google Doc, etc. Verifying business logic in a pseudo-interactive fashion would let builders know if they’ve regressed on a feature or assess if the tradeoff is worth it. Sadly, most would use this to build over-complicated products, since “maintaining growing complexity” would no longer be an acceptable excuse to pare down features. My hope is that a cacophony of messy, spaghetti products jolts us back to being designers again, letting simplicity shine. Design Thinking We certainly have AI doing real design work https://diverging.run/checkpoints/claude-design-is-real-design/ . But LLMs are not quite doing “design thinking”, made famous by IDEO and others. What’s special about “design thinking” is tying business problems to product development. In practice, this means UX and UI understanding. For a model to understand “UX”, that’d require predicting human behavior possibly tractable https://www.mantic.com/ . But today’s benchmarks on UI understanding are fact-based question/answer pairs https://mmmu-benchmark.github.io/ , not more subjective visual understanding on what makes one product well-designed vs. another. We do, in fact, have a process for making subjective “good design” legible. It happens during a weekly ritual, all around the world, called the “Design Crit”. Some researchers are trying to encode design thinking into AI workflows, either through model training https://contralabs.com/research/design-crit or an interface https://dl.acm.org/doi/10.1145/3800645.3812885 . It’s very nascent, but expect to see progress on this soon, given that data farms are beefing up in this domain https://work.mercor.com/explore?listingId=list AAABnJ0LvLdNuRT 1I9Iib8 . AI-first Programming Language If we had to design the perfect output from an AI agent - an “AI-first” programming language + runtime - what would it look like? What would the requirements be? Here my stab at it: - Static verification via algebraic types. - Strict memory safety, optional or incremental. - Runtime metrics like JVM, BEAM, etc. . - Readable, legible. Ruby, Elixir, Crystal are great examples. - Short iteration loops. - Sandboxing & security https://docs.deno.com/runtime/fundamentals/security/ built-in Of course, these requirements are in conflict with each other are algebraic types legible? , and to some extent this is just a hand-wavy, pipe dream wishlist programming language that anyone would love to use, with or without AI. a short detour... This a kernel of an idea - I may need to expand this in a later post One thing to consider is designing the right interface for this “AI-native” programming language perhaps before we design the language itself . Let’s take a basic, possibly flawed comparison between Ruby & Rust: python Ruby def average numbers return nil if numbers.empty? numbers.sum.fdiv numbers.length end Rust fn average numbers: & f64 - Option