If AI makes you 10x faster at coding, why is your team not shipping 10x faster? Amdahl's law has the answer... The law says the overall speedup is capped by the part you did not speed up. With `p` as the fraction of the work you accelerate and `s` as the speedup on that fraction, speedup is computed as attached. Now plug in some numbers. Say writing code is 30% of the time from idea to production, and AI makes that part 10x faster. The overall speedup is 1 / (0.7 + 0.03), which is about 1.37x. Even if coding is half of the cycle, you get about 1.8x. These numbers are illustrative, so use your own, but the shape stays the same. The rest of the cycle is still there: - Figuring out what to build - Aligning product, design, and other teams. - Code reviews, which are now more than ever - CI and CD takes the same wall time as before. - Debugging and incidents, where code that nobody on the team wrote line by line takes longer to understand. In fact, it can get worse than Amdahl predicts. Faster code generation increases the load on every stage after it, so the review queue grows and the bottleneck shifts. A team that writes 10x more code with the same review capacity is just building a bigger queue, unfortunately So if you want the team to actually ship faster, measure the whole path from idea to production and find where work waits. Then apply AI there too: review, test generation, flaky test triage, deploy safety checks. Otherwise, you have optimized the part of the system that was never the constraint. Speeding up the typing was always the easy part :)

this answer is correct but it's slow. the correct and fast answer is tigerbeetle

Recently I interviewed a Senior Engineer. Strong candidate. Kafka? ✅ Redis? ✅ Microservices? ✅ Distributed systems? ✅ Then I asked: "You're building the inventory service for a flash sale. Only 1 item left in stock." Two users hit “Buy Now” at the exact same millisecond. Both requests pass the “is available?” check. Both create an order. Both deduct stock. Now you’ve sold 2 items when only 1 existed. How do you guarantee you never oversell — even with concurrent requests, client retries, and partial failures? "Just use a database transaction." Doesn’t fully solve it if both requests read `stock = 1` before either writes, or if the response is lost and the client retries. "Check stock before deducting." What happens when both checks happen at the same time? "Use Redis DECR and reject if it goes negative." What happens if Redis is down, or the decrement succeeds but the order is never persisted? Your turn: How would you design this inventory reservation API so concurrent buyers and retries never oversell the last item? There’s a specific distributed-systems concept behind this. And you’ll encounter it everywhere inventory, tickets, seats, coupons, and limited resources are involved.

Even if your database is infinitely fast and infinitely parallel you can’t hack your way around network round-trip time and contention, where multiple transactions force you to lock your hot rows. This is Amdahl’s law applied to transaction processing and it’s why even at just 10% contention, your throughput drops not by 10%, but 10X. @jorandirkgreef describes this fundamental flaw in the SQL transaction interface 👇 @TigerBeetleDB #OLTPforthenext30years