Picture this: a pull request has been sitting in your queue since Tuesday morning. Tests pass, the story’s done. Then you scroll back through the module’s history. Three weeks ago the same team shipped a feature there, and the two implementations barely look related. Same module, same team, same standards on paper. You ask the lead what changed. Nothing did. Both developers used the same AI assistant, just differently: one fed it the surrounding code and asked it to follow existing patterns, the other described the feature cold, took the response, and use it as a base.

Neither did anything wrong, and each feature works fine on its own. But the module now speaks two dialects, and every feature that lands next will have to pick one. Nobody decided what the AI assistant should or shouldn’t do, so the codebase made the governance decision by default. Nobody decided it should.

It’s a small scene, but some version of it is playing out on most development teams right now.

Most treat the AI tooling decision as something still ahead of them, when it’s actually already here: a present condition nobody has managed yet.

Three failure modes of unmanaged AI tooling

That pull request is just the visible tip of the iceberg. Left unmanaged, the same condition tends to surface as three recognisable patterns, starting with the one you just pictured above.

Quality debt

AI-assisted code can look clean in review while the inconsistencies compound underneath. Picture a team using AI assistance informally, without shared conventions: tab sequences that ignore the screen standard, database naming that drifts from feature to feature, validation messages worded three different ways. All of it ships, release after release. The output just reflects whoever happened to be prompting that day, and there is no version control for a person’s phrasing.

Compliance blind spots

AI output can sound confident while quietly diverging from how your systems actually work: a schema decision that looks reasonable in isolation but contradicts a table structure two layers down. Without a deliberate step checking AI-proposed designs against the real codebase before anyone acts on them, nothing catches this early. It tends to surface downstream instead, later and more expensively, because nobody agreed in advance that someone should be looking.

Productivity theatre

Teams report heavy AI usage and feel busy, but context gets rebuilt from scratch on every feature, and handoffs between stages still mean redoing work that should have carried forward. Usage goes up. Cycle time doesn’t move. Nobody is misusing the tool. What’s missing is the connective tissue that turns individual sessions into compounding progress.

All three trace back to the same gap: nobody has decided, on purpose, what governing this actually looks like.

What good looks like

Governance sounds like it requires getting every rule right before you start, but waiting for that is its own kind of paralysis. What we’ve watched work, with a small development team building an ERP product that we advised, is treating an imperfect first draft of the rules as something to plan around rather than a blocker to clear first.

With that team, the rulebook came first: the coding conventions, database and schema standards, UI patterns, and module-by-module domain rules the assistant would be held to. The assistant drafted it itself, scanning the existing code for patterns already in use, then running structured interviews on the grey areas no codebase documents. That removed the blank-page problem on day one. A rulebook built that fast was never going to be right immediately, and the team treated that as part of the process, not a defect to patch later.

They built a correction mechanism directly into the workflow from day one. After any session that needed real correction, the AI assistant drafted the fix: a proposed edit to its own instructions, reviewed by a team member before it took effect. A one-off mistake stayed one-off. A recurring pattern became a permanent rule, and the rulebook improved because using it counted as writing it.

The same discipline carried into the retrospective. Before the team sat down to talk, the assistant pulled real delivery data from the finished feature and classified each issue by cause: a knowledge gap, a design gap, or a missing convention. On one feature it connected four separate bugs nobody had linked: all four traced back to a single design question, flagged before build began and never answered. The team walked in with the root cause already found, ready for discussion.

Three governance decisions

Everything that worked with that team traces back to three decisions they made deliberately. Once AI tooling is a present condition, no team can afford to keep deferring them.

Scope: where do people stop and the assistant start?

Scope is the division of labour, written down: what the assistant produces, what people decide, and the rules that hold the boundary between them. With this team, the assistant drafted at every stage: prototypes, designs, user stories, test cases, implementation plans, code. People held everything that carried judgement: whether a feature was worth building, whether a design was approved, what a story was estimated at. Two rules gave the boundary teeth: the assistant drafted a plan and stopped before writing any code, until a human approved it; and it never set estimates, because nobody owns a number the assistant generates.

Review: what changes about your process?

Review is where your process changes most. Most teams review AI-assisted work in one place, the pull request, which is the most expensive moment to discover a design problem. With this team, review moved upstream: every stage ended with a named sign-off, and no stage started before the previous one had it. Before any stories were written, a built-in check compared the design against the feature the team originally approved; contradictions blocked progress until resolved. It sounds like more process. In practice, the rework it prevents costs far more than the checkpoints do.

