The arrival of AI in software development is not just about writing code faster. It transforms how developers explore a codebase, resolve tickets, document their changes, and validate what they ship.<\/p>\n\n\n\n
Its real value is therefore not measured solely in time saved. It is also measured by a team’s ability to frame, review, and validate what it produces with AI.<\/p>\n\n\n\n
This is where the topic becomes interesting: AI genuinely augments the developer, but it also amplifies the consequences of their working methods. When tickets are clear, objectives well-formulated, and validations well-organized, it becomes a powerful lever. When requests are vague or validation responsibilities are implicit, it can accelerate technical debt production with remarkable efficiency.<\/p>\n\n\n\n
The most immediate gain from AI in day-to-day work is not just speed. It is the expansion of scope.<\/p>\n\n\n\n
A concrete example: a ticket flags a display error in a backend-generated document. The cause is a date calculation logic that does not account for a specific business case: a status depends on two distinct events in time, but these events are incorrectly combined in the query. The project runs on a stack that the assigned developer, primarily frontend-oriented, does not fully master, even though they know the project and its business domain.<\/p>\n\n\n\n
Without AI, this ticket would probably have waited for the right expert. With AI, the developer can move forward: describe the business rule, share the relevant files, request an analysis of the existing logic, then precisely identify where the calculation breaks down. The diagnosis is reached quickly, the fix is targeted, the ticket is resolved.<\/p>\n\n\n\n
A second case, more radical: a frontend ticket on a project the developer has never touched, whose business domain and structure they do not know. A notification points to content deleted from the back office: the user lands on an error with no explanatory message. The fix involves three elements to coordinate: display a readable error message on the frontend, delete the orphaned notification from the database, and correctly decrement the counter displayed in the interface.<\/p>\n\n\n\n
These three points could easily have been handled separately, with the risk of missing one. AI made it possible to quickly identify the relevant code in an unknown codebase, propose a coherent implementation across both layers (frontend and API), and not overlook the counter detail. What could have taken a day of exploration was resolved in a few hours.<\/p>\n\n\n\n
These two cases illustrate a broader logic. Understanding a project’s structure, its implicit business rules, and its conventions usually requires several back-and-forths with the team. AI significantly reduces this onboarding time.<\/p>\n\n\n\n
The scope expansion goes beyond application development. With the right access and the right guardrails, it can also help query a database to verify suspicious behavior, inspect server logs to isolate an error, or automate repetitive tasks that would otherwise have taken disproportionate time.<\/p>\n\n\n\n
This matters. It means a team can handle a more varied backlog, assign tickets more flexibly, and reduce certain dependencies on individual expertise. On paper, this is both a productivity gain and an organizational gain.<\/p>\n\n\n\n
But this gain comes with a trade-off: the wider the scope of action, the more structured the validation must be.<\/p>\n\n\n\n
The Git history of a developer who integrates AI into their daily work changes in form.<\/p>\n\n\n\n
Commits tend to become broader. Where a developer would naturally break their work into several small successive changes, AI frequently addresses multiple aspects of a problem in a single response. A commit may then simultaneously touch several files, mixing a business logic correction, a data layer update, and a display adjustment.<\/p>\n\n\n\n
On documentation, the observation is almost the reverse. An experienced developer tends to be concise in commit messages. AI generally takes the time to detail the changes, their justification, and sometimes the associated points of attention.<\/p>\n\n\n\n
Git therefore reveals a new asymmetry: denser commits, but better documented<\/strong>.<\/p>\n\n\n\n This shift is not neutral. A better-documented commit is not necessarily a more manageable commit. When a single change touches business logic, persistence, and the interface, the review must adapt: logical decomposition, description of assumptions, identification of sensitive points, and validation by someone capable of evaluating the functional scope.<\/p>\n\n\n\n In other words, AI often improves the declarative readability of a change, but it does not guarantee its technical or business readability.<\/p>\n\n\n\n This raises a methodological question: should one accept larger commits because they are better documented? Not necessarily. The better practice is to avoid letting the commit structure passively reflect the AI’s output. The decomposition must remain human-driven: a functional intent, a coherent scope, a reviewable unit.<\/p>\n\n\n\n For a team, this can translate into a few simple rules:<\/p>\n\n\n\n Git does not lie. It records the pace, size, and declared intent of each change. With AI, it also becomes a governance indicator: it shows whether the team maintains control over what it ships, or whether it lets the tool structure the work in its place.<\/p>\n\n\n\n The scope expansion AI enables is real. But it introduces a new responsibility: knowing precisely what you are in a position to validate.<\/p>\n\n\n\n The first case worked well because the developer had sufficient business understanding to evaluate the proposed fix. They could read the diff, understand the date filtering logic, and confirm that the fix covered the problem in depth, not just the visible case.<\/p>\n\n\n\n It is this judgment capability, combined with AI, that produces a solid result.<\/p>\n\n\n\n The risk is not only that AI produces bad code. The risk is that it produces a technically plausible fix that seems correct in a quick review, but does not cover all business cases. In this scenario, no one sees the error immediately: the code compiles, tests may pass, the interface seems to work. Yet an important assumption may have remained implicit.<\/p>\n\n\n\n This is not a question of individual competence. It is a structural problem. The wider the scope of action, the more explicit the validation responsibilities must be.<\/p>\n\n\n\n The question is therefore not: “did AI do the work correctly?”<\/p>\n\n\n\n The right question is: “who is in a position to validate what it produced, and at which stage?”<\/p>\n\n\n\n Integrating AI into a team workflow means answering this question clearly. Several levels of validation must be distinguished:<\/p>\n\n\n\n This is where AI ceases to be solely an individual tool. It becomes an organizational topic.<\/p>\n\n\n\n AI does not fix a poorly written ticket. It executes it, and amplifies its imprecision.<\/p>\n\n\n\n The ticket mentioned earlier is a good example: it was precise. It provided concrete cases, identified the exact condition causing the problem, and explicitly distinguished the display error from the underlying calculation, which was correct. This precision enabled a rapid diagnosis and a targeted fix.<\/p>\n\n\n\n A ticket worded “the column is sometimes wrong, please fix” would have produced a far more speculative exploration, and probably a partial fix.<\/p>\n\n\n\n Feeding a ticket as-is to AI amounts to hoping it will interpret ambiguities correctly. It may. But it will not always. And when the developer does not sufficiently master the scope to evaluate the result, a misinterpretation can go unnoticed until production.<\/p>\n\n\n\n The practices that make a real difference are simple, but require active discipline.<\/p>\n\n\n\n If the ticket is vague, reformulate it until it is precise, not only for the AI, but for yourself. Understanding what you are asking before delegating it remains a quality condition.<\/p>\n\n\n\n For complex tasks, it is preferable to first describe the final objective, request a plan, evaluate its relevance, then iterate. Launching AI directly into code on an ambiguous ticket is like starting a sprint without framing the user story.<\/p>\n\n\n\n “We will first do X, then Y, with the final objective being Z.” This structure gives AI the context needed to arbitrate correctly, instead of treating each subtask as an isolated problem.<\/p>\n\n\n\n Some rules must be stated upfront: naming conventions, forbidden scope, compatibility to preserve, sensitive business rules, expected tests, dependencies not to introduce.<\/p>\n\n\n\n A good AI request is therefore not just an instruction. It is a mini development brief.<\/p>\n\n\n\n One simple practice consistently produces good results: once development is complete, submit the code to AI and ask whether it sees any inconsistencies, omissions, or potential risks.<\/p>\n\n\n\n Not to validate the business substance. Not to replace a human code review. But to detect what can slip through: an unhandled edge case, a poorly initialized variable, an overly restrictive condition, a naming inconsistency, a missing test, an implicit assumption to verify.<\/p>\n\n\n\n Regularly, this review surfaces a useful point. Sometimes minor, sometimes more significant. In all cases, it forces the developer to step back from what they are about to ship.<\/p>\n\n\n\n This practice works well provided it is framed. The goal is not to ask AI: “is this good?” The question is too vague. It must be directed:<\/p>\n\n\n\n AI then becomes a complementary reviewer. It does not decide whether the deliverable is acceptable. It helps better prepare that decision.<\/p>\n\n\n\n Another blind spot appears on features spanning multiple tickets: fragmentation.<\/p>\n\n\n\n AI does not naturally have reliable memory between sessions. Two tickets related to the same feature, handled a few days apart, can produce two independent implementations, slightly divergent in their conventions, data structures, or naming.<\/p>\n\n\n\n Individually, each piece may be correct. Collectively, the whole becomes incoherent.<\/p>\n\n\n\n This is not theoretical. It is precisely what happens when continuity is not enforced: endpoints that do not quite communicate, states managed in duplicate, small variations between tickets that seemed harmless and become problematic once the pieces are connected.<\/p>\n\n\n\n The fix is simple, but must be systematic: for each new ticket in the same feature, the context of what has already been produced must be explicitly re-provided, established conventions must be recalled, and consistency must be imposed as a constraint.<\/p>\n\n\n\n AI will not maintain this coherence on its own. It must be driven.<\/p>\n\n\n\n For long features, the best practice is to maintain a short shared context document:<\/p>\n\n\n\n This document can then be re-injected at each new AI session. It avoids starting from scratch, reduces divergence, and makes collaboration more reliable.<\/p>\n\n\n\n AI is not equally effective on all tickets.<\/p>\n\n\n\n On well-defined subjects (a display bug, a business rule to fix, an error handler to add) it quickly produces usable results. On tickets that combine several intertwined technical issues, the dynamic changes.<\/p>\n\n\n\n An offline mapping ticket is a good example: displaying points of interest via Leaflet and StadiaMaps, tile caching for offline operation, calculating the number of tiles to download to cover the relevant points, filtering points that are too remote to avoid overloading the cache.<\/p>\n\n\n\n Each issue taken in isolation is tractable. Combined, they form a system where each fix can destabilize another.<\/p>\n\n\n\n In other words, the problem is no longer just producing a piece of code. It is maintaining the coherence of a system composed of several interdependent constraints: performance, storage, user experience, offline operation, network consumption, and business relevance of the displayed data.<\/p>\n\n\n\n On this type of ticket, even with detailed and precise prompts, iterations multiply. AI proposes a solution that resolves one aspect and degrades another. Reformulation, re-contextualization, testing, and starting over are required.<\/p>\n\n\n\n The tool remains useful. It structures thinking, suggests leads, generates base code, helps explore alternatives. But it cannot replace the developer’s ability to hold the entire problem in mind and arbitrate between constraints.<\/p>\n\n\n\n This is a real and useful limit to know: the more cross-cutting and interdependent a ticket is, the more decisive human steering becomes.<\/p>\n\n\n\n The lessons from this hands-on account go beyond the individual developer.<\/p>\n\n\n\n The first effect is immediate: AI reduces certain day-to-day dependencies between developers. A question about a part of the code one doesn’t know, a bug in a stack one barely masters, a skill one doesn’t yet have: situations where it was necessary to wait for a colleague to be available. Today, one can often unblock independently, move forward, then involve the other person only when truly necessary.<\/p>\n\n\n\n This is not a replacement for collaboration. It is a reduction of the friction that sometimes made collaboration costly.<\/p>\n\n\n\n But for this gain to last, the team must adapt its practices.<\/p>\n\n\n\n For a product team or startup<\/strong>: AI allows each developer’s scope to be broadened, but also creates a risk of silent debt if review practices do not follow. The merge criterion can no longer be limited to “it passes CI.” It must also integrate input quality, assumption readability, and business scope validation.<\/p>\n\n\n\n For a CTO or IT director<\/strong>: traceability of AI usage becomes a governance issue. Who produced what, in what context, with what validation? Git keeps a partial trace, provided that commit, review, and documentation conventions genuinely allow changes to be understood.<\/p>\n\n\n\n For an agency or consulting firm<\/strong>: industrializing AI practices across multiple client projects requires shared rules on input quality, ticket decomposition, validation criteria, and review responsibilities. What works well for a single developer in a controlled context does not automatically generalize.<\/p>\n\n\n\n A simple grid can help translate these observations into operational practices:<\/p>\n\n\n\n The challenge is therefore not simply to authorize or prohibit AI usage. The challenge is to define the practices that allow benefiting from it without losing control over the quality of what is shipped.<\/p>\n\n\n\n AI does not automatically make a developer more competent. It amplifies their existing practices.<\/p>\n\n\n\n When tickets are clear, objectives well-formulated, changes reviewed, and validation responsibilities explicit, it enables saving time, exploring a codebase faster, and genuinely broadening the scope of teams.<\/p>\n\n\n\n Conversely, when used on vague requests, without proper framing or review, it accelerates technical debt production with remarkable efficiency.<\/p>\n\n\n\n The topic is therefore not only whether a team uses AI. The real topic is whether it knows how to organize quality around this new way of producing.<\/p>\n\n\n\n This is precisely where Castelis intervenes: helping technical teams integrate AI into their development practices without losing control over what they ship.<\/p>\n\n","protected":false},"excerpt":{"rendered":" AI widens developers’ scope of action, but the real risk is validating deliverables you can’t properly evaluate. A hands-on account of practices that make AI genuinely useful in a team.<\/p>\n","protected":false},"author":2,"featured_media":3019,"template":"","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[63,77],"tags":[85,92,88,93,89],"class_list":["post-3033","article","type-article","status-publish","has-post-thumbnail","hentry","category-dans-les-coulisses","category-ia","tag-agents-ia","tag-developpement-augmente","tag-gouvernance","tag-productivite","tag-rex"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article\/3033","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/users\/2"}],"version-history":[{"count":1,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article\/3033\/revisions"}],"predecessor-version":[{"id":3043,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article\/3033\/revisions\/3043"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/media\/3019"}],"wp:attachment":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/media?parent=3033"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/categories?post=3033"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/tags?post=3033"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
The Blind Spot: Knowing What You’re Validating<\/h2>\n\n\n\n
\n
Input Quality Drives Everything<\/h2>\n\n\n\n
Reformulate Before Submitting<\/h3>\n\n\n\n
State the Global Objective Before Starting Development<\/h3>\n\n\n\n
Decompose Complex Tickets<\/h3>\n\n\n\n
Make Non-Negotiable Constraints Explicit<\/h3>\n\n\n\n
AI as a Final Look Before Shipping<\/h2>\n\n\n\n
\n
The Fragmentation Risk on Long Features<\/h2>\n\n\n\n
\n
When Technical Complexity Takes Over<\/h2>\n\n\n\n
What This REX Changes for a Team<\/h2>\n\n\n\n
Situation<\/th> Best Practice<\/th><\/tr><\/thead> Vague ticket<\/td> Reformulate before submitting to AI<\/td><\/tr> Unknown codebase<\/td> First request an analysis and a plan<\/td><\/tr> Long feature<\/td> Re-inject the global context at each session<\/td><\/tr> Multi-layer commit<\/td> Document assumptions and validation points<\/td><\/tr> End of ticket<\/td> Use AI as a complementary reviewer, then validate humanly<\/td><\/tr> Sensitive business scope<\/td> Explicitly identify who can validate the result<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Conclusion<\/h2>\n\n\n\n