DEV Community: bfuller

What does it mean to be a “Technical” Product Manager in the AI era?

bfuller — Tue, 06 Jan 2026 04:26:00 +0000

There's a dangerous narrative emerging in tech: that the AI era demands Product Managers to be Developers. I'm here to argue the opposite. AI hasn't made technical skills more critical for Product. AI democratizes technical execution, which makes the strategic, customer-focused aspects of Product work more valuable, not less.

The Gatekeeping Myth

The logic seems straightforward: AI is technical, products are increasingly AI-powered, therefore, Product needs deeper technical chops. But this is gatekeeping dressed up as evolution.

Consider what's actually happening. I've built two functional applications without writing code from scratch. I can buy a domain, learn why it’s always DNS, navigate databases, comment out problematic code and database tables, modify front-ends, and troubleshoot AI-generated cruft. I can research best practices and leverage a decade of product knowledge to build real tools that solve real problems.

So why would I also need to be a Developer in my Product role?

AI as a Leveling Force

Here's what AI has actually done for “non-technical” Product Managers: it's made us dangerous. Not in a reckless way, but in our ability to close the gap between product vision and technical execution.

When I load technical documentation into a GPT and ask it to create implementation guides for my apps, something interesting happens. If the docs are incomplete or unclear, I get back garbage. That's not a failure, that's insight. It's a window into why users struggle. It's the canary in the coal mine for documentation gaps and onboarding friction.

I'm no longer just the first customer who figured out the workarounds. I'm the next customer, the new customer who can identify barriers before they become churn.

The Real Value of Product Thinking

Here's what happens when I take off my Product hat and just build what I need: I build for myself.

My garden app tracked containers, prevented antagonistic plant pairings, and managed crop rotation history. That's what I needed because I've been gardening since childhood. But when I asked actual users? They wanted growing zone-appropriate plant recommendations, sun exposure guidance, and shopping lists. They needed the foundational knowledge I took for granted.

My home maintenance app assumed everyone grew up pulling electrical wire and cutting egress windows. Turns out, most people need climate-based reminders, checklists, and how-to guides for common home maintenance projects. Who knew?

Developers face this exact challenge constantly. It's why product management exists in the first place.

What Product Actually Does

Our job isn't to write the code. Our job is to:

Gather customer feedback and trace problems two steps back to find root causes
Pattern match across data and lived experience
Negotiate with leadership when they're working from different assumptions
Partner with engineering to understand true capacity, accounting for technical debt, firefighting, sales interruptions, and SLA commitments

Navigate team dynamics, burnout, and sustainable pacing
This is more art than science. It's a trust exercise built on understanding context, politics, and human limits.

We also track competitive movement, align product strategy with company goals, build features that ensure sales hit their numbers, and give marketing enough lead time to build market momentum.

None of this requires me to be a developer. All of it requires me to be a great Product Manager.

The AI Advantage

Yes, AI has expanded my technical comfort zone. I navigate GitHub and VSCode with confidence. I delete unnecessary code. I read log files, live by console outputs, and troubleshoot problems well enough to prompt my IDE toward solutions.

But here's the thing: I'm doing this with a decade of DevOps experience and zero development background. AI hasn't made me a developer. It's made me a more empowered Product Manager.
The Magic Remains

What I love most about this work hasn't changed: building something meaningful with a team and solving real problems for real people. The magic of hearing from a user years later that your feature made them the hero that day, that's still the heart of it.
AI isn't changing what makes great product management. It's amplifying it.

The Path Forward

The AI era doesn't need Product Managers who code. It needs Product Managers who understand customers, navigate complexity, and translate between business strategy and technical execution. These skills matter more now, not less.

The question isn't whether Product Managers should learn to code. It's whether we're ready to fully leverage AI as the powerful enabler it is…one that lets us focus on the irreplaceable human work of understanding what to build and why.
That's the future of product management. And it looks nothing like gatekeeping.

Using a Non-Deterministic System to Find Climate Patterns

bfuller — Mon, 20 Oct 2025 04:53:26 +0000

A few months back, I started on a journey to learn about how I might use Generative AI. I wasn’t sure what I was going to learn. I’ve found the joy in Product Management again. I have also started to pattern match enough that I am fixing code and making changes on my own. I ask for help early and often, and I delete cruft when I find it.

I’ve been doing live "coding" with my friend. Ok, I mostly get walked through things on Twitch. They also ask me architecture questions and walk me through how to think about the long-term architectural trade-offs. I spent one live stream learning how to change the HTML, and I might have spent most of the time giggling in delight because that is deeply satisfying!

Slow is smooth and smooth is fast

Generative AI is built to hallucinate; it's a feature, not a bug. So it’s great when I’m looking for an “ish” idea of the UI/UX, but as soon as I get the format I want, I need it to be consistent all the time. Which meant I needed to switch tools, and that is scary!

