Rohit Kumar

Generating a new project feels relatively straightforward, but modifying an older codebase with existing conventions is a different challenge. I m curious how well coding agents handle unfamiliar folder structures, shared components, and legacy code. What has your experience been with this?

A ten minute check for anyone whose code catches a broad exception around a service call and shows its message to the user.

In PHP, every database error I can get is a RuntimeException. So is almost every refusal I throw on purpose: please add at least one item, this plan does not include that. From the first commit my controllers caught RuntimeException around service calls and showed the message, which is right for the refusals and quietly wrong for everything else that shares the type.

A review in August read what an unreachable database would have produced. On the invoice form, a validation error made of an SQLSTATE line, on a form the user cannot fix. On checkout, a message saying the payment had permanently failed, from the branch meant for refusals, while the branch that says try again later never ran. On every document page at once, not found, for documents that exist. In the API the same kind of catch would have answered 4xx, which a client library reads as do not retry, so the request a retry would have saved gets dropped.

The fix was to give the refusals a type of their own. A refusal is a message written to be read by the person who caused it, whoever is to blame: unable to save the logo counts, even though that one is our fault. Everything else is logged and answered with a 5xx and one plain sentence. The new type extends the old one, so a catch nobody had narrowed yet kept behaving exactly as before.

Every time we try to write a case study, the biggest bottleneck is actually interviewing the internal team.

Engineers are busy fixing bugs, PMs are on to the next launch, and nobody remembers the exact metrics from months ago.

It feels like 80% of the effort goes into back-and-forth calls just trying to rebuild what actually happened before writing a single word.

How does your team capture project details early so you don't have to chase people down later?