Victor Moreno

Accountability is the great equalizer of leadership. Without it, standards slip. Trust erodes. Culture drifts. I’ve led teams from 12 to 200+ people across commands spanning 100,000 square miles - and the most consistent factor in every high-performing team I’ve seen is accountability. It’s what aligns people behind one standard, regardless of rank or personality. In my latest video, I break down: 🔹 Why accountability separates good leaders from great ones 🔹 How to correct “organizational drift” before it destroys culture 🔹 When to move from verbal to written accountability 🔹 Why accountability can be both corrective and caring Watch the full breakdown here: 🎥 https://lnkd.in/eT2W6eZZ Let’s start a conversation - how do you build accountability without crushing morale? #Leadership #Accountability #OrganizationalCulture #LeadershipDevelopment #TeamBuilding #MilitaryLeadership #ElderMasterChief

1

"Why is the background job crashing?" "And why is that variable nil?" Background jobs in Rails can be tricky to understand. Especially when there are errors. Why? 1. Remote nils. In Ruby a nil can be passed down through many layers or objects before a method is called on it. So the stack trace becomes quite useless - the nil was introduced somewhere else in the system. Who knows where? 2. Out of date state. Background jobs can be run hours or days after they were triggered. Maybe the state when they were triggered was good... but another process corrupted that state in the meantime. 3. Limited context. Most teams use error tracking software in 2025. But often these tools aren't set up to record enough context. 4. Other. Race conditions, missing transactions, overloaded queues... and many others. I've solved these problems by adding observability to the entire lifecycle of my apps. I instrument: * All HTTP endpoints * Job enqueued, started and performed events * Job arguments, queuing time, class, ID * A link between the job and the HTTP endpoint that kicked off the job I generally do this with traces as they give me the power to fully understand the path through my code. But I've also done this with structured logging and it's still very powerful. The result? An observability tool where I can ask questions like "what's the p95 delay in jobs in the urgent queue enqueued by the profile show endpoint?" I've found that debugging background jobs shrinks from a 4+ hour super confusing wild goose chase into a 20 minute homing missile that zeroes in on the defect. Want more info? DM me OBSERVE

5

Here's a simple framework to build systems that scale. Track: Notice what you're doing repeatedly Note: Add to your automation wishlist Just Do It: Start your day with twenty minutes of system building Today I built a UI testing loop in Claude Code that runs iterations automatically. No more sitting there, running the same tests manually, waiting for results. Five minutes saved per test. Twenty tests a day. That's 100 minutes back. But here's what most founders miss about systems: They wait for the "right time" to build them. When things calm down. When they have bandwidth. When the crisis passes. They're still waiting. I keep a simple list in my notes app. Every time I catch myself doing something twice, it goes on the list: "Manually copying customer data between systems" "Rewriting the same email response" "Running the same code tests" Then every morning, before the chaos starts, I pick one thing. Twenty minutes. That's it. This morning's automation will save me hours this week. Last week's Gemini CLI setup now transcribes thousands of calls while I sleep. Monday's Superwhisper setup means I speak emails instead of typing them. Small wins compound. Six months ago, I was manually formatting every email. Now Superwhisper handles it while I talk. A year ago, I was copying data between systems. Now APIs do it while I sleep. The compound effect is real. But it only works if you start. What's one thing you'll automate in the next 20 minutes?

4

2 Comments

I was surprised that Upstash Redis didn't have an official local development server, so I and GitHub Copilot teamed up to create one. https://lnkd.in/enHCZgd2 Zero lines of code written by me. 😊

1

Don't believe the BS that you can use Claude Code for free. Ollama recently made their API compatible with Claude Code. Many creators quickly jumped on the opportunity to farm engagement with the hook: "You can now use Claude Code for free!" My thought? Claude Code without Opus 4.5 is not Claude Code. Period. But this is exciting news. Not because I can use Claude Code for free, but because I see an opportunity to optimize costs by delegating easier tasks to local LLMs. The key question is: what tasks can local LLMs handle? I tested out 7 local LLMs. In this post, I will explain the BS and share my 1st experiment. -- Why the BS? Claude Code has been praised as one of the best AI tools by its users, not only for coding but for many other tasks. But the price feels steep to many. The $20/month plan is not enough for any serious work. You need to at least subscribe to Max 5x ($100/month). Many heavy users, including me, subscribe to Max 20x ($200/month). It’s a steal. But still, many were eager to try it but aren't ready to pay. Ollama's recent announcement means you can buy a Mac, a Strix Halo, or a GPU and use Claude Code for "free" with local LLMs. It’s appealing, as it is a one-time investment, and you can use the machine for other purposes. Creators are leveraging this opportunity to farm engagement. But the reality? Claude Code without Opus 4.5 is not the same Claude Code we praised. Local LLMs are far less intelligent. -- But for those who understand the difference, we see an opportunity to optimize costs by delegating some easier tasks to local LLMs. I'm interested in finding out what tasks local LLMs can handle. This is my typical flow when using Claude Code. This is for coding, but I have similar flows for marketing and content creation. 1. Research and planning 2. Create PRD and implementation plan 3. Break plan into bite-sized tasks 4. Implement + review with reflection pattern 5. Final review with agents 6. Final review and QA by me Based on my quick tests, we can forget about asking local LLMs to do research and planning. All of them failed at a simple instruction: "Visit https://learnparrot.ai/ and tell me about the website." So, I think the most viable use cases would only be (4) — implementation + review loops. While it looks like a very narrow use case, it is where we burn a lot of tokens. So I think it is worth a try. The main selection criteria for this will be instruction-following capability. One very common task is to refer to code samples or templates to code a new feature or page. This is a good test of instruction-following. So, I crafted my first test: - Used Opus to create HTML that I can screenshot as a LinkedIn carousel to display info for each model. - Turned one of the pages into a template and deleted the rest. - Asked each LLM to refer to the template to code its own page, given its specs. Swipe the carousel to see the results. Who would you hire? #LocalLLM #ClaudeCode #VibeCoding