It’s also slower. I'm learning that it’s ok to go slower. I need to be mindful of and consider what the evolution of the tool might be, and remember, I just need to scale to the first 10 users before I scale to 10,000 or 100,000.

Now I’m reading and understanding the documentation, and I asked a tech question on Discord. It was scary, but I shouldn’t have worried about it. I already know the Dev community is rad.

As I've moved to slow and smooth on the front end, I'm switching gears and creating a data warehouse for the weather and climate data. Since both apps need the same data, it makes sense to have one data warehouse for temperature trends, humidity, air quality, precipitation, regional flooding, wind storms of all varieties, and fires. I've been using PG Admin, but I can already tell this is going to take a little time to get used to. And that’s ok. In the meantime, I have been collecting climate data going back decades. I feel like a data hobbit who stops for an elevensies, second breakfast of CSVs.

The data magic of it all, or something like that

What I’m doing is using AI and a simple ML model to identify microclimate patterns based on the last 5 years of climate data. I started with heat domes/extreme heat by season.

I want to be able to track whether that cute neighborhood near that adorable lake is at risk of rising waters. What actions can the owners take now to become more resilient to that future state without having to leave the community they love?

Is there a weather pattern to help identify where wildfires are likely to strike next? Can we help a community predict if the fires are likely to come their way in the coming years? There is amazing research and real-world examples of how to create a fire-resistant home. Fun fact: There are FEMA grants for disaster types.

People need to have enough time to plan for the changes coming their way. Having a non-deterministic system or model to help find some of these microclimate patterns means we might find some interesting weather insights to help people prepare. Further, we want to help replicate the communities that are finding success in adapting to climate shifts.

I was reading about a home in Utah that survived the Forsyth fire. This guy built a fire-resilient home. The fire department was able to triage that his home would be fine and focused their efforts elsewhere. Which has me thinking, what if we could help an entire street, block, or neighborhood become fire, flood, drought, or wind resilient instead of 1 house? It’s a goal and what pushes me to keep learning. Only time will tell if I can learn something useful from the data. If not me, someone else will, which is what really matters!

How AI Helped Me Find the Joy in Product Management Again

bfuller — Sun, 12 Oct 2025 18:23:29 +0000

When I started on my journey to learn more about AI, I didn’t expect it to help me find the joy in my job again. I’ve been a product manager for about 20 years. I like the chaos, the people, finding that thing that makes users' lives better, and I enjoy the project management piece. I love trying to understand the community we are building for, the culture of the team, each team member's calculator, creating transparency so the team can 100% miss their delivery window and still have customers happy, and taking risks with the features. I love the chaos, but lately things have been off in the industry.

I’ve been hearing all this hype around how AI is going to make my job obsolete. I’m not unique in that, but I can only talk about my experience. Now when presented with the notion of losing my job, I like to get curious. Why is AI better than a human?

My analysis so far it’s not. It’s a tool. It’s not a human replacement. I’ve seen influencers state that the only way Product is going to find work is if they are effective vibe coders. People who say this do not understand what Product is, nor do they understand what vibe coding is.

First, what makes a good product manager? It is not a technical person who can create specs for the development team to code to. That’s actually a different job. It isn’t taking the directive from management and delivering exactly what they asked for.

My first role as a product manager, my VP said, “Your job as a Product Manager isn’t to be everyone’s best friend, it’s to deliver the right features to the customers and drive revenue.” As a people pleaser, this was a hard role to step into. You take a lot of hits, you will not make people happy, and you will have engineering managers take you aside to threaten or blame you for missed dates. That’s the job.

I think of Product as the orchestrator. We need to have a technical understanding of the problem space and product, be able to do data analysis, gather customer feedback and requirements, prioritize, consider long-term vs short-term impacts, evaluate tradeoffs, communicate the impact across the organization, and be collaborative.

For me personally, it’s being humble, building trust with my team, and building trust across the organization. One person can’t fix the company culture. It's my job to help the team deliver value to our customers and grow revenue. If you are good at Product and the culture is bad, doing your job correctly can feel like a challenge. My job isn’t to be your buddy; it’s to ensure the right features are being delivered on time and those features drive revenue. You can do all of that without being a giant jerk face.

I’ll follow up with specific ways to leverage AI for the core functions of Product:

Technical knowledge/expertise: Controversial take, I’m a terrible PM if I’m an expert in the product. AI can help me with my knowledge gaps.
Data analysis: Data is always the best but sometimes I need a non-deterministic system to find trends that aren’t obvious to me.
Analysis of customer feedback: Listening to customer feedback means I might bias what I hear to the features I think need work.
Requirements: I hate writing PRDs not because they aren’t useful but because some companies have turned it into a flair competition. AI helps me create faster using my information. Usual caveats apply.
Transparency: I can get the idea out of my head and use the non-determinism of AI to create a first look. This means I can use words, data, and images to help communicate the features to Engineering, UI/UX, CS, PS, Sales, and Marketing.