Accountability: who owns AI-generated output?

The team ran on one principle here: the assistant generates, a person validates, and the person who validates owns the result. Every artefact, from design documents to code, passed a named human checkpoint; past that point it was theirs, exactly as hand-written work would be. When something went wrong anyway, someone traced it back to one of the retrospective’s three causes (a knowledge gap, a design gap, or a missing convention) rather than letting it sit as a vague feeling that a feature “took longer than it should have.”

What’s actually at stake

Go back to that pull request. The cost of leaving these decisions unmade is quieter than a dramatic failure: the same small defects recurring across releases, a schema decision that looks fine until it hits production, a growing gap between how fast your team appears to move and how fast features actually land. None of it arrives as a single incident, only as a slow erosion of the exact advantage AI tooling was supposed to deliver.

Teams that decide Scope, Review, and Accountability deliberately see the gains compound the other way: each feature makes the next one faster, because conventions, context, and lessons carry forward instead of resetting. Teams that leave the decision unmade are only postponing it, and they discover their exposure later, at a worse time.

Whether AI ends up a tool, a teammate, or a liability on your team was never a question about the technology. It’s answered by whether Scope, Review, and Accountability get decided on purpose, or left to drift.

Your team is already making this decision every day it uses the tool. The only open question is whether it’s one you’re making on purpose.

Author: Felix Arya

Executive Summary

AI coding agents are becoming increasingly valuable in software development because they can accelerate coding, testing, refactoring, documentation, and problem analysis. However, their benefits can only be realised safely when organisations apply strong engineering discipline, clear requirements, automated quality gates, and human accountability. AI-generated code must be treated as untrusted until it has passed the same engineering, quality and security controls required for human written code. It must be reviewed, tested, secured, and aligned with the architecture and standards of the software system.

This white paper is written for senior engineering leaders, platform and DevOps teams, security engineers, and technical product owners who are responsible for governing AI-assisted software development. It identifies the major risks of using AI coding agents, including poor code quality, maintainability, security, and requirements alignment. To address these risks, organisations should establish a controlled software development environment that includes documented functional and non-functional requirements, coding conventions, architecture guidance, code review checklists, CI/CD quality gates, automated unit and integration testing, code quality analysis, and security testing.

The paper also emphasises the importance of training software development teams to work effectively with AI coding agents. Developers should learn how to :

• create high-quality prompts using the 4S principles: Single, Specific, Short, and Surround.
• use AI Spec-Driven Development tool so that requirements, design intent, implementation plans, and tests are defined before code generation begins.

Finally, this white paper recommends a phased implementation roadmap that starts with governance and standards, proceeds through controlled pilots, strengthens automated quality and security gates, scales adoption across teams, and continuously improves based on measured outcomes. With the right controls in place, AI coding agents can enhance developer productivity while preserving code quality, security, maintainability, and accountability.

1. Risks of Using AI Coding Agents in Software Development

AI coding agents can produce convincing code quickly, but speed can mask defects in quality, security, maintainability, and requirements alignment [1]. To assess these concerns clearly, it is useful to separate the root causes from the risks.

1.1 Common Root Causes

• Incomplete or ambiguous requirements. When functional requirements, non-functional requirements, acceptance criteria, and edge cases are not clearly defined, the AI coding agent may optimise for the prompt rather than reflecting the real business need.
• Insufficient project context. AI coding agents may generate code that does not align with existing architecture, coding conventions, domain models, integration patterns, or operational constraints if these are not provided as context.
• Over-reliance on generated output. Developers may accept generated code too quickly when it appears plausible, especially under delivery pressure, without fully validating design, behavior, security, and maintainability.
• Weak review and validation practices. Risks increase when teams do not apply structured code reviews, automated tests, quality gates, security scanning, and dependency checks to AI-generated code [3].
• Lack of prompt engineering discipline. Vague, broad, or overly complex prompts can lead to code that is technically functional but misaligned with standards, specifications, or long-term maintainability goals.
• Inadequate data usage policies. When organisations lack clear rules for what source code, secrets, production data, or customer information may be shared with AI coding agents, developers may inadvertently expose sensitive or regulated data in prompts.

 

1.2 Code Quality and Maintainability Risks

