Jerry Fernholz

Anthropic released another paper on their ongoing work towards interpretability of large foundational models like their Claude 3 family, built on previous work by many. Their work continues to be enlightening and inspiring. The findings in this work are generally similar to previous findings on smaller models but scaled up to Claude 3 Sonnet: 💡 they find large numbers of "features" corresponding to combinations of neuron activations and these features map to concepts that we recognize/understand: for example, features for transit infrastructure, particular people, concepts (like bias and "objects lacking sentience"). This might sound familiar from classical machine learning, but the interesting thing is that there is no single thing/neuron encoding each of these concepts, it's a particular combination of neuron activations that embeds these concepts in "superposition" in the network. 💡they observe a sort of "distance" of these feature activations that arrange themselves "near" semantically similar features. When they use their sparse autoencoder approach to learn more and more features they observe that the level of abstraction in the detected features becomes more granular, in ways that are interpretable and meaningful. 💡when they artificially fire these activation patterns during inference, it affects the output in ways that relate to the "feature". For example, asking Claude "what's the most interesting science" normally it responds Physics, but if you clamp the feature activations for the feature "Brain Science" to 10x their max values then Claude responds: Neuroscience. Ways to interpret _and_ influence the model. Great readable work [1] along with an interactive explorer of some of the "features" themselves [2] 🎂 There's an easter egg too: if you scroll in the feature explorer tool and try and select one of the "Randomly selected features from 1M" you get a message "if you want to see the rest of the features, we're hiring!" with a link to their recruiting page :) [1] https://lnkd.in/gZbparwp [2] https://lnkd.in/gC9eus53

19

Want a preview of what I'm going to be talking about in my keynote for RubyConf? You can catch a glimpse of it here!

10

Hey folks! Garrett Milster and I have only posted about Sacramento Labs once, so we figured it's time for an update 😊 **What is Sacramento Labs?** We’re a small team focused on launching software products that solve real-world problems. Think of us as a startup lab—constantly testing ideas, learning from feedback, and building tools that matter, and having an impact while doing it. **How do we decide what to build?** We like to build products that: -         Solve real-world problems in mostly ignored industries -         Are small, highly maintainable, and scalable codebases -         Make the world a better place directly, or by donating a percentage of profits to a relevant charity in that space You can learn more about our philosophy at sacramentolabs.com **What you can expect from us** We’ll be posting product ideas that are in various stages of our pipeline: Early Concept, Customer Development, In Progress, Launched, Scaling. We’d love to hear your feedback! **Our latest concept: Self-Hosted Security** Here’s the problem: - Businesses often use third-party URL shorteners to share internal tools, resources, or campaigns, but these services introduce serious risks. Enterprise companies like Google, Microsoft, and Stripe have built their own internal URL shorteners for this reason – but most businesses don’t have the resources to do that. - Phishing attacks are rampant, and links from external services can be spoofed or abused. - Branding and security controls are limited, leaving sensitive information exposed. - You can’t track link activity—who’s clicking what, when, or why. - When employees leave, their shared links still work, leaving potential vulnerabilities. Our proposed solution: Self-Hosted Security. It’s a plug-and-play solution for businesses to host their own branded URL shorteners with: - SSO for secure access tied to your company’s directory. - Link expirations to ensure old links don’t stay active indefinitely. - Audit logs to track activity and improve visibility into link usage. 📢 We need your input! Would this solve a problem for you? What features would make this indispensable? Check out the landing page and share your thoughts: selfhostedsecurity.com Want to chat? Email me at [email protected] 😊 💡 And here’s something we’re passionate about: a percentage of profits from Self-Hosted Security will go to the Electronic Frontier Foundation (EFF). Your feedback not only helps us create better solutions, but also contributes to making a positive impact. Thanks for being part of the journey!

58

6 Comments

