When we talk about artificial intelligence in software development, the conversation usually stays on productivity.

On writing code faster. On automating tasks. On “doing more with less”.

But that is only the surface.

Today we are facing a much deeper change:

The transition toward an AI-driven SDLC is not just a technological change… it is an operational and organizational change.

And understanding this is key to avoid falling into the most common mistake:

👉 adopting AI without a clear strategy for how to integrate and govern it.

🧠 AI-First is not just speed… it is responsibility

When we analyze models like AI-Native SDLC or the maturity models for AI adoption, something becomes evident:

AI without proper governance is not a competitive advantage… it is an accelerator of risks and technical debt.

And this completely changes the conversation.

We are not just talking about tools, we are talking about how we redesign the way we build software.

⚙️ The change is not technical… it is organizational

This is not a change exclusive to the development team, it is an organizational change because the impact is not in the SDLC phases, the phases still exist:

• Analysis.
• Design.
• Development.
• Testing.
• Deploy.

But what radically changes are the activities within each phase. We move from:

• Linear processes.
• Manual execution.
• Human-centered development.

To:

• Continuous iterations.
• Automated processes.
• Development driven by AI agents.
• Developer-led orchestration.

👨‍💻 The developer’s new role

The developer stops being primarily the one who writes code and becomes the one who:

• Validates AI-generated solutions.
• Analyzes architectural decisions.
• Orchestrates agents.
• Approves changes.

It is a much more strategic role.

And this is not the future…

👉 this is already happening.

⚙️ Operating Model: from writing code to orchestrating intelligence

This is where many conversations fall short. Because when AI in development is discussed, there are still those who see it as a “copilot that helps write code faster”. But that is already behind us.

The real change is not writing code faster… it is no longer being the one who writes code, to become the one who orchestrates the intelligence that generates it.

This is not a future projection. We are talking about a change that has already begun to impact the way we build software.

👨‍💻 The developer’s evolution: from executor to orchestrator

Today AI is not just another tool within the stack.

👉 It is an additional member of the development team.

But here there is a critical point we cannot ignore:

AI being part of the team does not mean it operates without control.

Quite the opposite. This raises the developer’s responsibility to another level:

• Defining how the AI interacts.
• Validating its results.
• Supervising its behavior.
• Ensuring it complies with standards.
• And, above all, governing it.

Because the success of AI in an organization does not depend on how good the tool is, it depends on how well it is orchestrated.

🧩 They are not new phases… they are new activities

We are not creating a new SDLC. The phases remain the same. But within them new activities appear that completely change the dynamics of the process:

• Prompt Engineering.
• Agent Orchestration.
• Human-in-the-loop.
• AI-driven QA.

🔄 An interconnected system (not a checklist)

Proper Prompt Engineering:

👉 Allows the AI to propose more accurate solutions.

👉 Improves the quality of generated code

But those results:

👉 must be constantly validated by the human factor (Human-in-the-loop)

That validation:

👉 is, in essence, AI governance

That governance:

👉 takes shape through agent orchestration (Agent Orchestration)

And all of this:

👉 is enhanced through automated quality processes (AI-driven QA)

⚖️ The critical piece is not one… it is the balance

There is no single most important piece. Because:

• Without a good Prompt → the AI loses precision.
• Without validation → risks increase.
• Without orchestration → there is no control.
• Without QA → there is no scalability.

It is not a chain… it is a gear mechanism.

🧠 Key insight

👉 It is not about using AI.

👉 It is about designing how AI works within the SDLC.

📈 Evolutionary Model: organizational maturity in the AI-First era

So far we have talked about how to operate with AI within the SDLC. But there is a much more important question:

👉 How prepared is the organization really to sustain that over time?

🚧 It is not a lack of intention… it is a lack of landing it

Today most organizations:

• Know they must adopt AI.
• Are experimenting.
• Are seeing results.

But they have not managed to land a clear model. They are evolving, but at a very accelerated speed.

⚠️ The silent risk: moving forward without governance

If we don’t make strategic decisions today, by the time we want to react… it will already be too late.

Many organizations are adopting AI without:

• A governance model.
• A sustainable strategy.
• A long-term vision.

And that turns AI into:

👉 An accelerator of technical debt.

👉 A multiplier of risks.

😏 The gap between perception and reality

Many organizations believe they are already leveraging AI. But the reality is different:

We have not yet seen the true potential of a fully mature and integrated AI.

🧠 The biggest challenge is not technical

Yes, there are technological challenges. But the real challenge is:

Organizational culture.

🧩 Culture, talent, and governance

• Culture → the hardest change.
• Talent → it is built along the way.
• Governance → the fundamental element.

🔥 Key insight

👉 The operating model defines how we use AI.

👉 The evolutionary model defines how prepared we are to sustain it.

🤖 Project Bob: from tool to cognitive companion in the SDLC

👉 Think of assistants like IBM Project Bob, conceived not as a tool, but as a development companion within the team.

Bob:

• Understands the system.
• Analyzes code.
• Proposes improvements.
• Automates processes.

👥 Hybrid teams

Humans + AI working as co-workers.

🔄 Developer’s evolution

• Orchestrator.
• Validator.
• Architect.
• Responsible for governance.

🔥 Conclusion

Adopting AI in the SDLC is not a matter of tools or productivity. It is a transformation that impacts how we design, develop, validate, and govern our systems. The real challenge is not in using AI, but in integrating it with intention:

• With a clear operating model
• And an organizational maturity that allows sustaining it over time.

Because without governance, speed becomes risk. And without strategy, innovation becomes technical debt. In the end, the difference will not be in who adopts AI first, but in who integrates it best.

It is not just about modernizing the code, but about modernizing the way we think and work.

In recent years, development assistants have evolved from simple autocompletion tools into systems capable of generating complete code from natural language instructions.

However, the real change is not solely about generating code faster.

The most profound change occurs when artificial intelligence ceases to limit itself to code and begins to interact with real tools, data, and systems within the enterprise environment.

That is where concepts like Model Context Protocol (MCP) and agentic development come in.

From copilots to agents

The evolution of AI in development has gone through several stages:

1. Autocompletion

Tools that suggested code fragments and completed lines.

2. Copilots

Tools capable of generating complete functions, explaining code, and proposing refactorings.

3. Development agents

Systems that can:

• analyze complete repositories
• execute tools
• interact with APIs
• query databases
• automate workflows

This is where Project Bob appears.

The problem of context

Language models can generate excellent code, but without access to the project’s real environment their capacity remains limited. For example, they normally cannot:

• Query real data.
• Interact with internal systems.
• Discover existing functionalities.
• Execute tools from the enterprise ecosystem.

This is where Model Context Protocol appears.

What is MCP?

The Model Context Protocol (MCP) is a standard that allows AI agents to interact with external tools. This enables access to capabilities such as:

• Enterprise APIs.
• Databases.
• Internal tools.
• Cloud services.
• Legacy systems.

MCP turns language models into consumers of tools within a digital ecosystem, which allows them to integrate into a digital ecosystem and access a wide variety of capabilities.

MCP architecture

A typical architecture includes three main components:

The agent

In this case Project Bob.

The MCP server

Exposes tools that the agent can use.

The tools

Represent concrete capabilities.

Example:

GET_CUSTOMER_PRICING  
GET_ORDER_HISTORY  
CALCULATE_DISCOUNT

Tools usually return information structured in JSON.

MCP and legacy systems

One of the most interesting aspects of MCP is the integration with existing systems. Many organizations possess critical logic in:

• RPG.
• COBOL.
• Java legacy.
• PL/SQL.
• C#.
• IBM i.

Rewriting these systems is costly. With MCP we can expose that logic as tools consumable by agents.

For example:

GET_CUSTOMER_PRICING

This allows reusing existing enterprise logic within AI‑First architectures.

Agentic architecture

When we combine agents with tools, an agentic architecture appears. Conceptually:

Developer
   │
   ▼
AI Agent (Project Bob)
   │
   ▼
MCP Layer
   │
   ├ API Tools
   ├ Database Tools
   ├ Legacy Tools
   ├ Cloud Services
   │
   ▼
Enterprise Systems

These systems can include:

• IBM i
• databases
• APIs
• cloud services
• internal platforms

What changes for developers

The developer’s role evolves. Before:

• Writing code.
• Creating services.
• Integrating APIs.

Now:

• Designing tools.
• Defining reusable capabilities.
• Governing interactions between agents.
• Building intelligent automation ecosystems.

AI‑First Development in action

Project Bob allows:

• Analyzing systems.
• Generating code.
• Applying engineering rules.
• Collaborating on technical design.

MCP allows:

• Connecting AI with real tools.
• Integrating enterprise systems.
• Creating agentic architectures.

The combination of both enables AI‑First Development in real enterprise environments.

Final reflection

The future of development will probably not be defined only by languages or frameworks. It will be defined by how developers, agents, and tools interact within the same ecosystem. Project Bob represents a clear signal of that direction. Not because it writes code automatically. But because it forces us to start thinking about software development in a different way.

It is not just about modernizing the code. It is about modernizing the way we think and work.

In the previous article I talked about a central idea: Project Bob should not be seen merely as a code generator, but as an agent capable of collaborating in the design, analysis, and implementation of software. That shift in perspective is fundamental. Understanding Bob as a development agent opens the door to new ways of working where artificial intelligence stops being just a productivity tool and starts becoming a technical collaborator within the development process.

In this second article of the series we will explore advanced techniques that allow you to truly get the most out of Project Bob.

1. The most common mistake: using Bob as a simple prompt box

One of the most frequent mistakes when starting to work with AI tools is treating them as a simple text box where you write isolated instructions. This approach works, but it only takes advantage of a small part of the potential of tools and uses we have available with Project Bob.

Bob can:

• Read files.
• Modify code.
• Execute commands.
• Interact with external tools.
• Analyze the full context of the project.

When we understand this, the interaction with the tool changes completely. Instead of asking for isolated code, we begin to ask the agent to:

• Analyze existing systems.
• Evaluate design decisions.
• Identify technical debt.
• Propose refactorings.
• Suggest architectural improvements.

2. Bob Rules: teaching Bob how your team works

One of the most powerful capabilities of Project Bob is the possibility of defining engineering rules. These rules allow you to establish standards that the agent must follow when working on a project. Instead of relying on repeated prompts, you can define guidelines such as:

• Naming conventions.
• Architecture standards.
• Security policies.
• Testing requirements.
• Documentation rules.

