AI in software development: from coding agent to engineering process

The debate about AI in software development suffers from two extremes. On one side the expectation that an agent will soon write the entire product. On the other the defensive stance that AI produces unusable code by definition. Both miss real project life. The interesting question is the one in the middle: which parts of a development process does AI actually change – and which not?

1. What AI reliably delivers in development today

Language models are strong when a task has three properties: it can be described in words, it follows recurring patterns, and its result is machine-checkable. When all three hold, the productivity gain is real and measurable.

Typical tasks in this category:

• Translation work: data structure to DTO, DTO to form, form to API call, API response to table view.
• Frontend implementation against a known interface, including states, validation messages and display edge cases.
• Test scaffolding for existing code: parameterisation, boundary values, fixtures, mocking boilerplate.
• Migrations along clear rules: framework versions, naming conventions, import restructuring, deprecation replacements across many files.
• Explaining unfamiliar code – an underrated use case in maintaining legacy systems.
• First drafts of documentation, commit messages, changelogs or review summaries.

What these tasks share: something external can judge the result – a compiler, a type system, a test, a linter, a schema. That is exactly where AI is strong, because mistakes become visible fast and are cheap to correct.

2. Code generation is not software engineering

Software engineering is not only producing source code. It is a chain of decisions before and after the code: clarifying requirements, modelling the domain, settling the architecture, agreeing interfaces, checking quality, shipping, operating, changing. Code generation addresses a single point in that chain.

That is not a detail but the decisive difference for costing. If an agent speeds up implementation by 60% while implementation is only 30% of the total effort, the net effect is just under 20%. If review effort rises at the same time, because more code has to be checked in less time, the effect can even turn negative. Acceleration without process change creates a queue at the next constriction.

Three properties generated code does not bring with it

• Intent. The code shows what happens, not why it was decided that way. The reasoning – alternatives, trade-offs, domain constraints – exists only if somebody records it.
• Commitment. A model can solve the same requirement differently in two runs. Without an explicit rule there is no reason why project A and project B should share a structure.
• Evidence. That something works is a claim as long as no test, no review record and no build artefact backs it up.

That is why the most productive way to use AI is not “more prompting” but more explicitness outside the prompt: models, contracts, rules and checks that generated code has to measure up against.

3. Architecture context: the model does not know your decisions

A coding agent sees a slice: open files, search hits, perhaps a project handbook. It does not see the discussion from the last architecture meeting, nor the multi-tenancy that was solved differently in three modules, nor the reason a particular library is forbidden.

Whatever is not explicit gets plausibly invented. That is the mechanism behind most “odd” agent results – not a model failure but missing context. Practical countermeasures:

• Keep architecture decisions in writing (ADRs) and store them in the repository, not in the wiki of another system.
• Treat interfaces as contracts: OpenAPI, JSON Schema, Protobuf. A contract is readable by people and tools alike.
• Model the domain structure instead of only implementing it: entities, relations, mandatory fields, validation rules, roles and permissions as a model, not scattered across controller code.
• Store project rules in machine-readable form – directory conventions, permitted dependencies, naming schemes – so they apply both in review and in the agent's context.

The side effect is notable: the same explicitness that makes an agent productive also makes onboarding new developers and every audit easier. Context is not a special AI task but good engineering hygiene that AI finally gives an immediate payoff.

4. Tests and quality gates: the bottleneck moves

When implementation gets cheaper, reviewing gets relatively more expensive. Teams using AI seriously notice this within weeks: the bottleneck is not writing code but answering for it.

Three consequences for test strategy:

1. Tests need an independent source. A test generated from the same context as the implementation often confirms only the behaviour, not the requirement. Test cases should be derived from the domain requirement – if necessary in a separate step, deliberately without looking at the implementation.
2. Coverage is a weak signal. Generated code reaches high line coverage effortlessly. More meaningful are edge cases, error paths, concurrency, authorisation checks and – where the effort is justified – mutation testing.
3. Gates belong in the pipeline, not in an agreement. A rule that only exists in the team handbook is not a rule under time pressure.

A sensible minimum set of automated gates before merge – regardless of whether code came from people or agents:

# Minimal set of gates that must pass before merge.
# Applies to every change, regardless of who or what produced it.

build            # compiles / packages without warnings that matter
unit-tests       # deterministic, fast, no external services
contract-tests   # implementation still matches the published API contract
lint + format    # no style discussion inside code review
sast             # static application security testing
dependency-scan  # known vulnerabilities and license policy
secret-scan      # no credentials in the diff

The point is not the specific tool list but the commitment: what does not pass the gate does not get merged. That single rule decides whether AI speed reaches the team or dissolves into rework.

5. Security: shifted failure modes, familiar instruments

Generated code does not produce fundamentally new vulnerabilities – the classics from the OWASP lists remain the classics. What has changed is the distribution: defects appear more often where the model has to guess plausibly.