It was hard, but we now have a primitive at Gadget that lets us do absolutely 0 downtime atomic changes to an application's structure or data under the hood, with 0 requests dropped. I call it "request catching" but it was inspired by this Braintree eng post I read long ago For stateless workloads like serverless functions, 0-downtime deploys are pretty easy. You stand up the new one next to the old one, use a load balancer to start sending requests to the new one, and slowly stop sending requests to the old one. But for stateful workloads, it's much harder. You can't just start a new Postgres and send some queries to the new one and some to the old one without lying to somebody about state. If you want to be consistent, there has to be one source of truth. Fancy DBs have quorums for this, but PG doesn't. If you want to be consistent, you're effectively forced to have some tiny-but-real window of downtime in between draining the old one and starting the new one. That said, there's nothing forcing you to return errors to clients while that is happening. If your infrastructure supports it, you can pause requests while this changeover is happening under the hood, and then resume them once it is over. Clients will notice a longer request that normal, but it will be served like normal and they'll be none the wiser! What's required to do this though is a deep deep integration between the load balancing infrastructure and the thing doing the database deploy under the hood. We've built this up using a distributed locking tool, where all requests start by taking out a shared lock. When we're ready to do the maintenance under the hood, the maintenance workflow takes out an exclusive lock, blocking all requests from proceeding. The workflow does the atomic change it needs to make knowing it has exclusive access which means nothing will change under its feet, and then releases the exclusive lock as fast as it can so those requests can proceed. As an optimization, we only check the lock on the request path if an app is marked as near a maintenance window. This is only possible because of Gadget's architecture where we bundle together the load balancer, the request processing layer, and the database access tier such that we can reliably intercept all requests and all database transactions and do this lock checking. Its these nasty, in-the-weeds details that make me so proud of Gadget -- we can do world-class engineering stuff under the hood on behalf of all our apps without them ever noticing. If you're interested in doing this on your stack some OSS tools have the primitives you need! We use nginx for our load balancer, Temporal for the reliable workflow execution and we're currently using postgres advisory locks for hte locking. I think the Braintree post has been lost to time after they got acquired, but @simonw has a great post on the subject here: https://lnkd.in/eZmiktGT

51

Santana Row shopping center in San Jose has implemented a ticketless parking system that eliminates the need for drivers to take a ticket upon entry and pay at a pay station upon exit. Instead, drivers can simply scan a QR code (see photo) posted throughout the garage using their phones, enter their license plate number and credit card information on the website that pops up, and a camera will read their license plate and open the gate as they exit. While this system may seem convenient and efficient, I think there is a significant security concern! There is a risk that perpetrators could replace the posted QR code with their own, which would redirect drivers to a fake website where they would unknowingly enter their credit card information. This could lead to unauthorized charges and potential identity theft. It is crucial for the shopping center to address this security concern by taking appropriate measures to protect drivers' personal and financial information. They must ensure that the QR codes posted are authentic and that there are no vulnerabilities that could allow perpetrators to manipulate the system. As an alternative solution, pay stations could be installed for shoppers to use instead of relying on their own phones.

33

12 Comments

DevEx tooling and enablement are essential investments in an engineering organization's budget. This is (hopefully) not news to anyone! But there are 3 other takeaways that resonated with me from the Hangar DX (https://dx.community/) meetup last week organized by Aviator and Slack at the Salesforce HQ - 1 - Adoption - Dev tool adoption varies from one org to another even within the same company. It is especially cumbersome when migration means changing existing processes/rituals. Leadership support is critical and business context is the catalyst that drives rapid change. 2 - Surveys - Surveys seem like a good way to collect and analyze Dev sentiment within engineering orgs regarding state of tooling and enablement. But survey participation can ONLY be guaranteed IF action is swift and effective. Importantly, surveying tend to collect feedback in a partitioned way. e.g. Most organizations do surveys where process/people/management issues are collected in Pulse surveys BUT Dev tooling feedback is collected in DevEx surveys which are not necessarily reconciled against Pulse surveys. 3 - Horizontal orgs for Quality will continue to exist and thrive because the fundamental tradeoff between speed (more features) versus quality/reliability will always mean Devs have a conflict of interest. This reiterates the idea that the "you build it, you own it" (full ownership) is not for an individual but for a team that includes dev, qa, performance engineering etc. thanks to Ankit Jain and Poya Osgouei for the invite and thanks to Sridhar Ramakrishnan for hosting. pic credit - Ankit Jain #dx #devex #developerenablement #quality

55

9 Comments