Example of a rules structure:

.bob/rules/
  01-general.md
  02-coding-style.md
  03-security.md
  04-testing.md
  05-architecture.md

These rules transform Bob from a generic tool into an agent aligned with the team’s engineering discipline.

3. Global instructions vs project instructions

Project Bob lets you manage two types of instructions:

Global instructions

They apply to all projects. Examples:

• Preference for clean code.
• Emphasis on security.
• Documentation style.
• Personal conventions.

Project instructions

They apply only to the current workspace. Examples:

• Specific technology stack.
• Allowed libraries.
• Mandatory architecture.
• Repository naming rules.

Separating these levels allows you to maintain a consistent base while respecting the particularities of each project.

4. Custom Modes: creating specialized agents

Bob lets you create custom modes, which in practice means creating specialized agents for specific tasks. Examples:

• Security Reviewer.
• DevOps Engineer.
• Documentation Writer.
• Performance Analyst.

Conceptual example of a custom mode:

customModes:
  - slug: security-review
    name: Security Reviewer
    roleDefinition: You are a security specialist reviewing code for vulnerabilities

This allows the agent to adopt different roles depending on the type of task being performed.

5. Enhance Prompt: improving the quality of requests

Many problems when working with AI do not come from the model’s capability, but from the quality of the prompt. Project Bob includes a function called Enhance Prompt, which allows you to transform a simple instruction into a more structured request. For example:

Simple prompt:

Analiza este programa RPG

Enriched prompt:

• Program structure.
• File usage.
• Business logic.
• Embedded SQL.
• Error handling.
• Standards compliance.

This kind of expansion significantly improves the quality of the analysis.

6. Context Mentions and Tagging

Another fundamental technique is the use of context mentions, which allow you to add real project context to the conversation. This is achieved using the @ symbol. Examples:

@/src/auth/login.ts
@problems
@terminal

This allows Bob to work with:

• Specific files.
• Project errors.
• Terminal output.
• Recent commits.

The result is a much more precise analysis.

7. Checkpoints: experimenting without risk

Checkpoints allow you to save the state of the workspace before making important changes. This enables an exploratory workflow:

1. Create checkpoint.
2. Experiment with changes.
3. Evaluate the result.
4. Restore if necessary.

This functionality is especially useful when performing:

• Large refactorings.
• Module reorganization.
• Architectural experiments.

8. Auto-Approve: productivity with responsibility

The Auto-Approve function allows Bob to perform actions without asking for confirmation every time. This can significantly accelerate the workflow. However, it must be used with care. Practical recommendation:

• low risk → auto approve
• medium risk → human review
• high risk → mandatory confirmation

9. Literate Coding: writing intent inside the code

Literate Coding allows you to write instructions in natural language directly inside the source file. Example:

    // create a function that calculates the order total
    // apply volume discounts

Bob analyzes the file context and generates the corresponding implementation. This reduces friction between intent and code.

10. Security Scans

Project Bob also includes integrated security functions:

• Vulnerability Scan.
• Secrets Scan.

These tools allow you to detect:

• Exposed credentials.
• API keys.
• Tokens.
• Common vulnerabilities.

This introduces a shift-left security approach within development.

11. MCP: the point where Bob becomes a platform

The Model Context Protocol (MCP) allows Bob to connect with external tools. This enables integrations with:

• APIs.
• Databases.
• Internal tools.
• Legacy systems.

For example, an existing RPG program could be exposed as an MCP tool and consumed by the agent. This opens the door to agentic architectures where AI interacts directly with enterprise systems.

Final reflection

When you observe all these capabilities together — rules, custom modes, enriched prompts, checkpoints, literate coding, integrated security, and MCP — it becomes clear that Project Bob is not simply a code assistant.

It is a technical collaboration platform powered by artificial intelligence. The difference is not only in generating code faster. The difference is in how we begin to integrate intelligent agents within the real software development process.

Next article

In the third article of this series we will explore: Project Bob, MCP, and the future of Agentic development. We will see how agents can interact with tools, enterprise systems, and complete platforms to transform the way we build software.

For years, programming assistants have evolved from simple autocomplete tools to sophisticated copilots capable of generating complete code. However, the real challenge of modern development has never been just writing code.

The real challenge is understanding complex systems, designing sustainable architectures, and maintaining software that evolves over years.

This is where a new paradigm begins to emerge: AI-First Development.

In this new approach, artificial intelligence is not limited to suggesting lines of code. Instead, it becomes an agent capable of understanding the system’s context, analyzing architectures, and proposing structural improvements.

One of the tools driving this transition is Project Bob, a development assistant designed to work directly within the development environment and collaborate with the programmer on tasks that go far beyond code generation.

The paradigm shift: from assistants to agents

Most current development assistants are based on a reactive model.

The typical flow is simple:

Developer → requests code\AI → generates a response

This model is useful, but limited. The AI responds to specific instructions without fully understanding the system it is working on.

Project Bob introduces a different approach.

Instead of behaving solely as a code generator, Bob acts as a development agent that can understand the project’s context, analyze existing code, and actively collaborate in the software-building process.

This completely changes the way we interact with AI within development.

Instead of asking for isolated code, we can ask the AI to analyze the system, identify problems, and propose architectural solutions.

Thinking of Bob as a software architect

One of the most common mistakes when using development assistants is treating them as simple code generators.

For example, many developers use prompts like:

Genera una función que valide un correo electrónico

This type of interaction is useful, but it does not really take advantage of the potential of an agent like Bob.

A more powerful interaction would be:

Analiza este módulo del sistema de autenticación identifica posibles problemas de diseño y propone mejoras en la arquitectura

In this scenario, Bob stops being a code generator and starts behaving as a virtual technical architect.

It can:

• Analyze existing modules.
• Explain design decisions.
• Identify technical debt.
• Suggest refactorings.
• Propose architectural improvements.

This change in the way of working is one of the pillars of AI-First development.

How Project Bob organizes its reasoning

One of Bob’s most interesting features is that it does not use a single mode of operation.

Instead, it uses specialized modes, each optimized for different types of tasks within the development cycle.

Among the main modes are:

• Plan mode, oriented toward planning and designing solutions.
• Code mode, focused on writing and modifying code.
• Ask mode, used for analyzing and understanding the system.
• Advanced mode, which allows access to extended tools and capabilities.

This approach allows the agent to adapt its reasoning according to the type of task being performed.

For example:

• When designing an architecture → Plan mode.
• When implementing code → Code mode.
• When analyzing the system → Ask mode.

This model resembles much more closely how human development teams work.

First you design, then you implement. For these, the best approach is to use specialized modes, each optimized for different types of tasks within the development cycle. In short, Project Bob is a software development model that uses specialized modes for different tasks within the development cycle.

The right mental model for working with development agents

To get the most out of tools like Project Bob, we need to slightly change the way we work. Instead of thinking of AI as a code-generation tool, we must start seeing it as a technical collaborator within the development process.

This means using AI for tasks such as:

• Analysis of existing systems.
• Design of new features.
• Code review.
• Identification of technical debt.
• Generation of technical documentation.

In this model, the developer stops interacting with AI solely at the code level and begins to interact with it at the architecture and design level.

AI-First Development

The concept of AI-First Development does not mean replacing developers with artificial intelligence. It means something much more interesting. It means designing development processes where artificial intelligence actively participates in understanding, building, and evolving software.

In this approach, the developer’s role also evolves. Developers go from being solely code builders to becoming system architects who collaborate with intelligent agents.

Final reflection

As artificial intelligence tools evolve, the way we use them must also evolve.

Project Bob represents an important step in this direction, by allowing developers to work with agents capable of understanding complex systems and collaborating in software design. But the real change is not in the tool. It is in the mindset.

It is not just about modernizing the code, but about modernizing the way we think and work.

In the next article

In the next article of this series we will explore practical techniques to get the most out of Project Bob, including:

• How to define development rules so Bob follows the team’s standards.
• How to create custom modes for specific tasks.
• How to improve the quality of interactions with more structured prompts.

All of this will allow us to transform Project Bob into something much more powerful than a code assistant.

In other words: a true AI-driven development architect.

AI does not eliminate technical debt. It only decides how quickly you make it visible… or how quickly you accumulate it.

Introduction – Beyond the enthusiasm for AI

When people talk about AI-First today, the focus is often placed on speed, productivity, and code generation. However, from a more technical and realistic perspective, the first thing that comes to my mind is not enthusiasm, but caution.

Artificial intelligence, as we use it today, is not infallible. There are well-known scenarios such as hallucinations or solutions that are effective but not necessarily efficient that, far from being minor details, can turn into real technical debt.

And here is a key point: AI no longer enters at the end of the process, it enters from moment zero. This means that these problems do not appear later, but can be born at the design stage, accelerating the accumulation of technical debt from very early phases of the software life cycle.

Paradoxically, that same early presence of AI can work in our favor. When it is used appropriately —improving the quality of requirements, refining user stories, and bringing greater clarity to analysis— AI can help us identify and reduce technical debt even before the system goes into production.

The real challenge is not in the technology itself, but in how we work with it and how we integrate it into our software development life cycle processes.

Does AI reduce or accelerate technical debt?

The short answer is: it depends on how it is used. That is, the presence of AI can be an ally or an enemy depending on how we use it. In some cases, AI can be a powerful ally in solving technical problems, while in others, it can be an accelerator of technical debt.

AI can be a powerful ally when it is used to analyze, question, and improve. But it can also become a debt accelerator when it is used solely to produce code faster, without solid technical judgment behind it. For example, if an AI is in charge of generating code but is not given solid technical judgment behind it, it can generate code that is hard to maintain and scale.

The problem is not that AI generates code, but that we often normalize as correct anything that simply works.

When AI is effective… but not efficient

One of the most complex things about working with artificial intelligence in software development is that many of its failures are not obvious at first glance. They are subtle details, but for someone with experience in enterprise systems and architecture, they are practically impossible to ignore.

One of the first signs usually appears in the architecture. Today AI is capable of proposing cloud designs that are technically correct, even aligned with modern best practices. The problem is that, in many cases, these proposals do not consider costs, resource consumption, or licensing.

The result can be a perfectly functional architecture, but one that is financially unsustainable in production. In cloud environments, especially with SaaS services, this type of decision translates into technical debt from the design stage, even if the system “works.”

