Generative AI in software development: the role of the prompt engineer

Generative AI is changing one of the most important activities within tech teams: the way software is developed.

Generating functions, explaining code, creating tests, or proposing solutions to an error were some of the first applications. Current tools can work on complete repositories, modify multiple files, execute commands, check tests, and participate in engineering tasks that require several steps.

This change is also transforming the role of the Prompt Engineer within software development.

Knowing how to formulate a good instruction remains useful, but it is insufficient when an AI system must understand an architecture, respect internal conventions, use tools, and produce changes that will eventually be integrated into a real product.

The work is beginning to shift from writing isolated prompts to providing context, constraints, tools, acceptance criteria, and validation mechanisms.

For software teams, this evolution raises a broader question: if producing code is becoming increasingly easier, what capabilities are truly important for a developer?

Generative AI is already participating in more stages of development

The first AI-assisted programming tools were particularly focused on autocompletion. The developer would start a function, and the system would suggest the next lines.

Then came conversational interfaces capable of generating components, explaining errors, creating SQL queries, or proposing refactorings based on natural language instructions.

Current coding agents significantly expand that model.

Tools like Codex can plan modifications, write code, execute tests, and prepare changes for review. This allows for delegating broader tasks than just a one-time code generation.

The change can be summarized in several stages:

• Autocompletion: AI proposes snippets while the developer programs.

• Conversation: the developer describes a task and receives code or explanations.

• Context-aware coding: the tool works using information from the repository.

• Coding agents: the system inspects, modifies, executes, and validates different steps.

• Agentic workflows: multiple agents and tools participate in different parts of the development cycle.

As autonomy increases, so does the importance of correctly defining the environment in which the AI operates.

The Prompt Engineer is evolving into Context Engineering

A prompt works well when it contains enough information for the model to correctly interpret the task.

In software engineering, that information can be considerable.

The agent needs to know what the team wants to build, which part of the repository can be modified, what architecture the project uses, what conventions must be respected, and what result will be considered correct.

An instruction like “create an authentication system” leaves too many decisions open.

A task prepared for an engineering environment can specify the existing authentication mechanism, the components that can be modified, security constraints, the tests that must be maintained, and the acceptance criteria.

The work then ceases to consist exclusively of finding the best linguistic formulation.

The engineer needs to build the operational context within which the AI can make useful decisions.

This evolution is closely related to Software Architecture, because an agent needs to understand the architectural boundaries of the system before making significant modifications.

More context does not automatically mean better results

An apparently simple strategy would be to provide the model access to the entire repository.

This can introduce another problem: not all available information is relevant for each task.

Enterprise repositories can contain thousands of files, historical documentation, dependencies, configurations, legacy code, and multiple services.

The goal of Context Engineering is to provide enough information to make a decision without unnecessarily filling the context with elements that may distract the system.

This may involve identifying relevant files, explaining dependencies, including internal documentation, or providing existing examples that represent the correct pattern.

It may also be necessary to establish persistent rules for the repository.

Current agentic tools allow for introducing instructions about standards, workflows, and ways of working for the team so that agents can use them during their tasks.

The repository thus begins to need documentation designed for both human developers and agents.

From generating code to delegating complete tasks

The most important change occurs when AI stops producing only responses and begins to execute actions.

A coding agent can receive a task, inspect different parts of the repository, develop a solution, execute tests, and fix errors found during the process.

Anthropic describes the loop of its agentic tools as a process where the agent can read, plan, act, and observe on a real repository. OpenAI, for its part, describes workflows where Codex takes tasks from an issue to tested code ready for review.

This modifies the interaction between engineer and AI.

The engineer begins to spend less time indicating how to write each line and more time establishing what result is needed.

Agents can work on increasingly broader tasks

An AI tool integrated into the development cycle can participate in multiple types of work.

Functionality generation continues to be an obvious application, but debugging, refactoring, documentation, migrations, test creation, and code review also emerge.

Codex, for example, is currently designed for tasks ranging from fixes and test coverage to refactorings and complex migrations.

This is especially relevant for Full Stack Developers, who typically work across different layers of an application.

An agent can help understand existing code before modifying it or execute repetitive tasks while the developer maintains control over decisions that affect the product.

The value appears when automation frees capacity to work on problems that require a deeper understanding of the system.

Frontend and Backend also change with coding agents

In Frontend, AI can generate components, adapt interfaces, create tests, or assist during a framework migration.

However, building a functional interface does not guarantee a correct experience.

Frontend Developers still need to evaluate accessibility, performance, responsive behavior, component architecture, and consistency with the design system.

Backend presents a similar situation.

An agent can generate endpoints, models, migrations, or tests, but decisions about data integrity, concurrency, security, service contracts, or performance require understanding the implications within the system.

Backend Developers need to review these implications even when much of the initial implementation has been generated automatically.

AI increases the capacity to produce changes. That speed makes it even more important to know which changes should be integrated.

Generated code still needs validation

Just because a model produces syntactically correct code does not mean the solution is suitable for production.

