Josh Lehman

Pushed a feature this week I'm pretty excited about. imPAC now generates remediation steps dynamically when a compliance check fails. The system looks at the specific check, pulls context from the asset's actual configuration, and builds out tailored fix instructions with the exact CLI commands and console steps for that resource. Example: an EBS snapshot fails the encryption check. Instead of pointing you at a generic "how to encrypt EBS" article, imPAC generates the full remediation. Create a KMS CMK (here's the CLI command with the right flags), copy the snapshot with encryption enabled, verify, clean up the old one. Scoped to the actual account and resource. The part I like most is what this does for the handoff between security and ops. Security finds the gap in a policy check. Ops gets a ticket that already has the fix written out. Without the back-and-forth that adds friction of "can you be more specific about what needs to change?" We built this because we are delivering the simplest ways for cloud teams to govern their cloud estate across security AND ops. The detection side of cloud security is a solved problem, but the cloud ops and engineers side is still mostly manual. That's the gap we're closing. If you want to see it in action, drop a comment or DM me.

22

1 Comment

Some thoughts from Erik Collinder, our Head of Design at Interloom, on workflow builders and how we approach orchestration a bit differently.

5

1 Comment

As the Plaid monorepo grew to hundreds of commits per day, the Developer Efficiency team found that operating without a merge queue had become increasingly costly. We set out to build a merge queue with a target median latency of five minutes. Read on to learn why the naive “build everything” approach failed, and how the work led us to contributing a bug fix to the rules_go project. https://lnkd.in/gRRH_X9u

50

The most value our eng team has gotten from LLM isn't writing code. Sure, it's nice to get auto-generated unit tests or boiler plate code. But in a domain as complex and specific as ours, the LLM doesn't get very far on its own. Instead, the most value we've realized is in learning. 12 months ago, we identified several areas in which our team was lacking expertise. This was meant to inform our hiring roadmap. We didn't end up hiring for any of those skill sets. Instead, everyone upskilled. We've taught ourselves about networking and devops and this one really niche thing about how our OTEL library works. This has allowed us to remain leaner (*cough* profitable *cough*) and to keep everyone's scope larger. Better yet, it allows our team to continuously grow and evolve. It's a lot more fun for someone on the team to say "let me go learn [intricacies of deep technical subject]" than to hire a domain expert for it. Pair high-trajectory, high-agency folks with a boundless well of knowledge, and you've got an unstoppable combo.

19

2 Comments

Context engineering isn’t just prompt writing. It’s pattern-based prompt design that connects intent, context, and guardrails. When I read Rock Lambros's post (https://lnkd.in/e9ZGzCGP), it got me thinking. Today, we do not use simpler prompts to interact with AI systems anymore. Instead, we write sophisticated prompts to get meaningful output. As AI systems become integrated with workflows, agents, and automation, prompt engineering must evolve into context engineering - where patterns shape how the model interprets, reasons, and acts on instructions. Prompt Patterns enable Context Engineering with the help of: ➡️ Providing structured context - Patterns become containers for contextual information that retains meaning across varying input sizes and types. ➡️ Reducing model ambiguity - Well-patterned prompts reduce hallucination, unexpected outputs, and semantic drift. ➡️ Enforcing policy constraints - By including guardrails directly in the pattern (e.g., “Only output responses that comply with X”), you embed policy into execution. ➡️ Supporting agentic workflows - Agents need structured pattern cues, not free-form questions, to reason and execute actions safely. Prompt Pattern Research paper by Jules White, Quchen Fu, Ph.D., Sam Hays, Michael Sandborn, Ph.D., Carlos Olea, Henry Gilbert, Ashraf Elnashar, Jesse Spencer-Smith, and Honorable Dr. Douglas C. Schmidt - https://lnkd.in/enD3EWq5 Prompt Pattern Guide by Groq - https://lnkd.in/exvUUuB8 5 Patterns for Scalable Prompt Design by Cesar Miguelanez - https://lnkd.in/e6Rq9dEV Agentic tools need deeper context to generate meaningful code / content / output. This has also led to development of spec driven development. Adoption of such tools like Amazon Kiro or Google Antigravity has been on the rise. How do you do Spec driven development today? #ai #agenticai #aiengineering #contextengineering #promptengineering

7

2 Comments

Last year we hit a major milestone shipping GRDB as Todoist's production database layer on iOS. 🥳 The release went smoothly for most users, but some folks with large task lists hit performance issues. Andris Zalitis jumped in, tracked down the bottlenecks, and built a fix that cut query times by 90%. He's just written up how he pulled it off. Worth a read if you're into database optimization or GRDB: https://lnkd.in/ecGQBaRk

8

SaaS is almost dead. But “Software on Demand” (SOD) Is Rising Over the last 12 months, I’ve been pushing hard on AI in my engineering and product organization, especially “vibe coding” and the broader AI toolset. No strict agenda. No hard boundaries. Use whatever tools you want. Just don’t miss the train. About six months ago, we ran an internal AI hackathon and it became a turning point. Two days. AI-assisted coding only. No hand-writing code. Teams of two. Everyone builds. In most hackathons, people fall into familiar roles: developers code, product folks do product, and everyone else tries to find a way to contribute. This time was different. The most impactful outcomes didn’t come from the strongest programmers. They came from people who don’t know how to code. AI-enabled development gave them the ability to build exactly what they needed: small tools, automations, and workflow improvements that remove friction from their day-to-day work. Since then, I’ve been pushing even harder to embed AI into how we operate. And the results have been incredible: * A testing system that automated ~90% of a team’s daily work (asaf Katz) * Analytics workflows that shrank “data evaluation” cycles from days to minutes (Aleksandra Brichenok) What impressed me most wasn’t just the speed it was who built it. These systems were built by the people doing the work. They didn’t need to write requirements, explain context to engineering, or wait for a sprint. They explained it to the AI, iterated based on their own domain expertise, and got working software tailored to their needs. That’s what I mean by Software on Demand: Not “predefined software” built for the average customer by a product team trying to satisfy everyone. But software built on the spot by the user, for his needs! Imagine having something like Base44 inside Salesforce, Tableau, Monday, or any major platform: Instead of being locked into someone else’s UI and workflow assumptions, you can build your own experience on top of your data. No more fighting dashboards you hate just because they’re “the standard.” And here’s the real implication: If a company’s value is primarily “we provide software,” that value will erode over time. Because “software” alone is becoming easier to recreate fast. To stay defensible, you need to offer something that can’t be replaced overnight: Network effects, Proprietary data, Trust, Compliance, something durable. This hit me again yesterday. I was sitting with our data analytics team (Eilam Avinary). They’re not software engineers. They don’t “know how to code” in the traditional sense. And they showed me a full replacement for Tableau built for their exact needs. Our data sits in BigQuery. Tableau used to be “the software layer.” Now, the team built their own. That’s the shift. SaaS isn’t disappearing but the era of “one product UI fits everyone” is fading. The future looks a lot more like: Software created on Demand, by the people closest to the problem.

66

21 Comments

Two updates from the Enterpret Wisdom team that I'm genuinely pumped about: 1. Claude Opus 4.6 is now live on Wisdom. Our customers can now switch between Claude Sonnet 4.5 and Opus 4.6 depending on the complexity of their query. Sonnet is fast and great for everyday questions. Opus is the most capable model available — perfect for when you need deeper reasoning across your customer context graph. One toggle. You pick the horsepower. 2. Custom Rules are here. This one is a game-changer. You can now teach Wisdom exactly how you want it to behave — at the org level or as personal rules. Want NPS calculated a specific way? Set a rule. Want Wisdom to always ask a clarifying question before diving into analysis? Set a rule. Want every response to reference ticket volume alongside sentiment? Set a rule. Your customer intelligence agent now works the way your team thinks.

38

Performing a migration on one enterprise repo from an old version of Grails 2 to Grails 5 took over 11 hours with Claude Code at one Moderne customer. And this was after the bulk of the base language update was done deterministically. I present Act 3: Better Editing Tools, part of a series on Agent Tools as we find ways to exchange GPU for CPU. Catch up on the prior acts: * An the introduction to the series at https://lnkd.in/e5-3sbn7 * Act 1: Better search tools at https://lnkd.in/eFQKAkMJ * Act 2: Prethink Context Ahead of an Interaction https://lnkd.in/drt339QA I'm thinking about those 5,000 .NET apps that we need to migrate at another customer before the fall. Or the 300 more apps at the customer with the Grails app. I did a test where I ran Claude Code doing a Java 25 upgrade on a single one of our ~400 repositories. By connecting the entire OpenRewrite recipe marketplace as tools to Claude and building an LST incrementally as Claude edited the repository, the bulk of the work was done with 30k tokens and a little under 3 minutes. In comparison, when I uninstalled the recipe tools and asked it to do the same migration in a separate session, it had completed about 1/3 of the migration in 45 minutes and burned over 65M tokens. It seems the state of the art out there is connecting something like LSP to a coding agent to give it better editing tools, but we came to the realization that our existing recipes both covered basic refactoring operations (ChangeMethodName, FindTypes, DeleteMethodArgument, etc.) and also those basic refactoring operations stacked together into progressively more complex units of operation. Allow the agent to select combinations of both low level and high level recipes in the service not just of migrations but everyday editing!

58

2 Comments

Most companies try to fix misalignment with more meetings, more docs, or more dashboards. But alignment isn’t about broadcasting information. It’s about shared understanding of why decisions were made and what changed since last time. Sentra focuses on that layer: the living context behind decisions. When everyone can trace the why, alignment becomes a byproduct—not a constant struggle. If alignment feels fragile, the problem usually isn’t effort. It’s missing memory.

16

I’m not always a fan of headless. For years, one of the best things about Optimizely CMS was defining content models in code and working strongly typed. With Optimizely SaaS CMS, headless is the model — and suddenly you’re maintaining types in two places, wiring up Graph queries, rebuilding routing, and keeping everything in sync. So I tried flipping it. Instead of adapting the frontend to the CMS, I built the head first in .NET 10 — and let the CMS adapt to that. The result is a small open-source package: HeadlessKit It lets you: - Define content types in code - Mark editable properties with attributes - Sync content types + display templates automatically on startup - Render via Content Graph without wiring everything manually Blog post: 👉 https://lnkd.in/eQf2GRE7 GitHub: 👉 https://lnkd.in/eE79Vq-Y It’s early, but real. Feedback very welcome — especially from others exploring Optimizely SaaS CMS in .NET.

46

4 Comments