← Blog

Leveraged Engineering: The Subtle Art of Cooking With Gasoline

10 July, 2026

10xer

For decades the "10x engineer" was a bit of a meme. It refers to knowledgeable, high agency individuals with deep technical knowledge, domain expertise, and excellent tactical implementation skills. They are the person everyone would go to when they needed a problem solved and most organizations have at least one.

Today's AI tools are making these people even faster. A 10xer in 2026 is not someone who writes 10x more code. It is someone who leverages agentic tools to operate at a pace and quality level that was previously not possible. However, it is not simply due to the tool itself, it is because they already possess certain fundamentals. AI is a force multiplier for those that can use it effectively; for those that lack experience or expertise it doesn't have the same effect.

It'd be like if we were on a job site and everyone was hammering nails. The rookies will hit repeatedly to tap it in, missing a few times in the process, but the veterans will knock it in with one accurate swing.

AI is a force multiplier, but if you multiply any number by 1 you get the same number.

I've been using OpenCode and Claude Code daily for quite some time. Infrastructure automation and orchestration, ticket updates, task management, summarization, platform tooling, documentation, refactoring scripts, terraform modules, pipelines, etc. My output has increased dramatically and I am running circles around people.

It's Not a Replacement

If you don't already have strong terminal skills, scripting ability, technical experience, software architecture / design, systems level and first principles thinking, AI coding tools will make you dangerous, not productive. You'll generate plausible-looking code but riddled with bugs, things that work on the happy path but silently mangle data on the sad path, or things that just don't work or make sense, are overly complicated, wrong tool for the job, etc.

Absolutely worst of all: you will inundate people with slop code and comments. I absolutely hate reading people's AI slop; it's distasteful. Even worse is having to fix someone else's slop. I will call you a slop cannon.

The LLM doesn't know your environment and it doesn't know your constraints. You have to know that. You have to be able to read what it gives you and immediately spot what's wrong and correct it.

Valuable Skills to Possess

My Methodology

This is how I actually use these tools on a daily basis.

Set Proper Context

The single biggest differentiator between someone getting garbage output and someone getting great output is context. Agentic tools operate within the context of your project. The more structured context you provide, the better the output.

I maintain AGENTS.md or CLAUDE.md files (or equivalent context files) in every project I work in. Mind you, I work as a consultant and systems integrator, so I bounce between many clients and projects with all different goals and technologies. Here's what I usually define:

Take Small Iterations

The longer your sessions go on and the more context you provide the more opportunities you allow the agent to hallucinate or misinterpret. Current harnesses can actually compact your session to limit this, but it's still a good practice in my opinion to keep them short and pointed.

Instead of having one large session where I do everything, I compose all of my work into distinct "chunks" and utilize a different session for each. If I decide it will be worthwhile to get a "fresh set of eyes" I'll document a small handoff from one agent session to the next. This way I am not starting from 0, I'll have a blueprint for the task at hand, informed by the previous and usually dependent work.

This in my opinion is where most slop comes from. It's a person saying "here are a bunch of call transcripts, tell me what i need to know" and the result is just spaghetti. Some things just need more careful review and pointed specification; you have to know when that is.

Plan Before Executing

Sometimes you can start off with a basic prompt for something simple:

"write me a python script that deletes all objects and versions in an s3 bucket."

Simpler, more objective tasks don't need much iteration as the variations are limited and generally well-known.

However, for anything more complicated than that I start with planning. I describe what I'm trying to accomplish, what the constraints are, what already exists, and I use the LLM as a tool for scaffolding a plan.

More importantly, I think about the end state, describe in as much detail as I can and define explicit and measurable outcomes. From there, I work backwards from that and think through the end to end process and apply systems level thinking in the planning. I also ask questions and fine tune things because oftentimes the initial design proposed doesn't account for something.

I iterate continuously on a Markdown document. I'll decide checkpoints as I go and commit them to version control so I don't lose changes unexpectedly.

I review the output, poke holes in it, adjust it until I deem it worthy, and then move into execution.

This is how I approach problems without AI; think first, act second. Now I just have a very knowledgeable and willing assistant that can actually accelerate both phases.

For complex work I'll break things into phases explicitly:

  1. Research phase: "Look at the existing module structure and tell me how X currently works"
  2. Design phase: "Given what you found, propose an approach for Y"
  3. Iteration phase: "This looks wrong, it should be like this"
  4. Implementation phase: "Implement the approach we discussed"
  5. Validation phase: "Run the tests / linter / plan and fix any issues"

Each phase builds on the last. The AI retains context and notes across sessions. This iterative refinement produces dramatically better results than a single shot prompt.

I keep a running document with the relevant details of the task at hand and have the LLM update it as we go.

Take Copious Notes

