Nick Khami 3 months ago

Engineering Management 101

I started as an "engineering manager" (more on my personal feelings for the title later) about 9 months ago. Prior to that I was a founder/CEO. The peak size of my team as a founder was 8 and the peak size of my team as an EM has been 9. So I would say that at this point I have around 3.5 years of total management experience. I think being a "manager" is mostly the same as being an IC, but with additional responsibilities like managing headcount, budget, and providing coaching. You're also expected to do things like executive writing, speaking engagements, vendor procurement, 1:1's, team bonding events, shoutouts, and project planning that you wouldn't have been responsible for as an IC. Personally, rating myself on the Dunning-Kruger chart, I think I'm about here right now. I still ship code, write product specs, write engineering specs, approve PRs, and post on socials. The biggest adjustment from CEO to EM was the responsibility change, specifically not being responsible for fundraising. Thankfully, I didn't particularly enjoy fundraising. In general I just like working hard and solving problems so there's nothing specific that I really care to focus on or maintain doing. In the future, I could see myself fundraising again. I subscribe to the servant leader approach to a large extent. To me that means my priorities are: Even when it comes to 1, I am usually motivated to make the business grow because it means that there is now space for the folks I support to be promoted. I also really resent the words "manage" and "report to." I think they create a hierarchy that doesn't really exist. I use the term "support" instead. Once you're not the IC actually doing the thing, you immediately have less authority over how it gets done. I basically acknowledge that at this point I make general suggestions for things and then people decide to what extent they want to listen. Usually their instincts are right. I hired well at my startup and Mintlify hires well too. That said, people definitely aren't "reporting to" or "being managed by" me. When someone ignores my suggestion and their instinct turns out to be wrong (which is rare in my experience), usually it just comes out as the work being less successful than it otherwise would have been. What I care about in this case is that they acknowledge that they'll try something different next time. Sometimes that's my original suggestion and sometimes it's not, but what's important is that there's a learning. One thing I used to believe is that you were also a servant to those who are supposed to be supporting you. I no longer believe that. You should support who is supporting you, but not serve them. Keep your own priorities intact in places where you might otherwise discard them for someone you have explicit leadership responsibility to. I have two expectations: To help people skill up, you usually have to do some amount of the work for them then hand it off. So, for example, you make a half-finished markdown doc with a list of issues then you hand it off and the person you're helping to skill up finishes it and gets tickets into the issue tracking system. This method is often described as founder mode'ing . Or, if they are very junior, you can get a PR into draft state such that they can finish it. You slowly get them to 100% of the task by doing it repeatedly with this handoff method scaling from them doing 10% then 20%, and so on. Then, following, support them such that they can maintain 100% of the task's complexity for 6 months without burning out. I reject the whole frame of throwing people you support into the deep end with a "what doesn't kill you makes you stronger" mindset. I think there is failing and it's incredibly important to fail. But that should feel like a comfortable and supported experience instead of a painful struggle. People grow more in healthy and supportive environments. Sometimes people who move into "management" start thinking work is beneath them. They take so many meetings and burn so much of their time writing docs that people don't read that they stop actually getting work over the finish line. When you see someone struggling who you are in charge of supporting, you have to get in there and embrace the burden so you can support them in digging their way out. This is the most important part of the job. Occasionally I see a project where no code goes out to production for an entire day. In these specific cases I always will jump in and get some work over the finish line. Or it can be gigantic issues in the issue tracker that need to be broken down. I'll just go in and break them down myself. You have to parachute in sometimes. I don't like the signal that I am taking over and now have distrust, but if you are being earnest about it and doing it in a way that is supportive, then you can avoid those bad vibes. You just need to communicate clearly and explicitly explain your intentions. "Hey guys, I see that we haven't gotten any PRs in. I'm going to help kickstart the process. If I'm stepping on your toes or repeating work here, please let me know." My hot take in management is that 1:1s are not entirely the meeting of who you are supporting. Of course it's their meeting if they push and take ownership of it, but I have personally rarely found that to be the case. I usually ask what they're working on, what they want to do better, what they would want me to do if they could wave a magic wand, and what feedback they have for me. You likely shouldn't fight overly hard to surface interpersonal problems if they aren't brought up somewhat naturally. It's much more important to focus on helping people actually complete their work. The job of an IC is to get contributions out into the world for people to use. Focus your energy on supporting every aspect of that for the person you are working with instead of magnifying problems interpersonally to the extent you can. Of course, if there are major issues then you need to address and work those out, I just personally err on the side of caution here. Increasing pace and getting work shipped usually solves most problems in my experience thus far. But again, Dunning-Kruger, this out of all my opinions is where I think I will continue to evolve my thinking the most. I have a few techniques I like a lot. Replace standup with an async todolist Slack channel. Have people post a list of what they are doing every day in the morning instead of having a synchronous meeting. There are many reasons for that which I explain in the linked article. Write a monthly brag doc for everyone you support. I do this after every single month. It gives me a clear picture of what each person did and I often change my opinions on performance level when I write them. Throughout the month you can just lose track of things so it's really important that you confront your biases on a recurring basis. I use the Slack MCP and Claude Code to look back through everything and compile all the information. AI has really changed the game here. I frequently redirect conversations being had over DM into public channels. I see a lot of my job as supporting the folks I am responsible for in feeling secure communicating there in public. Ultimately it's incredibly important that their contributions are visible to the entire org as much as possible. Sometimes when I redirect, people feel like their idea isn't clear enough. So you can rewrite their message into something clearer and say "hey, would you be comfortable sending this?" People need reassurance that if they make mistakes, you will cover them. Which I do. You have to really encourage the act of failure. No successes will ever happen if people don't feel comfortable failing. Limit testing in a corporation is not natural for most, so it's your job as a "manager" to encourage it. You want people to find the level of complexity where they either don't know what to do or mess up. If they don't get there frequently then they won't have rapid skill growth. In my opinion, leveling (by title) primarily exists so people don't feel awkward. You want everyone to have clear and fair expectations for themselves and those around them. When someone is overleveled, there is tension because people try to hand off work or get help from someone who is supposed to be at a higher skill threshold than them. But in reality they are not higher skill and it's just an awful time for everyone. Then, when someone is underleveled, there is an issue where that person becomes restricted in how much impact they can actually have. Instead of scaling themselves and spreading techniques and processes, they leave your company for another job, start doing work on the side, or just quiet quit. Occasionally a super motivated person will stick it out, but I think that is relatively rare and ultimately not in their best interest. Anyone who is able to do that without a company change is incredibly high grit and special. Rarely can you demote someone. More often than not you just have to fire. When I have had to fire, it is usually because of two things. There is either a lack of will -- someone just can't summon the energy to try -- or it is a lack of skill. Almost always I have learned when firing (including myself out of being a founder/ceo) that for some reason or another there is a lack of will. People get stuck and stop taking actions altogether. When it comes to underleveling, you never want to promote too fast. I am very firm on 6 months of sustained performance. When people have asked for faster, if they are crushing it and you need to promote to retain them, then do it with compensation instead of title. I think the best founders and managers are not naturally bossy people. Rarely are you successful when you come across as domineering. To that end, founders can often struggle with being in a drive by management mode trying to get work done. They sometimes feel overly shy about being bossy. They want everyone to take high ownership of problems and therefore default to understeering. The problem is that without explicit framing, people misinterpret fyi's as plea's or plea's as fyi's. Wade Foster from Zapier has a great system for preventing this. #fyi : something interesting. An article and podcast, etc. I thought you might like it. But if not no worries. Nothing to see here. #suggestion : a passing thought. I sometimes have good ideas. You might like to hear good ideas. If I'm in your shoes, I consider it. But I'm not in your shoes so do what you'd like. A friendly response if you don't go with the suggestion is nice, so I make better suggestions over time, but is by no means necessary. #recommendation : I've thought a lot about this. Perhaps even lost sleep. I've invested deeply. I think this is a good plan. You can still disagree and go a different direction, but walking me through why you are doing this is kindly requested. #plea : We don't have a lot of mandates at Zapier, but this is one. Please do this. If you disagree enough that you can't go along with it, we should both reconsider our roles here. It's that important. I use #fyi and #suggestions all the time. #recommendation much less so. And #plea is almost entirely unused. I learned it from Andreas Klinger who is a great follow on X by the way. Whenever I am communicating directionally, I explicitly callout where I'm at from fyi to plea. It's rare I exceed a suggestion, but does happen. Plea's usually at most once a quarter. You cannot burn your social capital being at a recommendation or above all the time. People will just get annoyed and quit or stop taking you seriously. I strongly suggest you adopt some system like this when you begin supporting people as a career path. I think building a personal brand is an incredibly important part of being a leader. You want to be known for things. You want to have a reputation. You want people to understand your values and what you care about so they can properly assess how to engage and work with you. If you expect to be able to change companies or orgs and continue leading, then it's important there is an incredibly public track record of your work. Unlike being an IC, you are rarely directly "shipping" things when in manager mode, so you need to have social influence beyond. Good leaders can own go to market for their projects and part of that is having a personal brand. This was true before social media when you would write columns in newspapers and it's even more true post-social media when you can build a huge following from your phone in the moments between spinning up your favorite coding agent. I fall on the become a thought leader end of the spectrum. You want to have trust both internally at your org and externally with peers in your industry that you are first-principled, make rational decisions, and can be trusted to own blame for your own decisions and those of who you support. If you don't have a personal brand then I do not think you would be able to escape middle management. Getting to a manager of managers level in my opinion requires a personal brand to some extent, likely closer to the thought leader end of the spectrum. You can be a great IC with no personal brand. I think that's the appeal of staff IC. But for leadership, you do, unfortunately, need to build one. Look at Bill Belichick, famously terse with media during his Patriots tenure, then immediately started his own podcast and network TV appearances once he was out to justify another coaching role. Same for JJ Redick, built a massive audience as a podcaster soon after retiring from the NBA, then parlayed that into coaching the LA Lakers. They built credibility through public performance at first by being on professional sports teams who had games broadcasted on primetime TV slots and then, once that was over, they pivoted to alternative media forms prior to getting back onto a high performing and visible team. Post instead of cruising early and dodging media like they did, because odds are that you're not an athlete performing on primetime TV every week. You need to build your brand through other channels. I am always pushing the people I support to build and write in public. If someone is resistant to it, I let it go. It's not a hard requirement unless they are going from manager to manager of managers level. My personal brand, in my opinion, is a strong attracting force for hires and customers. It's effectively a marketing channel for the business, particularly for brand marketing. The ROI is hard to attribute directly, but it is certainly there. I spend between 10 to 20 hours a week outside of the 9-5 work hours on personal brand. Writing, recording, commenting, and scrolling. I think of scrolling as research. It's very intentional. Final note on this, if you do decide to work on a personal brand then you'll find that some people don't like your style. I think that's fine and you shouldn't worry about it. The beauty of the brand being personal is that it's yours and not everyone has to be aligned with it. Do whatever you're comfortable doing. Ignore haters. If you take nothing else away from this post, please let it be this section. I think the best "managers" (🙄) are optimistic and positive. They earnestly want to contribute to growing the organization they are at and the people they support. I heavily disagree with Sean Goedecke's writing on management. He overindexes on politics and managing stakeholders which I think is incredibly cynical and short-sighted. Nothing good is going to happen from analyzing and kissing ass all the time. High performing teams and organizations are all aligned in being high action and throughput. If you are high action and throughput then, in my opinion, things usually work out. Of course, that is to an extent. Be a good person, be kind, apologize when you make mistakes, buy people gifts when they do things that help you, say thank you, say please, say good morning. Don't be a cold and unfeeling curmudgeon. But do also primarily focus on doing your best work and putting things out there into the world. Everyone wants to solve problems and build cool shit at the end of the day. Or well, at least everyone I would be excited to work with. Help the business grow Get the people I'm supporting promoted People who I am supporting skill up to get promoted. Usually this means embracing additional complexity. As a software engineer that can mean hiring, doing planning, leading and making sure the right work is prioritized throughout, or owning product by interviewing customers, having vision, pitching, etc. Once they reach 100% ownership of a new skill level, they maintain that performance proactively and without active support for 6 months leading up to a promotion.