• Non-compliance with coding conventions. AI-generated code may use naming conventions, formatting, error handling patterns, logging approaches, or folder structures that are inconsistent with the project standard. This inconsistency increases review effort and makes the codebase harder to navigate [1], [2].
• Violation of SOLID principles. AI coding agents may generate classes or functions that are tightly coupled, difficult to extend, overly broad in responsibility, or dependent on concrete implementations rather than abstractions. These issues reduce modularity and make future changes more expensive.
• Poor maintainability and technical debt. AI-generated code may be verbose, duplicated or over-engineered. It may pass initial tests while creating hidden complexity that becomes costly in later releases [1], [2].
• Hallucinated dependencies and APIs. AI agents may introduce non-existent functions, endpoints, or third-party libraries that compile initially but fail at runtime or during integration testing, increasing rework and debugging effort.

1.3 Security and Compliance Risks

• Security vulnerabilities. AI coding agents may use insecure patterns, omit validation and authorisation checks, mishandle secrets, use unsafe dependencies, or produce code that is vulnerable to injection, insecure deserialisation, broken access control, or other common weaknesses [1], [2].
• Dependency and supply chain exposure. AI-generated code may introduce libraries or package versions that are outdated, vulnerable, unnecessary, or inconsistent with approved dependency policies.
• Compliance gaps. AI-generated code may fail to meet privacy, auditability, accessibility, logging, data retention, or regulatory requirements if those constraints are not explicitly provided and validated.
• Data leakage. Prompts and generated code submitted to cloud hosted AI coding agent may be stored or logged by the provider, creating risk of confidential source code secrets, or customer data if appropriate data classifications and private deployment options are not in place.

1.4 Requirements and Delivery Risks

• Failure to meet functional requirements. AI-generated code may satisfy a narrow interpretation of the prompt but miss business rules, edge cases, data constraints, or user expectations.
• Failure to meet non-functional requirements. AI-generated code may not meet expectations for performance, scalability, reliability, observability, accessibility, privacy, compliance, or operational resilience.
• Misalignment with delivery expectations. AI-generated code may appear complete while lacking sufficient test coverage, documentation, deployment readiness, or operational considerations.

1.5 Human Accountability and Knowledge Risks

• Limited developer understanding. When developers accept AI-generated code without fully understanding it, ownership weakens. This creates risk during debugging, production support, incident response, and future enhancement work.
• Reduced engineering judgment. Teams may become overly dependent on AI-generated suggestions and spend less time reasoning about architecture, trade-offs, error handling, and long-term maintainability.
• Weak traceability. If prompts, assumptions, generated code, review decisions, and test evidence are not captured, the team may struggle to explain why the code was implemented in a particular way or how it was validated.

2. Development Environment Controls to Address AI Coding Agent Risks

Organisations should treat AI-generated code as untrusted until it has passed the same engineering, quality, and security controls required for human-written code. The development environment should make the desired standard explicit, automated, and enforceable.

• Provide clear functional requirements. Every AI-assisted development task should begin with documented user stories, acceptance criteria, business rules, input and output expectations, edge cases, and error handling requirements.
• Provide clear non-functional requirements. Prompts and specifications should include performance targets, scalability expectations, security requirements, logging standards, privacy constraints, accessibility needs, and operational requirements.
• Define and publish coding conventions. Teams should maintain a coding standard covering naming, formatting, folder structure, dependency management, exception handling, logging, testing expectations, and documentation practices.
• Define architecture and code structure guidance. The team should provide reference patterns that help AI agents generate code aligned with SOLID principles and the system architecture.
• Establish a code review checklist. Reviews should confirm that the code is understood by the developer, follows conventions, satisfies requirements, avoids unnecessary complexity, includes appropriate tests, and does not introduce security or dependency risks.
• Use CI/CD quality gates. Pull requests should trigger automated unit tests, integration tests, build verification, linting, formatting checks, and other quality gates before code can be merged.
• Integrate code quality tools. Tools such as SonarQube should be incorporated into the CI/CD pipeline to detect code smells, bugs, duplicated code, maintainability issues, and security hotspots.
• Integrate security scanning tools. The pipeline should include Static Application Security Testing, Software Composition Analysis, secret scanning, and supply chain analysis. Tools such as SonarQube and Snyk can help detect vulnerabilities in first-party code, AI-generated code, open-source dependencies, and software supply chain components.
• Enforce remediation policies. Teams should define thresholds for blocking builds, such as failing the pipeline for critical or high-severity vulnerabilities, unacceptable test coverage, failed integration tests, or unresolved maintainability issues.
• Maintain traceability. Requirements, prompts, generated code, test cases, review comments, and pipeline results should be traceable so the team can explain why a change was made and how it was validated.