Another clear sign appears in the code. I have seen how AI can generate implementations that meet the objective but incorporate bad practices: hardcoded values, forbidden characters, incorrect patterns, or solutions that violate internal standards. Here, human review remains key.

Perhaps one of the most worrying scenarios is when some AI assistants force the code to satisfy a test case or an acceptance criterion, distorting the logic to always guarantee a successful result.

When AI stops being an ally and becomes a debt accelerator

The line that separates artificial intelligence as an ally or as an enemy of technical debt does not run through the model or the tool. It all comes down to governance and the responsible use of AI.

When teams allow AI to operate without control, without clear rules, and without human supervision, it stops being a support and quickly becomes a technical-debt accelerator.

One of the most common risks is excessive dependence. Teams that stop questioning the results and simply accept what the AI proposes, implicitly transferring technical responsibility to the tool.

Responsible AI-First: reduce debt, don’t hide it

An AI-First approach that genuinely aims to reduce technical debt must be grounded in the principles of Responsible AI.

Transparency is key: developers must understand why the AI proposes certain code or a particular architecture.
Governance defines clear limits, constant human reviews, and sustainability over time.

AI-First does not mean delegating technical thinking, but elevating it.

Conclusion

Technical debt does not disappear with artificial intelligence; an inadequate implementation of AI can accelerate the generation of technical debt. An AI-First approach that genuinely aims to reduce technical debt must be grounded in the principles of Responsible AI. Transparency and governance are key for AI to propose appropriate solutions.

AI can help make it visible earlier… or it can accelerate its accumulation if it is not governed properly.

Because in the end:

It’s not just about modernizing the code, but about modernizing the way we think and work.

In the previous parts of this series, we explored how integrating artificial intelligence (AI) into the software development life cycle (SDLC) is transforming the way developers build, test, and maintain applications. In this third part, we will dive deeper into the Deploy, DevOps, and Operations phases, and we will also review critical topics such as governance, security, and ethics in the use of AI in software development.

SDLC – Deploy, DevOps, and Operations

When AI accompanies software all the way to production

If there is a stage where the AI-First approach fits naturally, it is in Deploy, DevOps, and Operations. Here, artificial intelligence not only accelerates processes, but also reduces friction, human errors, and rework, directly impacting the stability of the product.

From my experience, integrating AI in this phase is practically perfect. In particular, support for Infrastructure as Code (IaC) makes a clear difference. With tools like Project Bob, generating CI/CD pipelines becomes a surprisingly simple and structured process.

Bob does not limit itself to creating a basic pipeline. Its command of technologies such as Terraform allows it to:

• Generate complete IaC
• Define variables per environment
• Establish validation plans
• Automate build and teardown processes
• Integrate tests within the deployment flow

All of this is built coherently, considering the full life cycle of the infrastructure, not just the moment of deployment.

Pipelines that are analyzed, not just executed

Another key point is AI’s ability to review and analyze existing pipelines. In several scenarios, I have used AI agents to inspect CI/CD flows, identify recurring failures, and propose optimizations.
The result is not just a pipeline that works, but a pipeline that is more stable, predictable, and efficient.

This kind of continuous analysis allows problems to be corrected before they turn into production incidents.

AI in operations: observability with context

In the operations phase, the role of AI becomes even more relevant. AI agents can automate monitoring and observability processes, detecting anomalous behaviors in systems and classifying them intelligently.

Beyond generating alerts, AI provides context: it identifies patterns, groups related events, and proposes response plans. This significantly accelerates incident response and reduces the operational noise that usually affects teams.

Deciding is still human

Even with all these advances, there is one principle that remains intact: the final responsibility is always human.

AI can take part in processes such as rollbacks, incident mitigation, or operational adjustments, but the decision must always rest with the people responsible for the system. The inputs, analyses, and summaries that AI generates are valuable and enrich decision-making, but they do not replace human judgment.

The AI-First approach in DevOps does not seek to automate responsibility, but to enhance decision-making capacity, relying on more complete and better-processed information.

AI-First use in IaC and operations without “breaking production”

Applying an AI-First approach in Infrastructure as Code (IaC) and in the operation of production systems requires a key principle: automate without losing control. AI can greatly accelerate and optimize these processes, but only if it is implemented with clear limits, strict validations, and explicit human responsibility.

The following practices make it possible to leverage AI in critical environments without compromising stability, security, or operational continuity.

• Ephemeral environments to validate IaC (automated plan/apply/destroy) Before touching production, every infrastructure definition must be validated in ephemeral environments, created and destroyed automatically. AI can help by generating and reviewing:
  • Execution plans (terraform plan).
  • Validations of dependencies and deployment order.
  • Full creation and teardown tests of the environment.

  This approach makes it possible to detect configuration errors, implicit dependencies, or unexpected costs before they impact production environments, drastically reducing operational risk.

• Policy-as-code (guardrails) to avoid insecure resources In an AI-First model, AI should not have absolute freedom to define infrastructure. The use of policy-as-code establishes clear guardrails that both AI and teams must respect, such as:
  • Public network restrictions.
  • Mandatory encryption.
  • Limits on size, regions, or resource types.
  • Regulatory and security compliance.

  These policies act as a technical contract that protects the organization even when IaC generation is highly automated.

• Assisted postmortems: AI summarizes the timeline, hypotheses, and actions In operations, AI can play a key role after an incident. Instead of relying solely on manual reconstructions, AI can:
  • Analyze logs, metrics, and events.
  • Reconstruct a timeline of the incident.
  • Propose technical hypotheses based on patterns.
  • Suggest corrective and preventive actions.

  The postmortem stops being a reactive document and becomes a continuous learning tool, always validated and enriched by the human team.

• Runbooks generated and maintained by AI, validated by humans Runbooks tend to become obsolete quickly. In an AI-First approach, AI can:
  • Generate initial runbooks from architecture, code, and operational events.
  • Update them as systems change.
  • Suggest mitigation steps for common incidents.

  However, the final validation must always be human. Runbooks thus become living, reliable artifacts aligned with the operational reality of the system.

Automation with judgment: the key to AI-First in operations

The true value of the AI-First approach in IaC and operations is not in automating everything, but in automating with judgment. AI accelerates validations, analysis, and documentation; the human team defines limits, validates decisions, and assumes final responsibility. Used correctly, AI does not “break production”. It protects it, makes it more observable, and makes it more resilient.

SDLC – Governance, Security, and Responsible Use of AI

Productivity without control is not progress

As artificial intelligence becomes integrated across the SDLC, the conversation stops being purely technical and becomes strategic and organizational. Adopting AI without a clear governance framework is not only risky, but counterproductive.

From my experience, the main risk of an uncontrolled adoption of AI is the progressive deterioration of software quality. AI can generate effective solutions in the short term, but not necessarily efficient ones in the long term. This imbalance directly impacts maintainability, system growth, and, in more critical scenarios, the security of production platforms.

An architecture or code that “works” today, but is not designed to scale, be maintained, or be audited, quickly becomes a technological liability.

Fundamental principles: Transparency and Ethics

If I had to prioritize principles for a responsible adoption of AI, I would start with two: transparency and ethics.

Transparency means that AI is able to explain how it arrived at a conclusion or result. It is not just about getting an answer, but about understanding the reasoning behind it. This capability is key to validating decisions, auditing processes, and building technical trust.

Ethics, for its part, is not an abstract concept. It is directly related to how and for what purpose we use AI. An ethical use implies responsibility, traceability, and respect for the limits of the system and of the people who operate it.

Curiously, when these two principles are well established, the rest —security, compliance, quality— tends to align naturally.

Productivity, security, and compliance: a necessary balance

There is a false perception that productivity is affected when security and compliance controls are introduced. From my experience, exactly the opposite happens.

When an organization defines clear working frameworks, solid procedures, and well-established rules for the consumption of AI, productivity is not slowed down: it becomes orderly and is enhanced. AI stops being a one-off tool and becomes a strategic organizational ally, capable of driving growth in a sustained and controlled way.

The real challenge is not choosing between productivity or security, but designing processes where both evolve together.

Distrust as a starting point, not as a barrier

Distrust toward AI is natural, especially in business environments and critical systems. However, that distrust should not lead to rejection, but to the documentation, analysis, and definition of responsible usage frameworks.

To some degree, distrust is even healthy. It forces us to question, validate, and build more secure and stable environments. When well managed, it becomes the engine that drives a conscious, informed, and professional adoption of artificial intelligence.

Minimum AI-First governance framework for the SDLC

Adopting AI within the SDLC without a clear governance framework is not innovation, it is risk. A sustainable AI-First approach requires explicit rules, well-defined responsibilities, and auditable processes that make it possible to leverage AI without compromising quality, security, or organizational control. This minimum framework does not seek to bureaucratize the use of AI, but to organize it and make it reliable.

• Clear RACI: who approves requirements, architecture, merges, deployments. In an AI-First environment, decisions are accelerated, but responsibility is not diluted. It is essential to explicitly define:
  • Who approves final requirements.
  • Who validates and decides architecture.
  • Who authorizes merges to main branches.
  • Who enables deployments to production.

  AI can propose, analyze, and assist, but the RACI guarantees that there is always a clearly identified human responsible. Without this, governance breaks down from day one.

• Data and context: what AI can see (code, tickets, never secrets). Not all information should be available to AI. A serious AI-First framework defines clear limits of visibility. It is valid for AI to have access to:
  • Source code.
  • User stories and tickets.
  • Technical documentation.

  But there must be a strict policy that prevents access to:

  • Secrets, credentials, and keys.
  • Sensitive customer information.
  • Regulated or confidential data.

  Governance begins by controlling the context that AI consumes.

• Traceability: versioned prompts, decisions, and outputs (auditing). In an AI-First environment, prompts and outputs become technical artifacts. For this reason, it is indispensable to:
  • Version relevant prompts.
  • Document AI-assisted decisions.
  • Maintain traceability between requirements, code, and generated results.

  This traceability not only facilitates audits, but also makes it possible to understand why a decision was made, something critical in regulated environments and long-lived systems.

• Quality: mandatory gates (tests, security, performance). The speed that AI provides must always be contained by clear and non-negotiable quality gates. This includes:
  • Mandatory automated tests.
  • Security analysis (SAST, dependencies).
  • Performance validations.
  • Compliance with coding and architecture standards.

  AI can help execute and analyze these controls, but it cannot skip them.

