Dike Homme

How a Head of Legal Built AI Agents Without Writing a Single Line of Code

작성자

Dike Homme

카테고리:

Key Takeaway

You don’t need to be a developer to build AI agents that actually work. The real skill isn’t coding — it’s knowing your own work well enough to document it. This is a practical account of how a head of legal with zero engineering background created AI-powered workflows for legal review, content management, and tool development using nothing but structured documentation.

The Problem: Every Conversation Starts From Zero

AI chatbots are impressive in a single session. Ask a sharp question, get a sharp answer. But try to use AI for recurring work — weekly reports, contract reviews, content pipelines — and you hit a wall fast.

Every new session, the AI forgets everything. Your rules, your preferences, your domain knowledge — gone. You end up repeating the same instructions over and over, and the output quality fluctuates wildly between sessions.

This isn’t a minor inconvenience. According to TechRT’s 2025 research on prompt engineering, structured prompting reduces AI output errors by up to 76% compared to ad-hoc queries (TechRT, 2025). The gap between “chatting with AI” and “systematically directing AI” is enormous.

The Solution: Documentation as Code

Instead of learning Python or JavaScript, I wrote what I call AI Operations Manuals — markdown files that function as persistent instructions for AI agents. Each project gets its own manual containing:

  • Project context and goals: What the AI needs to know before starting any task
  • Rules and constraints: What’s allowed, what’s prohibited, what requires human approval
  • Workflow sequences: Step-by-step task order with verification checkpoints
  • Human intervention points: Where the AI must stop and wait for review

Think of it as an employee onboarding document — except the employee is an AI that reads the entire manual in milliseconds and follows it precisely every session.

The result? Repetitive explanations disappeared. Output consistency improved dramatically. And the system scaled: once a manual worked for one project, adapting it for another took hours, not weeks.

Why Non-Developers May Actually Have an Advantage

This might sound counterintuitive, but domain experts often build better AI agent systems than engineers — at least for their own workflows.

The global AI agents market reached $7.63 billion in 2025 and is projected to hit $10.91 billion in 2026, growing at a 45.8% CAGR (MarketsandMarkets, 2025). Yet only 5% of enterprise AI pilots reach production. Teams using external low-code approaches doubled their success rates compared to internal engineering builds (MIT/Vellum Analysis, 2025).

Why? Because the bottleneck was never the code. It was domain knowledge translation. Engineers build technically sound systems that don’t understand the actual work. Domain experts who can articulate their workflows clearly give AI exactly what it needs — context, rules, and judgment criteria.

Case Study 1: Legal Review (High-Stakes AI)

Legal work is where AI hallucination risk is most dangerous. Stanford HAI research found that AI models hallucinate in 1 out of 6 or more legal benchmarking queries (Stanford HAI, “AI on Trial,” 2024). A deeper study on the same topic revealed hallucination rates of 69–88% on specific legal tasks, with models fabricating case citations at least 75% of the time when asked about a court’s core holding (Stanford HAI, “Hallucinating Law,” 2024). Damien Charlotin’s database has documented over 1,200 court cases involving AI-generated hallucinations globally.

My solution wasn’t to avoid AI in legal work. It was to build guardrails into the operations manual:

Rule 1 — No Unverified Claims: Any information the AI cannot confirm from primary sources must be tagged as [unverified] or [estimated]. The AI is explicitly prohibited from presenting uncertain information as fact.

Rule 2 — Mandatory Source Citation: Every legal reference requires a statute number, case citation, or official document ID. No exceptions.

Rule 3 — Self-Verification Loop: After the AI produces an analysis, a separate verification step challenges its own conclusions, looking for logical gaps and factual errors.

This three-layer approach doesn’t eliminate hallucination risk — nothing does. But it makes hallucinations visible instead of hidden, which is the critical difference between a dangerous tool and a useful one.

Case Study 2: Content Pipeline (Platform-Specific Strategy)

Running a blog sounds simple until you try to maintain consistent quality across platforms with different audiences and algorithms.

My system manages two platforms simultaneously:

WordPress (AI-Optimized): Structured headings, statistical citations, external sources, and comprehensive guides. This format is designed for visibility in AI-powered search engines. Research from Princeton, Georgia Tech, and IIT Delhi on Generative Engine Optimization (GEO) shows that content with verifiable statistics and explicit source citations improves visibility in generative search results by 30-40%.

Secondary Blog (Human-Optimized): Experience-driven narratives, casual tone, photo-heavy format. Same topic, completely different angle — not a shortened version, but a perspective shift.

The critical design element: AI uploads content as draft only. A human reviews, adds images, and makes the final publish decision. This approval gate is non-negotiable. It’s the single most important safeguard against AI errors reaching readers.

Case Study 3: Tool Development (Yes, Without Coding)

The biggest accuracy problem in legal AI isn’t the model — it’s the training data. AI relies on what it learned during training, which may be outdated or incomplete for rapidly changing legal codes.

I built integration tools (MCP servers) that connect AI directly to live legal databases — the Korean National Law Information Center and Supreme Court case archives. Instead of relying on memorized statutes, the AI queries current databases in real-time.

How is this possible without coding? By clearly defining what’s needed — input format, expected output, error handling rules — and letting AI handle the actual code generation and debugging. The 78% enterprise AI adoption rate in 2025 (PwC AI Jobs Barometer, 2025) reflects a market where the ability to specify what AI should do matters more than the ability to code it yourself.

Three Principles for Non-Developers Building AI Agents

1. Document your work before you automate it. The foundation of an AI agent isn’t code — it’s a structured description of how work actually gets done. If you can write a detailed onboarding guide for a new hire, you can build an AI agent.

2. Draw clear lines between AI territory and human territory. Not every task should be delegated to AI. Define exactly where AI operates autonomously and where it must stop for human approval. The approval gate isn’t a limitation — it’s what makes the system trustworthy.

3. Scale incrementally. Start with one workflow. Prove it works. Then adapt the pattern to the next project. The no-code AI platform market grew from $4.28 billion in 2024 to $5.35 billion in 2025 (Grand View Research, 2025) — the tools are ready. What’s missing is domain experts willing to take the first step.

The Bottom Line

The question isn’t “which AI tool should I use?” It’s “do I understand my own work well enough to hand it off?”

Automation doesn’t start with technology. It starts with clarity — about what you do, why you do it, and which parts a machine can handle. If you can write that down in a structured document, you’ve already built the blueprint for your first AI agent.

The developers will catch up on domain knowledge eventually. But right now, the fastest path to a working AI system isn’t learning to code. It’s learning to document.

References

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

더 많은 게시물