← 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 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. Implementation phase: "Implement the approach we discussed"
  4. 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 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, review the Dockerfile, propose a fix, create a merge request, then tag you in it all in one flow and ten minute session.

Integrations, integrations, integrations. 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 agents, it is 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. It becomes a launchpad and makes me incredibly expedient and nimble when it comes time to deliver solutions.

Leverage MCP Servers

Model Context Protocol sounds complicated, just think of it as an extra plugin that runs that gives your agent real-time access to certain things.

Most models are trained on old data so their knowledge or understanding of things is likely outdated which can sometimes introduce bugs or hallucations. The workaround is to add an MCP server to your agent which then means it has access to the latest and greatest documentation or info.

My primary MCP servers are:

Real Examples

These are not theoretical things I've dreamt up, these are actual things I have done in my projects 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.

This Customer had integrations with Google Vertex AI and was using Claude Code.

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.

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 it.

This is tool-augmented engineering. The same way we went from manually SSH'ing into servers to using Ansible, from clicking in the AWS console to writing Terraform, from 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 and I can never, ever go back to not using these tools.

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 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.

But 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 has actually been stated by frontier AI model company executives like Sam Altman and Dario Amodei. TLDR:

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

It's easy to follow that thread and I do think it's possible that companies leverage AI as a tool to do more with less; cut costs by firing staff and offload work to AI.

However, most business owners, board members, and executives are thinking long-term and interested in growth (shareholder value). Markets dislike reductions in force but love steady growth. The above concept goes both ways; 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".

I don't think we really see this displacement for quite some time and I expect new markets to form around this AI expertise; take the hot new job title, Forward Deployed Engineer for example.

This, of course, is just conjecture. I have no clue what will happen like the rest of us but I am optimistic (e/acc).

Getting Started

If I have convinced you to get started, here's a basic walkthrough for getting set up with OpenCode using AWS Bedrock as the model inference provider. I work on a Ubuntu machine for personal stuff and a Macbook for work. This is catered only for those two. If you're using Windows or some other OS you are on your own (and probably ngmi with the exception of a few people I know).

Install OpenCode

# yolo
curl -fsSL https://opencode.ai/install | bash

Verify it's in your $PATH:

which opencode
opencode --version

If it's not found, add the install location to your shell profile (~/.bashrc, ~/.zshrc, etc):

export PATH="$HOME/.local/bin:$PATH"

Install AWS CLI

The AWS CLI is how you authenticate to AWS services including Bedrock. Opencode will require some config file. You don't technically need this but you might as well have it, it's invaluable. 

# yolo
curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash

Install uv

uv is the best Python package manager and tool runner. You'll use it for managing Python tools and virtual environments going forward:

# yolo
curl -LsSf https://astral.sh/uv/install.sh | sh

Authenticate to AWS

You need valid AWS credentials for Bedrock access. Two common approaches:

Option A: IAM Identity Center (SSO)

aws configure sso
# Follow the prompts: start URL, region, account, role
aws sso login --profile your-profile

Option B: Static credentials (IAM user access key)

aws configure
# Enter Access Key ID, Secret Access Key, region, output format

Verify your identity:

aws sts get-caller-identity

You should see your account, ARN, and user ID. If this fails, nothing else will work.

Enable Bedrock Model Access

In the AWS Console, navigate to Amazon Bedrock > Model access in your target region and request access to the models you want to use. Common choices:

Model access approval is usually instant for Anthropic models but can take a few minutes.

Configure OpenCode for Bedrock

See https://opencode.ai/docs/providers#amazon-bedrock

Create or edit your opencode.json (project root or ~/.config/opencode/opencode.json).

If you're using SSO, ensure your profile is set. If using static credentials or environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION), OpenCode will pick those up automatically.

Set Up a Project

Navigate to an existing project or scaffold a new one:

cd ~/projects/my-project
opencode

Run /init inside OpenCode to generate an AGENTS.md file that describes your project structure, conventions, and context. Commit this file to your repo.

Run /model to select your model. I personally use Claude Opus and Sonnet 4.6.

Pick Your Workflow

From here:

  1. Start with a real task you'd normally do manually. Don't start with toy problems.
  2. Write up your AGENTS.md with structure, conventions, and constraints.
  3. Plan before you execute. Use OpenCode's Plan mode (Tab key) to review approaches first.
  4. Always review output. Never ship what you can't explain.
  5. Iterate. Your first sessions will be clunky. By week two you'll have a rhythm.

Hit Me Up

If you need help, DM me on linkedin or email me.

↑