Business Career

▲ 0

0 views

Nick Khami 4 months ago

Startup Marketing 101

Everyone in startups has heard the advice: "don't tunnel vision on product, make sure you do marketing." If advice were a horse, that one would have been beaten dead a decade ago. Some version of it appears on my X feed every single day. I heard this constantly while founding my previous startup Trieve , and I bought into it. You can find old TikTok posts from August 2023, four months before we raised funding or got into YC. Then, ironically, some switch flipped once we became venture backed. The posting stopped. We turned inward and focused on product. It saddens me in hindsight, because our product was getting a whole lot better at exactly the moment we went quiet. Startup media and accelerator programs create an expectation of a "launch" event, think of TechCrunch Disrupt in the Silicon Valley TV show , Supabase's infamous "launch week" , and of course the OG themselves - ProductHunt . I'm kind of an idiot and let being "post-fundraise" change my mindset. We felt like we had the capital to just burn money on ads when it made sense and therefore went heads down building in silence for some number of weeks to then pop our heads out once or twice a month and do a big launch event. That was, without question, horrendous strategy and terrible CEOing on my part. The best comparison I can think of is composing a song out of nothing but thirty-second rests and cymbal crashes. People tune you out. Good marketing should feel more like an EDM track: a steady beat with the occasional drop. You want consistent content that people can engage with, punctuated every so often by a big announcement that gets them excited. You can post and launch all of the small things you ship along the way to the final product. Get the login page working? Post about it. Add the ability to invite users into your org? Post about it. Put new actionable insights in the dashboard? Post about it. Each of these is a chance to build awareness and improve your yapping abilities, so once your product is finally stable and working, you have the skillset and audience necessary to get a base of people familiar with it and excited to share. The alternative is to put all your eggs in one basket and wait until you have a big announcement to make. This is the strategy that most startups follow, and it is a high-risk, low-reward play. If your launch goes viral, you can get a huge boost in awareness and users, but content on social media is rarely evergreen and gets buried in feeds quickly. Your best case scenario is a couple days of electricity in return for weeks or months' worth of work. And, worst case, your launch falls flat and you get literally nothing out of it. I hate to quote Roy Lee, but he's not wrong when he says "most of u tech ppl are doomed to be ngmi forever on x. ur just not funny or sarcastic or arrogant enough for this place" . Founders, including myself, are typically nerdy software-engineer type folks who are boring to the extent that building a personal brand on X or elsewhere is going to be a struggle. However, I'm here to tell you that with enough failure, any skill issue can be overcome. It takes a lot more effort than being naturally interesting, but you absolutely can activitymax your way into an audience by posting a lot, replying, and engaging with people active in your niche online. That's not to say you can post terrible content nobody likes and succeed, you definitely do still have to aim to entertain, but you can pick that up as a skill over time. You just have to be comfortable posting into the void for a while until you start to figure it out. Failure is part of the process with marketing the same way it is with everything else. The light at the end of the tunnel is that success on social media tends to compound. While it's true that social media feeds are more competitive than ever and no longer show your content consistently to followers , there will be some people who consistently engage with your content and see it day after day. Their engagement kind of serves as a core that makes your content count as a live shot on goal, so the platform you're posting on at least tests if your content resonates with a wider audience. The size of that "test group" gets bigger as your following grows, and you therefore start to more consistently go viral over time. Finally, I want to note that you should endeavor to not do this alone. Ideally you hire people or have co-founders and you all have different angles and audiences, so you can test different messaging and content styles to see what resonates as you build. Imagine you have a classical cast - engineer, designer, and businessperson. Engineer can post knee-high sock photos about how you're using Rust btw, the designer can share overdone figmas nobody's ever going to build, and the businessperson can complain about how they were rejected by 67 VCs before getting their mom to finally write the first check. Over time each person's social graph will grow in different directions and you'll be able to test product marketing messaging with different hooks and audiences to see what resonates the most so you can double down on the best possible angle for the big launch. Think jackass for startup marketing. Host an event once you know what you're building. If you put some money behind an open bar and a DJ and message some people an invite, you can usually get a pretty good turnout. You want to do your best to get people who you think have the problem your product solves to show up, but even if you just get a bunch of friends, it's usually worth it. At some point, probably about a third of the way through the event, grab a mic and talk for a few minutes about what you're building. Don't bother with a demo or presentation or video, just talk naturally about why you decided to nuke your future career prospects and work 996 for a 1% shot at building something people want. If you can get a few laughs and make it feel like a fun story, people will be more likely to remember it and share it with their friends. Use something like Partiful to manage RSVPs and send reminders, and make sure to collect contact information from attendees so you can follow up with them after the event. Auto-enroll people who show up in your product newsletter and send them once a week updates about your progress. If you have a launch date, make sure to send them a reminder a few days before so they can be ready to support you on launch day. I like this one because it's pretty earnest and doesn't require being funny or clever to execute well. If you can throw a good party and tell a good story, you can get a lot of mileage out of this tactic. Hosting "VIP Dinners" also tends to be a pretty good lead funnel and functions in the same way. I think founders, including myself, are often stubborn when it comes to trend-driven marketing. We tend to feel like adding product features purely for the sake of "going viral" is a sellout move, and that we should only build things that are directly related to our product vision. While I do think it's important to stay true to your vision, I also think it's important to be flexible and adapt to trends when they make sense. On that note, I think competitive surfing rounds are a reasonable proxy metaphor for how to think about this. When you're in a surf competition, you're only going to be allowed to be out in the water for a certain amount of time, so you have to be strategic about which waves you choose to ride. You want to pick the waves that are going to get you the most points, but you also want to make sure you're not hesitating too long and missing out on rides that could be good but aren't perfect. You're always under similar time pressure in startups, if you miss a growth goal for a single quarter or sometimes even month then it can be a huge problem for your employee retention and fundraising prospects. Therefore, you can't afford to be too picky about which trends you choose to ride. If there's a meme or topic that's relevant to your product and has the potential to get you a lot of attention, you should probably jump on it and ship even if it's not perfectly aligned with your vision. On a lower level, my recommendation to get started on this is turning on post notifications for accounts in your niche that are good at this and more or less copying what they do. Reply to the same things they reply to, post about the same topics, and use the same formats. You can add your own twist to it and actually make product changes over time as you get more comfortable with the format and start to understand what resonates with your audience. If you take nothing else away from this, please for all that's holy, just post. It increases your odds of getting lucky and making it by orders of magnitude. And, odds are nobody's even going to see your content anyways, so stop worrying about embarrassing yourself.