There may be a logical error that only appears under certain conditions. There may also be unnecessary dependencies, vulnerabilities, performance issues, or implementations that contradict existing architectural decisions.

Human review continues to play a central role.

Teams need to check at least three dimensions: that the change correctly resolves the requirement, that it maintains the project's technical standards, and that it does not introduce regressions.

QA Engineers can take on a particularly relevant role within these workflows. The greater the volume of changes produced with AI assistance, the greater the need for automated mechanisms capable of verifying them.

Unit tests, integration, end-to-end, and validations within CI/CD provide feedback that an agent can use during its own execution process.

Tests become executable instructions for agents

In a traditional workflow, tests help detect regressions and ensure that certain functionalities continue to work.

In an agentic environment, they have an additional utility: they provide the system with an objective signal about the result of its work.

A developer can define a task using natural language, but a test programmatically expresses a condition that must be met.

The agent can modify code, run tests, observe what fails, and continue working.

This turns the testing infrastructure into part of the environment that allows for delegating tasks with greater confidence.

A repository with good coverage, updated documentation, and clear validation processes provides better feedback mechanisms than one where the only way to know if a modification works is to check it manually.

The developer also starts to design the agent's environment

One of the most interesting transformations occurs around the repository itself.

If agents are going to work continuously on a codebase, the organization needs to provide them with information that previously may have only existed in the heads of developers.

Naming conventions, architectural boundaries, testing procedures, development commands, security requirements, and criteria for modifying certain components need to be documented.

OpenAI describes this approach as harness engineering: humans provide intent, environments, and feedback loops while agents execute a larger part of the implementation work.

This introduces a new dimension in engineering quality.

A well-structured repository is easier to understand for new developers and can also provide better conditions for software agents.

Prompt engineering remains important, but its function changes

The evolution towards Context Engineering does not eliminate prompts.

An ambiguous instruction can cause an agent to spend time solving the wrong problem, even if it has access to the entire repository.

The engineer needs to express objectives precisely.

A good task should allow identifying what result is expected, what constraints exist, and how to verify that the work is finished.

In software, this capability is closely related to competencies that already existed before AI: requirements analysis, problem decomposition, and technical design.

The difference is that now those instructions can be executed by systems capable of carrying out a considerable part of the implementation.

Using AI to develop software and developing AI products are two different things

This distinction is important when a company defines what profile it needs to hire.

A developer can use coding assistants or agents to increase their productivity without becoming a Prompt Engineer.

In this scenario, knowing how to work with AI gradually becomes a competency within the technical profile itself.

Another situation arises when the product the company is building directly depends on generative models.

A RAG system, a business agent, or an application based on LLMs may need to design prompts, contexts, tools, evaluations, and mechanisms to control the model's behavior.

There may be a greater specialization there.

AI specialists can work alongside software teams to design these systems when AI is part of the product architecture and not just the tools used to build it.

What changes when hiring developers in an AI-native environment

The ability to use generative tools is becoming part of the everyday work of engineering.

However, evaluating a developer solely by the amount of code they can produce with AI offers a limited signal.

If generating implementation is becoming progressively faster, other competencies gain weight:

• Ability to decompose ambiguous problems into verifiable tasks;

• Understanding of architecture and consequences among different components;

• Skill to provide relevant context to agents;

• Judgment to review generated code and detect seemingly correct solutions;

• Mastery of testing, debugging, and validation mechanisms;

• Ability to oversee delegated tasks without losing technical ownership.

The available data on agentic tools also points in that direction. A study by Anthropic on approximately 400,000 sessions of Claude Code found that users contributed most of the planning decisions while the agent took on a larger proportion of the execution decisions; moreover, greater domain experience was associated with better results.

Technical experience continues to be valuable precisely because it allows for better delegation.

AI can produce more code; the team remains responsible for the software

The automation of development can significantly accelerate execution, but a company still needs ownership over what goes into production.

Agents can write code, execute tests, and prepare changes. Engineers need to decide which changes make sense within the product, what risks are acceptable, and what standards must be maintained.

Security also needs specific controls when agents can execute commands or interact with tools. OpenAI describes governance mechanisms aimed at limiting what resources a coding agent can use, when it needs human approval, and what telemetry must be retained to audit its actions.

As autonomy increases, defining these boundaries becomes more important.

The prompt engineer evolves alongside software engineering

Generative AI began by helping to write code. Coding agents are expanding that scope toward complete engineering tasks.

This transition also changes the meaning of Prompt Engineering.

The relevant capability shifts from focusing on finding a phrase that can yield a good response. The engineer needs to structure objectives, context, constraints, tools, and feedback mechanisms so that an AI system can work reliably.

In some teams, this function will continue to be part of the competencies of Frontend, Backend, Full Stack, QA, or Software Architecture. In products built directly around models and agents, it can become a much deeper specialization.

In both scenarios, the principle is similar.

Generative AI is progressively reducing the effort needed to produce code, but it remains necessary to decide what code should exist, how it should integrate with the system, and what evidence demonstrates that it works correctly.

The developer who masters that combination of technical judgment, context, and oversight will be better prepared to work with the next generation of software engineering tools.