• Training: the team learns to ask, validate, and justify. AI-First is not just technology, it is a human skill. Teams must be trained to:
  • Formulate good prompts.
  • Question AI’s answers.
  • Validate results with technical judgment.
  • Justify decisions made with AI support.

  A team that does not know how to ask or validate turns AI into a risk. A trained team turns it into a competitive advantage.

Conclusions

AI-First does not change the SDLC, it changes the way we work

Adopting an AI-First approach completely transforms the role of the developer. We are no longer the only brain within the software development process. Today we share the space with a second brain, artificial, capable of taking on manual, repetitive, and operational tasks.

This change does not displace us; it elevates us. By delegating those kinds of activities, the developer’s role evolves toward one that is more analytical, strategic, and conscious, focused on making better-argued decisions with greater impact on the final product.

In this new context, we stop being mere code typists and become systems analysts. Our value is not in writing lines of code, but in understanding processes, interpreting contexts, and validating decisions. We have a fundamental role: ensuring that artificial intelligence operates within a secure, stable, and reliable framework, one that makes it possible to build robust, sustainable systems aligned with business needs.

More than a new stage within the SDLC, we are facing a profound reform of the way we work. The phases of the software development life cycle will continue to exist, but the way we execute them is restructured and enhanced. AI does not replace these stages; it amplifies them, accelerates them, and forces them to mature.

The AI-First approach is not about adopting tools because they are trendy, nor about delegating critical thinking. It is about rethinking how we design, develop, test, deploy, and operate software, responsibly integrating an artificial intelligence that complements our human capabilities.

And as always, I close with the phrase that summarizes my vision of this change:

“It is not just about modernizing the code, but about modernizing the way we think and work.”

Continuing our exploration of the AI-First approach in the software development life cycle (SDLC), in this second part we dive into the critical phases of Development and Testing. These stages are fundamental, since they are where ideas materialize and the quality of the final product is ensured. Integrating artificial intelligence (AI) tools into these phases not only optimizes processes, but also redefines the way developers work and collaborate.

SDLC – Development / Coding

Programming with AI is not about writing faster, it’s about understanding better

The impact of the AI-First approach in the development stage has been, from my experience, profound and transformative. It is not just about speed, but about how it changes the way we understand the problem before writing a single line of code.

When we work with well-structured user stories —like the ones Project Bob generates and standardizes— the pre-development analysis becomes much more agile. Understanding the scope, the acceptance criteria, and the business rules stops being a fuzzy process and becomes a clear starting point shared by the whole team.

In many projects, we developers end up “specializing” in very specific business particularities. Sometimes, it is even assumed that we must fully master the technical or operational language of the functional area. With the help of AI agents, this process is greatly facilitated: the assistants not only explain the context, but translate business language into technical logic, and even propose base code for complex algorithms.
This frees up valuable time, which can be invested in higher-level analysis and in decisions that truly add value.

From writing code to solving problems with context

The differences between using traditional assistants and AI-First agents are notable.

With Project Bob, we are not talking about a simple coding assistant, but about an artificial brain integrated into the team. Bob does not merely execute instructions; it analyzes requirements, proposes solutions, contextualizes the problem, and accompanies the development process from start to finish.

For its part, GitHub Copilot Agents brings a different but complementary dynamic: the ability to delegate development tasks. You can assign an activity, let the agent work in the background, and then come back to review and validate the changes. This asynchrony completely changes time management for the developer and the technical lead.

Both approaches elevate the developer’s role: we stop focusing solely on writing code and move on to orchestrating solutions.

AI applied to the entire code cycle

In practice, I have used AI in practically all the key development activities:

• Initial code generation
• Refactoring
• Explanation of legacy code
• Modernization of applications in IBM i, .NET, and Java

These processes become significantly more agile, but there is a critical point that marks the difference between success and failure: the quality of the prompt.
Defining clear, detailed prompts with good context is fundamental. AI is only as good as the information it receives; without context, the results lose value.

Speed or quality? The false dichotomy

The question is often raised: does AI increase the speed or the quality of development?
From my experience, this is a false dichotomy.

Both concepts are deeply related. Higher-quality code reduces technical debt, decreases attention to incidents, vulnerabilities, and rework, and that, inevitably, translates into less time consumption in the long run. Speed is not just about writing fast, it’s about delivering sustained value over time.

With AI, I have observed increases on both fronts: we produce more in less time, but —more importantly— we produce better code. AI reinforces compliance with standards, organizational guidelines, best practices, documentation, and tests (unit, integration, and coverage). All of this considerably raises the quality of the final product.

The non-negotiable principle: human validation

However, there is a principle that must not be broken: every AI proposal must go through human review.

Reviews, approvals, and conscious analysis remain indispensable. Not only to validate that the code works, but to understand it, maintain it, and be able to evolve it in the future. AI accelerates development, but the final responsibility still belongs to the human team.

The true value of the AI-First approach in development is not in delegating thinking, but in expanding it, always with judgment, context, and responsibility.

Concrete practices to avoid technical debt with AI

Using artificial intelligence in software development can accelerate value delivery, but without technical discipline it can become a massive generator of technical debt. In an AI-First approach, technical debt does not disappear: it is amplified if there is no control.

The following practices help leverage AI without compromising the maintainability, quality, and evolution of the software.

• Mandatory Pull Requests with a checklist (security, performance, tests, standards) All AI-generated or AI-assisted code must go through a formal Pull Request process. This is not optional in an AI-First environment. The checklist must include, at a minimum:
  • Security validation (injections, secrets, vulnerable dependencies).
  • Performance considerations (algorithmic complexity, resource usage, latency).
  • Evidence of tests (unit, integration, coverage).
  • Compliance with coding and architecture standards.

  AI can generate code quickly, but the PR ensures that the team consciously understands, validates, and accepts that code.

• Prompt review: document “good” prompts by task type In an AI-First environment, prompts become reusable technical assets. Documenting effective prompts for tasks such as refactoring, test generation, legacy analysis, or technical documentation allows you to:
  • Reduce variability in results.
  • Ensure consistency across teams.
  • Create an organizational “prompting library”.

  Prompting stops being individual improvisation and becomes part of the engineering process.

• Style rules and linters: have AI produce within your standards AI must adapt to the team, not the other way around. Integrating linters, formatters, and style rules into the pipeline ensures that the generated code:
  • Respects naming conventions.
  • Follows defined architectural patterns.
  • Complies with internal security and quality guides.

  In an AI-First model, linters act as automatic guardrails for AI and developers.

• Tests first: ask AI for tests before or alongside the code A powerful practice is to require AI to generate the test cases first or to deliver them together with the implementation. This:
  • Forces you to define the expected behavior before coding.
  • Reduces regressions.
  • Turns AI into a generator of executable specifications.

  In an AI-First approach, tests are not an afterthought, but a primary development artifact.

• Explainability: require “explain why you did it this way” as part of the PR AI must justify its technical decisions. Explicitly asking for an explanation of the design, algorithms, and trade-offs allows you to:
  • Detect conceptual errors early.
  • Transfer knowledge to the team.
  • Avoid “magic” code that nobody understands.

  In an enterprise environment, unexplained code is future technical debt.

  AI-First does not eliminate technical debt, it changes how we manage it

  Technical debt will always exist, but in an AI-First context its origin changes. It no longer comes only from rushed human decisions, but also from unsupervised automation. These practices turn AI into a controlled accelerator, not a factory of accidental complexity. The goal is not to slow down productivity, but to ensure that speed does not compromise the future of the system.

SDLC – Testing and Quality

When AI stops “testing” and starts elevating the culture of quality

For a long time, testing has been seen as a necessary stage, but frequently postponed or minimized within the SDLC. With the adoption of an AI-First approach, this perception changes significantly.

From my experience, the current maturity of AI in the testing field is satisfactory and functional. We are not talking only about test generation, but about much more complete support throughout the process. In the case of Project Bob, the support ranges from the initial configuration of the test environments and the creation of scenarios, to their automatic execution and validation.

One of the most valuable points is Bob’s ability to validate code against the defined test cases, run the scenarios, and analyze the results, generating complete and detailed reports of the execution. This considerably reduces manual effort and, at the same time, increases the reliability of the process.

Coverage, business rules, and forgotten scenarios

In practice, AI adds value on all the key fronts of testing:

• Test case generation
• Detection of uncovered scenarios
• Business rule validation

In each of these stages, Project Bob has proven to be a solid and consistent tool. By analyzing the code and the system context, it is able to identify logical paths that would normally go unnoticed during a manual review, thus raising coverage and reducing risks.

Quality as a habit, not an exception

One of the most interesting impacts of the AI-First approach is the cultural change it promotes within teams.

Project Bob, for example, automatically includes the generation of unit tests as a natural part of development. In addition, when a commit is made, Bob can review the introduced changes, run the associated test cases, and validate the results. This constant feedback turns quality into a continuous habit, not a reactive activity at the end of the cycle.

This kind of dynamic encourages teams to adopt quality practices organically, without needing to impose them as an additional burden.

The new human role in testing

Even so, human judgment remains indispensable.

The role of the developer —and of the quality engineer— evolves. We go from being manual test executors to analysts and interpreters of results. The value is no longer in running a script, but in understanding the execution reports, interpreting the findings, and making informed decisions about the quality of the product.

AI can execute, measure, and report; the human being validates, contextualizes, and decides.
That balance is what truly allows quality to scale without losing control.

How to integrate AI into the “Quality Gate”

Integrating artificial intelligence into the Quality Gate does not mean relaxing quality controls; it means making them smarter, faster, and more consistent. In an AI-First approach, AI acts as an automatic quality analyst, while the validation and final decision remain human.

These practices allow you to incorporate AI into the quality process without compromising standards or governance.

• Define a minimum threshold (coverage, linters, SAST, tests) Every Quality Gate must begin with clear, non-negotiable limits. Before introducing AI, the team must explicitly define:
  • Minimum test coverage percentage.
  • Mandatory linter and formatter rules.
  • Static security scans (SAST) and dependency analysis.
  • Successful execution of unit and integration tests.

  AI does not decide whether the threshold is acceptable; it only verifies and reports. These limits act as guardrails that protect product quality against excessive automation.

• Require an automatic report that AI interprets and summarizes Beyond generating technical results, AI must be able to interpret and synthesize them. Instead of delivering only extensive logs or isolated metrics, AI can:
  • Summarize the general state of the Quality Gate.
  • Identify critical failures versus warnings.
  • Prioritize risks according to technical and functional impact.
  • Point out recurring quality trends.

  This summary allows developers, QA, and technical leads to make quick decisions with context, without manually reviewing large volumes of information.

