Some patterns we're seeing across our engineering clients that tell you where AI adoption is actually heading: 1. Companies are done spending blind on AI. A few months ago, most were approving unlimited API budgets for OpenAI and Anthropic with no tracking on where the tokens went. Today they're asking us to build governance layers and monitor every dollar. One client had three teams running up five-figure token bills before a single production agent shipped. Now they want dashboards that show exactly what's AI-generated, what it costs, and whether it's actually faster than adding headcount. That means more diagnostic work for us and meaningful savings for them. 2. Companies are accepting the real timeline. A few months ago, leadership expected to go AI-native over a few workshops and a handful of tool subscriptions. Now they're calling us because the codebase is seven years old and can't absorb automation without a full foundation phase first. Their developers are using AI at 60-70% adoption, but nobody's tracking what's generated vs. human-written. QA hasn't been touched. There's no governance. Going AI-native means rethinking org charts, handoffs, and process ownership across every department. Not a software purchase. 3. Companies are walking away from the big firms. The Accentures and McKinseys are all pitching AI transformations. Our clients keep showing up saying the same thing: "We paid seven figures for a strategy deck and nothing shipped." This is why firms like ours have a market. We operate at the engineering layer while having the business sense to map a process end to end, then build the agents to automate it. A year ago we had to explain this on every first call. Now prospects open the conversation with it. In the last 90 days we've taken calls with PE firms, law firms, healthcare companies, VPN providers, construction platforms, and retail tech businesses. Some are direct competitors with each other. Nearly all came through referral. AI SaaS won't transform your company. Giving every developer a Copilot subscription and calling it a strategy won't either. The only path to real operational ROI is combining a team that learns your business processes on the ground with engineering capacity to automate every manual workflow worth automating. We built Limestone Digital around this thesis ten years ago. AI made it urgent. If you're looking to transform engineering delivery or automate business processes with production-grade agents, visit limestonedigital.com.

AI adoption rarely fails on the technology. It fails when the pitch is aimed at the wrong problem. An operating partner who brings us into his portfolio companies told me he runs two completely different pitches depending on who's across the table. The first is the CEO who can already feel where the market is going and suspects the company won't get there in time. The best vertical software CEOs have that instinct. For them the pitch is short: here's help moving at the pace of your own ideas. They want the hungriest AI-native team available, dropped in, shipping. The second is the CTO, and the board is the one feeling the gap. The roadmap still runs two years, adoption of AI tools across the team is patchy, and the question in every board meeting is where the pace is. For the CTO, the pitch is about bandwidth and example. A pod takes real work off his plate, and it shows his own engineers what working this way looks like, up close, in their own codebase. CTOs respond to having someone to copy more than they respond to a mandate. The CEO worries about the market, the CTO worries about his team, and the same pod solves both only if you explain it in the terms each of them already cares about.

How AI Agents Work in Healthcare From Intake to Billing Read here 👇 limestonedigital.com/blog/ho…

This made me think about how you’d set up an existing company if you were starting it today. Mark compares it to factories that installed electricity but kept everything arranged for steam. Took changing the factory layout to really benefit from it. Would be interesting to ask the people running your company what they’d arrange differently now that AI exists.

This is the most honest breakdown of AI-augmented delivery I've seen.

If the moat is building 1,000x more every day for a decade, the constraint stops being code and becomes the people who can direct it without the system rotting underneath them. Cheap to generate, expensive to own. Compounding is a team capability, not a model capability.