The last few years, there has been this trend that requires Product to be an Architect, customer 1. It frankly is a sentiment that has taken all the joy out of my job. I can be technical and not an expert in a niche tool. Really good Product Managers have roots in many other areas. Data analysts (me), Technical Writers, Developers, QA, Customer Success, Professional Services, Librarians, Researchers, and many more. Some of the most obscure backgrounds make some of the best Product Managers. AI helped me remember why the human side of Product is the most critical and that my experience, which is not “technical,” which really means I’m not a developer, is valuable. Now I have another tool to help me deliver the right features and drive revenue.

Helping people rewild their yards: The AI journey continues

bfuller — Wed, 01 Oct 2025 01:58:37 +0000

Helping people rewild their yards: The AI journey continues

I started on the AI journey with a few goals in mind: to figure out where the edges are for people like me, and to build two climate-resilient apps.

I grew up gardening, and I love everything about it. My yard growing up was a food forest, and our street had a massive community garden. All summer we’d snack on raspberries, blueberries, cherries, Santa Rosa plums, apples, pears, and when the fall was settled in and winter was on the horizon, we’d get to tackle the corn stalks.

We gardened without pesticides. Instead, we had flowers growing everywhere, planted companion plants, repellents (marigolds), and traps (calendula and nasturtiums) to keep the insects away.

I grew up understanding that sometimes that mess we are so eager to clean up is actually our pollinators' winter home.

As a gardener today, I’ve realised I can’t garden the same way; in fact, the growing zones were recently adjusted. I live in Portland, and my tiny part of the world is a whole growing zone different from the outlying areas because of the heat island effect. Portland, Oregon is the same growing zone as San Antonio, Texas.

Climate Resilient Practices Are the Best Way Forward

So I asked myself, “How do we continue to grow and thrive in a climate resilient way?” I wanted a way for new and experienced gardeners to be able to adapt to the changing environment. Food in our yards is food for the critters, birds, bees, and other insects too. We are part of the ecosystem.

Learning to code using AI meant I had to learn to be comfortable with being uncomfortable. In fact, I’d imagine this how it feels for new gardeners. I was terrified of deleting code, going in and changing the code myself and I was worried I’d break it.

Just like gardening combinations to get new gardeners started, I figured out how to get started coding with assistance. I wouldn't call it vibe-coding. I'd call it product with a systematic approach to solving problems. Hmm, doesn't have the same ring to it. Anyway, I tinkered a bit until I figured out a requirements doc format that works for me. I answer the following questions:

How will it be used?
Who’s it for?
Multiple users with auth? OR no users, all public
Using external data through APIs?
Storing user data in your own database?

It seems simple, but any seasoned Product Manager will tell you the devil is in fact in the details. So, for a simple chore app, you'd do the following:

Create a Chore app for people with ADHD. It should include the following:
1. User selects what category of chores they wish to do daily, weekly, monthly, or seasonally. The list can be found in this PDF (https://i.pinimg.com/originals/01/46/10/01461068831a5193bb0ed353e00bedfe.jpg). 
2. Provide 2 choices in a choose-your-own-adventure experience with a fun fact surfaced after each selected chore is completed. Please use [fun facts found in this PDF](https://factrepublic.com/wp-content/uploads/2017/03/1000-Interesting-Facts-to-Blow-Your-Mind.pdf) 
3. Connect to the music streaming app of your choice to help keep the user engaged and motivated with their chores.

This app should be clean, crisp, and engaging.

Systematically building an app

All I wanted was the right framework. I tried a few tools until I got a starting point I liked. With the right framework, I systematically go through section by section and build out the details. Doing it this way helped me track how the code was laid out, and I could start to pattern-match how the code worked together. It also reduces the context window, which makes token usage more efficient. All around win!

I still don’t know what I don’t know

In many respects, this was the fun and easy part. Aside from tabs. For the love, I could not figure out the right prompt to get Lovable, Windsurf, Co-Pilot, or Cursor to do tabs.

I started to get comfortable checking logs, learning to read the code (I’m still terrible at it, but I am making progress), and identifying the cause of an issue, even if I don't understand how to prompt a solution.

Then I got overconfident and decided to start pulling data. Oof, some of the biggest challenges came from trying to pull from government sites. The way Cursor struggled with Celsius and Fahrenheit was entertaining. This turned into a phone a friend scenario. With help, I sorted out how to use Bruno, so I can prompt AI to pull from the API correctly.

All of that got me garden spaces with hover icons and a set of containers. Think of it as a framework for gardening.

I have a context aware chatbot to help users create a container space or to ask it garden questions. My test case was making a salsa garden because I wanted to see if it could put together something specific. As an apartment and small garden space dweller, themed containers were perfection! Salads and salsas taste better when you grow the ingredients. I don't make the rules.

The context aware piece was another opportunity to learn. AI has no concept of size or gardening, so I taught a GPT. I seeded the model with permaculture and indigenous practices for gardening, added reference links to programs, and created a rule that the Sprout bot needs to link to references so users can fact-check if needed.

By the end of it, I built an alpha/beta garden app Root & Stem and started on my climate resilient home app. I thought the garden app was a learning curve. I was not prepared for the shenanigans that happened with my next app! A tale for another time.

You can try out Root & Stem here. If something seems off, assume it is the app. Let me know about any bugs, features, or questions at beth@3mor.io.

If you are interested in being a Beta tester for the home app, where you’ll get insights on climate resilient updates, both big and small, sign up here.

I'm hoping I can make your gardening journey an adventure.

Trials and tribulations of learning how to code and navigate databases in an AI world

bfuller — Tue, 26 Aug 2025 18:42:35 +0000

NOTE: These are musings as I navigate the world of AI. I suspect some blogs will be more linear than others.

I find all the AI hype exhausting. Ok, most hype I find exhausting because it rarely lives up to the hype. Then it’s just a giant pile of disappointment that I need to fake smile through someone’s excitement. I’m not a fan. That said, there is no way to get around it. Right now, it feels like the only way to survive this stage of tech is to dive into the deep waters of AI. So, that’s what I’m doing.

I’ve spent the last 2 months or so digging into AI tooling and I have lots of opinions. In fairness, I used V0 over a year ago to build out wireframes for 3Mór. I didn’t love it. In fact, I liked the experience of creating a mockup using Figma a whole lot more. I had more freedom and wasn’t bound by the content fed into the model. I could use my imagination and push boundaries so the eng team and I could find a happy medium. It’s terribly banal designing with AI tooling.

I don’t write code. I’ve worked in data off and on for a few decades. One thing to note about me is that I have dyscalculia, and it’s possible I have some niche brand of dyslexia, but it’s hard to say. I tend to think in pictures. I can understand complex math problems, but basic arithmetic is weirdly hard because the numbers and scale never stick and I can’t visualize it. Fun fact, it’s thought that Albert Einstein also had dyscalculia, and apparently so does Bill Gates.

Understanding my dev team's pain more acutely

Why is that important? Well, periodically, I’ve tried my hand at coding. It generally goes poorly. I try following the book, but I get stuck at the same spot each time: Hello World. Every time I think, what now? Hello world is prescriptive and not interesting, it doesn’t tell me how the apps I use work, what goes into scaling an app, or how to get started. It’s just following directions. Which, to me, is not interesting. Enter AI tools.

One of the coolest things for me was being able to write a requirements doc, feed it with some simple context and tooling requirements, and have AI provide me with a framework. Now all of a sudden, I could start to look at the files and try to back track to figure out what the front end looked like and the code that created it. Reverse engineering is my favorite kind of engineering.

With AI, I’m getting real experience around the tools I’ve been building for over the last decade. The IDE will tell me to look in the console. A few months ago, I had no idea what it was talking about. Console? What is that? Where do I find it? I envisioned something totally different for console. I was weirdly disappointed with the term vs tool if I’m being honest. So I knew what logs were, but it never occurred to me how many and how different they are. This is where the dyscalculia makes every tool their own special snowflake, a real drag.

The bigger issue is learning when you have to override AI. I have to remember the order of operations to troubleshoot issues. Do I look at the console, logs, or those pesky Typescript problems that AI keeps telling me aren’t relevant. I have no idea why AI tooling things problems or errors being thrown by a typed language aren’t relevant, but I now have fixing them as a global policy. Anyway, while I still rarely understand what the problem is exactly, I'm starting to get a sense of what the problem could be related to and asking Gemini for help.

In short, I am learning a ton, everyday. I’m learning it at my own pace. Or until the AI companies ratchet back their offerings. I can ask AI and not feel dumb that I haven’t a clue what it’s talking about. All of that to say, I’m at a point where I want to learn how to navigate the data portion on my own. I want a Postgres database, timeseries, and an ML model. I don’t trust AI to do it right, it has really struggled with real data. I think AI can walk me through how to set everything up. Time will tell!

Data integrity lessons ignored are costing us all

When you work in and around data, you learn the most important lesson is, garbage in, garbage out. What’s become clear is AI companies made some critical errors when they set up their models. They didn’t clean the data. Next they tossed in everything and the kitchen sink to every model thinking that’s a good choice. Seriously, were there no data scientists helping build the models? It would have been more ethical, and ecologically sound to have smaller models with good data.

Our lack of understanding how databases work and the humans who train them was made abundantly clear when folks in the US bashed Deep Seek because it didn’t have insights on Tiananmen Square. Well duh and also have you read a US history book? They are just as inaccurate leaving out all manner of atrocity. So don’t use an AI model from China to build a History of China app. Problem solved. Add the data that makes sense for the problem you are solving. Get the data from expert sources.

Opportunistic tool creation

What’s next in my AI journey? My focus is on climate data. The US government has lots of freely available data but that’s slowly being removed which makes it impossible to plan gardens and climate resilience.

I’ll keep working on my apps and adjusting them so the garden and home apps have modern feature functionality instead of AI blocks of text with terrible accessibility. I’m feeling more comfortable with how frameworks come together and as I work on the apps I’m learning the patterns through repetition and reverse engineering.

I don’t imagine myself becoming junior developer level but I do hope to be more comfortable with how the front end and back end work together as the weeks go by. I’m really excited to dig into the data of it all. Seeing if I can learn more about machine learning and can find some insights that will help farmers, gardeners, and those living in the world to be more climate resilient. I want to make sure we can adapt how we grow food and keep our spaces liveable.

All in all the start of my AI journey has been steep. There is good and bad but in the end it comes down to the basics and best practices. I suspect as I get deeper in I’ll become more passionate about best practices instead of less. I’ll also have a better sense of how we can use this new toolset whether its AI, LLMs, or ML each has strengths. I look forward to seeing more folks define what those boundaries are and exploring them for myself.

How Many AI Tokens to Play a Game of Chess?

bfuller — Sat, 17 May 2025 21:19:49 +0000

Just because AI tokens are cheap today doesn’t mean they’ll stay that way.

When cloud adoption peaked around 2015, everyone migrated to “save money.” But many teams didn’t fully understand their on-prem costs, nor did they have a realistic plan for managing spend once they migrated. It’s as though we forgot about all our best practices.

In 2015, cloud spend was projected to grow from $49B to $67B by 2018. In 2023? It hit $563.6 billion, with $678.8 billion forecasted for 2024

Alongside that growth came tool sprawl, security risk, and unexpected costs. Sound familiar? AI token usage is on a similar path only this time, the underlying mechanics are even more opaque.

What’s a Token, Really?

Let’s demystify it. A “token” is just a chunk of text (words, punctuation, etc.) that an AI model processes. But the cost and impact of using tokens isn’t always clear especially when engineers interact with AI in iterative cycles.

You might wonder:

How many tokens do I use per prompt?
What does it actually cost?
Should I care, if they’re so cheap?

The answer is yes. Because scale hides cost until it doesn’t. Think of those surprise cloud bills.

Understanding Context Windows & Token Accumulation

Let’s look at how developers commonly use AI in practice particularly when “vibe coding,” which is where prompts evolve over time rather than being sent all at once.

Imagine each set of 10,000 tokens as a crow: 🐦‍⬛

Example: Three-Crow Vibe Coding Session

🐦‍⬛ Initial Prompt
- You upload a small repo, TypeScript rules in Markdown, README, visuals, and your prompt. That’s your initial 10k tokens.
🐦‍⬛🐦‍⬛ Model Response
- The AI responds using more tokens. This response, plus your initial input, is now part of the context for the next round.
🐦‍⬛🐦‍⬛🐦‍⬛ Follow-up Prompt
- You send a second prompt, which includes all previous input and output — stacking more tokens.

This adds up quickly — especially on large codebases.

Most models (e.g., GPT-4 Turbo) max out at 200k tokens. For anything complex, like Shopify or HubSpot sized repos, you’ll hit that limit fast if you're not careful. In fact, you can’t send a full repo. You need to have a level of expertise to parse a crows worth of context in your initial prompt.

Best Practices for SRE & AppSec Leaders

Uncontrolled token usage presents three key risks:

Cost Overruns
Security Exposure
Operational Complexity

Here’s how to keep your AI interactions efficient:

Explicitly scope code slices: Only include relevant modules or services.
Externalize business rules: Use Markdown docs instead of bloating prompts.
Link strategically: Reference specific parts of your README or API docs.
Document architecture: Provide structural context only where necessary.
Use visuals sparingly: Only include component libraries or mockups when critical.
Write focused prompts: Avoid solving multiple problems at once.

Your goal: include only what’s essential to solve the task at hand.

Token Costs Today (But Not Forever)

Here’s what OpenAI charges for GPT-4 Turbo as of now:

Model	Input Tokens	Output Tokens
GPT-4 Turbo	$0.01 / 1,000 tokens	$0.03 / 1,000 tokens

This seems cheap and it is. But AI compute is expensive. OpenAI still operates at a loss but investors won’t tolerate that forever. Sam Altman himself has talked about how much OpenAl loses with every “please” and “thank you.” It’s only a matter of time: token costs will rise.

Just like cloud costs, token costs will follow a hockey stick trajectory.

What feels like a minor cost today can quickly become a multi-thousand-dollar surprise if you're running CI/CD workflows or incident response playbooks on top of AI agents.

Optimize Early — Before It’s Too Late

If you're a platform, AppSec, or SRE leader, think of AI tokens like CPU cycles or S3 buckets:

You track them.
You optimize them.
You don’t leave them unmanaged.

Educate your teams. Create internal best practices. Monitor usage.

Just like we learned in the cloud migration, getting efficient early pays off in scale, security, and speed.

🔗 Further Reading

If this helped, drop a 🐦‍⬛ in the comments or share your own best practice for managing AI usage at scale.

Strategic Security: New Features from 3Mór

bfuller — Mon, 28 Apr 2025 19:28:39 +0000

Why Strategy Matters in Security

At 3Mór, we're guided by our namesake, the Mórrigan—goddess of strategy. Our mission is simple: to help you be strategic about security in the midst of complex technical stacks and objectives.

We've investigated why teams delay implementing Dependabot fixes or addressing CVEs. Beyond the overwhelming volume of alerts, we discovered something surprising: insufficient CI/CD infrastructure is often the biggest blocker.

The CI/CD Challenge

Many teams struggle with perfectionism when building testing frameworks. The vast literature on best practices can paralyze action—we overthink, over-discuss, and wait for perfection. This often leads to delayed implementation or over-engineered solutions. In a nutshell, perfect is the enemy of good.

During my time at Puppet implementing DevOps practices, we learned a valuable lesson: start by fixing one small repeatable problem. Automate that. Save time. Then build from there.

Our Solution: Order of Operations

In the coming weeks, we're rolling out "order of operations" recommendations to simplify your security journey. When you visit our Actions page for a repository, you'll see:

Tailored prompts for implementing security measures
Step-by-step implementation guides
Verification checklists for prompt engineering
Our recommended "happy path" with guardrails against AI hallucinations

Connecting Security and CI/CD

This approach directly strengthens your vulnerability management by:

Reducing your attack surface
Fortifying existing systems
Making major version upgrades manageable, not herculean

For vulnerabilities requiring major version bumps, we'll assess your CI/CD readiness and provide recommendations for necessary tests and linting—complete with prompts, checklists, and implementation paths.

Even when you're not facing urgent patches like Log4j, we'll guide you through strengthening your CI/CD pipeline—a critical security measure given that these pipelines are frequent targets for hackers, ransomware groups, and nation-states.

Join Our Early Testers

We're seeking early testers for these features. Sign up for our 90-day free trial to experience the value firsthand. After the trial, individual and small team pricing is $20/user per month, with special considerations for non-profits, schools, and government agencies.

Ready to get strategic about security? Let's talk.

Stop giving hackers the easy button

bfuller — Wed, 09 Apr 2025 00:03:07 +0000

I’ve been tracking the Salt Typhoon attack off and on. In part that’s because I’m a customer of one of the telecom companies impacted. Also in part because I’ve been seeing an uptick in attacks that use Advanced Persistent Threat (APT) methodology. After digging in a little and learning about more APT attacks that are impacting our infrastructure, I wanted to understand what I can do.

The quick explanation of an APT is they find a way in via a known Common Vulnerability and Exploit (CVE) and start to traverse through the stack until they get to the information they want. As they traverse, they cover their tracks so they can hang out. It’s like a woodboring beetle. Here is a link to a technical description from Crowdstrike. The attackers are patient and have a specific goal in mind. Whether it’s an infrastructure attack like with Volt Typhon or Silk Typhoon targeting IT supply chains.

Prevention is a long, tedious game but there are some simple practices you can put in place. It’s kind of like dealing with dishes, laundry, or weeding your garden. It can become overwhelming unless you set up a routine to take care of the day-to-day. These are your best practices.

Strong access control and user authentication
Endpoint Protection
Internal education around phishing and social engineering
Monitoring of suspicious activity
Vulnerability management

I’m going to focus on one aspect of the hack, the fact that they compromised existing CVEs. I know that vulnerability management is a chore. It’s easy to let time pass and assume since nothing happened, you are safe. The risk of not remediating includes increased risk of data breaches which have an average cost of $4.88M! And also ransomware attacks. Not addressing CVEs negatively impacts your compliance for critical regulations like HIPPA, PCI DSS, and GDPR.

Vulnerability management is like tending a garden. When I weed my strawberry patch, I’m rewarded with strawberries in early summer. But weeding isn’t enough. Strawberries need friends to help add nutrients into the ground and plants that deter pests. Companion plants and coffee grounds are the best practices in action.

Celebrate the small stuff

There is no reward for avoiding incidents. My suggestion: celebrate the small stuff! As DevOps and Security teams we understand that technology is deeply connected, whether it’s through companies like Blue Yonder or our use of open source software. DevOps teams are master gardeners.

Before we can talk about solutions, we need to understand why fixing CVEs in a timely fashion is hard.

Fragmented data across multiple scanning tools
Risk scores not being relevant to the company's technical stack
Finding the teams to fix the problem is just hard

For more details check out the blog, “Swimlane report finds 68% of organizations fail to remediate critical vulnerabilities on time.”

Ok, now that we get the problem, let’s talk about steps to get you started on the right path.

Find the right tools. I follow the Portland growing zone 8b to know when to grow my plant starts inside vs outside. Which means I do things differently than friends in LA, Alabama, or Ohio. Your tools need to fit your unique technical stack. Tools that simply scan but don’t provide intelligence based on the unique technical stack configuration, are going to make keeping up to date on vulnerability remediation hard. Luckily, there is a new generation of tools on the rise.

Here are a few companies taking a unique approach for you to check out:

AppMap Instantly scan your AppMap data for security gaps and attack vectors.
DryRun Security Helps you uncover risks that pattern matching SAST tools miss.
3Mór Maps and prioritizes CVEs based on customers' unique code & infrastructure.

Find your community. Once you have the right tools, you need to find ways to sustain the project long term. Like weeding your garden if you let it go too long, the weeds win. I like picking fresh strawberries on a warm summer day. To get those, I need to pull weeds in the cold and rain. Weeding is boring. I like to track and celebrate my progress.

Support Open Source. Don’t reinvent the wheel, follow the Golang community which has gardening days. Set up some gardening days that are dedicated to squashing those CVEs internally and in partnership with open source projects.

Celebrate the small stuff. Set a milestone and how you’ll celebrate achieving it. It’s hard because companies don’t often recognize the incidents they missed. You need to make time celebrate your prevention efforts.

As Former NSA Director, Gen Nakasone said, “You know, after decades of talking about hygiene and patching, the software is not getting that much better and the attack surface is only growing.” I’m confident that the DevSecOps community can get us to a good place, quickly. Find the tools that work for your team, set up those best practices, create a plan, celebrate the small stuff. You’ll have fewer security incidents and will be better prepared when one happens.

Hack the Planet as a Service

bfuller — Fri, 07 Mar 2025 01:13:57 +0000

Risk is complicated. Everyday life is full of risk, we just don’t think of it that way. With the state of the world right now, I sometimes wonder if there are so many risky things that we tune them out. We know that alert fatigue is real, but maybe we have hit a point where we don’t even see the risks until they impact our day.

Things have escalated to the point where we have a thriving Ransomware as a Service industry. At a certain point, it can feel like, why play whackamole? In corporations, teams feel like it’s easier to wait for something bad to happen. As individuals, we know that our personal identifying information is now in the hands of nation states through breach after breach after breach.

So much so that when the US government banned TikTok in the US due to security reasons. The pushback from users was pretty loud: “That’s fine, I’ll send the Chinese government my data myself.” FWIW, I thought the ban was rubbish, but that’s a topic for a different day.

It was a fascinating few months to see such swift action by the US Government to fix “security” followed by a curious set of EOs and actions that actively removed the safeguards being put in place at the speed of government.

All of this got me thinking about categories of risk. This category is vast, but I’m going to focus on a few kinds of risk that impact our DevOps/SRE teams.

So, let’s break down some of those ways. I’m specifically not addressing the security risk of tools that manage the supply chain. Think of tools like Blue Yonder. They are an obvious target for ransomware attacks because of the one to many relationship. Not to be confused with supply chain management.

With that in mind, let’s break down some of the most common risks we face on a daily basis. Risk we have control over.

Deployments: What happens when we don’t have the right guardrails in place? Mostly, nothing, but when it goes bad, it goes really bad.

Dependencies between services or repositories are so tricky because teams are like, eh, I sort of care, but do I care? The catch is that it matters when you are building out proper CI and CD. I sometimes wonder if we stop at CI because the connectivity of our code makes CD too hard to manage.

Best practices vary. A Reddit thread

Vulnerability: Oof, I get it, that spreadsheet of doom is miserable. How do you decide what to take care of? Do you have enough information to make informed decisions? And really, the only piece of secure tech is the tech that is unplugged and buried in cement. That said, it’s important to be smart about your approach when you have a growing industry like RaaS.

AI: Everything that can be used for good can be used for bad.

Maybe this makes you feel more anxious instead of less, but here’s my advice, like anything, pick what’s important to you. Understand your risks. Find the tools that make your life easier and split the load. We talk about shifting left, but maybe it’s less "shift left" and more you own this piece and I’ll own the next.

I continue to believe that we are better together, but we need to understand what’s at stake, how to help, and how to play to each other’s strengths. 3Mór is helping to address many of these risks. Whether you feel security is a vitamin or a painkiller, it will impact you in some way, shape, or form.

Let's get messy

bfuller — Mon, 20 Jan 2025 18:49:24 +0000

I want to take a moment to shout out to all the people who are not working with all the latest tech. You know, like at most companies.

Anyone who has been in the tech space for any length of time knows that once you build the foundation of your company that’s it. That’s what you have. The rest is context, language, and maybe a little acceptance. I think this is where the discussion of technical debt or something else is critical. Emily Rosengren has a great talk called “Can We Please Stop Talking About Tech Debt?” It’s amazing.

I think of it this way mostly because I enjoy “classic cars” — the minute you drive a car off the lot the value drops significantly.

But the reality is you can drive that car for your lifetime and pass it on to kids, cousins, neighbors, with the right care and attention. With some bits being replaced or rebuilt over time, cars last a long time. The same goes for tech. I like to think of these stacks as the tech version of a 1968 Camaro. It’s a solid car. Ok maybe more like an International Scout? You get the idea.

Just like a 1968 Camaro you need to have the right tools, documentation, or someone who has enough experience to guide the team. As Emily talked about, context is everything and language matters. Understanding what tradeoffs are the best for the stack you have is what’s important.

Old tech isn’t the problem. Southwest airlines avoided the Crowdstrike outage because they are using a version of Windows that predates Clippy. Ok that might not make you feel better. Let’s take the Mars explorers. They aren’t using the latest tech and they landed on Mars, took samples, pictures, and brought all of us a little bit of joy as we watched the rover roam Mars.

All of that to say, you are doing a great job and hindsight is 20/20. Maybe your stack runs on an old version of Ruby or Python and you are just now starting to set up CD. That’s HARD and more importantly, you need the context relevant to your stack in order to make appropriate decisions on policies when building out CD pipelines. You get to be more creative in your implementation.

For us at 3Mór, we know that there are amazing tools to help people on the newest versions of their stack and we LOVE this. We are focused on tidying up the rest of your stack. As we start looking into how to identify dependencies, there are tools we can integrate for Python and after that we will look into Ruby. Our role is to augment what you have, and surface up the context you need to make the hard tradeoffs.

And remember that AI isn’t running on the latest and greatest versions. AI is constantly living in the past.

3Mór: How we started with Valkyries and ended with a Goddess

bfuller — Mon, 13 Jan 2025 20:53:53 +0000

I’ve had a few people ask how to say our company name 3Mór. But really Mór is short for the Mórrígan. When thinking about the values of our company, there are a few things that are top of mind.

We are better together. I believe that with my whole heart. Our differences in thought and experience make us stronger.
There is a predictiveness with how we work in tech — if you follow the thread you can see how “the fates” brought us to that point.
History is everything! Our past choices are what brought us to where we are today. Which isn’t a bad thing.

Sometimes I think we work too hard to forget how or why we got here. Almost ignoring the parts of our stack or history that are the workhorses, the warriors and the mistakes.

Alice and I are building a tool to provide those insights where once you see it, you can’t unsee it. It’s the holistic view of how your stack works and how the people work within it. It’s the threads of connection between team, code, and infrastructure. Just like those pesky threads of fate. Once you put all that together, the pool of potential names for our company becomes much smaller!

Initially we were going down the path of an Oracle or Valkyrie, but those were taken. The Mórrígan, she’s the best of both worlds. You can expect us to use crows, knitting or other related references from here on out.

The Mórrígan is one of the triple goddesses which made her an even better choice being we are focused on making the lives of our DevSecOps teams better.

Who are the three goddesses? Morrigu is the goddess of battle, Macha is the goddess of sovereignty, and Badb is the goddess of prophecy. There are many other interpretations of who the three are, with Nemain often switched for Morrigu. Nemain is the goddess of frenzy. For the purposes of company name, we went with the Morrigu interpretation. Although a goddess who is a bit of a berserker is fun reading.

As Alice and I assessed how to address the problem of vulnerability hell and reduce incidents, we realized that the problems of these three personas are deeply related. This is evident in all the movements from DevOps to DevSecOps to Shifting Left. We are doing this with a people-first approach. Focusing on reducing risk, reducing operational cost through strategic observability. Which centers the holistic quality of the stack (sovereignty), and proactively identifying and remediating problems based on the context of your stack (prophecy and battle). See? 3Mór. It makes sense.

Automation for the People

bfuller — Wed, 08 Jan 2025 17:26:52 +0000

I was catching up on the SREcon EMEA talks and Courtney Nash’s Exploring the unintended consequences of automation dives into why automation doesn’t always do what we think it’s going to do. Automation creates more complexity. More automation means we need more infrastructure to make sure the automation is automating correctly. Hello drift! This requires a person to understand when things have gone off course.

The slides that are most relevant to this blog are the ones talking about what points a human had to intervene with an incident on behalf of automation. Meaning, automation was the cause of the chaos. Think about that for a minute. We know the cost per minute of incident can be as high as $9,000/minute. That’s up from $5,600/min a few years ago. It’s clear that since we started automating, using the cloud, and now using GenAI things have been a little “hold on to your hats”. 🤠

After years of managers wondering if they have “the DevOps” because they bought a tool, we realize through time and data that we do not in fact have the DevOps. 🤯 This is mostly because we thought a tool or automation was the DevOps when really there is a symbiotic relationship between people and automation.

3Mór is creating tooling that helps your team surface the complexity you are facing and make it actionable. We give you the map, project list, and a few starting points. We are doing the wildly boring work of helping you stair-step your way to a tidier stack. And for those complex bits, we surface the context you need to build more effectively and securely.

We provide the conversation starter for Ops and Security to collaborate on how to address your vulnerability hell. We bring visibility so that your Devs see where they fit into the whole without forcing them to be Ops or Security.