Business Rust Marketing

▲ 0

0 views

Nick Khami 6 months ago

Replace Your Standup with a Todo List

Note: You can watch me write this blog post on video here on x.com! Standups create anxiety. You hoard updates during the day because you need content for the meeting. You forget your blockers. You adjust your schedule to be in early, even if you work better at night. I ran into this when I started my company. People join startups to escape corporate bureaucracy. When I tried to introduce morning standups, the early hires pushed back hard. It didn't feel like a startup move to them. Given that, I went back to the drawing board to break down the actual utility of the meeting. A standup exists to distribute context so a team can parallelize work and maintain synchronization. If that's the goal, you don't need a meeting. Here's what one of those messages looks like. As you work, you come back and edit the message to cross things off. Add timestamps if you want to track how long things are taking you or otherwise provide more context. That's it. Everyone sees what you're working on. No meeting required. Post your task list in a channel like first thing in the morning Edit the message to cross off tasks as you complete them throughout the day

Agile

▲ 0

0 views

Nick Khami 7 months ago

Working with Me

Several people have recommended I write a "working with me" document to help onboard new collaborators, teammates, and contractors and I finally got around to it. Here it is! I will always provide you with a quick response or answer, but will often go back and edit the message to clarify or poke at the topic with further thoughts over the course of the next hour or so. I believe word economy is important and try to be quiet if I have nothing valuable to respond with. Call my cell phone if you have my number. Otherwise, @ me on Slack. I strongly prefer that you call me though. Most of my texts are voice transcriptions and I tend to add emojis to communicate my intended tone. It's easier to get all that right over a phone call when things are urgent. My written communication can often be read with a tone I didn't intend. If you are messaging me on Slack, try to do it in a shared channel. DMs create communication silos and I think they are usually more harm than good. Very few things actually need to be private. If you send me a DM that I think should be in a channel I will often just forward it there myself and continue the conversation in that new location in front of a larger group. Please never send me a planning document. Communicate your idea in 3 paragraphs or less and text it to me. I detest opening 3 pages of workslop full of theory about an unstarted task. If you really can't get it to work in a single message, make a Slack canvas. Anything is better than a document which lives in another piece of software I have to sign into and open. I like recurring 1:1s when they are about moving towards goals. If we can set something up where one of us is working towards something and we decide on steps to get there, then a recurring meeting is useful to continuously sync on that. Progression is fun, and even more so when you keep track of it with someone who's invested in holding you accountable. I try to only give unprompted feedback when it's extremely specific and easy to understand. My mindset is that high-level feedback about a general topic or performance is only something that should be shared on request. Please send me any feedback you think would be useful. Specificity is always good. I will try to improve where I can at all times. Please try to do something and fail before asking me for help. I find it much easier to help when you are actively experiencing a problem and want to solve it rather than just wanting my thoughts. Speaking extensively about strategy before doing something is almost always a waste of time. I prioritize failure. You are usually some number of failures away from success, and I think you should try to get those over with as fast as you can so you reach success earlier. I get frustrated seeing people play it safe, always doing what they're good at, or ponder endlessly before closing the loop by launching and getting feedback. I tend to be skeptical, sarcastic, and kind of a curmudgeon. Complexity is something I avoid on principle, even when it will save me time. Newfangled toys are something I rarely find valuable. UX is important to me, but not so much UI. I would rather something be functional and easy to use than pretty. I don't think design is particularly valuable. Just solve the problem. I don't sleep all that much and am easily awoken. 3am–8am are the hours I am typically hard to reach, but if you call my cell phone I will usually pick up. Just call me! Direct pings are something which I always try to respond to as fast as possible. If it's important enough that you're annoyed with my response time being slow, again, call my cell. Writing, making videos, and marketing are the core skills I want to improve in the upcoming year. I would appreciate any feedback or ideas you may have for me in those areas.

Business Career

▲ 0

2 views

Nick Khami 8 months ago

Prompting the Agent Loop

The standard definition of an AI agent is "a language model which runs tools in a loop to achieve a goal." The critical insight is that your prompt should define the goal as a condition the agent can loop on. Compare these two prompts for testing a function : Without a loop condition: With a loop condition: The second prompt creates a fundamentally different interaction. The agent writes the test, runs it, sees failures, fixes them, and loops until the test passes. It handles the entire debug cycle without your input. Adding a blog post to your site: The agent writes the post, runs the build, and debugs any issues with frontmatter, file location, or slug until the build succeeds. Fixing an authentication bug: The pattern is consistent. Describe the task, describe how to verify completion, and tell the agent to iterate until verification passes. For tasks without automatable verification, ask for multiple iterations upfront: This is less powerful than a full verification loop, but more effective than a single attempt. With looping conditions, your role changes from QA tester to product manager. You define success and the agent handles iteration. Instead of checking each step, you describe the end state and let the agent determine how to reach it. The unlock is simple. Give the agent a condition to satisfy, tell it to iterate until the condition is met, and let it do the work.