Saving markdown files is free. My repo is usually scattered with Markdown files I am using as a scratchpad (I clean it up eventually). I have the LLM document everything we do into a file so that I can maintain current context and throughout a session we iterate on the document.

At any point in time I can fire up another agent or session with fresh context and just have it parse the cleaned up document. I use this to keep my sessions small and focused.

Terminal-First Workflow

This is where infrastructure and operations people have a massive advantage over pure application developers when it comes to AI tools.

We already live in the terminal. Our workflows are already composable. We already think in terms of piping output between tools, running commands, and reading structured output. Agentic tools like OpenCode and Claude Code are terminal-native and execute commands, read files, and interact with your system directly on your behalf, with your tools and your permissions.

The agent can run commands in your environment. It can kubectl get pods, read the output, identify a failing pod, kubectl describe it, read the events, read the stack trace, read the Dockerfile, read the code, identify the root cause, propose a fix, create a merge request, then tag you in it all in one flow and ten minute session.

Integrations are paramount. Find CLI tools for the systems/services you interact with. A pretty standard toolkit of mine is:

I also routinely develop custom scripts for API actions I perform for my project (a poor man's MCP).

Establish Headquarters

Every project of mine consists of many Git repositories. Sometimes dozens, usually hundreds. The convention I've had success with is instead of firing up agents in each individual repo I work in, I have a single repo where I maintain all of my skills, rules, scripts, config, notes, etc for the project (my work is project based and different for each customer I support).

From that one repo I fire up an agent session, which is in my current working directory, and when it's needed I have the agent jump into other repos where it can modify code, create the pull request, etc, and I track my work in a centralized place with a local backlog I can track tasks in.

I maintain the agent configs, iterate on rules, conventions, etc. It morphs alongside me with the project and I have a changelog. It becomes a launchpad and makes me incredibly expedient and nimble when it comes time to deliver solutions.

Leverage MCP Servers

Frontier models are trained on somewhat old data so their knowledge or understanding of things can be outdated which can oftentimes introduce bugs or hallucations. The workaround is to add an Model Context Protocol (MCP) server to your agent which then means it has access to the latest and greatest documentation or info.

Model Context Protocol sounds complicated, just think of it as a plugin that gives your agent real-time access to live data.

My primary MCP servers are:

Instead of relying on trained data, my agent can now just programmatically read the Terraform and AWS documentation to get current state knowledge/details/spec.

Clone the Repos / Get the Data

If you are working with some open-source technology or dataset just clone the repo to have it available. The LLM can digest the code and you can get actual specific implementation against it. For example, if I am learning technology XYZ, I can clone the repo of XYZ, or scrape/download web pages, or download datasets, etc.

I'm working in an Excel/Sheets document I'll load it into a Python Pandas dataframe and start working with it.

Give the LLM data and documentation, leverage having an expert that you can query to better understand things.

Keep It Simple, Stupid

KISS.

There's a lot of blog posts, Linkedin posts, Hackernews articles, and whatnot about the "most amazing Skill", "must have tool", shiny new "prompt library of the month", "awesome-mcp", "so and so made this and he's a genius", "oh my gawd, you have to use this". These things are catering to the "optimizooooor" who finds excitement in tuning and tinkering.

You don't really need all that. Skills are basically just Markdown files, you can accomplish the same thing by just having a Markdown file somewhere and telling your agent to read it and do what it says.

Sure, there's some value in a shared library that many across a team or org can use. Sure, there are some genuinely useful tools out there, but the point of this section is just to say:

Don't feel like you need a bunch of flashy tools in order to be effective. Just fire up a CLI harness, use a decent model, and start going, you'll figure it out as you go.

Real Examples

These are not theoretical things I've dreamt up, these are actual things I have done in my projects as an AWS systems integrator and consultant where having the LLM massively streamlined my work.

Terraform IaC Refactor

The Customer had roughly 50+ old Python/Troposphere repos which defined AWS deployments (dev, stg, prd) and wanted to migrate to Opentofu (open-source Terraform) to resolve many years of technical debt (brittle change management). They had built a handful of modules which decomposed the infrastructure but they were incomplete and in active development; bleeding edge. I was part of a squad that was responsible for the infrastructure of these applications with varying levels of complexity (API Gateway, Cognito, Lambda, ECS, KMS, SQS, Connect, WAF, EC2, RDS, etc) and tasked with the refactoring.

This Customer had Enterprise licensing for Cursor. I installed the Cursor Agent CLI in addition to the editor.

The workflow I had refined was:

I got this procedure down to a science and to the point where my work was telling an agent:

Update the base module to v1.3.9 for all applications; fan out subagents to create merge requests, compile the URLs for my review, monitor the plan pipelines

Dev reported an error in Jira ticket BUG-1234, check the app CloudWatch Logs, identify the problem and create the merge request

It would go update everything on my behalf pretty much. If problems ever came up they'd be squashed in minutes.

Database Migration

The Customer needed to migrate several on-prem PostgreSQL clusters to a new AWS environment and I needed to come up with a game-plan and execute. They were using Google Vertex AI for inference and Claude Code as the harness.

With these things in-place I just fired up interactive sessions where we walked through the plan, repeatedly iterated, worked out the bugs, and then executed every step of the way together. First performed the procedures by hand to build familiarity and then built it into fully automated workflow. Performed a whole data migration, leaving comments and closing each ticket as I went through them, constantly refining as I went.

I wasn't an expert with distributed PostgreSQL clusters with Patroni orchestration, etcd distributed configuration store, pgbouncer pooling connections, and haproxy routing service. Now I am.

Observability Dashboards

The Customer recently deployed a new system on AWS and was going into production soon. They needed to ensure they had proper observability dashboards and runbooks created to maintain the system. I fired up the Opencode harness using Amazon Bedrock as my inference.

The Customer had a full observability interface that offered rich context into the system health and performance and notified their Operations team in the event of any failures or anomalies.

Serverless Analytics and CRM Funnel

The Customer was using LassoCRM to collect form leads on their website. They had been using an HTML form integration from Lasso but they stopped offering this as a solution; they deprecated that feature which meant no further data collection or updates.

All of this work was agent created but driven by my style and design choices. I was constantly overriding the outputs especially as this was primarily actual software deliverables, not just IaC. It required deep software architecture and systems thinking perspectives. The agents often-times wanted to pursue clunky solutions.

In the end, I built an extremely resilient serverless system with a couple Lambda functions:

What This Isn't

This isn't "vibe coding." I'm not asking an AI to build me things I don't understand. I'm not blindly shipping generated outputs and I'm not replacing my judgment with a language model's. Even if it's something I lack experience with, like my distributed Postgres example above, I'm using AI as a learning tool as if I have a highly qualified expert in the room and I can pick their brain to quickly learn something faster than I could reading dry, boring documentation or forum posts. I then still spend cycles learning on my own to get a feel for the thing I'm learning.

I don't just ship LLM output and pretend like I'm a subject matter expert. If I don't understand the output I break it down Barney style until I understand. The LLM can literally explain things to you in this way.

This is tool-augmented engineering. The same way we went from manually SSH'ing into servers to using Ansible/Puppet/Chef, clicking in the AWS console to writing Terraform, writing runbooks to writing automation; this is the next evolution. The tool does the mechanical work. I provide the judgment, context, constraints, and quality bar and I guide and leverage the tool at my discretion.

The Gap Is Widening

If you are in the technology industry and not using these tools you are behind the curve and will get lapped soon. The gap between people using AI effectively and people not using it (or using it poorly) is widening fast. The toothpaste is out of the tube. I don't think I can go back to not using it.

I'm not talking about job security fear-mongering. I'm talking about practical output. The engineer next to you who has strong fundamentals AND an effective AI workflow is producing at least 3-5x what they were a year ago. Higher quality and higher throughput.

If you're a software engineer, web developer, site reliability engineer, platform engineer, DevOps engineer, sysops engineer, sysadmin or whatever and you're still doing things manually you are leaving massive leverage on the table and doing yourself a disservice.

If your organization prohibits you from using these tools then they are holding you, your colleagues, and the whole org back.

Job Displacement

There is a prevalent theory that AI is going to replace jobs and massively displace the global workforce with it's ability to automate many people's work. This is coming from frontier AI model company executives like Sam Altman and Dario Amodei (THE PEOPLE RUNNING THE COMPANIES THAT MAKE THE MODELS).

[The executives] warned that advanced AI could act as a general labor substitute, risking massive disruption and heavy job losses across multiple industries.

Many tech executives and the investor class disagree and take the other side of the coin; if you can achive higher throughput with the same costs then your capital becomes leveraged. Yes, you can do more with less, but you can also do "much much more" than you previously could with "more".

However, the markets actually reward reductions in force because it cuts costs and increases revenue which makes the stock more attractive. Companies can now feasibly do more with less...allowing them to cut costs and offload to AI. In the current market AI is quite hyped and there is a general sense of urgency to make as much money as possible during this bull period. Game theory (to me) dictates that we will see job loss in the coming years with AI being the excuse (though probably reality in some cases).

I don't know what will happen. It's a weird dynamic. For now, it's making me much more competitive in the job market and improving things in my personal life so I'm going to continue to use it. I am still optimistic about the future (e/acc) but I acknowledge it might get weird.

Closing

I was going to end this with a walkthrough but I don't think I will spoonfeed you. If you are already using these tools then hopefully reading this has made you better in some way. If you are not, then hopefully I have motivated you to start.

If you feel like I am missing out on some convention or tool, let me know.

↑