• Review edge cases: AI proposes, QA/Dev validates One of AI’s greatest contributions is its ability to identify edge cases that are not always obvious during test design. AI can propose extreme cases, unusual combinations, or infrequent flows, but the final validation must rest with QA and development. This model reinforces quality without replacing human judgment, combining automatic exploration capability with domain experience.
• Ensure no regression: regression tests per PR In an AI-First environment, every Pull Request must trigger automatic regression tests. AI can:
  • Detect which areas of the code are affected by a change.
  • Select or generate relevant regression tests.
  • Verify that existing functionality does not break.

  This approach reduces the risk of silent regressions and turns the Quality Gate into a continuous protection mechanism, not just a one-time control.

Summary and upcoming blogs

In this second part of our series on AI-First in the SDLC, we have explored how artificial intelligence is transforming the Development and Testing phases. From code generation to automatic quality validation, AI not only accelerates processes, but also raises standards and changes the development culture. The human role evolves toward supervision, analysis, and informed decision-making, always maintaining control over the quality and responsibility of the final product. In the next blog, we will dive into the Deployment and Maintenance phases, where we will see how AI continues to revolutionize the software life cycle, ensuring safer deployments and proactive management of system performance and stability. Don’t miss it!

We have seen how AI is transforming the Development and Testing phases within the SDLC, not as an isolated tool, but as a strategic partner that enhances human capability. The key to success lies in combining the speed and efficiency of AI with the judgment and responsibility of the human team, thus ensuring that software quality and sustainability are not compromised. In the end:

It’s not just about modernizing the code, but about modernizing the way we think and work.

Introduction

AI-First in the SDLC: beyond the hype, toward a conscious adoption

One of the main mistakes I have observed in organizations when trying to incorporate artificial intelligence into software development is not technological, but strategic. The problem is not in the tool, but in the approach with which it is adopted.

When an organization is not clear about how it measures its productivity, it will hardly be able to identify in which stages of the development life cycle AI can add real value. This gap usually leads to complex scenarios: silos between teams, diffuse governance, technological over-dependence, and, in the worst cases, systems that are difficult to maintain due to an uncontrolled use of AI, without a clear vision of its true capabilities and limits.

It is precisely for this reason that I speak of AI-First and not simply of “use of AI”. The AI-First approach is not about writing code faster or generating more lines of code. From my experience, artificial intelligence can —and should— be integrated into each of the stages of the SDLC, from the gathering and analysis of requirements, through design, development, and testing, all the way to observability and operation in production environments.

The real turning point for me came with the appearance of Agent modes. It was at that moment that AI stopped feeling like a reactive tool and began behaving like a cognitive assistant: a second artificial brain that accompanies human thinking throughout the entire development process.

I clearly remember a recent experience, about four months ago, during the definition of requirements for a project on cybersecurity and data governance in production systems. In that context, the interaction with AI agents made it possible to significantly reduce analysis times, establish much more solid acceptance criteria, identify early development risks, and detect opportunities for improvement at the architectural level. The result was not only operational efficiency, but a more robust final requirement and, above all, a product with greater value for the end user.

Within this context, I have decided to focus this analysis on two assistants that clearly represent this evolution: Project Bob and GitHub Copilot Agents.

In particular, Project Bob embodies the AI-First approach very clearly. I have had the opportunity to work directly with it and experience how it is capable of taking a high-level requirement, breaking it down into concrete tasks, generating an execution plan, and accompanying each activity until its complete resolution. It is not just about generating code, but about understanding the problem, planning the work, and executing with context.

For its part, GitHub Copilot Agents allowed me to delegate development tasks asynchronously: make a request, let the agent work in the background, apply the necessary changes, and then enter a review and validation phase myself. This dynamic transformed the way I work, optimizing times and allowing me to focus my attention on higher-value decisions while development continued without interruptions.

This blog is born precisely from that experience: not from theory, but from practice. From the real experience of how an AI-First approach, correctly applied, can redefine the way we conceive the software development life cycle.

What “AI-First” means in operational terms

AI-First is not simply “putting AI” into an isolated point of the process nor adding one more tool to the stack. AI-First means designing the complete workflow assuming that there is a second intelligence, artificial, that actively collaborates with human thinking throughout the entire SDLC.

This approach starts from a key premise: AI is not a replacement for the engineer, but an amplifier of reasoning, capable of absorbing operational load, reducing cognitive friction, and accelerating the generation of artifacts, allowing the human team to focus on analysis, validation, and decision-making.

From an operational perspective, this second intelligence is capable of:

• Summarizing and structuring information coming from multiple sources such as requirements, technical meetings, architectural decisions, and functional discussions. This reduces the loss of context and prevents critical knowledge from being scattered or depending exclusively on people’s memory.
• Identifying inconsistencies in early stages of the process: contradictions between requirements, unstated assumptions, ambiguities in language, or decisions that are not aligned with the technical or business context.
• Generating artifacts with speed and coherence, such as acceptance criteria, technical documentation, test cases, CI/CD pipelines, and infrastructure as code. Speed here is not the final objective, but a means to free up time and cognitive focus.
• Supporting decision-making by proposing alternatives, pointing out technical, operational, or maintainability risks, and exposing potential impacts, without replacing the person ultimately responsible for the decision.

AI-First does not eliminate human responsibility; it makes it more explicit.

AI-First demands clear definitions from the team and the organization

For this approach to work in a healthy and sustainable way, adopting tools is not enough. It is necessary for the team —and the organization— to explicitly define certain operational principles.

In practice, this requires clearly agreeing on:

• Which metrics really matter. Not only speed metrics, but indicators that reflect quality and sustainability, such as lead time, cycle time, defect rate, MTTR, test coverage, and level of technical debt. AI must align with these metrics, not distort them.
• Which decisions are human by design. Architecture, prioritization, final acceptance criteria, change approval, and releases must remain under human control. AI can propose, analyze, and question, but not decide.
• Which outputs must be auditable and traceable. Documentation, technical decisions, acceptance criteria, relevant changes, and justifications must be reviewable, versionable, and explainable. Traceability is key for governance, quality, and trust.

AI-First as a cultural change, not just a technical one

Adopting AI-First also implies a profound cultural change. The developer stops being a reactive executor and becomes an orchestrator of the process, responsible for validating, interpreting, and deciding on the results generated by AI. In this model, value is not in who writes the most code, but in who formulates better questions, detects risks earlier, and makes more conscious decisions. AI-First, in operational terms, is not automation without control. It is structured collaboration between human and artificial intelligence, with clear rules, explicit responsibilities, and a common goal: building software that is more robust, sustainable, and aligned with the business.

To better understand how AI-First can be integrated into each stage of the SDLC, in the following sections I will analyze in more detail its practical application in the phases of: Requirements, Design, Development, Testing, and Observability/Operation.

SDLC – Planning and Requirements

Where a project really starts (or breaks)

From my experience, many of the problems that appear during software development are not born in the code, but much earlier: in a deficient definition of requirements. It is at this stage where the foundations are laid for everything that comes next, and where errors can have a disproportionate impact in terms of time, cost, and quality of the final product.

One of the most common mistakes is ambiguity. Requirements written in a subjective way, open to interpretation, cause each team member to build a different vision of the same problem. The result is an early fragmentation of understanding that later translates into rework, friction, and constant deviations.

To this is added a deeply rooted practice in many organizations: extensive sessions to gather requirements, long meetings that end up generating distraction, fatigue, and loss of focus. Paradoxically, the longer these sessions are, the less clear the final understanding of the requirement usually is. The team attends, but does not always internalize.

Another critical point is the time factor. In many cases, there is a considerable gap between the moment a requirement is defined and the moment it is actually developed. In that interval, agreements, nuances, and important decisions are lost. The details —which are usually the most valuable— get diluted when there are no precise notes, structured documentation, or a “living artifact” that guides the development.

AI-First as a catalyst for clarity

It is precisely at this point where an AI-First approach begins to make a real difference. Instead of seeing AI as just another tool to “write requirements”, AI-First adoption means rethinking the entire requirements definition process, integrating artificial intelligence as an active collaborator from the start.

When artificial intelligence is properly incorporated in the planning phase, the advances are significant. AI makes it possible to substantially improve the wording of requirements, helping to express ideas in a clearer, more structured, and more objective way. By reducing ambiguity in language, subjectivity in interpretation is also reduced.

This has a direct effect on team dynamics: by speeding up the writing processes, time stops being invested in “how to write” and concentrates on analyzing the problem, questioning it, and validating it. AI does not replace analysis, it enhances it.

In my experience, tools like Project Bob go far beyond documenting. Bob is capable of:

• Writing clear and well-structured requirements
• Proposing concrete and verifiable acceptance criteria
• Explaining and documenting the functional and technical context
• Relating the requirement directly to the existing code

It does all of this with a speed and depth that a single team member could hardly achieve in the same amount of time.

From the requirement to the tasks, before they exist

A particularly relevant point is AI’s ability to identify work before it is tangible. By analyzing the need, the system context, and the existing code, Project Bob can anticipate tasks, dependencies, and impact areas even before the team has formalized them.

In addition, the detection of ambiguous requirements is practically reduced to a minimum. By having a comprehensive view of the project, AI identifies vague phrases, implicit assumptions, or contradictions, helping to refine them from the start.

Real risks and necessary limits

That said, adopting AI at this stage is not without risks.

The first is well known: hallucinations. AI can generate incorrect, incomplete, or simply inaccurate information. This is where human technical judgment becomes irreplaceable. No output generated by AI should be considered an absolute truth without going through a conscious validation process.

The second risk is more subtle: AI can propose solutions that are effective, but not necessarily efficient. A solution can work and still compromise maintainability, scalability, or long-term quality. Evaluating this difference requires experience, context, and architectural vision; deeply human attributes.

That is why the limit is clear: AI assists, but does not decide. Critical analysis and decision-making remain the team’s responsibility. It is not about replacing human thinking, but about accepting that we now work with two complementary forms of thinking: the human and the artificial.

Practical techniques to do “AI-First requirements” without losing control

Adopting an AI-First approach in the definition of requirements does not mean ceding control of the process to artificial intelligence. On the contrary, it demands more discipline, more clarity, and better practices to ensure that AI’s outputs are useful, verifiable, and sustainable over time.

