AI Coding Careers: Build, Verify, Deliver

David has been a Java developer for ten years.

Recently, he has started to worry.

A new colleague, Alex, uses an AI coding assistant to build APIs, admin pages, and test scaffolding in days. Work that once required David to search documentation and write repetitive code now emerges from a few conversations.

David begins to wonder: how much is his experience still worth?

Then a load test reveals a problem. Throughput stops increasing while response times keep climbing.

Alex asks the AI to adjust the thread pool. David suggests checking thread dumps, database connection wait times, slow queries, and recent changes first.

They trace the bottleneck to database access. Adding more application threads would leave more requests waiting for connections.

Together, they reduce unnecessary queries, change how data is fetched, and repeat the test under the same load.

This is an illustrative scenario, not an account of a specific incident.

The point is not that experienced developers understand systems while newcomers merely operate tools. Alex can learn to diagnose the problem. David can make mistakes by trusting outdated assumptions.

The meaningful distinction is whether someone can explain why an implementation works, identify the conditions under which it fails, and establish how to recover.

AI has not removed those responsibilities.

What AI Coding Incidents Actually Teach Us

Reports of AI agents damaging production systems deserve attention. But useful lessons require separating confirmed facts from personal accounts and speculation.

In April 2026, Railway confirmed that an AI agent had found a locally stored API token and used it to delete a customer’s production data volume. The token had account-wide access, and the API deletion path lacked the delayed deletion protection available through the dashboard.

Railway also confirmed that the database was subsequently recovered. Describing the incident as permanent data loss would omit an important part of the outcome. Railway’s incident explanation

Other incidents involve disputed attribution. Following reporting that connected an AWS Cost Explorer interruption with Kiro, Amazon attributed the event to misconfigured access controls and said the impact was limited to one service in one region. It should not be presented as an undisputed case of AI destroying an entire AWS production environment. Amazon’s response

These cases raise a practical question:

When a tool makes a bad decision, how far can that decision travel?

Incorrect code, excessive permissions, weak environment isolation, and inadequate recovery mechanisms are different failure modes. Treating all of them as “AI being unreliable” obscures the changes that could prevent damage.

A handful of incidents also cannot establish whether AI-assisted development is generally more dangerous than manual development. That comparison would require information about usage, task difficulty, and the human baseline.

What these incidents demonstrate is the importance of controlling the consequences of mistakes.

Code Generation Is Only Part of Delivery

AI can help developers understand unfamiliar code, draft implementations, generate tests, inspect logs, and compare approaches.

That gives developers a reason to spend less time on repetitive typing.

But generating code quickly does not establish that the requirement was understood or that the system is ready for production.

An order API can compile, return the expected response, and still leave important questions unanswered:

• What happens when a payment callback arrives twice?
• Can a timeout job cancel an order while payment is being confirmed?
• Are records isolated correctly between customers or tenants?
• Can a retry decrement inventory more than once?
• Will the previous application version still work after a database migration?

These questions do not resolve themselves as the codebase grows.

The useful measure of AI productivity is therefore broader than files generated or lines written:

How much time does it take to move from a understood requirement to a stable release, including review, rework, and incident handling?

If generating an implementation takes thirty minutes but understanding and repairing it takes two days, the typing became faster. Delivery may not have.

Turn Ambiguous Requests into Explicit Rules

“Build an order cancellation endpoint” sounds like a clear task.

It leaves almost every important business decision open.

Which order states permit cancellation? What happens after payment? Should a coupon be restored? When should inventory be released? What happens if the request is repeated?

When these details are missing, an AI assistant has to make assumptions.

A developer adds value by turning the request into rules that can be checked:

• Only unpaid orders are eligible for timeout cancellation.
• A normal timeout process cannot move a paid order back to an unpaid state.
• Repeated delivery of the same business event must not repeat a financial or inventory effect.
• State changes must leave an auditable record.
• Disagreement between an external payment result and local state requires a reconciliation path.

These are business invariants: conditions that should remain true despite concurrency, retries, and partial failures.

