I've built quite a few projects from 0 -> business over the last 20 years, and I think the fundamentals are still true today.
First rule: if you're building the product solo, is it something you're the target user of? I've always felt like the biggest "cheat code" for building successful products is just making them for people like you. I know that goes against a lot of lean startup methodology (talk to users, etc.), but it has always worked in my experience. Use your unique domain knowledge to make something meaningfully better, cheaper, more accessible/simple than the competition.
Second rule: marketing is important. Almost all the things I've built are developer services, so to get user feedback and early traction, I'd submit to go speak at the local meetup groups in my area, talk about the tech stuff I worked on as part of the product, then give people a free shirt if they'd give me some in-person feedback after the event. I made some good friends that way (hello, SoCal Pythonistas!), and also made meaningful product growth. Don't be a shill, just genuinely nerd out about the things you're doing in an authentic way. People like that.
Third rule: write well. Don't use LLMs to spam blog content that's low quality about your product. Write about it yourself. Show examples, highlight features. Don't use marketing words, use simple descriptions.
I truly believe that the product will be better if the author is the first targeted user.
> AI coding tools moved the ceiling.
I'd say AI coding tools raised the floor, not the ceiling. Building a product with great UX is still difficult and demands constant attention to detail.
Marketing is the hard part.
Ideas are trivial. Code is easy (and now with AI trivial.)
Most humans do the easy part first. It's the most fun. Lots of people can play a guitar. Only a tiny fraction market enough to make any money.
If you want success (in anything) learn (and do) the hard part first. Every product idea starts with 3 basic questions;
A) who is this for?
B) how do I reach them. Prove it by getting 10 names, email addresses, and nominal deposits.
C) can my target market afford this? Poor people need private jet transport, but that market cannot afford that product.
Writing the code is the last thing you do, not the first.
Assuming of course your goal is to make money. I make ceramics for fun, not to sell. I get the joy of making and using my own pots. It's a hobby, not my day job. I'm not interested in marketing or selling them. And that's perfectly OK.
One question I have on the `tool boundary` methodology -- does this penalize a skill for having any sort of scripts/ embedded? I've found it really helpful to take larger skills, like ones I've built at Snyk which handle data processing, and encode the process in the SKILL.md, but also ship it with python/go code in scripts/ to deterministically handle a lot of data validation/etc. For data analysis skills I feel like it's really hard to just encode teaching logic without costing a fortune in inference.
Good post, breaks down the threat models really well. =)
One small note, I think there may be a small issue in one of the code blocks explaining the client key:
> cache_namespace = tenant_id || client_secret
I believe that should say `tenant_id + client_secret`, ya? To append them together? If you OR them out it'll default to the `tenant_id`, which isn't what you want in this case, I believe.
=0 I stumbled across this post and was thinking that it's interesting to see this topic trending now, since I've done a lot of work on it in the past. Then I clicked through and realized the author is linking to some of my stuff! What a blast from the past.
Anyhow, there are way smarter people than myself who have covered this topic extensively over the years, but I still think that, even in 2026, JWTs are the wrong tools for web auth. They're fine to use for service-to-service stuff, but if you have the option, just use PASETO -- it solves a lot of the issues!
Straight white US citizen male here. This scares the shit out of me. I travel for work all the time, but understanding that we will now have barely trained, and in many cases completely lawless, consequence-free federal officers in direct, high stress, public areas where lots of people are constantly passing through seems like an absolute recipe for tragedy.
This will 100% make me reconsider travel and avoid airports with ICE agents. I think the writing on the wall is clear, nobody is safe.
Throwaway accounts and more propaganda isn’t proof of anything. I think it’s pretty clear that untrained, unaccountable armed people who have already killed multiple US citizens that they have no jurisdiction over is a real-world worry that people have.
It’s silly to dismiss rational, logic-based worry as “propaganda”.
> Yes US citizens that are putting themselves in a situation they shouldn’t have been in to begin with while threatening and provoking a violent reaction.
This is not at all true. Plus, it's inconsequential -- ICE agents have no authority over US citizens except in extremely limited circumstances (https://www.perplexity.ai/search/9f4518c4-8a32-474a-bd92-3f1...), and even if they did, being able to arrest someone, file charges, and work their way through the justice system is the answer... Not killing people on the streets.
Hot take: I am 100% legally allowed to equip my sidearm and go follow ICE agents around wherever the fuck I want and scream obscenities in their face literally all day long, 24/7.
This is such a great idea. When I'm building net-new projects, I typically end up working with the AI assistant to build a comprehensive AGENTS.md as the first thing before any work gets done: specify tools, dependencies, architecture requirements, style, etc.
I end up getting way better quality.
The same is true for existing projects, but it always takes a whole lot longer as I'm typically chatting with my AI assistant to figure out what conventions are there that I forgot, etc., before building an AGENTS.md to make future changes simpler.
Thank you!
The idea is that static analysis can recover most of the mechanical truth of a repo (stack, commands, layout), and then you can layer intentional constraints on top if you want. If this saves even a few of those back-and-forth setup chats, it’s doing its job.
Feel free to contribute if you find the right fit
He also taught me networking in C in the early 2000's! A few years ago I moved from the Bay Area up to Bend, Oregon and ended up running into him in-person at one of the tech meetups.
I was so floored to meet him in person, and as you'd probably imagine, he's super kind and relaxed =D
A++ human being who's contributed so much to our field.
At Snyk, we've been working on this for a while. Here's our flagship open source project consolidating a lot of the MCP risk factors we've discovered over the last year or so into actionable info: https://github.com/invariantlabs-ai/mcp-scan
ALAN
It's called Tron. It's a security
program itself, actually. Monitors
all the contacts between our system
and other systems... If it finds
anything going on that's not scheduled,
it shuts it down. I sent you a memo
on it.
DILLINGER
Mmm. Part of the Master Control Program?
ALAN
No, it'll run independently.
It can watchdog the MCP as well.
DILLINGER
Ah. Sounds good. Well, we should have
you running again in a couple of days,
I hope.
I believe one of the main differences is that our scanner looks for toxic flows between mcp endpoints regarding how they interact with one another. Unless I'm missing something, the Cisco tool does not support this.
Our research lab discovered this novel threat back in July: https://invariantlabs.ai/blog/toxic-flow-analysis and built the tooling around it. This is an extremely common type of issue that many people don't realize (basically, when you are using multiple MCP servers that individually are safe, but together can cause issues).
Here's a better option -- what we've been working on at Snyk.
- Take something like Cursor and plug the Snyk MCP server into it: https://docs.snyk.io/integrations/developer-guardrails-for-a... (it has a one-click install)
- Then, either within your project or via global settings, create some human-language rules for your AI code editor to use (this works basically the same between all editors: Claude Code, Cursor, Windsurf, etc...)
For example, a rule might state:
"If you add or change any code, run a Snyk Code scan on the modified files then fix the detected vulnerabilities. When you're done fixing them, perform another scan to ensure they're fixed, and if not, keep iterating until the code is secure."
Obviously, there are other rules you can use here, such as using Snyk's open source dependency testing to identify vulns in third-party dependencies and handle package updates/rewrites/etc., but you get the idea.
This works insanely well -- I've been playing around with it for a while now and we're getting close to rolling this out to all of our users in a major way =)
The best part about it is that you can just "vibe code" whatever you want, and you get really accurate static analysis security testing incorporated by default automagically.
I recorded a little video here that walks through this in-depth (https://www.youtube.com/watch?v=hQtgR1lTPYI), if you want to see the part I'm referencing, jump to 20:09 =)
First rule: if you're building the product solo, is it something you're the target user of? I've always felt like the biggest "cheat code" for building successful products is just making them for people like you. I know that goes against a lot of lean startup methodology (talk to users, etc.), but it has always worked in my experience. Use your unique domain knowledge to make something meaningfully better, cheaper, more accessible/simple than the competition.
Second rule: marketing is important. Almost all the things I've built are developer services, so to get user feedback and early traction, I'd submit to go speak at the local meetup groups in my area, talk about the tech stuff I worked on as part of the product, then give people a free shirt if they'd give me some in-person feedback after the event. I made some good friends that way (hello, SoCal Pythonistas!), and also made meaningful product growth. Don't be a shill, just genuinely nerd out about the things you're doing in an authentic way. People like that.
Third rule: write well. Don't use LLMs to spam blog content that's low quality about your product. Write about it yourself. Show examples, highlight features. Don't use marketing words, use simple descriptions.