Theodore Roosevelt once said, "The best executive is the one who has sense enough to pick good men (aka people) to do what he wants done, and self-restraint enough to keep from meddling with them while they do it." These words have never rung truer to me than they do today, as I reflect on a decision I made in October 2014 - a decision that would profoundly impact the next decade of my career. Enter Donald Green. When I hired Donnie, I had no idea the impact he would have. Over the past ten years, across three different companies (ACI Worldwide, Flywheel/WP Engine, Bloomerang), Donnie has been more than just an employee - he's been a pillar of strength, a catalyst for growth, and a true leader in every sense of the word. We've been through hell together. 3 AM triage calls? Check. Pushing each other to the breaking point? You bet. Winning against all odds? Absolutely. But here's the thing: Donnie isn't just good. He's the kind of leader that makes everyone around him better. And in the high-stakes world of technology and business, that's the difference between winning and losing. This experience has taught me a crucial lesson that I want to share with all of you: Your team is your limit. Make sure it's a high one. Building a team of strong leaders isn't just about hiring talented individuals. It's about creating an environment where leaders can thrive, where they're empowered to make decisions, take risks, and elevate those around them. It's about recognizing potential and nurturing it into exceptional leadership. Today, I'm proud to say that I now have a team full of people like Donnie. Leaders who push boundaries, challenge the status quo, and drive our organization to new heights. With this team, we're able to move faster and achieve more than I ever thought imaginable. So, to all the executives, managers, and aspiring leaders out there, I challenge you: - Seek out the Donnies in your organization. Look for those individuals who not only excel in their roles but elevate everyone around them. - Create an environment that fosters leadership at all levels. Empower your team to make decisions and learn from both successes and failures. - Never stop developing your leadership pipeline. The strength of your organization tomorrow depends on the leaders you're cultivating today. - Remember, as a leader, your greatest achievement isn't what you do yourself - it's what you empower others to do. Building a strong team of leaders isn't easy. It requires vision, patience, and sometimes, a leap of faith. But the rewards - the innovation, the growth, the ability to overcome seemingly insurmountable challenges - make it so worth it. To all the exceptional leaders I've had the privilege of working with: Thank you.

187

22 Comments

Totally agree with Dan DiGangi here. If you don't understand the overall strategy of a business, it's hard for you to align and be fully effective. This goes from leadership down to engineering. What are you doing to try and understand that vision? Link in comments to the full interview with Dan!

4

2 Comments

Was playing around with v0.dev before last weeks Next.js conf, wanted to stress test how much it could help someone build a complex feature in Catalyst. One of our merchants was looking to add a Gift Certificates section like Stencil has and we just haven't got to it yet within the out-of-the-box version. Was a perfect scenario! High level take? If you are building in Next.js you should 100% add v0 to your toolbox. It'll help you slice away at features much faster than any other AI solution in market. I include more notes in the PR along with a demo of what was built on GitHub: https://lnkd.in/eBm6wVdP

47

Scaling a business effectively often requires more than just adding new hires. The traditional approach of growing teams to drive growth can lead to increased communication challenges, slower decision-making, and diminished productivity. Instead of focusing solely on expanding headcount, it’s crucial to optimize existing resources and leverage technology. AI, for example, can automate repetitive tasks and enhance efficiency, allowing smaller teams to achieve more without the added complexity of a larger workforce. By adopting a leaner approach and integrating smart tech solutions, businesses can scale effectively and drive impressive results. #BusinessGrowth #AI #Efficiency

3