AI

▲ 0

1 views

Nick Khami 9 months ago

XGBoost Is All You Need

import LLMFeatureDemo from "../../components/blog/XGBoostIsAllYouNeed/LLMFeatureDemo.astro"; import ModelComparisonDemo from "../../components/blog/XGBoostIsAllYouNeed/ModelComparisonDemo.astro"; import FeatureImportanceDemo from "../../components/blog/XGBoostIsAllYouNeed/FeatureImportanceDemo.astro"; {/* <!-- TODO: Add a more concrete opening story - maybe a specific moment at the startup where you realized asking LLMs for direct answers was broken? --> */} I spent two and a half years at a well-funded search startup building systems that used LLMs to answer questions via RAG (Retrieval Augmented Generation). We'd retrieve relevant documents, feed them to an LLM, and ask it to synthesize an answer. I came out of that experience with one overwhelming conviction: we were doing it backwards. The problem was that we were asking LLMs "what's the answer?" instead of "what do we need to know?" LLMs are brilliant at reading and synthesizing information at massive scale. You can spawn infinite instances in parallel to process thousands of documents, extract insights, and transform unstructured text into structured data. They're like having an army of research assistants who never sleep and work for pennies. {/* <!-- TODO: Add personality - maybe joke about why you picked this problem, or a detail about trying the "ask LLM directly" approach first and failing? --> */} Forecasting how many rushing yards an NFL running back will gain in their next game is a perfect example of this architecture. It's influenced by historical statistics (previous yards, carries, opponent defense), qualitative factors (recent press coverage, injury concerns, offensive line health), and game context (Vegas betting lines, projected workload). {/* <!-- TODO: Add personality - show a real example of ChatGPT giving a plausible-sounding but wrong prediction? Make it funny? --> */} You could ask ChatGPT's Deep Research feature to predict every game in a week. It would use web search to gather context, think about each matchup, and give you predictions. This approach is fundamentally broken. It's unscalable (each prediction requires manual prompting and waiting), the output is unstructured (you'd need to manually parse each response and log it in a spreadsheet), it's unreliable (LLMs are trained to sound plausible, not to optimize for numerical accuracy), and you can't learn from it (each prediction is independent—there's no way to improve based on what worked). This is the "ask the LLM what's the answer" approach. It feels like you're doing AI, but you're really just creating an expensive, slow research assistant that makes gut-feel predictions. {/* <!-- TODO: Add personality - maybe contrast this with how a human would do feature engineering? Show the "aha" moment when you realized this approach? --> */} Instead of asking "How many yards will Derrick Henry rush for?", we ask the LLM to transform unstructured information into structured features. Search for recent press coverage and rate sentiment 1-10. Analyze injury reports and rate concern level 1-5. Evaluate opponent's run defense and rate weakness 1-10. This is scalable (run 100+ feature extractions in parallel), structured (everything becomes a number XGBoost can use), and improves over time (XGBoost learns which features actually matter). I started with basic statistical features from the NFL API: yards and carries from the previous week, 3-week rolling averages, that kind of thing. These are helpful, but they miss important context. So I had the LLM engineer seven qualitative features: press coverage sentiment, injury concerns, opponent defense weakness, offensive line health, Vegas sentiment, projected workload share, and game script favorability. An agent loop with web search processed context about each player and game to populate these features—searching for news in the week leading up to the game and rating each factor on a numerical scale. <LLMFeatureDemo /> Once we run this process for every running back each week, we end up with a dataset that has both statistical and LLM-engineered qualitative features. {/* <!-- TODO: Add personality - what were you hoping for? What did you expect to happen? --> */} I split the data chronologically—early weeks for training, later weeks for testing—and trained two models. A baseline using only statistical features (previous yards, carries, rolling averages), and an enhanced model using both statistical and LLM-engineered features. {/* <!-- TODO: Add personality - show your emotional reaction to seeing these numbers. Were you shocked? Skeptical? Did you run it again to make sure? --> */} <ModelComparisonDemo /> The LLM-enhanced model reduced prediction error by 22.6% . The baseline model was actually worse than just predicting the average yards (R² of -0.025), while the enhanced model explained 38.6% of the variance. But that's not the interesting part. The interesting part is what XGBoost actually learned. {/* <!-- TODO: Add personality - build up the surprise here. Maybe say "I looked at the feature importance rankings expecting to see..." --> */} <FeatureImportanceDemo /> Six of the top seven most important features are LLM-engineered. The top feature is average carries over the last 3 weeks (statistical). The second most important feature is press coverage sentiment (LLM). Then game script prediction (LLM), Vegas sentiment (LLM), projected workload share (LLM), offensive line health (LLM), and injury concern (LLM). I didn't tell XGBoost that press sentiment matters more than injury concerns, or that game script prediction is more important than offensive line health. The model discovered these patterns on its own by analyzing which features actually correlated with rushing yards. The most predictive LLM feature, press coverage sentiment, captures momentum and narrative that doesn't show up in raw statistics. When a running back is getting positive press coverage, they tend to get more carries and perform better. XGBoost found this signal and learned to weight it heavily. This is the power of the hybrid approach: LLMs transform messy, unstructured context into clean features. XGBoost discovers which features actually matter. Neither could do this alone. {/* <!-- TODO: Add personality - make the transition to "this is actually a bigger problem" more dramatic. Show frustration with the current state? --> */} This isn't just about NFL predictions. Email prioritization, Slack message routing, pull request quality assessment, prediction market opportunities, customer support triage—every one of these problems has the same structure. Some structured data combined with unstructured context that needs to be transformed into a prediction. The architecture is identical every time: use LLMs in parallel to extract features from unstructured data, combine with structured features, train XGBoost to find patterns, deploy and iterate. Setting this up from scratch takes way too much time. I want tools that make this trivial—upload your data, describe what you want to predict, and get back a trained model with a deployment-ready API. {/* <!-- TODO: Add personality - make this section angrier? More pointed? This is your villain reveal. --> */} The tools I'm describing could exist today. The technology is mature and proven. So why hasn't anyone built them? Random forests don't raise $1B rounds. Founders are building pure-LLM systems because that's what gets funded. VCs get excited about foundation models and AGI, not about elegant hybrid architectures that combine 2019-era XGBoost with LLM feature engineering. This is the real problem with modern AI development. Not that the technology isn't good enough—it's that incentives are backwards. VC-led engineering is bad engineering. The best technical solutions rarely align with what makes a compelling pitch deck. Everyone's building the wrong thing because they're building what raises money instead of what solves problems. If you're a builder who cares more about solving real problems than raising huge rounds, there's a massive opportunity here. Build the boring, practical tools that let people deploy these hybrid systems in minutes instead of weeks. Build what actually works instead of what sounds impressive. {/* <!-- TODO: Add personality - end on a more concrete note? What are YOU going to build next? What do you wish existed? --> */} The future of ML isn't pure LLMs or pure classical ML—it's knowing which tool to use for which job. Don't ask LLMs "what's the answer?" Ask them "what do we need to know?" Then let XGBoost find the patterns in those answers. Want to see the full implementation? Check out the complete Jupyter notebook walkthrough with all the code, data processing steps, training, and visualizations.

AI Data Analysis

▲ 0

2 views

Nick Khami 9 months ago

Use the Accept Header to serve Markdown instead of HTML to LLMs

