one year at ramp this week. came from a small startup, now I work on a system that does billions in monthly payments volume and a team that ships almost entirely through coding agents at one of the fastest growing fintechs ever. some of my most important learnings: - you can't hold the system in your head, and the agent editing it can't either. spending extra time going over states x flags x callers in a little matrix and building context for yourself + your agent feels slow but is faster than the TTR of an incident - throughput isn't scarce anymore. the engineers who sped up most this year weren't the best prompters, they were the ones with the most product context. "ships useful stuff often" is now "knows what's useful" - decisions made in conversation and not captured in writing get relitigated by ppl as well as by agents. make sure you capture the why. written / async communication by default is a commanding advantage for a company. - agentic coding makes it tempting to plan and build towards the final phase of a product from the beginning. Iterative development is still the way to win. Just because an agent can design and ship a fully fledged product in 48 hours doesn't mean that's the product your customers want. Design for the MVP - internalize the context yourself - and use that context to get to the _correct_ product / feature. - the bottlenecks are now at the start and tail ends of "engineering work": i.e. how precisely you specified & how well you can verify. a vague ticket produces a confident wrong PR in about the same time a precise one produces a right one - the only useful signal is if the things that someone shipped actually mattered, which is much harder to measure than "how many tickets / prs / lines of code did someone complete" - but if you can find a way to do it your team / org will absolutely rip. - the first real bug I shipped here involved a file with five callers I never read. the agent didn't read them either. happy to have learned that lesson - not one I needed to learn twice. - in my first month i burned a week reasoning & building from a design doc about how money moved before I actually looked at prod data and realized it was orthogonal to the outdated design doc. don't do that. - writing code is the cheap part now. my default way of working now is sending a linear ticket w/ context + verification criteria + agent instructions to inspect and getting a PR back while I'm in a meeting. this means I can scale myself in ways that were basically impossible a year ago. - most of my eng hours go into ticket / problem specification and review. this is normal and good. - the next reader of your code is typically an agent that's not gonna look at the git log, PR description, or slack. If the _why_ isn't evident or clearly documented in a comment it's probably going to be lost on the next implementer in there making a change. - tests are the spec the agent optimizes against and bad tests can be so so costly. every weak assertion is a gap agents can find and reinforce if you just blindly merge in tests. - most of these are the same lesson: you have less context than you think and so does the agent. now that implementation is easy the differentiator among engineers (and companies) will be how well can they build the correct context and make decisions & bets based on that context. act accordingly.

You can just build things. Super pumped for @Mochatradeapp and super proud to have helped build this. If you are a YC startup and are considering taking your funding round in stablecoins please reach out! We'd love to have you as a @tryramp customer.

.@tryramp now supports @global_dollar on @solana. As with all stablecoins we support, we're proud to offer 1:1 onramps & offramps for USDG across our suite of products. USD → USDG: $0 in fees USDG → USD: $0 in fees What makes this release extra special is that it's brought to you by the newest member of our digital asset team, @carterappleton, and was shipped in just his first two weeks at Ramp. Stay tuned, much more to come from him in the future.

Had an absolutely wonderful time chatting with @sytaylor @rangoldi and @chapello yesterday on the @TokenizedPod about Ramp, stablecoins, and the future of money movement. Gonna be sending this one to my mom when it drops.

I am genuinely stoked for @tempo's new virtual addresses feature that they announced yesterday. I think this could be a real sleeper hit and I'm guessing that most people who don't have first-hand experience building on-chain don't realize it. In almost 8 years building in crypto I've had to solve the deposit-address problem at literally _every single company_ I've worked at. Every time its the same build out: Generate a unique address per customer Sweep funds back to a master wallet Manage gas in every leaf address Reconcile timing differences Handle the edge cases It's the kind of thing that sounds simple in a design doc and then can end up eating a quarter of your team's roadmap. It is _so cool_ to make this a protocol primitive - and totally obvious in hindsight. No sweeps, no per-address gas, no state bloat from millions of customer accounts sitting around with minuscule amounts of dust in them. This is another one of those things that - if you've built any kind of systems in payments before - seems like an absolute no-brainer, yet somehow we don't have any blockchains with virtual accounts as a first-class citizen yet (Solana's ATAs partially get there but you still need to pay rent per account). Bullish on how much friction this will remove for teams bringing AR / AP on chain and on more protocols bringing more "obvious" payments primitives on chain in general. Hat tip.