20

10 Comments

Jira now lets you "close a ticket" using its built-in AI agent, Rovo Dev. Under the hood, it is Claude Code. One of our engineers tested it. The results were interesting. It asks questions like Claude Code's planning mode. It writes code. It attempts to fix issues. But it did not follow existing coding conventions. It likely ignored the project's Claude.md configuration file. And the permission negotiation for running tests in a virtual environment was painful. The verdict: useful for non-technical staff fixing small, clearly-defined issues. A convenience wrapper, not a replacement for proper agentic workflows. The concerning part? Product managers and sales teams now have a button that says "fix this." With no understanding of the codebase, no context beyond the ticket, and no guardrails beyond what Atlassian decided to implement. Every new AI integration follows this pattern: powerful capability, wrapped in a simple interface, deployed to people who do not understand the limitations. The job of the CTO is to figure out which of these integrations are helpful and which are dangerous. This one is both.

12

1 Comment

At this point every product I see from YC and other incubators feels like it can be vibecoded in a weekend. Coding agents have made it that easy. I don’t want to talk about launch videos lol basically they all look the same and I’ve never watched one full length. The moat isn’t the product anymore. It’s distribution and speed. And yeah in case you think I missed taste, I didn’t. I just don’t believe in that shit. LLMs can brute force creativity in unimaginable angles that were never possible for humans. Thanks for listening to my ted talk

1

I love Rails. I've built my wealth on it. That's exactly why I think we need to have an honest conversation about its biggest blind spot. Eileen M. U. gave a brilliant talk at Rails World last year: "The Myth of the Modular Monolith." After 6 years of modularizing Shopify's monolith, she concluded: "You can't solve human and cultural problems by changing your architecture." She's right kinda of about the culture part. But stopped one step short. Rails doesn't just allow tight coupling. It incentivizes it. ActiveRecord makes every model globally accessible from anywhere. Any controller, any model, any job can reach into any table through any association chain. There's no boundary enforcement. No import restriction. No compilation step that says "this module shouldn't know about that one." When your framework makes coupling the path of least resistance, blaming developers for coupled code is like blaming water for flowing downhill. Shopify tried to fix this with Packwerk. It just give you a map not a real solution. Rails Engines? Been there, done that. They are miniature apps that provide functionality to their host applications. They don't enforce real isolation and they weren't designed for progressive extraction. But this isn't a Rails problem. It's a missing tool problem. Look at what Nx did for the Node/TypeScript ecosystem: → Module boundaries enforced at the import level, not via YAML to-do lists → Dependency graph visualization built in → Affected-only CI: only test what actually changed → Clear public API per module, everything else is private by default → A real path from monorepo module to extracted service Nx didn't replace Node. It gave Node developers the guardrails to build modular systems naturally. The right thing became the easy thing. By default. Rails deserves the same. Imagine a Rails-native tool that: • Enforces module boundaries through autoload paths, not opt-in linting • Gives each module a public API (explicit exports) while keeping internals private • Generates a live dependency graph from actual code usage, not manual YAML declarations • Runs affected-only CI based on that graph Not a replacement for Rails. A companion that makes Rails' conventions work at scale. Eileen is right: culture matters. Education matters. Leadership incentives matter. But culture alone didn't give us CI/CD. Tools did. Culture alone didn't give us code formatting standards. Linters did. Culture alone won't give us modular Rails applications. Rails gave us developer happiness for building products. Now we need the same philosophy applied to building organizations of code. The myth isn't the modular monolith. The myth is that we have the right tools for one. Who's building this? 🎥 Eileen Uchitelle — "The Myth of the Modular Monolith" (Rails World 2024) https://lnkd.in/dabvzHQm

13

It looks like Claude Code is finally breaking through into the mainstream. People are starting to realize that the "Code" part is just a label, and not a constraint. Think of it like your web chat, but fully scriptable through commands and subagents (which it can put together for you). Over the last six months, I built a whole host of tools, creating a highly customized knowledge management system with Claude Code at its center, effectively becoming my "personal assistant" (without the hyperbole). It handles my note taking, task lists, reminders, research, ideation, project management, and organization of knowledge. All in one place, fully automated and connected. It completely changed how I work. Ask me about it and I won't shut up. Until now, the biggest hurdle for non-technical users has been the terminal, but Anthropic's upcoming Claude Cowork is all about to change all that. It's just Claude Code wrapped in a more accessible UI. If you struggled to effectively use LLMs to automate your tasks (beyond just one-shot prompting), you should take a look at it.

37

5 Comments