30 mistakes I see enterprises make with AI transformation: 1. Buying AI licences and calling it a strategy. Decide which problems you want to solve, how people will use the tools and what improvement you expect to see. Access alone doesn’t answer those questions. 2. Expecting every employee to become an AI engineer. People need different levels of training and responsibility. Helping someone use AI in their work doesn’t automatically prepare them to build and maintain a system for others. 3. Asking AI for answers before agreeing on what a good answer looks like. Start with real examples and clear criteria. Keep verified corrections as test cases, and rerun those tests when you change the system. 4. Blaming the model before checking the whole setup. A failure can come from the model, instructions, missing information, tools or the surrounding software. Investigate where it went wrong before deciding what to replace. 5. Automating a process nobody can explain from start to finish. We spoke to a team whose work moved between calls, emails, spreadsheets and shared folders. Understanding how the work actually got done was a substantial job in itself. 6. Giving an agent more access than its job requires. Limit what it can read and change, and require approval for consequential actions. Enforce those permissions in the software. An instruction telling the agent to be careful is not an access control. 7. Making data protection depend on someone remembering to delete a name. Use appropriate access controls and automated checks to limit sensitive information before it reaches the model. Removing names alone won’t address every way confidential information can be exposed. 8. Letting an agent spend money without a limit. We still meet teams with no budget cap. Set spending limits, request limits and stopping conditions, then decide what the system should do when it reaches them. 9. Counting AI usage as proof of business progress. Token consumption can help you understand adoption and cost. It doesn’t tell you whether useful work got finished. Measure results, quality and the time spent reviewing or fixing the output. 10. Letting company data end up in accounts nobody has checked. Know which services employees use, what happens to the information they enter and which settings and agreements apply. Make the approved way of working clear. 11. Choosing a model without considering what switching would involve. Understand which parts of your system depend on that provider. A different model may need different instructions and fresh testing, even when the technical connection is easy to change. 12. Paying for discovery without agreeing on what it must deliver. We heard about an engagement where the estimate kept growing, then the consultant left for another commitment. Set clear deliverables and a point at which you decide whether to proceed. 13. Committing to a plan with no way to act on what you learn. A long project isn’t automatically a mistake. The problem is having no checkpoints where real results can change the priorities or the proposed solution. 14. Launching an agent nobody is responsible for. Assign responsibility for its operation, monitoring, updates and eventual retirement. The people responsible need the authority and resources to do those jobs. 15. Buying a custom system without a plan for when the supplier leaves. Agree on documentation, access, support and handover while the relationship is working. Know who could maintain it if that relationship ended. 16. Waiting for users to tell you something has broken. You should have telemetry installed so you don't find a problem weeks later than you should have. 17. Making an agent read everything to find one thing. Give it tools that search, filter and return relevant information. Large responses full of unrelated data consume context and make the task harder to handle reliably. 18. Letting the people who built it be the only people who test it. Involve the people who do the job and understand the business. They can help identify answers that look reasonable but would cause problems in practice. 19. Testing only the situations where everything goes smoothly. Include exceptions, ambiguous requests and cases where the system should stop or ask for help. Confusing five cases with five individual items is exactly the sort of mistake your tests should catch. 20. Keeping essential knowledge in the heads of people who might leave. One company was trying to capture how experienced colleagues made decisions before they retired. Record their reasoning and examples while they can still explain and check them. 21. Assuming every AI project must wait for the ERP migration. Some read-only work may be possible against existing data. Check freshness, permissions and the work needed to adapt it later. A replica can help, but it may lag behind the live system. 22. Assuming one company’s AI success will transfer to the whole portfolio. Use that success as a starting point. Each company still needs to check whether the approach fits its work, data and business needs. 23. Expecting AI to understand terms your own departments use differently. Explain business terms, calculations and database fields. If several measures could reasonably mean “sales,” specify which one applies to the question. 24. Producing code faster than anyone can review it. Research describes how faster generation can increase the burden on reviewers. We spoke to a team where changes were piling up because every one still needed manual acceptance testing. 25. Hiring an AI engineer and assuming the rest will sort itself out. That person still needs a clear problem, access to useful data, suitable infrastructure and colleagues who understand the work. Hiring doesn’t remove those responsibilities from the business. 26. Expecting people to forget the last failed pilot. Earlier disappointments can make people less willing to trust another system. Find out what went wrong and show what has changed before asking them to invest their time again. 27. Calling a project “90% done” before testing the difficult workflows. We’ve seen projects move quickly, then spend weeks on a couple of remaining workflows. Check what is still unproven before using the feature count to estimate the work left. 28. Expecting an agent to follow rules it cannot access. Pricing exceptions, product substitutions and informal agreements may live in someone’s spreadsheet. Make the relevant rules available, keep them current and test whether the system applies them correctly. 29. Feeding AI conflicting numbers without explaining the differences. Systems may use different definitions, update schedules or reporting periods. Establish which source and definition apply to each question before expecting a dependable answer. 30. Assuming a data feed contains the whole picture. Check which customers it covers, which fields are missing and how far back it goes. Make those limitations visible so users know what the answer is based on. What else?

holy f*ck, what did I just read

AI implementation for financial services:

A US financial services company scoped three infrastructure projects for five engineers across two quarters. Our two-person Velocity Pod delivered all three in one quarter: automated funds movement, an underwriting portal, and investor access. I want to explain what made that possible, because “two engineers using AI” leaves out most of the useful information. The platform was already processing live transactions. Existing code, existing integrations, existing customers whose money had to keep moving. An audit found several things preventing the agents from working reliably. Domain rules weren’t documented clearly. Build and test commands were difficult to discover. Different modules followed different conventions. Recurring tasks had no established procedure the agent could follow. So the agents filled in the gaps themselves. That is a pretty expensive place to let software guess. We documented the architecture, domain terminology, coding conventions, and exact verification commands at both repository and module level. We also packaged recurring procedures into reusable skills. Adding an endpoint or writing a migration now had a documented approach. Every task started with a specification. Tests came before implementation. Every change passed automated verification before merge, with a PR review agent checking against the spec and project standards. All three projects used a shared architecture, so each subsequent project started with a foundation already in place. The result: 60% fewer engineers than planned, half the estimated timeline, and about $200 in AI compute per developer per month. The lesson I’d take from this is that your codebase contains less of your company’s knowledge than you think. Your experienced engineers know which conventions matter, where the exceptions live, and why something was built a particular way. An agent needs access to that knowledge too. Making it explicit is part of the engineering work. That’s what our Velocity Framework was built for.

An IBM engineer explained agent harnesses in 20 minutes at @aiDotEngineer, and it's the best tutorial you'll find anywhere. Tejas Kumar gave GPT-3.5 one job, upvoting a Hacker News post. The agent hit a login screen and still reported success, and he fixed it without changing the prompt. People are paying $500 for agent courses that teach less than this. Watch it, then read the article on the slow death of the enterprise below.

Claude Opus 5.5 just one-shotted our launch video. Enjoy.

"How did you go bankrupt?" Bill asked. "Two ways," Mike said. "Gradually and then suddenly." — Ernest Hemingway, The Sun Also Rises, 1926

Claude just one-shotted the entire video production industry:

A PE operating partner asked us to fix his fund's monthly reporting before we touch a single portfolio company. Fifteen active companies, a side of alternative investments, and a cycle that runs the way it runs at most funds. The first five days of every month go to chasing portfolio CFOs for a package. Some arrive in Excel, some as PDF, some as a link to a sheet. An analyst normalizes fifteen formats into one, a partner sees a number by the second week, and the question about why revenue moved at one company gets answered by a phone call. If it gets answered at all. This is the norm, not the exception. 72% of operating partners rank operational improvement as the top value creation lever this year. The metrics they'd use to steer it are the ones they're least satisfied with. Data integrity, accuracy, transparency and timeliness, is the most cited operational weakness in the industry. Management fee income has slowed while the cost of reporting, audits and valuations keeps climbing. Hiring another analyst is off the table. And 75% of GPs say AI can't help with portfolio monitoring. He decided to find out on his own fund first. Before he asks fifteen CEOs to let an engineering pod into their businesses, he wants to have lived through one with his own data and his own team on the receiving end. The sequence is the same one we run inside a portfolio company: 1. Prerequisites before user stories. Which systems the numbers come from, who owns each package, what the partner actually reads. 2. A definition of correct, written by the analyst who does the normalization today, so the agent is scored against her judgment rather than ours. 3. Read-only access to the sources, identifiers handled at the data layer, the model behind an interface inside the fund's own environment. 4. The agent ingests the packages, maps them to the fund's chart of accounts, flags what doesn't reconcile, and writes three sentences on why the number moved. 5. The analyst approves. Nothing reaches a partner without a human on it. Three things this gives a fund that a portfolio-first approach doesn't. The operating partner becomes the reference. When he walks into a portfolio company he can say this is what it looked like in our shop, here's what it cost, here's what broke. That changes the CEO's question from "should we" to "how." The fund learns the shape of the problem. Fifteen packages in fifteen formats is the same problem as customer reporting at a services business or claims data at a billing company. Messy inputs, a spreadsheet somebody trusts, a number a decision-maker needs by Friday. Solve it once at the fund and you've rehearsed it for the portfolio. The pod is already warm. The engineers who learned the fund's data conventions and the partner's standards are the ones who walk into the first portfolio company that says yes. The results section follows when the operating partner is ready to share it. What's already true: the workflow every fund runs monthly, by hand, at a cost rising faster than fee income, is the one most of the industry has decided AI can't touch. He'd rather know than assume.