serima | LayerX

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.