Agents don't need to see websites with markup and styling; anything other than plain Markdown is just wasted money spent on context tokens. I decided to make my Astro sites more accessible to LLMs by having them return Markdown versions of pages when the header has or preceding . This was very heavily inspired by this post on X from bunjavascript . Hopefully this helps SEO too, since agents are a big chunk of my traffic. The Bun team reported a 10x token drop for Markdown and frontier labs pay per token, so cheaper pages should get scraped more, be more likely to end up in training data, and give me a little extra lift from assistants and search. Note: You can check out the feature live by running or in your terminal. Static site generators like Astro and Gatsby already generate a big folder of HTML files, typically in a or folder through an command. The only thing missing is a way to convert those HTML files to markdown. It turns out there's a great CLI tool for this called html-to-markdown that can be installed with and run during a build step using . Here's a quick Bash script an LLM wrote to convert all HTML files in to Markdown files in , preserving the directory structure: Once you have the conversion script in place, the next step is to make it run as a post-build action. Here's an example of how to modify your scripts section: Moving all HTML files to first is only necessary if you're using Cloudflare Workers, which will serve existing static assets before falling back to your Worker. If you're using a traditional reverse proxy, you can skip that step and just convert directly from to . Note: I learned after I finished the project that I could have added to my so I didn't have to move any files around. That field forces the worker to always run frst. Shoutout to the kind folks on reddit for telling me. I pushed myself to go out of my comfort zone and learn Cloudflare Workers for this project since my company uses them extensively. If you're using a traditional reverse proxy like Nginx or Caddy, you can skip this section (and honestly, you'll have a much easier time). If you're coming from traditional reverse proxy servers, Cloudflare Workers force you into a different paradigm. What would normally be a simple Nginx or Caddy rule becomes custom configuration, moving your entire site to a shadow directory so Cloudflare doesn't serve static assets by default, writing JavaScript to manually check headers and using to serve files. SO MANY STEPS TO MAKE A SIMPLE FILE SERVER! This experience finally made Next.js 'middleware' click for me. It's not actually middleware in the traditional sense of a REST API; it's more like 'use this where you would normally have a real reverse proxy.' Both Cloudflare Workers and Next.js Middleware are essentially JavaScript-based reverse proxies that intercept requests before they hit your application. While I'd personally prefer Terraform with a hyperscaler or a VPS for a more traditional setup, new startups love this pattern, so it's worth understanding. Here's an example of a working file to refer to a new worker script and also bind your build output directory as a static asset namespace: Below is a minimal worker script that inspects the header and serves markdown when requested, otherwise falls back to HTML: Pro tip: make the root path serve your sitemap.xml instead of markdown content for your homepage such that an agent visiting your root URL can see all the links on your site. It's likely much easier to set this system up with a traditional reverse proxy file server like Caddy or Nginx. Here's a simple Caddyfile configuration that does the same thing: I will leave Nginx configuration as an exercise for the reader or perhaps the reader's LLM of choice. By serving lean, semantic Markdown to LLM agents, you can achieve a 10x reduction in token usage while making your content more accessible and efficient for the AI systems that increasingly browse the web. This optimization isn't just about saving money; it's about GEO (Generative Engine Optimization) for a changed world where millions of users discover content through AI assistants. Astro's flexibility made this implementation surprisingly straightforward. It only took me a couple of hours to get both the personal blog you're reading now and patron.com to support this feature. If you're ready to make your site agent-friendly, I encourage you to try this out. For a fun exercise, copy this article's URL and ask your favorite LLM to "Use the blog post to write a Cloudflare Worker for my own site." See how it does! You can also check out the source code for this feature at github.com/skeptrunedev/personal-site to get started. I'm excited to see the impact of this change on my site's analytics and hope it inspires others. If you implement this on your own site, I'd love to hear about your experience! Connect with me on X or LinkedIn .

HTML Tutorial AI Bash Web Development

▲ 0

1 views

Nick Khami 11 months ago

VPS Evangelism and Building LLM-over-DNS

My most valuable skill as a hacker/entrepreneur is that I'm confident deploying arbitrary programs that work locally to the internet. Sounds simple, but it's really the core of what got me into Y-Combinator and later helped me raise a seed round. When I was starting out hacking as a kid, one of the first complete things I built was a weather reply bot for Twitter. It read from the firehouse API, monitored for mentions and city names, then replied with current weather conditions when it got @'ed. My parents got me a Raspberry Pi for Christmas and I found a tutorial online. I got it working locally and then got completely stuck on deployment. The obvious next step was using my Pi as a server, but that was a disaster. My program had bugs and would crash while I was away. Then I couldn't SSH back in because my house didn't have a static IP and Tailscale wasn't a thing yet. It only worked on and off when I was home and could babysit it. When I started building web applications, I somehow skipped VPS entirely and went straight to Platform as a Service Solutions like Vercel and Render. I have no idea why. I was googling "how do I deploy my create react app" and somehow the top answer was to deploy to some third-party service that handled build steps, managed SSL, and was incredibly complicated and time-consuming. There was always some weird limitation: memory constraints during build, Puppeteer couldn't run because they didn't have the right apt packages. Then I was stuck configuring Docker images, and since AI wasn't a thing yet and I'd never used Docker at a real job, it was all a disaster. I wasted more time trying to deploy my crappy React slop than building it. During college, I got lucky and met a hacky startup entrepreneur who was hiring. I decided to take a chance and join, even though the whole operation seemed barely legitimate. Going into the job, I had this assumption that the "right" way to deploy was on AWS or some other hyperscaler. But this guy's mindset was the complete opposite—he was a VPS maximalist with a beautifully simple philosophy: rent a VPS, SSH in, do the same thing you did locally ( or whatever), throw up a reverse proxy, and call it a day. I watched him deploy like this over and over, and eventually he walked me through it myself a few times. It was all so small and easy to learn, but it made me exponentially more confident as a builder. I never directly thought, "I can't build this because I won't be able to deploy it," but the general insecurity definitely caused a hesitancy and procrastination that immediately went away. I've become an evangelist for this approach and wanted to write about it for a long time, but didn't know how to frame it entertainingly. Then on X, I got inspiration when levelsio posted a tweet about deploying a DNS server on Hetzner that lets you talk to an LLM . Want to see it in action? Try this: Getting that setup is probably more interesting than my rambling, so here's how to deploy your own LLM-over-DNS proxy on a VPS in less than half an hour with nothing other than a rented server. After purchasing your VPS, you'll receive an IP address and login credentials (usually via email). Connect to your server: Replace with your actual server IP address. Many VPS images come with or pre-installed. To avoid conflicts, remove or disable them: Install the required Python packages for our DNS server: Create a Python script that listens for DNS queries, treats the question as a prompt, sends it to the OpenRouter LLM API, and returns the response in a TXT record: Save this as on your VPS. Before running, you need to set your OpenRouter API key. For this tutorial, you can paste it directly into the variable. For anything more serious, you should use an environment variable to keep your key out of the code. Security Note : This is a proof-of-concept. For production use, you'd want proper process management (systemd), logging, rate limiting, and to avoid storing API keys in plaintext. Start the DNS server (port 53 requires root privileges): From another machine, send a DNS TXT query to test your setup: The LLM's response should appear in the output. Common Issues: To restrict access to your DNS-LLM proxy, use UFW (Uncomplicated Firewall) - and yes, it's literally called "uncomplicated" because that's what a VPS is, uncomplicated: This allows SSH access (so you don't lock yourself out) and DNS queries on port 53, while blocking everything else by default. Important : This setup runs as root and stores your API key in plaintext. For anything beyond experimentation, consider using environment variables, proper user accounts, and process managers like systemd. That's it! You now have your own LLM-over-DNS proxy running on a simple VPS. No complex infrastructure needed - just SSH, install dependencies, and run your code. This is the beauty of keeping things simple.

Cloud DevOps JavaScript Python

▲ 0

0 views

Nick Khami 11 months ago

I couldn't submit a PR, so I got hired and fixed it myself

