The Lowest-Risk Way to Bring AI Into Your Company: The 2025 Surton AI Readiness Playbook
Before automation and coding agents, build the context layer AI needs: documentation, guidance files, tests, and read-only diagnosis workflows. Includes Surton's 30-day AI readiness sprint.
Most companies start their AI plans in the wrong place.
They jump straight to autonomous coding, workflow automation, or agent-driven execution. Those can be valuable later, but they are rarely the safest first move. If your company knowledge is scattered across Slack, stale docs, and a few senior people’s heads, every AI system starts weak.
At Surton, the lowest-risk AI starting point is almost always the same: make the company legible. Document the business, the codebase, and the operating rules well enough that both people and AI can understand how work actually happens.
Quick Take
The safest way to start with AI is not autonomous coding. It is documentation and read-only diagnosis. Pick one team and one bounded system. Use AI to map the codebase, identify missing docs, explain risky areas, and draft guidance. Add AGENTS.md files so agents know conventions, docs, test commands, and systems they should avoid. Build tests around high-risk behavior before allowing code changes. Only expand to agent-written code after docs, tests, and review practices are in place.
Why documentation is AI infrastructure
Documentation is not just an internal knowledge asset. In an AI-enabled company, documentation becomes infrastructure.
It tells agents:
- what the system is supposed to do
- which files matter
- what conventions the team follows
- where risk lives
- how to test changes
- what assumptions are known
- what not to touch without approval
Without that context, agents infer. Inference can be useful in low-risk areas. It is unacceptable around payment systems, auth flows, data migrations, or customer-facing workflows.
The 30-day AI readiness sprint
Week 1: Pick the pilot area
Do not start company-wide.
Pick:
- one small team
- one repository or subsystem
- one clear goal
- one leader accountable for review
Good pilot candidates:
- important but not existential systems
- code with some tests already
- areas people find confusing
- workflows with documentation gaps
Bad pilot candidates:
- auth
- billing
- data migrations
- compliance-critical systems
- anything with no tests and high customer impact
Week 2: Audit the context layer
Review:
| Artifact | Exists? | Current? | Useful? |
|---|---|---|---|
| README | |||
| Architecture overview | |||
| Local setup guide | |||
| Test instructions | |||
| Deployment process | |||
| Known risky areas | |||
| Ownership map | |||
| Incident/runbook docs |
The goal is not perfect documentation. The goal is enough context to reduce guessing.
Week 3: Use AI for read-only mapping
Before agents edit anything, have them explain.
Useful prompts:
Read this repository and explain:
1. what the system does
2. the main entry points
3. the key data flows
4. the riskiest parts of the codebase
5. where documentation is missing
6. what tests exist and what they cover
Do not modify files. Produce a system map for a new engineer.
Then validate the output with senior engineers. The corrections become documentation.
Week 4: Add guidance and tests
Create an AGENTS.md file:
# Agent Guidance
## Project overview
[What this system does]
## Important docs
- Architecture: docs/architecture.md
- Local setup: docs/setup.md
- Tests: docs/testing.md
## Conventions
- Use TypeScript strict mode
- Add tests for behavior changes
- Follow existing service patterns
## High-risk areas
- Do not modify billing without approval
- Do not modify auth flows without approval
- Data migrations require human review
## Commands
- npm test
- npm run build
- npm run lint
## Review expectations
Before changing code, summarize plan and files to modify.
Then add or improve tests around the pilot area. Agents need a safety net.
The maturity ladder
Use this ladder to expand AI safely.
| Level | AI usage | Requirement |
|---|---|---|
| 1 | Read-only explanation | Repo access and human review |
| 2 | Documentation drafting | Senior engineer validates |
| 3 | Test generation | Tests reviewed and run |
| 4 | Low-risk code changes | Docs + tests + human PR review |
| 5 | Multi-file changes | Strong test suite and rollback path |
| 6 | Autonomous loops | Mature observability, tests, and review gates |
Most companies should spend 30-60 days at levels 1-3 before moving aggressively into levels 4-6.
What leaders should do first
Leaders should use the tools themselves.
That signals:
- this is a working practice, not a mandate
- leadership is learning too
- AI usage is not a secret side experiment
- review and judgment still matter
A useful executive exercise:
- Pick an internal process you barely understand
- Give AI the docs and artifacts
- Ask it to explain the workflow
- Note where it guesses or gets confused
- Fix those docs
This teaches the organization something important: AI exposes documentation gaps faster than humans do.
How to avoid unsafe AI adoption
Do not:
- give agents broad write access on day one
- let AI modify code without tests
- use AI output without review
- skip architecture context
- treat prompt libraries as a substitute for system documentation
- assume enthusiasm equals readiness
Do:
- start read-only
- document first
- test behavior
- set guidance files
- review every change
- expand scope gradually
The business case
This work pays off even if AI adoption slows down.
Benefits:
- faster onboarding
- less dependency on senior memory
- safer code changes
- better incident response
- cleaner architecture discussions
- more useful AI agents later
In other words: AI readiness work is also operational maturity work.
When Surton can help
Surton helps companies build the context layer required for practical AI adoption.
We can help with:
- repository and workflow audits
- documentation systems
- AGENTS.md guidance files
- test coverage strategy
- safe coding-agent pilots
- AI readiness scoring
See Surton’s AI implementation services if you want to start with AI without creating unnecessary production risk.
Related resources
- The Non-Technical Leader’s Guide to Claude Code — non-technical workflows
- The 3-Tool Rotation for AI Engineering — engineering tool roles
- The Lowest-Risk Way to Start Using AI (Original) — The Blueprint edition
This is Surton’s definitive 2025 AI readiness playbook. For the original newsletter version, see The Blueprint.
Frequently asked questions
What is the lowest-risk way to start using AI at work?
Start with documentation and read-only diagnosis. Have AI inspect systems, summarize workflows, identify missing documentation, and explain unfamiliar code before letting it change production workflows. This creates value immediately while building the context layer that safer automation depends on.
Why should documentation come before AI automation?
AI tools are only as useful as the context they can access. If your company knowledge is stale, fragmented, or trapped in people's heads, agents will guess. Good documentation helps humans today and gives AI accurate architecture, rules, edge cases, and operating context tomorrow.
What should an AI readiness pilot include?
A good pilot includes one small team, one bounded system, a documentation audit, AI-assisted system mapping, guidance files like AGENTS.md, meaningful tests around risky areas, and read-only diagnosis workflows. Avoid autonomous code changes until the context and test safety net exist.
What is AGENTS.md and why does it matter?
AGENTS.md is a guidance file for coding agents. It tells AI where docs live, what conventions to follow, what systems are risky, how to run tests, and what not to touch without approval. It reduces guessing and gives agents team-specific operating instructions.
When should we let AI agents modify code?
Only after three conditions are met: relevant docs exist, tests cover the expected behavior, and the agent has successfully performed read-only diagnosis on that area. Start with low-risk changes, require human review, and expand scope gradually as confidence grows.
How do we measure AI readiness?
Track documentation coverage, test coverage in risky systems, agent task success rate, human review findings, onboarding time, and time to diagnose incidents. AI readiness improves when humans and agents can both understand the system faster and make fewer unsupported guesses.
Keep reading
More field notes on applying AI, leading teams, and building durable companies.
AI Doesn’t Modernize a Codebase. Systems Do.
Legacy software doesn’t become AI-enabled through ad hoc tool use. It changes when teams redesign how work enters, moves through, and improves the engineering system.
The Overlooked Leverage Inside Software Companies
Internal tools rarely feel urgent, but they often deliver the fastest return in a growing software business.
The 3-Step Framework to Understand a Codebase Before You Build
A practical three-step workflow for turning unfamiliar code into shared understanding before AI accelerates the wrong work.