rahul

@rahulgs | CTO

it is simultaneously possible to spend a lot on AI and still underuse it, esp in larger orgs. we're seeing this with meta, uber, and many other orgs instituting budgets. some factors are at play: 1. cost of the frontier comes at an enormous premium: fable -> glm 5.2 is a 10x dropoff in cost. 2. tragedy of the commons, in large orgs, much safer to always default to larger model at a higher reasoning effort. ends up in a situation where most features/people are on too high of a setting, resulting in 2-3x more spend than needed. 3. very easy for runaway automations, openclaw bros, subagent accidents, to create a lot of spend quickly. results in a very skewed distrubtion of usage with a small number of people/features with high usage. to counteract these issues, and avoid internal budgets (for now): 1. we changed defaults across the company to lower reasoning levels, across surfaces. 2. thinking about the p50, p75, p95 session. cost to PR/cost for support ticket/cost for session, and actively compressing model tiers (gpt 5.1->5.4-mini) over time. 3. banning automations from using frontier models, and high reasoning efforts, and using flex api tiers (adds up to 75%+ savings). tldr before you institute budgets, try these first. more in the blog: engineering.ramp.com/post/ai-spend-value - "You're Spending Too Much on AI. You're Also Using Too Little."

Jun 19, 2026

Dylan Garcia

@_dylanga | Software Engineer

Inspect at Scale. Since our original blog post, Inspect's adoption has skyrocketed, the product has matured, and the industry has moved just as fast. What started as an engineer's tool for writing code is becoming...

Jun 19, 2026

rahul

@rahulgs | CTO

A 10-point thread on building software with frontier models: 1. as a mental model it is more correct to think of fable+ class models as english -> code interpreters - converts your idea into code into "correct" code regardless of problem complexity and output complexity (diff size). Fable 5 will be the worst of this new class of models. 2. diff size/complexity is to be managed purely for review: small diffs - in high risk areas of code (auth/identity/data access/network access/money movement); large diffs for code that can be empirically verified (frontend/backend plumbing/code without network or db access/performance code that can be empirically verified). 3. time it takes to ship software is completely disconnected from time to produce the PR - how long the work takes depends fully on ability to review/merge code while managing risk at scale. 4. solving the bottlenecks for above matter enormously - linters/testing/CI/shadow mode verification/empirical verification. 5. agency matters enormously - what are the biggest bottlenecks to speeding up the loop and eliminating them? what are the problems that need solving and when do they need solving? what does it take to the solution to all of them today? 6. deep understanding of the full stack matters enormously - what problems are worth pursuing? is there a higher level of problem abstraction to address first? should I give it the sub-sub task, the sub task, or the task itself. what are the major risks with this PR (order of importance: security holes/correctness holes/performance holes). is there a higher speed way of producing data that allows me to merge this? should this be run in shadow or in a sandbox or a flag. understanding every line of logic may not be needed but understanding and managing risk matters enormously. 7. the cost of complexity itself is changing. it might be now worth "maintaining" 50% more code to get a 5% performance win. getting the right abstractions matter less because larger refactors are less tedious. code quality nits become huge drag. very likely, a much smarter model will be maintaining your code so worth taking on more technical debt now. taking the time to hand architect and rebuild systems comes with an enormous cost of velocity. 8. if it quacks like a duck and walks like a duck, it's a duck. For low risk cases, it might be more sane to treat code chunks (services / functions) as a black box, like we do for neural networks: do full empirical verification only: has code produced correct outputs for the last 10,100,1000,10k inputs? can we quarantine this large piece of code - no outbound access to network / database? what happens when this code is wrong? do we get hacked/or crash(memory/cpu)/is an inconvenience? is it internal facing or external? what can we do to address these risks? 9. eventually, logical verification (line by line review) will come at an enormous cost - save it for where it matters and build systems that are tolerant to empirical verification. is there a decorator that prevents db / network access? correctness bugs are significantly easier to rectify than access bugs. 10. what are the rails that allow for even faster iteration? code permissions can be opt in - db writes, db reads, network egress (to where?), PII access. how long does it take to get shadow mode data? how many PRs can be tested? What are the categories of diffs

Jun 17, 2026

Veeral Patel

@vral | Software Engineer

Welcome to the Token Casino. It's not a secret that the Labs make more money when you spend tokens. But your company wins when you ship more product and get paying customers. A casino analogy isn't perfect. Casinos are built...

Jun 8, 2026

Ramp Labs

@RampLabs

A spreadsheet agent is only as good as the information it retrieves. We built Fast Ask, a sub-agent in Ramp Sheets post-trained with Prime Intellect, that scores +4% over Opus on exact match accuracy at Haiku latency.

May 7, 2026

Veeral Patel

@vral | Software Engineer

We built first-class AI usage tracking directly into Ramp, a full pipeline from ingestion to cost analytics that supports major AI providers including OpenAI and Anthropic as well as popular model gateways such as LiteLLM and OpenRouter.

Apr 16, 2026

Kabir Oberai

@kabiroberai | Software Engineer

We like saving our customers' time, and we knew it would be more seamless to scan your photo library and find receipts automatically than having customers rummage through their photo library. One key requirement: this needs to happen entirely on device so your private photos stay private.

Apr 13, 2026

Ramp Labs

@RampLabs

Existing approaches to managing this context such as LLM based summarization (slow) or retrieval via RAG (brittle) introduce their own tradeoffs. Instead, we use the model's attention patterns to identify which parts of the context are important and discard the rest at the representation level.

Apr 10, 2026

Karim Atiyeh

@karimatiyeh | CEO & CTO

No tool in the market connects token-level usage, invoice data, and card-level spend. So we built one.

Apr 9, 2026

Seb Goddijn

@sebgoddijn | Product Management

The difference between AI adoption that sticks and AI adoption that's performative comes down to one thing: does it actually make the work better?

Apr 9, 2026

Geoff Charles

@geoffintech | Chief Product Officer

6,300% YoY increase in AI adoption at Ramp. 99.7% of employees using AI tools. 1,500+ internal apps built in six weeks. Non-engineers now account for 12% of PRs.

Apr 8, 2026

Andrew Chapello

@chapello | Product Management

I just crossed 730 days at @tryramp. Here's 5 lessons for builders on how we operate which have shaped the way I approach building products.

Apr 2, 2026

Teddy Riker

@teddy_riker | Product Management

Diving into the engineering behind Ramp's latest infrastructure work and what it means for building at speed without sacrificing reliability.

Apr 2, 2026

Ramp Labs

@RampLabs

How we made Ramp Sheets self-maintaining — scaled from ten hand-written monitors to over a thousand AI-generated monitors, catching 40 real bugs in the first week.

Mar 24, 2026

Ian Tracey

@ian_dot_so | Software Engineer

The tech industry is splitting in two. We're at the beginning of a K-shaped divergence: some engineers becoming more valuable than ever, while others watch their skills depreciate in real-time.

Jan 5, 2026