import NoAbortVideo from "../../components/blog/DoingTheLittleThings/NoAbortVideo.astro"; For over a year, I was bugged by a search quirk on Mintlify that caused race conditions and wonky search results. Here's the fun irony: I was the founder of Trieve, the company that powered search for their 30,000+ documentation sites, yet their debounced search queries weren't being aborted as you typed. Check out this delightful chaos: <NoAbortVideo /> I had brought this up in our shared Slack before when I was just a vendor to them us (weird), but it wasn't a priority and never got fixed. It was extra frustrating because the race condition on the query was apparent enough that search would sometimes feel low quality since it would return results for a query many characters before the user was done typing. Even worse, as the founder of the search company powering this experience, it felt like a poor reflection on Trieve every time someone encountered these wonky results. Now that I'm on the team, I was able to finally fix it. I added an AbortController to the debounced search function, so that it aborts any previous queries when a new one is made. This means that the search results are always relevant to what the user is currently typing. There's something deeply satisfying about finally being able to fix the things that bug you. It made me feel a bit like George Hotz during his single week at Twitter in 2022, where he joined with overambitious plans to fix Twitter search, gave up due to hubris, and settled for fixing an annoying login popup before leaving. I've always admired engineers who are part hacker, part entrepreneur - people who see a problem and just... fix it. Getting to do something similar here (minus the dramatic exit) felt like a small win in steering my career toward that kind of direct approach. I prefer building and using open source software whenever possible, and this whole situation is a great example of why. With open source - when you encounter a bug or pain point, you can actually fix it yourself. Had this been an open source project during the year I was frustrated with the search race condition, I could have submitted a pull request with the AbortController fix and saved myself (and thousands of other users) the daily annoyance. Instead, it remained a persistent irritation until I happened to join the company and gain access to the codebase. There's something to be said for the immediate empowerment that comes with open source - though I understand why many companies choose different models for various business reasons. If search feels just a bit crisper and more responsive on Mintlify, it’s because of me! I fixed a bug that bothered me for over a year, and it feels great to have made that little improvement to the product. I can't wait to make more. Fixing small issues like this over and over again is how products become legendary. There's something deeply satisfying about finally having the power to fix the things that annoy you - even if they're tiny. Especially if they're tiny.

Web Development Open Source Career

▲ 0

0 views

Nick Khami 1 years ago

What 7,112 Hacker News users listened to on my side project

I was burnt out from my startup and wanted to recover some of my creative energy, so I decided to build a fun side project called Jukebox . I had the idea of building a collaborative playlist app where you could queue music together with friends and family. I launched it on Hacker News, where it hit frontpage and got a lot of traction. In total, it had 7112 visitors who played 2877 songs . Hacker News users are known for their eclectic tastes, so I was curious to see what kind of music they listened to. I did some data analysis on the usage patterns and music genres, and I wanted to share my findings. Part of the fun of side projects is that you can use them as an opportunity to build your skills. Personally, one of the core skills I want to improve is marketing. Therefore, it was important to me that I actually drove traffic to the app and got people to use it. I'm happy to report that I was able to do that! Here's a full breakdown of the user engagement: <UserEngagementSankey /> The data is reliable because each visitor to the site is assigned an anonymous user account. This allows for accurate tracking of how many unique users visited, how many created a "box" (playlist), and how many engaged with the main features. Conversion rate into the primary "Create Box" CTA was awesome! However, I was sorely dissapointed to see that only 6.7% of people who created a box actually used the app to queue music together, which was the main reason why I built it in the first place. I'd call it a pyhrrhic victory. My product sense was a few rings off the bullseye, but still on the target. I'm not going to continue working on Jukebox, but it certainly fulfilled its core purpose of helping me recover my creative energy and learn some new skills. I was originally planning to talk more about how Jukebox was built, but I think the more interesting part is the data analysis of what music Hacker News users listened to. Spotify is generous with their API, so I was able to hydrate the songs data with genres by using their data. Hacker News users actually disappointed me with their music tastes. I expected them to be more eclectic, but classic rock and rock were 2 times more popular than any other genre. New wave, metal, and rap followed as the next most played genres, but there was a steep drop-off after the top three. The long tail of genres included everything from country and EDM to post-hardcore and progressive rock, but these were much less represented. One thing that surprised me was how country music edged out electronic genres in popularity. I expected a tech-focused audience to gravitate more towards electronic or EDM, but country had a stronger showing among the top genres. It’s a reminder that musical preferences can defy stereotypes, even in communities you’d expect to lean a certain way. <SongsExplorer /> When it comes to artists, the results were a mix of the expected and the surprising. Michael Jackson topped the list as the most played artist—proving that the King of Pop’s appeal truly spans generations and communities, even among techies. Queen and Key Glock followed closely, showing that both classic rock and modern hip-hop have their place in the hearts (and playlists) of Hacker News users. I was surprised to see a strong showing from artists like Taylor Swift and Depeche Mode, as well as a healthy mix of rap, electronic, and indie acts. The diversity drops off after the top few, but there’s still a wide spread: from Daft Punk to Nirvana, Dua Lipa to ABBA, and even some more niche names like Wolf Parade and Day Wave. Overall, while classic rock and pop dominate, there’s a clear undercurrent of variety—perhaps reflecting the broad interests of the Hacker News crowd, even if their musical tastes lean a bit more mainstream than I expected. <ArtistAnalysis /> Dens Sumesh, a former intern at my company, originally had the idea for Jukebox and told me about it at dinner one day. I thought it was a great and had potential, so I decided to build it. AI codegen has made me drastically more willing to build things on a whim. Typically I would have probably quit after finishing the backend, because React slop is not my favorite thing to work on. However, since the AI is good enough at React to do most of that work for me, I was mentally able to push through and finish the project. Another side benefit of building this was that I got a better handle on when AI is an efficient tool versus when it’s better to rely on my own skills. For example, highlighting a component and prompting is a great use of AI. However, more complex asks like are more efficiently handled by a human with intuition and experience. Framing things out manually, or even prompting the frame, consistently seemed to be a more efficient strategy than trying to get the AI to one-shot entire features. Both approaches can work, but breaking things down helps you maintain control and clarity over the process. If you rely too much on one-shot prompts, you can end up in a cycle where your eyes glaze over and you're pressing the "regenerate" button like it's a Vegas slot machine. This slot machining makes launching less likely because you spend more time hoping for a perfect result rather than iterating and moving forward. It's easy to get stuck chasing the ideal output instead of shipping something real and learning from feedback. Build stuff, share it, get feedback, and learn. Shots on goal lead to more opportunities for improvement and innovation. Even though Jukebox is now going into maintenance mode, it was everything I hoped it would be: a fun side project that people actually used. If you want the raw data, you can find it on the GitHub repository . If you want to see the source code for Jukebox, that's on Github at skeptrunedev/jukebox .

Marketing Music Data Analysis JavaScript

▲ 0

0 views

Nick Khami 1 years ago

Building the Server for Threshold Multisigs

