Estimate work and scope decisions in the AI-coding era. Boil the Lake, AI compression ratios, three-layer search before building.
Install via CLI
openskills install 0xabrar/gstack-distilled---
name: estimate-and-scope
author: 0xabrar
description: Estimate work and scope decisions in the AI-coding era. Boil the Lake, AI compression ratios, three-layer search before building.
---
# Estimate and scope
How to size work and decide between approaches when AI compresses the cost of completeness.
Source: gstack `ETHOS.md`, `CLAUDE.md`, `ship/SKILL.md`.
## Boil the Lake
> "AI-assisted coding makes the marginal cost of completeness near-zero. When the complete implementation costs minutes more than the shortcut — do the complete thing. Every time."
Lake vs ocean:
- **Lake** = boilable. 100% test coverage for a module, full feature with all edge cases, every variant of a pattern.
- **Ocean** = not boilable. Multi-quarter platform migrations, full rewrites of legacy systems.
Boil lakes. Flag oceans as out of scope.
> "'Ship the shortcut' is legacy thinking from when human engineering time was the bottleneck."
## AI compression in estimates
Always quote both human-time and AI-assisted time:
| Type of work | Compression |
|---|---|
| Boilerplate | ~100x |
| Tests | ~50x |
| Feature | ~30x |
| Bugfix + regression | ~20x |
| Architecture | ~5x |
| Research | ~3x |
Phrase as: *"2 weeks human / ~1 hour AI-assisted."*
When evaluating "approach A (full, ~150 LOC) vs approach B (90%, ~80 LOC)" — almost always choose A.
### Anti-patterns in estimation
- *"Choose B — it covers 90% with less code."* (If A is 70 lines more, choose A.)
- *"Let's defer tests to a follow-up PR."* (Tests are the cheapest lake to boil.)
- *"This would take 2 weeks."* (Say: "2 weeks human / ~1 hour AI-assisted.")
## Search before building
> "The 1000x engineer's first instinct is 'has someone already solved this?' not 'let me design it from scratch.'"
### Three layers of knowledge
**Layer 1: Tried and true** — built-ins, official docs, well-established libraries.
> "The risk is not that you don't know — it's that you assume the obvious answer is right when occasionally it isn't."
**Layer 2: New and popular** — recent blog posts, trending patterns, popular libraries.
> "Humans are subject to mania. Mr. Market is either too fearful or too greedy. Search results are inputs to your thinking, not answers."
**Layer 3: First principles** — your own reasoning from fundamentals.
> "Prize them above everything else."
**Trust ranking:** Layer 3 > Layer 1 > Layer 2.
Most engineering culture says "don't reinvent the wheel" by default. This inverts that: *"Once in a while, questioning the tried-and-true is where brilliance occurs."*
### Search rubric
1. `{runtime} {thing} built-in`
2. `{thing} best practice {current year}`
3. Check official docs
### The eureka moment
> "The most valuable outcome of searching is not finding a solution to copy. It's finding a clear reason why the conventional approach is wrong... zig while others zag. When you find one, name it. Celebrate it. Build on it."
> "The truly superlative projects are full of these moments — 11 out of 10."
## Anti-patterns in scope decisions
- Rolling a custom solution when the runtime has a built-in
- Accepting blog posts uncritically in novel territory
- Picking the smaller-LOC option when the larger one covers more edge cases
- Deferring tests to a follow-up PR
- Quoting estimates in human-time without the AI-assisted equivalent
- Assuming Layer 2 (new and popular) is a strong signal because something is trending
## The completeness test
When you find yourself thinking "ship the 90% version":
1. How many lines is the gap between 90% and 100%?
2. What's the AI-assisted estimate to fill it?
3. Is this a lake or an ocean?
If it's a lake and the gap is hours not weeks → boil it.
No comments yet. Be the first to comment!