Solve By Default
The biggest level up you can make in your career in 2026.
Recently, I revealed how I’ve completely changed my work. I wanted to go even deeper into the principle of solving by default, with tons of practical examples of how to embrace it in your work.
I assume you are using Cursor, Claude Code, or Codex for this post.
Almost no problem is off the table with an AI engineer; those who ruthlessly seek out meaningful problems and solve them will be the most impactful and recognized employees throughout the AI revolution.
In my previous post, we touched on how focusing solely on solving by default can lead to great impact, thinking creatively, and feeling a deeper sense of accomplishment. Please read that post first.
We’ll define solve by default for this post as: when problems emerge that you traditionally wouldn't solve (e.g., execution risks, legacy organizational red tape/paperwork, limited bandwidth), you now solve them with genAI.
Recently, I spoke on an application security panel with Clint Gibler and Travis McPeak, where a major focus was on generative AI. Several times during the converation solve by default surfaced across our panel. Travis shared that he defaults to building when new problems arise in his role as head of security at Cursor. Clint shared how solving has never been more tractable, limited only by your own agency and creativity. And it was refreshing to hear that folks are embracing this builder’s mindset. After the panel, a few folks came up to me to ask more about what solving by default really looked like in practice. Specifically, they use AI tools for writing code, but they wanted more specifics on what I meant by going full AI-native and solving every meaningful problem that comes my way.
Today, we’re going to dive deeper into pattern matching, all sorts of ways to solve by default. But you may be asking yourself, wait, how do I go find problems to solve?
Seek Problems
I’ve written about how the best engineers seek problems as if their life depended on it. But we’ll do a quick summary here to get your wheels turning!
Hunt for the Meta-Patterns: Read Product Briefs and QBR memos, identify what may be missing or putting them at risk, and consider a solution. Look at incident trends or operational paper cuts that slow your team or org down (e.g., on-call patterns, flaky tests, or a lack of a runbook). Check out high-priority tickets in the “tech debt” label in your or your adjacent team's backlogs that no one has picked up. If everyone is facing a similar challenge, it sounds like a good problem to pick up.
Look between the ferns: Look for work or gaps that are falling in between charters. No one owns PSIRT? Maybe this is a good chance for you to solve by building automations and runbooks to enable the function.
If you hunt for these meta patterns and look between charters, you’ll see problems that maybe you wouldn’t have solved historically. The barrier has never been lower, so get to work! However, with a low barrier, we can also find ourselves getting trapped solving things that don’t really matter. So let’s be intentional about what we won’t work on.
What Not to Solve
“Scott, you are such a buzzkill, I want to get to solving!”
But for real, not all problems should be solved. Right now, dozens of engineers on Reddit are bragging about writing millions of lines of code, but it’s unclear whether the problems they are working on matter. Your company or startup probably has a seemingly untractable amount of problems. However, while AI has made execution cheap, there is still work to manage agents, resulting in you having to make tradeoffs with your time. I’ve spoken in the past about prioritization of work, but the shorthand here is,
What is the value of the work?
What is the scope and reach?
How complex is it?
What is the leverage (e.g., foundational work, compounding / accelerates other work, many projects would get unlocked if this existed)?
Run this quick gut check as you step into your next solve. If most of the answers to these questions feel like this is impactful work, you are on the right track. If the value seems weak/experimental, it’s complex, and is a standalone work, maybe shelf that problem for now. If you don’t like this framework, you can use lightweight RICE.
Now that we’ve gotten a good framework for gut-checking, I want to share a brain dump of patterns and apps I use to solve as much as possible by default.
Patterns
Ideas brought up in meetings - You’re chatting with a colleague who says, " Wouldn’t it be awesome if every Agent were in a monorepo? You get excited and start asking questions…how should we structure it? By org? Yes, that sounds great! We can also schematize the agents and use that for governance purposes. In an old model, this conversation would prob fizzle out or result in someone writing a 4-5 page memo, shopping it around to 2-3 different teams, I dunno, maybe bringing it into some Quarterly planning session. NOT ANYMORE! After we finish this conversation, the meeting notes will be added to a Claude session to begin creating a PRD. I know there won’t be enough details, so I informed Claude to ask me questions. I usually use the Superpowers brainstorming plugin + meeting notes to build the specification. 20 mins after the meeting, my agents are already working on a solution.
Pairing sessions and microcuts and nags- I’m working with a colleague, and he says, the keyboard shortcuts are kinda wonky on this panel. We continue pairing, and a bit later, he mentions, " Ah man, if we click into the modal, the highlighter resets. None of these are show-stoppers; they are micro-annoyances that add up. However, I have my AI notetaker right there. I have a skill that takes that AI notetaker and translates the entire conversation into a series of GitHub issues for the relevant project. Due to a fidelity issue with AI note-taking, I validate the issues before my agent creates them. Once they are created, I spin up some background agents to take them on. Next time we chat, they will be solved, and annoyances will be gone.
Slack threads - We're working on a sandbox, and I’m fortunate to get to collaborate with such a brilliant group of engineers. As they are looking at the MVP I built, ideas start flooding into the Slack channel. We’re emoji bombing each other and getting excited. In the old days, that thread would have died down and been forgotten about. Instead, I take that entire thread and have my agent convert it into GitHub issues (similar to the approach above). I tag the GitHub issues with the date and Slack channel name, which helps me remember the source of the conversation. Even cooler, it includes quotes from the conversation if you ask it to.
Example Slack thread turned backlog ticket my agents can pick up.
Thing “X” that slows you or your team down - Simple. Look for slow builds, painful runbooks, things that you can automate for on-call, inner and outer dev loop improvements you could make, deprecations, or even rewrites. Fine one that seems high-leverage and low-complexity, and kick it off! Try this: When you are on-call, do you touch a UI with your hands? Turn it into a skill and call the API directly. Agents are fantastic at working with APIs, faster than you with a UI. Put all those skills in a team repo so everyone has them.
A colleague and I were working on a framework for scanning LLM models for static vulnerabilities. Our build times were painful. A few iterations in, I pulled the entire build lifecycle and build artifacts from a previous run and asked Claude to analyze my build and identify opportunities for improvement. It identified that the way I had Docker built, my containers were caching, and I was doing a dependency resolution tree on a few packages that took minutes. About 10 minutes later, I made several changes to my build pipelines and artifacts, shaving about 10 minutes off the entire build process. I took 10 mins to save myself 10 mins from every build for the rest of the time this project exists. That’s huge!
Trying to solve something that’s high uncertainty - How many times have you just told yourself, this is probably too hard, or I’m not sure this is going to work? No excuse, set aside an hour or two to brainstorm a plan and put it into development with your AI agent. IF there is a lot of uncertainty, budget in a fair bit of time for human validation (e.g., checkpoints). If things aren’t working, decide: was it your prompting, or is this truly not the right problem? Regardless of whether you solve it or not, you’ll learn something that will make you faster for the next attempt.
All of that time you spend in meetings, pairing sessions, grooming backlogs, and digging for change through the cracks…can now turn into solves, if you switch your perspective to: I can solve this!
I believe this is a big step on the journey towards AI-native. And if you are unsure at any point, ask your agent. Should I solve this? Did i estimate this priority correctly? You’ll be surprised how just a few prompts can clarify whether you are or aren’t on the right track.
Band Practice - From Slack To Solution
Pop into a Slack channel where your team or projects you are working on are happening. Look back at previous threads where folks have shared ideas, complained about the tool, etc. Copy that context directly into Claude, and ask it to turn it into a set of GitHub (or Jira) issues. Ask it to file them for you, then in a separate window, kick off the first agent to solve it. When you are done, share it back in the Slack channel and, more importantly, share this technique with your team.
Let me know how it went!
S.B.
Great article, Scott.