You're launching a new Bitcoin ETF worth billions of dollars. You need to secure the funds backing it and are scared to build that security system yourself, so you look for a vendor. You pick Coinbase Custody, probably the most well-known and trusted company in the entire ecosystem, to custody your funds. Trying to be transparent, you publish the Bitcoin addresses holding the funds backing your ETF. Then, the whole world realizes that Coinbase has the entire amount secured behind a single private key, and that private key may or may not be an offline threshold multisig wallet. This is the story of Bitwise, Coinbase Custody, and the accusations that they were not using multisig wallets to secure their Bitcoin ETF funds. Ultimately, the accusations were likely unfounded, Coinbase Custody most likely uses a threshold ECDSA scheme which, while much scarier to implement and maintain than Schnorr, still provides a high level of security. However, the situation is still bizarre and highlights the need for better tools and infrastructure for implementing threshold multisigs in production. I started working on a Bitcoin bridge at ZeroDAO in 2022 and quickly realized that the state of the ecosystem was nascent. There are many libraries for implementing threshold multisigs, but that's the easy part. The hard part is building a complete server implementation that can be run in production. If you want to run a threshold multisig vault, you have to build your own server on top of these libraries. This is a lot of work and requires a deep understanding of the underlying cryptography and protocols. It's like having a powerful engine, but no car to put it in. You can build your own car, but it's a lot of work and you have to figure out how to make it safe and reliable. Bitwise is basically forced to rely on Coinbase Custody or some other vendor to manage their $4B of Bitcoin for them based on a trust model that is not transparent to the public and maybe not even transparent to them. This is not a good situation for the ecosystem, and it's not a good situation for the users of these services. Startups are fu**ing hard. Out of college, I have spent the past two years working 70+ hour weeks, making less than a third of what I would at a reputable tech company, trying to make something of myself and simultaneously put a dent in the world. Our first product, Trieve , is a relevancy optimized search engine in a simple API. We built it because we were frustrated with the state of having to go through the hassle of setting up an ingestion pipeline, indexing data, and optimizing the underlying engine every time you wanted high quality retrieval. I'm very proud of it! Lifetime, we have supported over 300 unique paying customers, made hundreds of thousands of dollars in revenue, served 150M+ searches, and indexed over 1B documents. At this point, it's a mature product and we have fulfilled our initial ambitions for it. There's even a shopify app that over 100 stores are using! But I still felt like there was something missing. I wanted to build something that would have a lasting impact and Trieve started to feel like a distraction from that. I stopped getting sparks of joy every time we onboarded a new customer or launched a new feature. AI is great, but overtime I started to feel more like a glorified data janitor than a builder. Trieve isn't big enough to sell for a life-changing amount of money. Denzell and I talked through some acquihire offers, but they didn't feel right. Denzell and I learned a ton from building Trieve, and we are both very proud of what we accomplished. Our tank of energy was still pretty full, the valve between it and Trieve's product was just closed. So, we started looking around and trying to figure out something that the valve could be opened to. In that process, we got drawn back to the startups we had worked at before Trieve, and the problems we had seen there. When you decide to join a startup, you typically are not doing it for the money. It's a raw deal to be an early employee at a startup. You are taking on a lot of risk, working long hours, and making less money than you would at a big tech company. But you do it because you believe in the mission and you want to be part of something bigger than yourself. I was extremely lucky to have the experience of being bought into two startups doing something I believed strongly in before founding my own. I worked at ZeroDAO , Quai , Breezy , and Botanix . Three out of those four startups were in the permissionless blockchain space, and that's no coincidence. I'm easily nerd sniped by the idea of building something that is open source, permissionless, and can be used by anyone who wants to use it. Ironically, ZeroDAO and Botanix in particular were both working specifically on applications which required managing a vault of Bitcoin assets. ZeroDAO, in typical startup fashion, used infrastructure from a vendor, speficially a company called renvm , to manage the Bitcoin assets backing their bridge. RenVM was owned by Alameda Research who collapsed in late 2022 along with FTX, and the RenVM team was forced to shut down the service. That was the end of ZeroDAO which was a damn shame because, prior to that, we had built a really cool product that processed over 184BTC in less than 7 months . As it turns out, similar to Bitwise, it was also out of scope for ZeroDAO to build their own threshold multisig vault server. Ultimately, the company was forced to shut down because we could not find a vendor to replace RenVM. Unlike Bitwise, we were in no way big enough to force a repuatable company, Coinbase Custody, BitGo, Anchorage, or others, to implement the features we needed. Coming out of that experience, I decided to join Botanix to right that wrong. Botanix is building a Bitcoin sidechain which requires a bitcoin vault the same way a bridge does. Ultimately, Trieve started to get traction while I was there and I left to focus on it. At the time trusting that the work would go on at Botanix and the world would get a threshold multisig vault server implementation with or without me working on it. But, two years later, I'm still waiting fot that to happen. It's a better time to bite this bullet on building this than ever before. The Zcash Foundation has announced that they are doing working on their threshold signature ( FROST if you care about the details) library and have a well-documented and audited implementation in Rust. Lucky for Denzell and I, we are now proficient Rust developers after building Trieve, so we can build on top of that library. Serai also has a fantastic complete reference server implementation in Rust . Building blocks are much more mature than they were two years ago, and it feels like the right time to build on top of them. Also, it doesn't seem like anyone else is really working on it, so perhaps we can reap first mover advantage in a way that we couldn't with Trieve. Coming from the search engine space for the past 2 years, I like to think we are in a similar spot relative to where Shay Bannon was in 2005 when he started building compass , a server abstraction layer on top of a search engine library called Lucene. Compass was a complete server implementation that made it easy to run a search engine in production, and it was the precursor to Elasticsearch, which is now the most popular search engine in the world. Completlely different industry, but I think the analogy holds. I love startups more than anything, but we want to make this work for larger custodians and exchanges first. Ideally, we build a standard piece of infrastrcuture that's used by all of the largest custodians and exchanges in the Bitcoin ecosystem. We want to make it easy for them to run a threshold multisig vault, so they can focus on building their products and services instead of worrying about the underlying security infrastructure. Also, we want to help large institutions be their own custodians. Part of Blockchain's promise is that it's trustless, and we want to help large institutions take advantage of that. We want to help them run their own threshold multisig vaults, so they can be their own custodians and not have to rely on third-party vendors. However, that doesn't mean we are going to ignore the startup and individual developer use cases. People have big blockchain application dreams, from decentralized exchanges to marketplaces to lending protocols, which all require vaults to manage the assets backing them. While it's not our primary focus, I still do want to make sure we build something which would have solved the problems we faced at ZeroDAO back when RenVM shut down. It's just an open source server! Anyone is going to be able to run it. We are not going to be shutting down Trieve! It's a mature product which keeps us profitable and default alive. We are going to keep marketing it and supporting our customers. The only difference is that we are cutting back on the ambition of our roadmap. We are going to continue fixing bugs, adding features that our customers request, and making sure the product is stable and reliable. But we are not going to be adding any new major features or trying to expand into new markets.

Business Rust Security

▲ 0

0 views

Nick Khami 1 years ago

Taking Dynamic Key Generation (FROST) From Papers to Production

FROST (Flexible Round-Optimized Schnorr Threshold) is a protocol for distributed key generation (DKG) and threshold signatures. It allows a group of participants to jointly generate a public/private key pair, where the private key is split among the participants. This enables secure signing without requiring all participants to be online simultaneously. Algorithmically, it is a simple 2 round protocol. Many implementation libraries exist, but they aren't shaped like other kinds of software products that developers are used to deploying. They are often just libraries that require a lot of boilerplate code to get started with, and they don't provide a clear way to run the protocol in a production environment. We at Threshold Security have been working on a single binary Node which is designed to be a reusable piece of infrastructure for running FROST DKG in production. This Node is designed to be run by a group of participants who want to jointly generate a key pair and use it for signing. It provides simple command-line and RPC interfaces for starting the DKG process, managing participants, and generating keys. It's not completely ready for production yet, but we are making good progress. In this post, I will explain the background of FROST, how it works, and what our Node implementation currently supports. If you are interested in the details of FROST math, I recommend reading the paper FROST: Flexible Round-Optimized Schnorr Threshold Signatures by Chelsea Komlo and Ian Goldberg. It provides a comprehensive overview of the protocol and its security properties. For our purposes, the math doesn't matter as much as the protocol structure, so I will only be providing explanations for the necessary pieces of the protocol to implement on top of the FROST libraries which already exist. The DKG process is divided into two rounds of communication followed by a simple sum of public keys to produce a final public key. The rounds are as follows: In the first round, each particpant generates a private key, compute commitments to it, and sends their commitments to all other participants. The commitments are based on the private key and a random nonce, which ensures that the commitments are unique and cannot be predicted by other participants. These messages do not contain any secret information, so they can be sent over an insecure channel. The commitments are used to prove that the participants have generated their private keys correctly and to ensure that they are commited to them for the duration of the DKG process. mikelodder7/frost-dkg ⭐ 1 An implementation of the Frost Distributed Key Generation. cmdruid/frost ⭐ 13 — Flexible, round-optimized threshold signature library for BIP340 taproot. bytemare/frost ⭐ 20 — Go implementation of RFC9591: the FROST (Flexible Round-Optimized Schnorr Threshold) signing protocol. taurushq-io/frost-ed25519 ⭐ 68 — Implementation of the FROST protocol for threshold Ed25519 signing. topos-protocol/ice-frost ⭐ 18 — A modular Rust implementation of the static version of the ICE-FROST signature scheme. zellular-xyz/pyfrost ⭐ 2 — Python implementation of the FROST algorithm. LFDT-Lockness/givre ⭐ 9 — Threshold Schnorr Signatures based on FROST in Rust. ZcashFoundation/frost ⭐ 190 — Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures) by the Zcash Foundation. BlockstreamResearch/bip-frost-dkg ⭐ 59 — Bitcoin Improvement Proposal proposes ChillDKG, a distributed key generation protocol (DKG) for use with the FROST Schnorr threshold signature scheme.