The following techniques have proven to be key to achieving that balance:

• Standardization: The first step to reduce ambiguity is to standardize the way requirements are expressed. Using user story templates with a clear structure (Who / What / Why) forces you to make explicit the business value and the functional scope. Complementing this with a shared definition of Done and acceptance criteria in Given / When / Then format allows AI to generate more precise requirements and, at the same time, facilitates their validation by the human team. Standardization does not limit creativity; it reduces subjective interpretation and creates a common language between business, development, and QA.
• Structured prompting: The quality of the requirements generated by AI directly depends on the quality of the prompt. In an AI-First approach, prompting stops being improvised and becomes a structured practice. Explicit requests such as “remove ambiguity”, “list assumptions”, “list open questions”, or “propose verifiable criteria” force AI to reason about the text, not just rewrite it. This kind of prompt turns AI into a critical reviewer of the requirement, helping to detect gaps before they become problems during development.
• Traceability: An AI-First requirement must be fully traceable. Each acceptance criterion must be clearly mapped to:
  • Test cases (unit, integration, or functional).
  • Specific changes in the code.

  This traceability makes it possible to validate that what was built responds exactly to what was defined and prevents requirements from remaining isolated documents without real impact. In addition, it facilitates audits, technical reviews, and impact analysis in the face of future changes.

• Living artifacts: AI’s output should not remain in chats, loose documents, or temporary notes. Turning those outputs into living artifacts, versioned within a repository, is fundamental to preserving context over time. Documentation, acceptance criteria, and relevant decisions must evolve along with the code. This way, when development is resumed weeks or months later, the team does not depend on individual memory or late interpretations, but on a single, updated, and reliable source.

SDLC – Design and Architecture

When AI stops drawing for us and starts making us think better

The design and architecture stage is usually one of the most complex of the SDLC. Not because there is a lack of ideas, but because translating a conceptual vision into a clear and well-structured technical proposal consumes an enormous amount of time and energy.

On many occasions, the challenge is not in defining the solution, but in translating it into documents, diagrams, mockups, and artifacts that allow it to be analyzed, communicated, and validated. With the arrival of AI, this effort changes radically. The tasks of writing, diagramming, and building mockups are sped up significantly, reducing the time invested in “drawing” the solution and allowing us to focus on what really adds value: analyzing, questioning, and improving the design.

This change is key. When we stop investing hours in mechanical activities, we gain mental space to review critical points, adjust architectural decisions, and evaluate alternatives with greater depth.

AI as a catalyst for architectural thinking

From my experience, AI adds value at this stage in multiple ways. First, it helps to structure ideas. Many times we have the design clear in our head, but not necessarily organized. AI allows us to order that thinking, identify gaps, propose improvements, and, very importantly, force us to justify decisions that we previously took for granted.

It is especially interesting to observe how a second intelligence —in this case artificial— questions our own approaches. By proposing patterns, evaluating designs, or contrasting approaches, AI generates a kind of “assisted self-questioning” that ends up strengthening the final architecture. Not because it is absolutely right, but because it forces us to think better.

This is where tools like Project Bob show a clear advantage. By having full context of the project —requirements, code, dependencies— Bob can identify technical risks that are not always evident at first glance. In one of my projects, for example, it detected a possible data growth problem related to JWT handling, where the key was at risk of overflow. That finding was critical: had it not been identified in time, it would have caused truncations and serious problems in production.

This kind of contribution does not replace the architect, but it does expand their field of vision.

From the requirement to the tasks, before they exist

A point that becomes powerful in architecture is that, if AI has already “understood” requirements and code, it can anticipate impacts: affected modules, contracts to modify, integration points, and performance or security risks. This changes the way of planning: instead of discovering impact late, you discuss it early.

Risks and limits

One of the most common mistakes is falling into architectures that are effective but not efficient, or generating an excessive dependence where the team does not understand the product. That is why AI can suggest and observe, but the decision must be human.

AI-First checklist for architecture decisions

Adopting an AI-First approach in architecture does not mean delegating the design to artificial intelligence. It means using AI as a mechanism to contrast, validate, and expand architectural thinking, always keeping the architect as the person ultimately responsible for the decision.

This checklist serves as a practical guide for incorporating AI into architecture decisions without losing control or technical judgment.

• Compared alternatives (at least 2): In an AI-First approach, AI should be used to propose and contrast multiple architectural alternatives, not to impose a single solution. Explicitly asking the agent to put forward at least two options forces an analysis of different approaches, patterns, and trade-offs. AI can describe the advantages, disadvantages, and assumptions of each alternative, but the final choice always corresponds to the architect, who must evaluate these options based on the organizational, technical, and business context.
• Risks: Every architectural decision must be evaluated from a comprehensive risk perspective. AI can help identify and classify risks in areas such as:
  • Performance: bottlenecks, latency, scalability.
  • Security: data exposure, attack surfaces, regulatory compliance.
  • Cost: over-provisioning, unnecessary resource consumption, licensing.
  • Lock-in: excessive dependence on specific vendors, frameworks, or services.
  • Operation: support complexity, monitoring, recovery from failures.

  AI can point out these risks, but it is up to the architect to prioritize, accept, or mitigate them in accordance with the organization’s strategy.

• Evolution: An AI-First architecture must be designed with change in mind. AI can help define evolution strategies, answering key questions such as:
  • How are APIs versioned without breaking consumers?
  • How are gradual migrations managed?
  • What level of backward compatibility is necessary?

  Designing for evolution avoids rigid architectures and reduces the cost of change in the medium and long term, a critical aspect in enterprise environments.

• Observability by design: Observability should not be a later add-on. In an AI-First approach, the architecture must incorporate from the design stage:
  • Structured and traceable logs.
  • Key metrics aligned with business and technical objectives.
  • Distributed traces to understand complete flows.
  • Clear SLOs that define service expectations.

  AI can help define what to observe, how to correlate events, and which thresholds are relevant, but it is the architect who decides what information is critical to operate and evolve the system.

Summary and upcoming blogs

In this blog I have shared my vision of how an AI-First approach can transform the Planning, Requirements, and Design stages within the SDLC. I have emphasized the importance of adopting AI not as an isolated tool, but as an active collaborator that enhances human thinking, helping to structure ideas, identify risks, and generate artifacts more efficiently. However, I have also underlined the associated risks and the need to always maintain human control over critical decisions. In the next blog, I will dive deeper into how AI-First transforms the Development, Testing, and Observability/Operation stages, exploring practical cases, key tools, and best practices to maximize the value of artificial intelligence in each phase of the SDLC. Don’t miss it!

As you saw in this blog, adopting an AI-First approach is not simply a technological matter, but a strategic and cultural one, starting from the very foundations of the software development life cycle, in the end:

It is not just about modernizing the code, but about modernizing the way we think and work.

Introduction

For a long time, the evolution of software development has been marked by changes in approach rather than changes in tools. API-First, Cloud-First, DevOps-First… all of these paradigms redefined priorities, but kept one constant: the human being remained the only real cognitive entity in the process. Tools assisted, automated, or accelerated, but they did not reason or actively participate in decision-making. That assumption is no longer valid.

Today, talking about AI-First means accepting that artificial intelligence is no longer a peripheral component, nor a “productivity plugin,” but rather a technical actor with the capacity for analysis, proposal, and execution, integrated directly into the software engineering flow. It is not about writing code faster; it is about how technical thinking is built when a second intelligence participates in the process.

From my experience working with advanced assistants —especially in enterprise environments, systems modernization, and complex architectures— I have reached a clear conclusion: AI-First is not a technological decision, it is an epistemological one. It changes the way we understand technical knowledge, the developer’s responsibility, and the role of human experience.

When AI is capable of: • Analyzing complete repositories, • Proposing architectures, • Refactoring legacy systems, • Generating tests, documentation, and workflows, • And learning from the organizational context,

The real challenge stops being what AI can do and becomes how we govern its participation within the engineering process.

This blog does not intend to idealize artificial intelligence nor present it as an automatic solution. On the contrary, it seeks to place the AI-First approach in its proper technical dimension, analyzing how it is transforming software development, which assistants truly embody this paradigm, and why the developer’s role —far from disappearing— becomes more strategic, more architectural, and more responsible than ever.

🧠 What does AI-First really mean?

When I talk about AI-First, I am not talking about integrating artificial intelligence as an additional layer to the development process, nor about adding an assistant that “helps write code.” From my experience, AI-First is a shift in the way we structure technical thinking.

Traditionally, software development has been a linear and human-centric process: the developer analyzes, decides, designs, and executes; the tools merely accompany. Even with advanced automation, the reasoning always resided in a single mind. That model no longer describes today’s reality.

In an AI-First approach, artificial intelligence actively participates in the cognitive process, not as a substitute for the engineer, but as a second reasoning system, capable of analyzing context, proposing alternatives, and executing tasks under supervision.

This implies consciously assuming that:

• AI is not invoked only when “needed,” but is present from the conception of the problem.
• Development ceases to be an individual activity and becomes a human-AI collaboration.
• The developer’s value shifts from writing code to defining criteria, validating decisions, and governing the use of AI.

AI-First is not about using AI to program, but about programming knowing that an artificial intelligence is part of the engineering process.

The difference is subtle, but profound. While the traditional use of AI responds to:

“How do I write this code?”

AI-First forces us to rethink structural questions:

• What decisions can AI propose?
• Which must remain exclusively human?
• How is a solution partially generated by AI validated?
• Where does technical responsibility begin and end?

In that sense, AI-First is not a productivity practice, it is an engineering discipline.

🧩 Visualizing AI-First: from reactive tool to expanded cognition

When we try to draw AI-First, the challenge is not to show arrows or boxes, but to convey a cognitive idea: the transition from a model where AI responds to our requests, to one where AI actively influences how we think about technical problems.

In traditional approaches, AI operates as a reactive instrument: it executes tasks on demand, with isolated prompts and without global understanding. But in an AI-First approach, AI ceases to be an accessory and becomes a cognitive extension of the engineer.

This section proposes a mental visualization that not only compares models, but helps to feel the transformation.

🧠 1. From AI as a productivity spring…

Imagine AI as a tool in your toolbox:

• It is available when you need it
• It responds to what you ask it
• It speeds up isolated tasks
• It depends on your local context

In this model:

• You think first, AI responds afterward
• The technical process remains —almost— the same

📌 Visual:

A tool in your hand, waiting for a prompt to act.