3. Training the Software Development Team

AI coding agents are most effective when developers know how to provide high-quality prompts, validate outputs, and use specification-driven workflows. Training should focus on making developers better engineers with AI, not merely faster code producers.

Training objectives should include understanding AI limitations, identifying hallucinations, interpreting security findings, and reinforcing core engineering skills such as design, testing, and secure coding.

3.1 Prompt Engineering

Create effective prompts using 4S basic principles of prompt engineering.

3.1.1 Decompose into small implementation tasks

To apply ‘Single’ principles, break down feature/requirement implementation into small tasks. This will help to create prompts focused on performing one clear task at a time.

So instead of asking AI coding agent with this prompt:

‘Build a Tic Tac Toe game web application.’

Break it down into smaller tasks and create prompt for each task. The previous prompt can be rewritten into several prompts as follows:

1. ‘Create a 3×3 grid of interactive buttons for the game board.’
2. ‘Implement turn-based gameplay alternating between X and O players.’
3. ‘Add win detection logic for horizontal, vertical, and diagonal alignments.’
4. ‘Add draw detection logic when all squares are filled with no winner.’
5. ‘Add start a new game after a game ended with either a win or a draw condition.’

3.1.2 Provide sufficient details

Building on the ‘Specific’ principle, create prompts with sufficient details. Include expected behaviour, acceptance criteria, constraints and edge cases.

From the previous prompts example for adding win detection logic, we can refine it as follows:

“

Provide win detection functionality to determine when a player has won the TicTacToe game by aligning three symbols horizontally, vertically, or diagonally.

– Implement horizontal win detection (checking all three rows)

– Implement vertical win detection (checking all three columns)

– Implement diagonal win detection (checking both main diagonals)

”

3.1.3 Provide sufficient context

Apply ‘Surround’ and ‘Short’ principles by providing the following information.

• Coding style and architecture in instruction file e.g. AGENTS.md.
• Add files related to the task into context to provide enough context for AI coding assistant.
• Provide the details required as comments in the file you are editing. This will enrich the context to help AI coding assistant producing accurate suggestions, and to keep prompts concise

3.2 Spec-Driven Development for Prompt Refinement

To further refine and enhance prompts, teams should adopt Spec-Driven Development (SDD) methodology. The team should define specifications as the primary source of truth. Use SDD tools and AI agents to generate implementation plans, code, tests, and documentation from those specifications.

• Use SDD tools for structured change definition. SDD tools such as OpenSpec and Spec Kit, can help teams capture proposals, specification changes, tasks, and implementation intent before code is generated.
• Review specifications before code generation. Developers should validate the specification before the AI agent generates code.
• Generate tests from specifications. Functional and non-functional requirements should be translated into unit tests, integration tests, and acceptance tests that become quality gates in the CI/CD pipeline.
• Keep specifications updated. When requirements change, the specification should be updated first. Code, tests, and documentation should then be regenerated or revised based on the updated specification. Specifications should be versioned and reviewed like code, with approvals, change history, and links to associated pull requests, to prevent specification drift and ensure that the “source of truth” remains reliable.

4. Practical Implementation Roadmap

A practical implementation roadmap helps organisations adopt AI coding agents incrementally while maintaining control over quality, security, and engineering discipline. The roadmap should start with governance and standards, then move into pilot adoption, automation, scaling, and continuous .

Phase 1: Establish Governance and Baseline Standards

• Define acceptable use of AI coding agents. Establish policies for when AI coding agents may be used, what types of code or data must not be shared, and how generated code must be reviewed.
• Publish engineering standards. Document coding conventions, architecture principles, SOLID design expectations, branching strategies, review rules, testing expectations, and security requirements.
• Create an AI-assisted development checklist. Include checks for developer understanding, prompt quality, requirement alignment, maintainability, security, test coverage, and dependency risk.
• Identify pilot teams and applications. Select teams with strong engineering discipline and applications with manageable risk, clear requirements, and existing automated tests.

Phase 2: Run Controlled Pilots

• Start with low-risk use cases. Use AI coding agents for unit test generation, documentation support, refactoring suggestions, boilerplate code, and well-bounded feature tasks.
• Require specification before generation. Ensure every AI-assisted task has documented functional requirements, non-functional requirements, acceptance criteria, and constraints before code is generated.
• Review all generated code. Require developers to explain the code, validate the design, and confirm that it follows project standards before submitting a pull request.
• Measure pilot outcomes. Track productivity, defect rates, review findings, security findings, test coverage, rework effort, and developer feedback.