Security Open Source Rust Python

▲ 0

0 views

Nick Khami 1 years ago

Web Developer's Guide to Midjourney

I tried to use Midjourney unsuccessfully a few times before, but decided to give it one more try after reading a good tutorial thread on X by @kubadesign . His thread got me most of the way there, but I picked up an additional trick with Midjourney's describe feature that I think is worth sharing. My initial plan was to use these images for uzi.sh , a tool for parallel LLM coding agents. While I ultimately chose a different final image for that project because I only needed one, the learning process was valuable. For this set, I aimed for a red color scheme to evoke action and speed, which you can see in the images below. <MasonryImages /> Following Kuba's advice, I went to pinterest and found a cool base image that I liked. I went with something that had a lot of red, but also darker colors on the border since I knew that I would need space for text and other elements if I wanted to use these on an actual website. <PinterestStarter /> You can't just start by describing the specific kind of image you want and expect to get good results. Style reference images are needed to give Midjourney the boundaries it needs to stick to your desired aesthetic and theme once you get more specific with your exact asks. It's unlikely that you'll be able to find multiple images on the internet which match your desired style exactly, so I recommend using neutral prompts to generate additional images in order to create a cohesive gallery. My neutral prompt here was . Essentially, any prompt describing a general subject and its characteristics without getting too specific about style, camera angle, action, or other details should work well. <SimilarStyleGeneration /> One of the images I wanted was an eagle diving. However, wasn't getting me the results I wanted. I accidentally discovered the describe feature dragging images around, and instantly realized that it was a cheat code for getting the images I wanted. <DescribeFeature /> You can take any one of these and pair them with the style reference images you generated earlier to get the eagle or any other image you described into the style you want. I could not believe how well this worked. <EaglePromptWithStyleReference /> Midjourney produces images which are too crisp to fit well as background images for the web. I recommend adding grain to them when you put them into your final site to create a more cohesive feel. If done correctly, you'll end up with a result that looks like the below. CSS is great for this! See a complete guide of how I applied the filter for the uzi.sh site below, full code on Github here . You first need to add a svg filter definition to your HTML file such that the CSS can reference it later to put the grain on top of the background image. The filter uses to create a fractal noise pattern, and to adjust the opacity. You can experiment with values like in or the alpha channel (the in the ) to finetune the grain's intensity and texture. Once you have the filter defined, you can apply it to a grain overlay element in your CSS. This element will cover the background image and apply the noise effect. Finally, you need to structure your HTML to ensure the layering works correctly. The grain overlay should be positioned above the background image but below any content you want to display. While there's ongoing debate about AI generated art, I see Midjourney as just another tool in the toolkit. The key is using it to bring your vision to life, not to replace your creativity. Take inspiration from what you see, but make it your own. Use AI to bridge the gap between the style you have in your head and what actually shows up on screen. The techniques I've shared here are all about developing your unique voice and letting AI help you express it better. The goal isn't to generate something generic. It's to create images that actually work for your projects and feel intentional, not obviously AI generated.

AI CSS HTML JavaScript

▲ 0

0 views

Nick Khami 1 years ago

LLM Codegen go Brrr – Parallelization with Git Worktrees and Tmux

import Pile from "../../components/blog/UsingGitWorktreesWithAI/Pile.astro"; This realization isn't unique to me; the effectiveness of using Git worktrees for simultaneous execution is gaining broader recognition, as evidenced by mentions in Claude Code's docs , discussion on Hacker News , projects like Claude Squad , and conversation on X . <br></br> <Pile /> I'm building a component library called astrobits and wanted to add a . To tackle the task, I deployed two Claude Code agents and two Codex agents, all with the same prompt, running in parallel within their own git worktrees . Worktrees are essential because they provide each agent with an isolated directory, allowing them to execute simultaneously without overwriting each other's changes. The number of agents I choose to rollout depends on the complexity of the task. Over time, you'll develop an intuition for estimating the right number based on the situation. Here, I felt 4 was appropriate. <br></br> <ImageFourSquareWorktrees /> <br></br> Voila, results! Only one of the four LLMs produced a solution that actually saved me time. This validates the necessity of rolling multiple agents: if each has a chance of producing something useful, then running four gives a chance that at least one will succeed . Four agents was essentially the bare minimum to have reasonable confidence in getting a workable solution. With LLMs being so affordable, there's virtually no downside to running multiple agents. The cost difference between using one agent ($0.10) versus four ($0.40) is negligible compared to the 20 minutes of development time saved. Since the financial risk is minimal, you can afford to be aggressive with parallelization. If anything, I could have run even more agents to further increase the odds of getting a perfect solution on the first try. And yet, the process of running them is still cumbersome and manual, it's more effort to setup 8 than 4, so I'm often lazy and opt to run the minimum number of agents I think will get the job done. This is where the problem comes in, and why I'm excited to share my proposed solution. Right now, I manually create git worktrees using , start a session for each one, run Claude Code in the first pane, paste a prompt, into a new pane, run to get a preview, switch to my browser to review, repeat if no agents succeed, then finally commit, push, and create a PR once I'm satisfied with an output. Here are the top frustrations: I feel like I've been through the wringer enough times with this process that I can see a solution shape which would create a smoother experience. To address these challenges head-on, the ideal developer experience (DX) would involve a lightweight CLI that wraps tmux, automating this complex orchestration. My co-founder Denzell and I felt these pain points acutely enough that we've begun developing such a tool, which we're calling uzi . The core idea behind uzi is to abstract away the manual, repetitive tasks involved in managing multiple AI agent worktrees. See some of the commands we are thinking to implement below. Our goal is to make the workflow more seamless while sticking closely to the existing mechanics of worktres and tmux. We want to make sure that we feel at home using alongside standard unix tools like , , and . These commands would primarily operate via instructions to the appropriate sessions. We don't want to reinvent the wheel; we just want to polish the existing process and make it more efficient. While focuses on software developers, its methodology isn't limited to tech; the principle of leveraging multiple agents running in parallel to increase the odds of finding an optimal solution applies universally. Consider a company like versionstory , which is pioneering version control for transactional lawyers. An attorney could leverage their software to run multiple instances of an agent to redline a contract. After reviewing the outputs, they could select and merge the best components to finalize the document. This approach would provide additional confidence in the quality of the final review as it would be based on multiple independent analyses rather than a single agent's output. Similarly, a marketing team could employ this parallel strategy to perform data analysis on ad performance. By prompting multiple AI instances, they could quickly gather a range of analyses, review them, and select the most insightful ones to inform their strategy. More coverage of the solution space leads to better decision-making and more effective campaigns. This parallel paradigm isn't just a new technique for developers; it's a glimpse into a more efficient, robust, and powerful future for AI-assisted productivity across various fields. I expect to see existing software products start to gain more powerful version control and parallel execution capabilities which emulate the workflow enabled by git worktrees for software development. My DMs are open if you want to chat about this topic or have any questions. I'm happy to discuss.

AI

▲ 0

0 views