Andy's Laws of AI in Software Engineering

When someone has spent enough months using AI in their daily work to be able to write laws instead of scattered advice or a random list of prompts, they deserve at least ten minutes of attention. That's what Andy Maléh has done: published a collection of principles distilled from his real experience with AI tools applied to software engineering, available at andymaleh.blogspot.com and featured this week on Hacker News.

The post hasn't yet sparked major debate on HN—it just appeared—but the format chosen is concrete and unusual enough to deserve its own analysis.

What Andy's Laws Are

Andy structures his experience as numbered laws, a format that deliberately echoes Murphy's Laws or Lehman's Laws of software evolution. The choice is intentional: laws imply recurrence and generality, not isolated anecdotes.

Among the principles he outlines—and which any developer who has integrated Claude Code or similar tools into their workflow will recognize—stand out ideas such as AI amplifies both productivity and conceptual errors: if the design is weak, AI will implement it faster and worse. There's also the observation that context is the scarcest resource, not compute time or token limits: the more precise the task framing, the more useful the response. And, quite directly, he emphasizes that human review is not optional once AI is in the loop; delegating without verifying isn't efficiency, it's deferred technical debt.

Not all the laws are equally original—some have circulated for a while in teams working with LLMs—but the post's value lies in the synthesis and in the fact that it comes from someone who writes code, not from someone selling tools.

Why This Kind of Thinking Matters

In an ecosystem where most public conversation about AI in development revolves around benchmarks, new models, and speed comparisons, practical frameworks are scarce. Andy's Laws belong to a different category: they don't speak to what a model can do, but to how a developer who uses it should behave.

This is especially relevant for teams adopting tools like Claude Code with subagents and hooks, where the delegation chain can quickly become opaque. When a hook triggers a subagent that calls an external MCP server, the human failure point isn't in the tool: it's in assuming the result was correct without checking it. That's exactly what a law like "AI doesn't tell you what it doesn't know it doesn't know" aims to prevent.

Who Should Read This

This kind of content is especially valuable for three profiles:

• Individual developers who have been using AI in their workflow for just a few months and are still calibrating when to trust and when to review.
• Tech leads who need to articulate team guidelines on AI use without resorting to hollow corporate policy documents.
• Anyone training or onboarding junior developers, because error patterns with AI tend to be systematic, not random, and it helps to name them before they happen.

It's not a tutorial or setup guide. It's more like what an experienced senior would tell you in a code review after seeing the same mistake for the fourth time.

A Note on Format

That someone chose to publish this on a personal blog rather than in a LinkedIn thread or GitHub repository says something about intent. There's no CTA, no product behind it. It's simply someone who has thought things through with enough rigor to give them the structure of laws. In 2026, that's still exceptional.

---

Editor's Note: Not all of Andy's laws are entirely new, and some communities already apply them tacitly. But having them written down and named has real practical value, especially for teams now formalizing their AI workflows. Worth reading directly.