Phase 3: Automate Quality and Security Gates

• Strengthen CI/CD pipelines. Ensure every pull request triggers build verification, linting, formatting checks, unit tests, integration tests, and automated quality checks.
• Integrate code quality analysis. Use tools such as SonarQube to detect maintainability issues, code smells, duplication, bugs, and security hotspots.
• Integrate security scanning. Add SAST, Software Composition Analysis, secret scanning, and supply chain analysis using tools such as SonarQube, Snyk, and other approved security platforms.
• Define blocking thresholds. Prevent merges when critical tests fail, high-severity vulnerabilities are detected, minimum coverage is not met, or code quality gates are not satisfied.

Phase 4: Scale Adoption Across Teams

• Expand approved use cases. Gradually allow AI coding agents to support more complex development tasks once governance, review practices, and automated controls are proven effective.
• Standardise reusable prompt patterns. Create prompt templates for feature implementation, test generation, refactoring, security review, performance review, and documentation.
• Adopt Spec-Driven Development practices. Use SDD framework to ensure that requirements, design intent, implementation plans, and tests are defined before code generation.
• Create communities of practice. Encourage teams to share effective prompts, lessons learned, review findings, security patterns, and examples of high-quality AI-assisted development.

Phase 5: Continuously Improve and Govern

• Review metrics regularly. Monitor defect trends, vulnerability trends, review cycle time, escaped defects, build failures, test coverage, maintainability scores, and developer productivity indicators.
• Update standards and checklists. Revise coding conventions, prompt templates, review checklists, and pipeline thresholds based on actual findings and lessons learned.
• Refresh team training. Provide periodic training on prompt quality, secure coding, SOLID principles, testing strategy, specification writing, and responsible AI usage.
• Audit AI-assisted changes. Periodically review selected AI-assisted pull requests to ensure that controls are being followed and that generated code remains explainable, maintainable, secure, and aligned with requirements.

The roadmap should be implemented as an iterative change program rather than a one-time tooling initiative. Successful adoption depends on aligning people, process, technology, and governance so that AI coding agents enhance engineering capability without weakening accountability.

5. Conclusion and Recommendations

AI coding agents can significantly improve software development productivity, but they do not eliminate the need for disciplined engineering practices. Their output must be treated as a starting point that requires human understanding, architectural alignment, code review, testing, and security validation. Without these controls, AI-assisted development can introduce inconsistent coding styles, weak design, maintainability issues, security vulnerabilities, and gaps against functional and non-functional requirements.

The recommended approach is to adopt AI coding agents as part of a governed software engineering ecosystem rather than as a standalone productivity tool. This ecosystem should combine clear requirements, coding standards, SOLID design guidance, code reviews, automated CI/CD quality gates, code quality analysis, security scanning, prompt training, and Spec-Driven Development practices. When these elements are in place, organisations can use AI coding agents to increase delivery speed while preserving quality, security, maintainability, and accountability.

Recommendations

• Adopt AI coding agents with governance from the beginning. Define acceptable use policies, data handling rules, review expectations, and risk boundaries before broad adoption.
• Make requirements the foundation of AI-assisted development. Ensure that functional requirements, non-functional requirements, acceptance criteria, constraints, and edge cases are clearly defined before code generation begins.
• Standardise engineering practices. Maintain and enforce coding conventions, architecture patterns, SOLID principles, testing expectations, and documentation standards so AI-generated code aligns with the existing codebase.
• Require developers to understand and own AI-generated code. Developers should be able to explain the purpose, design, behavior, limitations, and risks of any AI-generated code they submit.
• Strengthen code review practices. Use a review checklist that verifies requirement alignment, maintainability, security, test coverage, dependency risk, and compliance with standards.
• Automate quality and security gates. Integrate unit testing, integration testing, linting, code quality analysis, SAST, Software Composition Analysis, secret scanning, and supply chain analysis into the CI/CD pipeline.
• Train teams in effective prompting and specification practices. Provide practical training on the 4S prompting principles and Spec-Driven Development framework.
• Measure outcomes and improve continuously. Track productivity, defect rates, security findings, review findings, rework, test coverage, and maintainability metrics to refine practices over time.

In conclusion, AI coding agents should be viewed as engineering accelerators, not substitutes for engineering judgment. Their value is maximised when development teams combine AI capabilities with strong requirements discipline, secure coding practices, automated validation, and continuous learning. Organisations that implement these controls will be better positioned to gain productivity benefits while reducing the risk of poor-quality or insecure software entering production.