AI can help find contradictions or missing cases. But the rules still need a reliable connection to the actual business—contracts, product decisions, financial definitions, historical incidents, and user behavior.

Business understanding becomes valuable when it produces constraints that other people and systems can apply.

Knowing where a feature lives in the repository is useful. Knowing what must never go wrong is more useful.

Learn to Explain Runtime Behavior

Technical fundamentals still matter. Their purpose extends beyond recalling definitions in an interview.

Thread pools, transaction boundaries, indexes, caching, and memory management help developers form hypotheses and interpret evidence.

Consider this Java code:

List<Order> orders = orderRepository.findAll();

return orders.stream().map(order -> {
    OrderVO vo = new OrderVO();
    vo.setUserName(order.getUser().getName());
    return vo;
}).toList();

If associated users have not already been loaded and are not fetched through caching or batching, accessing each user can trigger additional queries. This is a familiar route to an N+1 query problem. Hibernate documents fetching strategies and their performance implications. Hibernate performance documentation

However, it would be incorrect to conclude that processing a thousand orders necessarily occupies a thousand database connections simultaneously.

The actual behavior depends on association reuse, fetching configuration, caching, transaction scope, and concurrent requests. A request may execute many queries sequentially through the same connection.

A developer should investigate:

• Why does the endpoint use an unbounded findAll()?
• How many SQL statements does one request actually execute?
• Does the response need full entities or only selected fields?
• Would pagination, a DTO projection, batch fetching, or an explicit fetch strategy fit the requirement?
• Would the proposed change affect pagination or duplicate result rows?

The same discipline applies elsewhere. A saturated thread pool does not automatically need more threads. The presence of synchronized does not establish a deadlock.

Lock contention, deadlocks, connection waits, and long garbage collection pauses require different evidence.

Fundamentals help you decide what to examine next. They should not encourage confident diagnosis without measurement.

Build an Independent Way to Verify Results

AI can generate both an implementation and its tests. That is useful, but it creates a subtle risk.

If both are based on the same misunderstanding, passing tests can simply confirm that the misunderstanding is consistent.

Suppose an assistant assumes that every order can be cancelled. It may implement that behavior and generate tests confirming that cancellation succeeds. Coverage can look impressive while the business rule remains wrong.

Expected results should therefore come from an independently established contract.

For an order state transition, verification might include:

• Duplicate callback delivery.
• Concurrent updates to the same order.
• Retries after a partial failure.
• External success followed by a local transaction failure.
• Unauthorized or cross-tenant access.
• Historical records that violate current assumptions.

AI can expand the list, but it should not be the sole authority on what “correct” means.

Likewise, a message saying “fixed and all tests passed” is not sufficient evidence. Reviewers need access to the actual changes, the checks that ran, their results, and the conditions that remain untested.

A second model can provide another review perspective. It is still possible for two models to accept the same incorrect premise.

Reliable delivery requires evidence beyond the generated explanation.

Turn Experience into Reusable Engineering Assets

Being the only person who can rescue a system may feel like job security. It can also indicate that the system depends too heavily on one individual.

A stronger contribution is to make recurring failures less likely.

After finding an N+1 issue, add a representative data test or a query-count check where appropriate.

After diagnosing an invalid state transition, add concurrency regression tests and explicit transition constraints.

After discovering an authorization gap, examine similar endpoints and automate checks around tenant boundaries.

After a failed recovery attempt, improve the backup process and perform a restoration exercise.

These improvements also give AI tools better context:

• Business rules and counterexamples.
• Architecture decisions and their rationale.
• Reproducible failure cases.
• Executable tests.
• Release and recovery procedures.

That context needs maintenance. A document that contradicts the current system can mislead a person or an AI assistant.

The lasting value of experience comes partly from converting it into mechanisms that improve future decisions.

Use AI Across the Development Process

Treating AI only as autocomplete leaves much of its usefulness unexplored.

A more deliberate workflow uses it at several stages while keeping responsibility clear.

