An AI engineer,
available right now.

The expensive engineering mistakes are decided in an afternoon and paid for over three years. Schema shape, service boundaries, the abstraction that seemed clean.

What catches them is a senior engineer with no stake asking why. Most teams do not have that person available at the moment the decision is made, which is why the Engineering Copilot is most useful before the code exists rather than after.

Generated code is a draft. It compiles, it looks plausible, and it can be subtly wrong in error handling, edge cases and concurrency - the three places where wrong is expensive.

Review it like a colleague's pull request. That is not a limitation of this tool specifically; it is the correct posture toward any code you did not write.

A bug that has stopped making sense is almost always a belief that is false - about what the data looks like, about what a library does, about what actually runs in production.

Explaining the problem to something that asks the obvious next question is genuinely effective, and it is why rubber-duck debugging has survived as a technique. Having the duck ask follow-ups is a real improvement on the original.

Generated code fails differently from human code, and knowing the failure modes makes review faster.

It is reliably good at the happy path and reliably weaker at the edges. Error handling is often present, plausible, and wrong - catching too broadly, swallowing the exception, or returning a default that silently corrupts state downstream. That is the first place to look.

It is confident about APIs that have changed. A method that existed two versions ago will be used with complete assurance, and the code will look correct until it does not compile or, worse, until it runs with different semantics.

Concurrency is the third weak point. Code that is correct single-threaded and subtly wrong under concurrent access is exactly the category that passes review by looking reasonable, and it is the category that produces the bugs that take three days to find.

And it does not know your codebase conventions, which means it will reimplement something that already exists in a utility module three directories over. That is not a correctness problem and it is a maintenance one.

The review posture that works is the one you would apply to a competent contractor on their first week: read every line, question the error paths, check the versions, and confirm it does not duplicate what is already there.

The most expensive engineering decisions are the ones that add capability you do not need yet, because they add operational cost immediately and deliver value conditionally.

Microservices are the standard example. They solve organisational scaling problems - independent deployment, team autonomy, isolated failure domains - and they cost distributed tracing, network failure modes, data consistency work and a deployment pipeline per service. A team of five adopting them buys all of the cost and none of the benefit, because the problem they solve is a problem of forty engineers.

The same pattern recurs. Event sourcing before there is an auditing requirement. A message queue before there is a throughput problem. Kubernetes for an application that runs comfortably on one machine. Each is a good technology and each has a threshold below which it is a net loss.

The useful question is what the current system is actually failing at. If it is not failing, the architecture is adequate by definition, and the migration can wait until there is a specific pressure to relieve.

The counter-argument is that some decisions are hard to reverse and worth making early. That is true of data models and much less true of infrastructure, which is generally easier to change later than teams assume.

Inheriting an undocumented system with no original author is a common situation and there is a reasonably reliable approach to it.

Start at the boundaries rather than the centre. What HTTP routes exist, what jobs run on a schedule, what the database schema looks like, and what external services it calls. Those four describe what the system does far faster than reading source in file order.

Then follow one request end to end. A single complete path through the system teaches more about its conventions and its layering than any amount of breadth-first reading, and it exposes the abstractions that are load-bearing versus the ones that are decoration.

Read the tests next, where they exist. Tests document intended behaviour, including behaviour that is not obvious from the implementation, and a well-named test suite is often the closest thing to a specification that survives.

Check the git history for the files that change most often. Those are either the core of the system or the part that is chronically broken, and either way they are where attention belongs.

Write down what you learn as you go. The document you produce in the first fortnight is the one the next person needs, and it will never be easier to write than while everything is still confusing.

There is a reasonably reliable procedure for the class of bug where the behaviour appears impossible, and most of it is about attacking assumptions rather than code.

Start by establishing what is actually true rather than what should be true. Print the value; do not reason about it. A surprising share of impossible bugs resolve the moment somebody confirms that the config being loaded is the config they think is being loaded, or that the deployed code is the code in the branch.

Then reduce. Remove pieces until the behaviour disappears, then put back the last piece. A minimal reproduction is worth more than any amount of reading, and the act of producing one frequently identifies the cause before it is finished.

Bisect on time when reduction is hard. If it worked last month, the change that broke it is in the history, and a binary search over commits finds it in a small number of steps regardless of how large the diff is.

Question the boundaries. Bugs cluster at edges - between services, between the application and the database, between your code and a library, between environments. The middle of a function is rarely where the surprise lives.

And explain it out loud, to a person or otherwise. The reason rubber-duck debugging persists is that articulating a problem forces implicit assumptions into words, and the false one is usually audible the moment it is said.