The advantage of decompilation as a task is that you have a reference output you can validate against.

I would assume the approach, mechanisms, and quality of produced code is similar to general/prompted code generating.

I assume the produced code (and its quality) depends on the compiled code; how much was stripped or obfuscated, and what runtime are we talking about which may or may not have language constructs that guide structure. With little metadata or code structure left AI would shift more into it’s general patterns than if there is more metadata available that already defines structures or names.

The thought of integrating a deterministic decompiler and then use AI to structure it and make it more readable while verifying the output remains the same seems like an interesting extension or alternative workflow and toolchain.

I have not used these kinds of AI decompilation tools or workflows, but thinking purely from my background and general experience.

Now, with all that telemetry in place and a coding agent I can finally engage with production properly: not reactively when something goes wrong, but every day I can chat with the production, ask it about its concerns, about what is going on lately, if something feels wrong.

Good luck

Reading the tldr immediately made me think of special keywords being introduced that you wouldn’t guess.

Those in the know could then trigger the more secure mode, while everyone else wouldn’t know any better.

It could also be the language you prompt with. Make Chinese prompt results secure by default, and others not.

The latter would be demonstrable. The prior would need discovering or leaking/whistleblowing the secret phrase before it would be demonstrable.

It’s a broad topic.

Be mindful of how you communicate. Differentiate between questions, risks, wrongs, subjective. Talk with your teammates. Establish a common understanding of deliberate word use or forms, intentions, and necessities to answer or change or not.

Consider whether passive and non-aggressive communication is the best approach. Some people may not pick up on defensive tone and just not care. Maybe they need more direct and pushy speech and discussions where you point stuff out, including the overall approach to working together and your assumptions or expectations.

Be mindful of sharing alternative approaches or knowledge vs not commenting to reduce own time investment and number of comments. Discuss with your team where the sweet spot is. This may change over time and is different with different people, their experience in general and in the project.

Make it clear that the one submitting the code is the owner and person responsible. They have to take ownership.

If necessary, establish a common understanding of where to commit time investment. Usually it’s much preferable for the author to invest time into a well documented submission over a reviewer trying to understand and find things out through analysis and questions.

Try to find a common understanding of not just the solution but what the authors understanding and intentions, what edges and alternatives did they consider, what risks or decision basis did they use.

Establish understanding on what your role as reviewer is. Risk reduction? Common standardized solutions and code? Are you lead and give long term direction, including how things are implemented to reduce long term complexity and variance? Do you teach through reviews?

If necessary or unclear, ask what or how deep you are being asked to review. Depending on the author expertise and trustworthyness and your load, sometimes merely approving a concept and a broad peek into the most risky parts or what you want to see the approach on may be enough. Sometimes they may be confident and just want approval on the concept, not every code change.

Be mindful of when to not post comments but ask for a shared screen meeting and talk for them to walk you through or explain things. The author should also be mindful of when they think discussion before asynchronous written review makes sense.

Consider whether you are always the one who should review. At all, or first. Maybe someone else can. Maybe you can do a second review pass, maybe only on remaining open questions.