Embedded Files
Healthy engineering skepticism and what to do about it.
---
## Why 60–80% coverage is an unrealistic goal
Even within a "standard" IT infrastructure, the variability is enormous:
- **Git**: some use trunk-based, others GitFlow, others GitHub Flow — different commit rules (Conventional, Angular, custom), different branching rules, different CI hooks.
- **CI/CD**: GitHub Actions, GitLab CI, Jenkins, CircleCI, ArgoCD — different syntax and philosophy.
- **Testing**: Jest/Vitest/Pytest/Go test + different approaches (unit vs integration vs e2e), mocks, fixtures.
- **Code style**: ESLint/Prettier/Ruff/Black + custom company rules.
- **Workflows**: Jira/Linear/YouTrack/Clickup + custom workflows.
- **Documentation**: ADR, RFC, Confluence, Notion, README culture.
- **Security**: different approaches to secrets, PR reviews, compliance.
Each of these areas is **a separate skill with its own logic**. And within each — dozens more variations.
To cover 60–80% of genuinely recurring cases, you need to write:
- 10–20 foundational skills,
- each with 3–5 variants for common configurations,
- plus integrations between them (orchestration),
- plus setup documentation,
- plus tests for the agent itself.
This is **years of team work and 15–20 replicated integration projects**, not "a week for an MVP." And even that doesn't guarantee a ready-made solution for a class of businesses.
---
## Even the base framework will be thin
`agents.md` is a living document. As soon as the first real client requirement appears ("we have a monorepo with Turborepo, not Nx"), the framework is **no longer base** — it's already adapted.
This is the law of infrastructure products:
> A base framework is useful right up to the first real project. After that, it either dies or evolves.
---
## What's actually standardizable then
Only the **meta-level**, not the domain level:
### 1. Meta-structure of the agent
Not "how to commit to git," but "how an agent should define its work stage and load the needed skills."
### 2. Meta-skills (work stages)
- research
- task definition
- decomposition
- architecture
- implementation
- review
- refactoring
These skills **don't know about specific tools** — they're about a way of thinking. And even that varies between companies, which already creates a company-specific workflow.
### 3. Artifact format
What should look like:
- task definition,
- ADR,
- review,
- work plan.
The format is standardizable; the content is not.
### 4. Integration principles
Not "a script for Jira," but a **pattern**: "how an AI should work with an external tool via MCP":
- how to read a task,
- how to update status,
- how to handle errors,
- how to log.
---
## A realistic product model
### Model A: "Framework + methodology"
We don't sell ready-made skills, but rather:
- a **framework** (agents, meta-skills, structure),
- a **methodology** (how to write your own skills),
- **examples** (2–3 real cases),
- **consulting** (help with setup).
The client gets not a "ready-made agent," but an **instrument for building their own agent**.
This is honest and aligns with the engineering worldview.
### Model B: "Agent as a service"
We sell:
> "In 2–4 weeks we'll create an AI agent configured for your project, stack, and processes."
This is consulting, but with a clear deliverable: a configured `agents.md` + a set of skills + documentation + team training.
Here, skepticism about "ready-made packages" becomes an **advantage**: we don't sell what doesn't work — we do what's actually needed.
### Model C: "Evergreen agent"
The most interesting model in my view, but also the hardest, due to the need to set up a self-learning loop:
- the framework is shared,
- but the agent **evolves on its own** during project work:
- remembers decisions made,
- adds new skills as needed,
- updates `agents.md` automatically.
Then the "minimum viable product" is the **engine of such evolution**, not a ready-made set.
We prefer to periodically conduct AI efficiency audits at the client's request and adjust their instructions — as a more effective, manageable, and predictable solution.
---
## Why this is actually better for business
Skepticism is actually a **competitive advantage**:
1. Competitors will sell a "ready-made package for $49" and disappoint the client when they realize 80% needs to be customized.
2. We sell an honest picture: "base framework + your domain configuration." The client knows what to expect.
3. Long-term, this builds loyalty: clients who've actually configured an agent for themselves don't leave.
---
## Summary
**A ready-made skill package covering 60–80% of real tasks is a utopia** — at least at the current state of AI.
But that doesn't mean there's no product. It means the product isn't a ready-made package — it's in:
- a **framework** that gives you a start;
- a **methodology** that shows how to grow;
- a **customization process** that's sold as a service, or training the client to do it themselves.
This is engineering-honest and commercially viable.
---
Page updated
Google Sites
Report abuse