When there is great uncertainty, there can't be predictability to any useful level. We have to reduce uncertainty to where it can be managed effectively, and we do this by running experiments... trying things. Does the stakeholder like what we've done? Does the customer like what we've done? Are we solving the problem that customers have? This puts us in the 'complex' quadrant of the Cynefin Model, where we have to try and (perhaps) fail, perhaps repeatedly, until we know enough. Yet, we still have a goal in mind and we at least know the first few things that need to get done... or the first thing we need to test to determine feasibility. Apple knew that unless it could source a ruggedized hard drive that would withstand being carried and occasionally dropped, the iPod would not be successful... so getting a commitment from Western Digital (who had been working on such a drive and was almost ready to ship) was the key decision point. The Wright Brothers knew that unless they could figure out a way to turn their airplane without 'skidding' and stalling a wing (a problem that had killed many of their inventive contemporaries) they couldn't build a safe airplane... oh, and find a lightweight, powerful-enough motor while you're at it. It all comes down to reaching decision points: do we know enough to know whether to continue, or whether to cancel our effort? In the example below (waterproofing a below-ground basement), we are going to have to continue. Therefore, we want to continue only at the pace at which we are certain of the decisions we're making. Is what we're doing working? If so, do more! If not, do something else. That is exactly what the contractor did in the post below, making 'MVP' experiments until the path to success was clear, until they had the 'Aha!' moment. So, when do we get predictability with useful accuracy? At the 'Aha!' moment. Figure out what 'Aha!' moments are needed, devise experiments to reach those moments and drive enough uncertainty out (you'll never get to zero) to where the range of uncertainty is acceptable. #predictability #forecasting #estimation #commitment #agile #planning #riskmanagement #projectmanagement

3

3 Comments

Project update! My application tracking extension is now doing fuzzier matching and injecting new information into LinkedIn (and other sites) to keep me from doubling up on applications. Next up: local storage and bulk import/export operations...

12

2 Comments

We're in the pets phase of LLMs right now, but the cattle phase is coming and it'll change everything. Yes, again. What do you mean "pets" and "cattle"? Servers used to be our pets. We bought, named, cared for, and persisted them individually. If we wanted a new one, it was a big commitment. If one went down, it was a big loss. But then servers became cattle. Today we manage them as a group of commodity assets. We want one, we clone it. If one goes down, we replace it with another. This change delivered an era of distributed, high availability applications with limited downtime. Cheap storage, containers, cloud, clusters all met riding on top of Moore's law. And machine learning changed too. Computer vision was first. We went from small, neural networks running on CPUs via Matlab to a larger networks running in on GPUs via C++. AlexNet kicked off the deep learning revolution, eventually Transformers in NLP, and then ChatGPT. So, today we call our LLMs by name but this is just the start. There will be more LLMs variations than there are people on Earth.

25

1 Comment

Three Articles From 2024 That Will Stick With Me in 2025 1. "I Will Piledrive You If You Mention AI Again" by Nikhil Suresh ⮑ https://lnkd.in/eC7q9ZWn 2. "Godot Isn’t Making It" by Ed Zitron ⮑ https://lnkd.in/e294rHXc 3. "Casual Viewing" by Will Tavlin for n+1 ⮑ https://lnkd.in/eRq_mZjh --- ⚠️ Before reading these, you may want to install Advanced Profanity Filter, a reputable, open source plug-in for your web browser that respects your privacy. - Download: https://lnkd.in/eCNMd3Y7 - GitHub > PRIVACY-dot-md - https://lnkd.in/e2frG_Ee And here's a pic of a new friend of mine so LinkedIn doesn't re-post a preview of the first URL.

3

James Stanier has a good argument for why deadline-driven development is so… difficult → https://lnkd.in/gz3rvj2s “Given that non-technical people don’t understand why software is hard, dates become the stick that they beat you with when you don’t deliver on time. Don’t ask me why, it’s just human behavior. I’m sure you’ve done it when roadworks have taken longer than were specified on the sign, or if a delivery of a package was late. Dates mean something to people, so handle them with care. In fact, perhaps we could do something entirely different instead.” What’s the “something different”? “So, instead, you should take a forecasting approach that follows the uncertainty curve that we outlined above. You start wide, and you taper in. At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.” This is why I will always advocate for time horizon roadmaps → https://lnkd.in/gN8VSYZc

13

If you're wondering, 'Tacos again, Matt?' the answer is 'yep.' Because, honestly, they continue to be a great way to think about the interplay between human factors, optimization, and guac-to-sour-cream ratios. So here's the second installment in my series on the things a well run taco restaurant can teach us about efficient complex systems (which is also a sneak peek into the kinds of problems we're solving at Fixify and—hopefully—a helpful way to think about some of your own complex-systems quandaries, too.) https://lnkd.in/e48K257N

90

14 Comments