🧠 2. …Toward AI as a structural cognitive layer

Now imagine AI as a second technical mind that:

• Understands the complete project
• Analyzes patterns, dependencies, and trade-offs
• Contextualizes decisions with technical memory of the system
• Proposes alternatives, not just answers

In this new model:

• Thinking is no longer isolated
• A continuous dialogue is generated between engineer and AI
• The solution emerges from a cognitive symbiosis

📌 Visual:

Two “mental engines” —one human, one artificial— interconnected by flows of data, interpretations, and shared context.

🧠 3. From answering prompts → to co-reasoning technical problems

In practice, this leap looks like this:

📌 Visual:

A continuum, not a rupture. An axis from prompt-AI toward cognitive-AI.

🧠 4. How it “feels” to work AI-First

Beyond diagrams, AI-First is perceived as:

• Less struggle with repetitive details
• More time to think about structures and trade-offs
• Less noise, more judgment
• More co-creation, less manual execution

It is like moving from:

“Asking AI for answers”

Toward

“Dialoguing with AI to build decisions”.

💡 What is the essential difference?

The difference is not technical: it is epistemological.

• Using AI is obtaining results.
• Thinking AI-First is rethinking how we arrive at those results, what criteria we use, and how we govern AI’s intervention.

🔄 AI-First in the software life cycle (SDLC)

When we think about the software life cycle requirements, design, development, testing, deployment, operation we tend to see it as a sequence of discrete phases.

AI-First forces us to break down that separation, because if AI affects how we legitimize a decision, then it modifies the nature of the transition between each stage.

In a traditional SDLC, each phase is governed by a set of human assumptions:

1. What must be solved
2. How to solve it
3. What is acceptable
4. How to measure it
5. Who is responsible

AI-First does not eliminate these assumptions, but distributes them between two reasoning systems: human and AI. This produces a qualitative transformation of the engineering process:

🧠 Redefining understanding the problem

Traditionally:

The developer captures business intentions and translates them into requirements.

AI-First:

AI collaborates in the formulation of the problem, detects ambiguities, suggests non-explicit limitations, and exposes tacit dependencies.

AI does not replace human understanding, but expands its reach and reveals assumptions that would otherwise go unnoticed. We are not just capturing requirements, we are conferring upon them a shared cognitive structure.

🧠 Architecture and design as dialogue

Software design has traditionally been a human activity with AI acting as a support tool (diagrams, sketches, autocompletion).

AI-First transforms design into an active dialogue:

• AI articulates constraints and trade-offs across multiple dimensions
• Anticipates friction points before they exist
• Builds design variants simultaneously
• Maintains coherence between discrete decisions

Design ceases to be a solitary art and becomes a space for co-reasoning, where each decision is examined under different optimization vectors.

🧠 Development: not just generating code, but constructive consistency

When AI participates from the implementation phase, development ceases to be a simple translation of design into code.

AI-First injects:

• Coherence of style and architecture
• Validation of technical assumptions in real time
• Detectors of technical debt before it crystallizes
• Suggestions that respect prior patterns and contexts

AI does not produce perfect code; it makes the code’s decisions more explicit and justified.

🧠 Testing as a conversation with the software

Testing has traditionally been a verification activity: we confirm that something behaves as we expect.

AI-First turns testing into an intuitive way of exploring unconsidered inconsistencies. It not only generates tests, but:

• Probes non-obvious edge cases
• Discovers contradictions between implicit assumptions
• Proposes adversarial scenarios based on learned patterns

Testing ceases to be confirmations and becomes explorations of epistemological robustness.

🧠 Integration and deployment: cognitive orchestration

AI-First amplifies the visibility of each change:

• Anticipates deployment impacts across connected services
• Simulates production states based on real data
• Warns of conflicts before they reach execution

It is no longer “integrate and deploy,” it is orchestrating with awareness of risk and benefit.

🧠 Operation and evolution: continuous learning

In an AI-First world, operating is not collecting metrics, it is interpreting them with the help of AI:

• Detecting emerging patterns
• Correlating events with previous design decisions
• Feeding the engineering process back with accumulated knowledge

This turns the SDLC into a continuous thinking circuit, not a line with discrete phases.

🧠 What is really happening

AI-First does not transform the SDLC by adding more automation. It reconfigures the nature of reasoning at each stage:

Before:

AI responded to what the human asked.

Now:

AI participates in the construction of the problem, the solution, and the evaluation.

In other words:

AI-First transforms the SDLC from a set of chained steps into a network of interdependent and co-reasoned decisions.

🤖 Code assistants with an AI-First approach

When we talk about code assistants under the AI-First paradigm, we are not enumerating what each tool can generate, but rather what kind of technical thinking each one enables or limits. The difference between assistants that “speed up tasks” and true AI-First agents is not in how much code they generate, but in how they transform the act of designing, reasoning, and deciding about a complex system.

🧠 1. Project Bob — expanded thinking, not just suggestions

Project Bob is the assistant that comes closest to the metaphor of AI as a cognitive extension.

It does not limit itself to autocompleting or responding to prompts. Its key technical value lies in that:

• It has access to the complete context of the project and the business
• It allows reasoning about architectural trade-offs
• It not only generates code, it proposes lines of thought
• It integrates with regulations, policies, compliance, and technical governance
• It acts as a design partner, not as a snippet generator

In the continuum I proposed from AI as a reactive tool toward AI as a cognitive coprocessor, Project Bob is clearly at the end of structured and contextual reasoning. If technical thinking were a conversation, Bob does not just answer: it poses new questions. Bob does not just suggest solutions, it exposes technical hypotheses.

🧠 2. GitHub Copilot Agents — agents as amplifiers of intent

GitHub Copilot was the first tool to popularize AI “at the code level,” but its evolution toward Agents implies a conceptual transition: from being an input-output extension to being configured as intelligent automation layers over established flows.

Copilot Agents does not replace your judgment, but:

• Interprets complete parts of the system
• Can generate tests, documentation, and solution proposals
• Acts over broader contexts than simple functions

From the AI-First perspective, Copilot Agents is not yet a complete cognitive coprocessor, but it is an accelerator of technical intent: it converts explicit decisions into contextualized executions. If AI were a second mind, Copilot Agents would be the first operational thinking assistant: it works while you decide which path to take. Copilot Agents accelerates your intent, it does not replace or generate it.

🧠 3. Kiro — the aspiration toward autonomous cloud-native agents

Kiro (and similar tools oriented toward autonomous agents) points toward an interesting technical idea: AI that not only helps conclude tasks, but can anticipate complete solution paths.

Unlike a reactive model, Kiro: • Seeks to close complete loops of tasks • Can make flow decisions (under defined rules and objectives) • Integrates with cloud services and pipelines as a contextual automation agent

At the level of technical thinking, it is situated closer to a provider of proposals than to a simple reactive assistant, although it does not yet have the degree of deep co-reasoning of an AI that maintains complete domain memory. In terms of the continuum:

Kiro is at the frontier of autonomous agents that propose paths and not just answers.

🧩 4. What really defines an AI-First assistant?

Technically, a code assistant can be considered AI-First if it meets at least these qualities:

1. Deep context understanding. Not only of the active file, but of the domain, architecture, and constraints of the project.
2. Active participation in reasoning. It goes beyond autocompleting: it proposes alternatives, explains trade-offs, and suggests paths.
3. Capacity to execute flows, not just tasks. For example: testing, design validation, security review.
4. Technical supervision and governance. Its output is auditable, explainable, and aligned with internal policies.
5. Human-AI co-reasoning. It is not a replacement. It is an expansion of structured thinking.

🧠 Final analysis of code assistants

Not all assistants embody AI-First. Many are powerful from the productivity standpoint, but cognitively limited: they operate on prompts, not on context. The true AI-First revolution is not that AI generates code faster —that is already a commodity—, but that it can be an active part of the construction of the technical thinking behind a solution. And this is not achieved by generating code It is achieved by generating criteria.

🚀 The future of software development

Looking at the future of software development from an AI-First perspective is not about describing new tools or cataloging functions. It is, above all, recognizing how the act of thinking software changes when artificial intelligence ceases to be an accessory and becomes an integral part of the cognitive process.

🔹 Short term: co-reasoning and expansion of technical capacity

In the next 1 to 2 years, we will see an accelerated transition from assisted development to co-reasoned development:

• AI as a continuous copilot: AI will cease to be invoked by isolated commands and will begin to be part of the flow of thinking, influencing:
  • Choice of architectural patterns.
  • Real-time trade-off suggestions.
  • Proactive detection of technical debt.
• Contextual domain memory: It will no longer be enough for AI to know code fragments: it must understand the problem domain, business constraints, and the team’s past decisions to make valuable contributions.
• Reasoning about technical intent: AI’s input will have to transcend the “what” to ask the “why”: What is the business objective behind a requirement? What is the implied context behind a design choice?
• AI as an auditor of criteria: Beyond generating code, AI will begin to:
  • Evaluate consistency between assumptions.
  • Anticipate design contradictions.
  • Propose alternative paths with logical justification.

This will imply a profound change for teams: not only will less code be written, but the very act of writing it will be questioned more.

🔹 Medium term: cognitive agents and the evolution of the professional role

On the horizon of 3 to 5 years, the AI-First vision will mature in forms that today seem conceptual, but will be practical and ubiquitous.

🧠 1. Agents specialized by role

We will not just talk about AI that generates code, but about cognitive agents with technical identity:

• Architect Agent: Proposes and evaluates architecture schemes.
• Analyst Agent: Detects inconsistencies, risks, and non-explicit dependencies.
• Quality Agent: Generates and adjusts test suites based on business objectives and risks.

These agents will not be replacements, but specialized extensions of human capabilities.

🧠 2. Persistent project memory

Knowledge will not be only in documentation or in the minds of engineers, but in AI models that maintain a technical memory of the project, which will allow:

• Continuous review of past decisions,
• Contextualization of new requirements,
• Suggestions aligned with the complete history of the system.

🧠 3. Technical co-governance

AI will not only suggest; it will participate in technical governance processes, supporting discussions about:

• Quality criteria,
• Security policies,
• Architecture decisions,
• Regulatory compliance.

🔹 And the human role in this future?

Contrary to the simplistic narrative of “AI replaces the developer,” the AI-First future will demand:

