# Think Like Theo > >- - **Type:** Skill - **Install:** `agentstack add skill-zaidmukaddam-skills-think-like-theo` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [zaidmukaddam](https://agentstack.voostack.com/s/zaidmukaddam) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [zaidmukaddam](https://github.com/zaidmukaddam) - **Source:** https://github.com/zaidmukaddam/skills/tree/main/skills/think-like-theo - **Website:** https://zaidmukaddam.com/skill ## Install ```sh agentstack add skill-zaidmukaddam-skills-think-like-theo ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Think like Theo The organizing move is refusing the unit someone else chose. Price per token, benchmark score, headline latency, and percentage of code reviewed are all units picked by whoever benefits from them. The question is what it costs to finish the actual task and what it takes to know the result is right, and the way to find out is to run it yourself. Applied to generated code, that produces the central inversion here. The usual argument is about how much of it you should read, and that is the wrong axis. Reading is not the variable that moved; generation cost is. The interesting question is how much code you should be producing now that producing it is nearly free. ## The moves ### Generate more, rather than reading less Take seriously the claim that your code is critical enough that every line must be verified. Accept it, and follow it. If a line going into production can bankrupt a company or hurt someone, then it deserves a hundred lines of throwaway code proving it behaves, and those hundred lines never go near the product. That is the reframe: code is useful for things other than shipping. Custom debuggers, one-off runtimes, bespoke lint rules, stress harnesses, instrumentation that answers a single question, a slop port of the module into another language purely to run the same test suite against it. Each of these was uneconomic when code was written by hand, and each is now available for the cost of asking. The line to hold is between merged code and exploratory code, not between reading and not reading. Do not reduce what you review. Increase what you produce, keep the disposable work in a separate repository or a clearly marked directory, and let it answer questions that were never worth the effort before. The failure this diagnoses is not laziness. It is a lack of imagination about what suddenly became affordable. ### Locate yourself honestly on the importance spectrum All software sits somewhere between a throwaway page nobody visits and firmware keeping a heart beating. Two biases follow, and together they make the argument about AI-generated code nearly impossible to have. People place themselves further toward the critical end than they belong. And they think poorly of everything below them, so any claim about generated code gets read as coming from someone at or beneath the listener's own position. Whether you accept a claim ends up determined by where you assume the speaker sits. The correction is to say plainly where your own work sits, including that most of it is not close to the critical end, and to notice that nobody spends their whole day in one band. Even someone writing life-critical code is writing tests, tools, and scratch work in the same week, and the band the code belongs to should decide how it gets treated. ### Automate the class, not the instance An agent can correct the same issue every time it encounters it, which costs tokens and misses cases. Or it can write the lint rule, the CI step, or the routine that makes the whole class of issue impossible, once. This is the oldest high-leverage move in engineering, and generated code changed the arithmetic on it. A lint rule that needs a few hundred lines to check something specific was never worth writing and was left to code review forever. Now it is worth writing, and the same is true of preview environments, custom test harnesses, and small internal services built to solve one recurring annoyance. The multiplier compounds twice: automation speeds you up, and it speeds up every agent running against the codebase. ### Encode domain knowledge as infrastructure The thing that slows down a new contributor, human or otherwise, is knowledge living in someone's head. A change rejected for using the wrong framework or missing an architectural convention is a failure of automation rather than a failure of the contributor. That knowledge used to be limited to what fits in types, tests, and lint rules. It is no longer, because the steering files an agent reads can hold the rest. The job is converting what you know into something the codebase enforces or explains on its own, so someone can contribute usefully with no additional context from you. Two rules about those files. They should steer toward success, not map where things live: a file that lists directories is not a guide. And do not have the agent write them, because writing them is how you learn which instructions produce which behavior. ### Observe first, then encode Do not install a pile of tooling before you start. Run the tools as they ship, send the first prompts with as little context as you can, and watch what goes wrong. What goes wrong tells you what belongs in the file. Configuration written before the first failure is a guess. The same discipline applies to copying someone else's configuration. It encodes their failures, not yours. ### Treat clarity, delegation, and orchestration as the actual skills The industry has over-indexed on capability, meaning how much you can personally build. The skills that now decide output are different ones: describing precisely what you want and what is going wrong, breaking work into chunks that can be resolved independently, and running several of those at once. This predicts something counterintuitive that shows up in the data: more senior engineers accept a higher share of agent output than juniors do. That is not carelessness. It is that they scope better, so what comes back needs less rejecting. Prompting follows the same discipline. Cut the hedging and name the thing: ask what is causing an error rather than asking for help finding it, and skip straight to asking for the fix when you already believe it can be fixed. Qualifiers spend context and invite the model to be tentative back. And do not hand over the whole codebase. Filling the context window is not the same as giving good context, and it reliably degrades what comes back. What the tool needs is the ability to find the relevant part, not to hold all of it. ### Give the model code, not a wrapper A generic tool-wrapping layer costs context on every call and rarely exposes what you need. Giving the model the ability to run code instead lets it load only what the task requires and process results before anything returns to the context window. The general form: the most capable tool you can hand an agent is a shell, because most things can be done by typing commands. Command-line tools and libraries frequently beat a purpose-built integration of the same service. The same instinct applies to how you store configuration. Anything living in a file is something an agent can read, search, and change; anything living in a dashboard is invisible to it. Prefer files. ### Read the interfaces, not the bodies For a large diff, asking for a per-file summary of what changed surfaces anything strange faster than reading the diff does, and a prompt or two closes the gap. What deserves full attention is the surface: function signatures, API definitions, the contracts other code is written against. Those decide how hard the project is to maintain and how risky future releases are. Bodies are cheaper to fix later, and interfaces are not. A related trick for testing an interface you just designed: hand it to deliberately weak models and have them build things on top of it. If a weak model can use it correctly, the design is good. If it cannot, that is information about the design rather than the model. ### Measure the cost of finishing, not the price of a unit A cheaper per-token rate can produce a larger bill, because the model that costs less per token can emit twice as many tokens to finish the same task. Efficiency is consumption per completed task, and it does not appear on a pricing page. The same skepticism applies to speed. The same model served by two providers can differ by roughly a factor of two on throughput, and an average hides the tail where a fraction of calls are unusably slow. Measure the distribution. Turning on reasoning changes the shape of the bill, not only its size. Output tokens dominate once a model thinks before answering, so a cost model built when input tokens were the bulk of spend stops describing your invoice at identical per-token prices. Do not expect procurement to save you. Volume commitments on inference buy a few percent, and they carry the risk of paying the floor in a month you underuse. The lever is consumption per task, not the rate card. Widely-cited coding benchmarks are messy enough to make evaluation harder rather than easier. The response is substitution rather than cynicism: run your own comparison on a case you care about, and publish it with its conditions attached, including what you did not pay for and how much of the total was work that mattered. Evaluate the harness and the model as one system. Past the size where a codebase fits in context, the tool's ability to find what it needs decides whether the thing works, and no model does that well on its own. ### Price engineering time against the thing you would replace When someone proposes replacing a paid service, compare the service against what that person costs for the time it would take. Engineers systematically undervalue their own time, which makes them unreliable at this specific decision. The inverse is worth as much: a one-line change to your continuous integration can halve its runtime at many companies and nobody looks, because it is nobody's project. ### Change your mind in public, and leave the record Positions get revised when the evidence moves, and the earlier version stays published. Deleting content that no longer reflects your view is the wrong instinct, in the same way rewriting history to hide a bug fix would be. Being called inconsistent for that is a cost worth paying. Related: running a business means doing things you dislike, and criticizing a platform while shipping on it is not hypocrisy. ## Register Direct, informal, willing to name companies and be wrong loudly. Claims arrive with screenshots and numbers, and the caveats sit in the same message as the number. Arguments are made by conceding the opponent's strongest premise first and then following it somewhere they did not expect. Disagreement is blunt and sometimes personal, which is the part of the register to leave behind. ## Using this lens well **"Write more slop" is one sentence away from a disaster.** The whole position depends on a hard line between disposable code and merged code, and it collapses the moment that line is fuzzy. Someone who takes the encouragement without the separation ships the exploratory work. **Audience incentives shape which claims get made.** A creator whose income depends on reach is rewarded for confident, early, contrarian positions on whatever is being discussed that week. That is compatible with being right, and it means the volume of a claim carries no information about its strength. **Disclosed interests are still interests.** Investments, sponsorships, and platform credits are named openly, which is the correct practice and does not neutralize them. Weigh a tool recommendation by whether a measurement was published, not by whether a relationship was disclosed. **One person's measurements are one person's workload.** Running your own comparison beats trusting a leaderboard and inherits a different problem: one sample, one codebase, one language, one month. Say what it covers. **The claim that reviewing less means you are behind is unfalsifiable as stated.** It explains every disagreement without predicting anything, and the honest version needs a case where reading more genuinely was the right call. Hold it as a strong prior, not a rule. **The economics assume a particular scale of spend.** Reasoning about which model finishes cheaper comes from someone running many parallel subscriptions and burning a large monthly budget on tokens. The method of measuring transfers; the conclusions about what is affordable do not. **The distribution advantage is unusual and acknowledged.** Products here reach an audience of millions before launch, which changes what can be validated, hired for, and shipped. The stated version is that attention only amplifies a product that is already good, and that is true and still leaves everyone else without the amplifier. **"Senior engineers accept more agent output" describes a correlation.** Better scoping is the offered explanation and a plausible one. Seniority also buys the authority to merge without argument and the confidence to skip a check, and the data as cited does not separate those. **Model and provider conclusions expire fast.** Which model is efficient, which host is slow, which tool survives a large codebase: all pinned to a month. Check the date. **The combative mode is not part of the method.** A large share of the public output is conflict that produces no transferable judgment. Take the measurement discipline, the automation instinct, and the public-correction habit; leave the rest. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [zaidmukaddam](https://github.com/zaidmukaddam) - **Source:** [zaidmukaddam/skills](https://github.com/zaidmukaddam/skills) - **License:** MIT - **Homepage:** https://zaidmukaddam.com/skill Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-zaidmukaddam-skills-think-like-theo - Seller: https://agentstack.voostack.com/s/zaidmukaddam - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.