Rajesh Selvaraj

• ▸AI can automate a weak SDLC — but first it exposes one

  ongoing

  AI can absolutely repair and automate a weak SDLC. But before it does, the surge in AI-driven change volume exposes every place the system can't reliably absorb, validate and recover from change — the bottleneck moves from writing code to everything that happens after the code exists.

  click to read the story

• Voluntary frameworks lose to local incentives

  resolved

  Every 'please adopt this' standard I've shipped only stuck once the paved road was easier than the workaround. If the incentives point elsewhere, the framework loses — so I design for the incentive, not the mandate.

• It's not testing — it's confidence to propagate change

  resolved

  Quality isn't shift-left or shift-right; it has to run across the whole SDLC. What you're really building is the confidence to propagate change through both loops — the inner loop (code → build → test) and the outer loop (lower env → preprod → prod, behind guardrails and testing in prod) — then feeding what production teaches you back into the inner loop. Test maturity is the precondition that makes that confidence possible, not an outcome you bolt on later.

• ▸Internal AI tools live or die on UX, not model accuracy

  ongoing

  For AI that augments human judgment — tools that surface information for a person to act on — the bottleneck is almost never the model. It's readability, trust calibration, and integration UX. Engineers won't trust a tool that's hard to read, even when it's right.

  click to read the story

• Platform reliability is part of the product, not an implementation detail

  resolved

  Dependencies are never neutral — you inherit their reliability, latency, support model, roadmap and org dysfunction along with their features. So the real question isn't 'can this upstream service do it?' but 'am I willing to make its failure modes part of my product's experience?' Architecture is partly an organizational-risk decision.

• Shared ownership usually means nobody owns the outcome

  resolved

  When five teams each own a slice — the data, the controls, the policy, the tool, the truth — everything sounds rational until something breaks and no one owns the whole experience. RACI charts don't create accountability; a named person with an outcome does. So I keep asking the uncomfortable question: who owns this end to end?

What's on my mind:

click any topic to start an email about it — or connect on LinkedIn

• →developer velocity & deployment excellence
• →developer-platform & infrastructure strategy
• →AI-assisted SDLC: create → verify → ship → automate
• →platform economics, and how developer investment gets funded
• →turning ambiguity into an operating model
• →systems thinking — and when to stop analyzing

No mail client? Copy rajeshselvaraj045@gmail.com.