Author: Anang Prihatanto

6. References

[1] Exceeds AI, AI Coding Assistants: Security Risks and Code Quality 2026. blog.exceeds.ai.

[2] Second Talent, AI-Generated Code Quality Metrics and Statistics for 2026. secondtalent.com.

[3] Dasroot, CI/CD Pipelines for AI-Generated Code. dasroot.net, Apr. 2026.

[4] Fission-AI, OpenSpec: Spec-Driven Development for AI. github.com.

[5] Intent-Driven Development, Spec-Driven Development with OpenSpec and OpenCode. intent-driven.dev.

[6] Github, Spec Kit: Toolkit to help you get started with Spec-Driven Development. github.com

 

For decades, mining and resources companies have leaned on tools that break down under the complexity of budgeting, forecasting, and reporting. In this conversation, Ramesys Global’s John Goodman, Founder and Managing Director, and Sonya Preece, Technical Director, join Mitrais’s Jeff Graham to talk through how Ramesys built a platform trusted by names like BHP, Chevron, Western Power, and Anglo American, and why the company made the shift from a traditional architecture to a containerised, cloud-ready platform.

Sonya and John also give an honest account of what it took to modernise a system that was already serving clients, and how Mitrais supported the transformation through architectural analysis, proof-of-concept work, and hands-on development.

Watch to hear the full story, and what the partnership looked like from Ramesys’s side.

There is a version of a software career that looks like this: you learn to write code, you get good at writing code, and you spend the next years writing better and better code. It is a respectable path. But it is not the only one, and for some engineers, the most important shift in their career is not becoming more technically proficient, it is learning to step back from the code entirely and ask what the whole system is actually trying to do.

Yosua Patria Widyanto Simaremare, whose friendly nickname is Yossi, has been asking that question for over a decade. He joined Mitrais in 2013 as a Junior Developer, fresh from Institut Teknologi Sepuluh Nopember in Surabaya, and by his own account he arrived knowing how to build things without fully understanding why they were being built the way they were. “My curiosity shifted over the years,” he says. “From ‘How do I code?’ to ‘How does this whole system fit together?’ Growing from a junior developer into an Analyst within the same company has been an incredible ride.”

That shift, from executor to architect of understanding – is what defines the work he does today. As an Analyst, sits at the intersection of what a client wants and what a development team can realistically deliver. He maps system workflows, works through complex process logic, and translates business intent into something a dev team can act on without ambiguity. “Think of me as the translator,” he says, “who turns big business ideas into clean, actionable tech plans.” It sounds straightforward until you have done it badly – until you have handed a team a brief that was clear in your head and watched it produce something the client never imagined asking for. The gap between intent and execution is where most software problems actually live, and it is the gap Yossi has spent twelve years learning to close.

What surprised him most along the way was not a technical challenge. It was a human one. As his responsibilities grew and he began leading teams, he encountered a problem that no amount of programming knowledge had prepared him for: how to hold people to a standard without losing them in the process. “I had to figure out how to lead a team while being someone people actually like working with, but also respect,” he says. His answer was not a management framework or a leadership course. It was simpler and harder than that. “I try to be approachable, listen to everyone’s ideas, and keep things light. But when it comes to the quality of our work, I don’t cut corners. When people see that you’re in the trenches with them and that you genuinely care about their growth, that respect comes naturally.”

The other thing that changed him was unexpected: English training. Ask Yossi what Mitrais investment had the greatest impact on his professional growth, and he does not reach for technical certifications or project exposure, though both have been significant. He points to language. “The English training was a massive game changer,” he says. “It wasn’t just about learning vocabulary, it taught me how to communicate smoothly, write professionally, and speak with confidence when presenting to stakeholders.” For an analyst whose entire value rests on the clarity of his communication between client and team, between intent and specification, between what is wanted and what gets built, it turns out that learning to say things precisely was as important as learning to think them.

He still lives in Denpasar, the city where he grew up, and when the work is done he goes looking for the kind of quiet that resets everything: swimming, long walks in nature, music, and the uncomplicated company of his dogs. “Their energy is the ultimate reset button,” he says. Twelve years in, he carries that same instinct into the work itself, the recognition that the best thinking happens when you have space to step back from the detail and see what is actually in front of you. “I came here to write software,” he says. “I stayed to understand it.”