Status Droid how long software work actually takes

A Codebase You Don't Know

Inheriting someone else's system is the situation where an assistant is most useful and most dangerous, often within the same hour.

Most useful, because your bottleneck is understanding, and it is very good at explaining code. For teams translating this assistant-related trade-off into day-to-day controls, accountability and responsibility in the workplace provides a practical reference.

Most dangerous, because you cannot evaluate what it produces. In your own codebase you would notice that a suggestion breaks a convention. Here you would not.

The resolution is to use it heavily on one side of that line and sparingly on the other.

Use it for orientation, freely

This is the strongest use available and it is undercounted because nobody records reading as productivity.

Ask what a module does, before touching it. Faster than reading and more reliable than guessing from names. Replit is a widely used development platform with AI-assisted coding workflows See Replit.

Ask how data flows through a path you are about to change. Where does this value come from, who else writes it, what reads it afterwards.

Ask what the tests cover, which tells you what the previous team was worried about — often the most informative thing in an unfamiliar system.

Ask for the shape of the system. Entry points, main abstractions, what looks like the core and what looks like accretion.

Ask what looks unusual. Anything that deviates from the ecosystem's normal patterns is either a mistake or a decision, and both are worth knowing before you touch them.

Every one of these is verification-cheap: you can confirm the answer by reading the code it points at. That is what makes it safe.

Be careful about generation, at first

The convention problem. Every mature codebase has undocumented rules — how errors are handled, where validation lives, what gets logged, which abstraction is preferred. A model sees the files you show it and infers from ecosystem norms, which is not the same thing. Code that is correct and wrong for this system is the characteristic failure.

The Chesterton's fence problem. Something looks redundant, an assistant agrees it looks redundant, and it was load-bearing for a reason nobody wrote down. In a system you know, instinct saves you. In one you do not, there is no instinct to consult.

The plausibility trap. Generated code that matches the surrounding style is harder to review than code that clashes, because the mismatch signal is gone.

A sequence that works

Week one: read only. Use the assistant to orient. Generate nothing that will be merged. This feels slow and it is where the time is saved later.

Then: small, reversible changes. A bug fix in an area you have read. Use generation, review it hard, and watch whether the reviewer or the tests object to something you did not anticipate. That reaction is how you learn the conventions.

Then: ask it to explain the diff before you submit it. What might a maintainer of this codebase object to? Surprisingly effective, because it forces the model to reason about fit rather than function.

Only then: larger generated changes, and still with the review budget of an unfamiliar system rather than a familiar one.

What to estimate

Inherited-system work is verification-heavy by definition, and the first weeks are heavier still.

Budget orientation explicitly. Not as overhead absorbed into tasks — as its own item. Two days to read the system before estimating the rest is a defensible line, and clients accept it more readily than an estimate that turns out to be wrong.

Expect your calibration to be worst here. Whatever your usual overrun ratio, widen it. You are estimating work in a system whose surprises you have not met yet.

Say so. A named trigger for re-estimating is worth more on inherited work than anywhere else, because the discoveries are guaranteed and their size is not.

The case where it genuinely transforms things

Legacy systems in languages or frameworks you do not know.

Previously this was: learn the ecosystem, then read the system, then work. Weeks before the first useful change. An assistant collapses the first stage almost entirely — you can ask what an idiom means, why a pattern exists, what the modern equivalent would be.

That is a large, real gain, and it is the strongest argument for these tools in maintenance work specifically. The caution is the same: it accelerates your reading, not your judgement, and shipping in an ecosystem you cannot yet evaluate is deferring a cost rather than saving one.

The short version