• Superior critical reasoning: AI can propose multiple solutions; the human must choose which is the most aligned with context, risks, and real objectives.
• Designing criteria, not just code: Productivity will no longer be measured in lines generated, but in defined criteria, justified decisions, and robust solutions.
• Integrated supervision and ethics: The responsibility of ensuring that AI operates in a safe, explainable, and ethical way rests on the team, not on the tool.

💡 A pragmatic change: from “doing” to “thinking”

If today the challenge is to integrate AI to produce incremental value, tomorrow the challenge will be:

How do we structure engineering thinking so that it can coexist, collaborate, and evolve with another reasoning system?

The answer is not in listing tools, but in rethinking the engineering process:

• Less noise in repetitive decisions.
• More energy on criteria and reasons.
• Less manual execution.
• More strategic supervision.

🌐 Conclusion: smarter software development

We are not projecting more code generated by AI, but rather an engineering ecosystem based on co-reasoning:

• The short term brings an expansion of technical thinking: AI as a constant copilot.
• The medium term brings specialized agents, shared memory, and co-governance.
• And in that future, the developer will not be displaced, but will indeed be redefined as a strategic thinker, an articulator of criteria, and a supervisor of reasoning.

Software development will cease to be:

“how do we make the software work”

To become:

“how do we make the software technically sustainable, cognitively robust, and strategically aligned”

🧠 Closing: AI-First as a discipline, not a shortcut

Adopting an AI-First approach does not consist of integrating code assistants nor accumulating tools powered by artificial intelligence. It implies redefining the discipline of software development under a new reality: the coexistence between human intelligence and artificial intelligence within the same cognitive process.

The most advanced AI-First assistants —such as Project Bob, GitHub Copilot Agents, or emerging initiatives like Kiro— evidence a clear transition: software development ceases to be a purely reactive and manual activity, and becomes an exercise in orchestration, supervision, and informed decision-making.

In this context, the developer’s role evolves. They are no longer solely the one who implements solutions, but the one who:

• Defines technical limits and criteria,
• Evaluates proposals generated by AI,
• Governs the responsible use of models,
• Guarantees quality, security, and alignment with the business.

The true competitive advantage will not lie in who uses more AI, but in who knows how to integrate it with judgment, experience, and responsibility. AI-First does not replace the engineer; it demands a more conscious, more architectural, and more strategic engineer.

And it is here where the most important change occurs not in the code, but in the mindset. In the end:

It is not just about modernizing the code, but about modernizing the way we think and work.

Introduction

In recent months I have had the opportunity to evaluate Project BOB, not out of curiosity about a new tool, but from the daily reality of two roles that constantly intersect: Solutions Architect and active developer.

It was not a lab test or a controlled demo. I decided to use BOB in real-world scenarios:

• development from scratch,
• modernization of existing code,
• daily work with version control,
• and DevOps-oriented practices.

The question was not whether BOB could “help,” but how deeply it could integrate into the software development life cycle and whether it truly represented an AI-First approach beyond the marketing.

My work context

My main focus has been Java, developing modern applications and evaluating modernization processes, particularly a migration from Java 17 to Java 21. In parallel, I have run tests on IBM i, working with RPG Full Free, SQLRPGLE, and DB2 for i.

All of this on Git repositories on GitHub, trying to maintain a clean and disciplined DevOps flow.

I came in with high expectations. I had seen BOB in action at IBM TechXchange 2025 and the concept was clear: it was not just another assistant, but something different. The real test was to see how it behaved when the code, the dependencies, and the architectural decisions were real.

Strength #1 — Real autonomy: working by tasks, not by prompts

The clearest strength I have identified in Project BOB is its autonomy to execute complete tasks. BOB does not limit itself to responding to isolated prompts; it understands a task as a functional unit that must be solved from start to finish.

In practice, this means that BOB can:

• analyze the full context of the project,
• run console commands when necessary,
• adjust code,
• update configurations and components,
• and resolve dependencies without turning the flow into a fragmented conversation.

Real example

While developing a Java application that communicated with AWS services, I defined clear, concrete tasks. BOB was able to develop those complete processes without creating excessive dependency or forcing me to guide every step.

This is key: AI does not replace you as an analyst, but it also doesn’t turn you into someone who just “feeds prompts.” The focus returns to validation and technical decision-making and, most importantly, to the final result.

Strength #2 — Commit review: CI from the very first moment

Another point of enormous value is BOB’s ability to review the commits you make in the project. Every time you commit changes, BOB can:

• analyze what was modified,
• assess the impact of the change,
• detect potential errors,
• and alert you to integration problems.

This approach promotes something fundamental in DevOps: detecting problems as early as possible.

In day-to-day work, this naturally encourages the use of micro-commits:

• easier to understand,
• easier to revert,
• and much healthier for a continuous integration flow.

Code quality improves not because processes impose it, but because feedback arrives at the right moment.

Strength #3 — Documentation and action plans, not just observations

BOB doesn’t stop at merely pointing out problems. One of its most useful capabilities is documentation accompanied by strategic improvement plans.

Real example

I had a project without a README and I asked BOB to document it. The result was a complete README that included:

• how the project should be managed,
• its structure and layers,
• the overall functionality,
• and recommendations for deployment in production environments.

This kind of documentation is not just there to “tick a box”; it raises the project’s quality standard and makes maintenance, support, and onboarding easier.

When I really felt it “works with me”

One of the most revealing moments was when, upon opening a project developed in Java 17, BOB automatically identified the context and proposed modernizing it to Java 21.

Afterward, it:

• reviewed the POM file,
• analyzed dependency versions,
• and began connecting technical decisions without me having to guide it step by step.

The same thing happened with commits: BOB gave me observations before the code reached a shared branch. This allowed problems to be caught at the most basic point of development, when fixing them is cheaper and less risky.

In a traditional flow, you usually have to explicitly ask: “review,” “validate,” “document.” With BOB, that friction is noticeably reduced thanks to its autonomy. It’s as if it truly “worked with me” and didn’t just respond to my orders.

AI-First: when AI stops being a tool

From my experience, AI-First does not simply mean integrating AI into the IDE. Nor is it just about automating tasks. To me, AI-First means that AI stops being an additional tool and becomes the center of the project.

When AI occupies that central role, it:

• orchestrates complete tasks,
• understands the global context,
• participates in every stage of the DevOps flow,
• and forces us to rethink how we work as developers.

I have always held an idea that makes even more sense here:
we don’t just modernize the code, we also modernize the way we think and work.

What changed in the way I develop

Two aspects changed very clearly, which I can attribute directly to using BOB and to the AI-First approach.

The first was documentation. I had never documented my projects with this level of depth and consistency. Having an AI that understands the architecture and the intent of the code raises the standard almost without any extra effort.

The second was the rhythm of commits and reviews. By reviewing more and earlier:

• code quality improves,
• testing increases,
• the number of bugs is reduced,
• and development becomes more agile, but also more disciplined.

From the detailed prompt to collaborative work

Before, much of the time went into explaining context and detailing prompts. With BOB, that model changes.

I no longer need to describe every step exhaustively. BOB knows the project, understands its state, and responds in a much more accurate way. My role now focuses on:

• reviewing,
• validating,
• and following up.

The time is invested in thinking, not in micro-instructing. And that, in my experience, makes a big difference in productivity and quality. The focus remains on decision-making, but with an AI that truly understands the context and acts autonomously to support development.

All of this leads me to reflect on which aspects remain exclusively human, and which can be further enhanced by AI.

What I would never delegate, even in an AI-First approach

Although the AI-First approach is powerful, there are responsibilities that remain human. In my case, architecture and deep technical analysis are not delegated.

Business domain knowledge, long-term maintainability, and functional validation require specialized judgment. AI accelerates, accompanies, and suggests, but the final responsibility remains human.

While BOB can propose architectural or technical improvements, the decision to adopt those recommendations always rests with the developer or architect responsible for the project, ensuring that the solutions are solid and aligned with business objectives.

Opportunities for improvement: taking AI-First to the next level

Despite the obvious strengths, there are areas where BOB and the AI-First approach can evolve even further, especially for complex enterprise environments and large teams. From my experience, I identify three key opportunities:

Integration with agile boards

A clear improvement would be direct integration with agile management tools such as:

• GitHub Projects,
• Azure Boards,
• Jira.

Today, BOB can document stories and tasks, but creating them is still manual. Integrating it with the boards would close the cycle between analysis, documentation, and execution. Automating the creation and updating of tasks based on the analysis of code and commits would allow a smoother flow aligned with agile practices, reducing administrative load and improving the traceability of activities.

Multi-repo and microservices scenarios

In modern architectures with multiple repositories, especially in Java microservices, a key question arises:
how do you help when the context is distributed?

Exploring how BOB can understand relationships between repositories and cross-cutting impacts would be an important step for real enterprise environments. This would allow BOB to offer more holistic recommendations, considering dependencies between services and making coordination easier in teams working on multiple fronts simultaneously. It remains a challenge to ensure that the AI maintains a coherent view of the complete system when the code is fragmented across several repositories.

Integrations, governance, and autonomy

The areas with the most room to evolve are:

• integrations,
• governance,
• and autonomy in large teams.

I am currently analyzing practices for responsible adoption, such as mandatory code reviews and clear controls over the use of AI. These improvements would make AI-First truly materialize across all processes. For example, establishing policies that define when and how BOB can be used in different stages of development, as well as audit mechanisms to ensure the quality and security of code generated or modified by the AI. In addition, fostering team autonomy to adapt the use of BOB to their specific needs, without losing control over the project’s critical decisions. This is especially relevant in large organizations where coordination and governance are essential to success.

Conclusion

Project BOB shows that AI-First does not replace the developer or the architect, but it does redefine their role.

When AI understands the context, orchestrates complete tasks, and accompanies the DevOps flow, development becomes more agile, more disciplined, and of higher quality.

The challenge is not only technical but cultural: learning to work with an AI that is no longer just another assistant, but a central copilot of the process, without losing the human judgment that guarantees solid and maintainable solutions.

That is where, from my experience, AI-First truly makes sense, and where I see the future of software development in the coming years. As these tools evolve, the collaboration between humans and AI will be the key to reaching new levels of productivity and quality in software development. It is up to us to take advantage of this potential without losing sight of what makes us unique as software professionals. Because at the end of the day, technology is only a means to enhance our creativity and our ability to solve complex problems. And in that sense, Project BOB is a significant step toward that collaborative future.

In the end, as I always say:

“It’s not just about modernizing the code, but about modernizing the way we think and work.”