Stage	Useful AI assistance	Judgment the developer must retain
Requirements	Identify ambiguity and suggest edge cases	Which rules reflect the actual business
Code exploration	Trace calls and explain relevant modules	Whether explanations are supported by the code
Design	Compare approaches and estimate change scope	Compatibility, trade-offs, and failure boundaries
Implementation	Produce focused changes	Whether the changes stay within the intended scope
Verification	Generate cases and analyze results	Whether expectations and evidence are valid
Operations	Draft release steps and assist diagnosis	Authorization, rollout, and recovery decisions

A useful task description explains more than the desired feature. It should establish the constraints and the evidence needed to judge success.

For example:

Optimize data access in the order listing endpoint while preserving its response fields and authorization rules. First inspect the query path and identify where additional queries may occur. Propose the smallest suitable change. Verify normal pagination, repeated user associations, empty results, and cross-tenant access. Report which checks actually ran and their results.

This does not guarantee a correct implementation. It reduces the number of important assumptions the assistant must invent and makes the result easier to review.

Focused, reversible tasks can support greater autonomy. Changes involving payments, authorization, data migration, or production infrastructure need stronger verification and authorization.

The appropriate boundary depends on the consequences of failure.

Enforce Permissions Outside the Prompt

“Do not delete production data” is a useful instruction. It is not an access-control mechanism.

If a development tool can read production credentials, possesses destructive permissions, and can call infrastructure APIs directly, an incorrect decision can still become an incident.

Teams should establish boundaries outside the model’s interpretation:

• Separate development and production credentials.
• Grant only the access needed for the task.
• Route high-impact changes through controlled release processes.
• Keep recovery copies outside the same destructive access scope.
• Verify restoration through exercises rather than assuming a backup is sufficient.

Dry runs, prompts, and model self-checks can help. They do not provide the same protection as an enforced permission boundary.

This does not mean requiring a lengthy approval process for every small edit. Controls should match the risk: routine work should remain easy, while high-impact actions should have deliberate safeguards.

Do Not Let Faster Delivery Replace Learning

For newcomers, AI can make unfamiliar work accessible. It can also make it easy to skip understanding.

For experienced developers, accumulated knowledge can guide review. It can also turn yesterday’s successful approach into an unquestioned habit.

Both groups need to preserve a learning loop.

After an important change, ask:

1. Can I explain the relevant call path and state changes without repeating the AI’s explanation?
2. Can I construct an input or execution sequence that exposes a weakness?
3. Can I explain why this approach was chosen over an alternative?
4. If it fails, do I know which evidence to collect first?

If the answers are unclear, the task may be complete while the learning remains unfinished.

A practical starting point is a small feature in a system you understand. Let AI implement it while you own the requirements, review, verification, and retrospective.

Track the generation time, but also track review time, rework, and missed requirements.

Then take a previously encountered defect, build a sanitized reproduction, and use AI to help investigate. Compare its hypotheses with the evidence. Convert the useful findings into a test or a troubleshooting note.

This produces something more durable than a collection of prompts: a repeatable way to work and learn.

A Career Moat Is Not a Guarantee Against Change

No skill combination can guarantee that a role will remain unchanged. Better tools, organizational decisions, and shifting business needs all affect employment.

It is therefore unwise to base a career strategy on the claim that AI will never understand business or never solve difficult engineering problems.

A more adaptable strategy is to keep expanding the range of problems you can own reliably:

From implementing a function to clarifying a requirement.

From delivering an endpoint to understanding an entire business workflow.

From fixing an incident to reducing the likelihood and impact of its recurrence.

David, from the opening scenario, does not need to prove that he can type faster than Alex or an AI assistant.

He can work with Alex to turn faster implementation into reliable delivery—and turn experience into rules, tests, and tools that others can use.

Use AI to do more work. Build the judgment to decide what should be done, why it matters, and what evidence makes the result trustworthy.

Related reading: Spring AI tool calling in Java | Small Java code choices that create unnecessary work