• Authorisation. Authentication is usually implemented correctly; fine-grained per-record permission checks are often only sketched. Object-level permissions belong in the model, not in the prompt.
• Dependencies. Suggested packages can be outdated, unwanted or simply non-existent. A package name that does not exist in the ecosystem is an open invitation for attackers to register it. Check dependencies against a curated source.
• Secrets. Example configurations with placeholders end up in the repository with real values surprisingly often. Secret scanning is mandatory, not optional.
• Data leaving through the tool chain. Whatever an agent may read, it can also process. That is less a model problem than a question of permissions, network boundaries and operating model – see MCP and permission boundaries for AI agents.

For teams with elevated requirements a second layer appears: not only whether something was checked, but whether that can later be evidenced. That is exactly where regulated software development begins.

6. Human review: from checking lines to checking intent

Classic code review implicitly assumes somebody thought about every line. With generated code that does not hold. A review that keeps checking style and syntax line by line consumes a lot of time and finds little.

A shifted set of questions is more effective:

• Does the change solve the actual requirement – or a plausible neighbouring version of it?
• Does it fit the existing architecture, or does it introduce a second pattern for the same problem?
• Are error and authorisation paths handled, not just the happy path?
• Is the size reviewable? A 4,000-line diff does not really get read, whatever the review comment promises.

Formal matters – formatting, import order, naming conventions – belong entirely in automation. Human attention is the scarcest resource in the process and should be reserved for intent, architecture and risk. Smaller change sets are not a style question but the precondition for review working at all.

7. Traceability: “who decided that?” gets harder

In a classic team the history answers that question quite well: ticket, commit, pull request, approval. With agents a gap appears – the commit author did not write the code but commissioned and reviewed it. That is no problem as long as it is visible.

In practice: the link between requirement, change, review and release has to be reconstructable from the artefacts – not from the memory of those involved. Structured commit trailers are a lightweight start:

feat(billing): add dunning level to invoice model

Implements the escalation rules agreed in REQ-1042.
Generated with an AI coding assistant, reviewed and adjusted manually.

Requirement: REQ-1042
Reviewed-by: a.beck
Assisted-by: ai-coding-assistant

That is no substitute for a traceability concept, but it makes the question answerable. What an end-to-end chain from requirement to release looks like technically is covered in the deep dive traceability: from requirement to release.

8. CI/CD: where rules become real

Any rule that is not in the pipeline is a request. That was already true before, but it weighs more once changes arrive faster than a team can discuss them.

A pipeline that carries AI-assisted development differs less in its steps than in how binding it is and in the evidence it produces:

• A reproducible build from a versioned project definition – same input, same artefact.
• Automated gates as a merge precondition, not as a report afterwards.
• Signed, versioned artefacts including a bill of materials (SBOM).
• Deployment into your target environment – your own GitLab, Jenkins, on-premise, private cloud or Kubernetes – not into somebody else's black box.
• Analysable logs: which version was shipped when, by whom, with what outcome?

How CodamAI implements this step concretely is on the features page: load the project definition, build the application, create the container image, run the quality gates, deploy.

9. Governance: rules instead of bans

The most common mistake in dealing with AI coding is the blanket ban. It does not prevent use, it only moves it to places where nobody is looking. A solid policy answers four questions instead:

1. Where may AI be used? By project or data classification, not across the board.
2. Which data may leave the company? Source code, client data, trade secrets and personal data are different categories – the operating model (cloud, private, on-premise) follows from that.
3. What has to be checked before it goes to production? Ideally identical to the rules for hand-written code, plus the specifics from section 5.
4. What gets documented? At minimum: that AI was used, who reviewed, and against what.

How these four questions combine into a short, enforceable policy is described in the deep dive AI coding governance.

Organisations with a management system can dock this onto existing structures – for example quality management to ISO 9001, an information security management system to ISO/IEC 27001, or an AI management system to ISO/IEC 42001. The sober framing matters: these standards certify management systems and organisations, not an individual software product and certainly not a tool in use.

10. Usage patterns for software companies

Software companies have a particularity: they rebuild the same technical base in every client project – user management, roles and permissions, tenants, master data, authorisation logic, reporting foundations. That share is uninteresting in domain terms but maintenance-heavy and relevant to liability.

A clear three-way split follows:

The economic lever is rarely faster typing. It is that recurring groundwork disappears from project costing and that quality requirements do not have to be renegotiated in every project. Introduce AI without standardising that base and you mainly get one thing: variety produced faster.

Checklist: AI in the development process

Conclusion

AI changes software development not by replacing engineering but by making the unstructured part of the work cheap. What remains is exactly what turns software into a product you can stand behind: explicit models, verified interfaces, solid tests, traceable decisions and a delivery you can repeat.

Teams that had this structure before gain markedly from AI. Teams that did not get their gaps presented to them faster. The sensible next step is therefore rarely “more AI” but more explicitness at the points where control is needed.