AI in development: where it helps and where it creates new risk

An evening can produce more code than a week used to. The next morning, a retried request charges the customer twice. Productivity has increased — at generating problems, at least.

I use AI extensively for development and analysis. My target is a working product that I can verify, deploy and maintain. That makes the full delivery cycle more interesting than the speed of the first answer.

Sources and tariffs checked on 19 October 2026. The article’s original date is 15 March. This revision includes working experience, pilot candidates and a selection procedure. Confirmed prices below are an official API-rate snapshot for the check date, not a reconstruction of prices at first publication. The comparison is not an independent benchmark I have run.

Recent practice: rebuilding a familiar kind of service

Some fellow technology leaders and I have been experimenting with implementing the behaviour of a familiar class of service in a few days. We write our own specification and use public or synthetic data. Company source code, internal documentation and confidential architecture do not enter these experiments.

With domain knowledge, a clear design and an understanding of failures, load and integration, a small service or bounded module can reach a useful working state in a short cycle. Reproducing one scenario and delivering a mature platform remain very different jobs. I do not promise the same timeline for every product.

My current conclusion: AI can perform a substantial part of implementation when the engineer can define the expected result. “Build something like that famous service” is weak input. “Accept a request once, handle retries, expose its status and recover after a crash” gives us something testable.

Since December 2025, my corporate role has involved a portfolio and engineering cluster for personalised banking offers. Corporate AI use follows internal rules. The external tools discussed here belong to my personal projects and permitted experiments. Professional experience improves my questions; it does not authorise exporting company data.

Model, agent and delivery process

The model reasons and generates. The agent environment supplies files, tools, a terminal, history and permissions. The delivery process decides how an implementation is checked and released.

Codex is an agent environment using a selected model. Claude is a model family; Claude Code is a coding tool. Comparing their names without identifying the model and environment hides important differences.

The same model can behave differently with different tools, context and permissions. Switching models is easy. Recovering data after a failed migration is rather harder. Start with the process.

Delivery loop, including rework

01Human framesOutcome, data, constraints

02Agent buildsCode, tests, explanation

03Checks challengeContracts, failures, review

04Owner acceptsRelease, observe, roll back

What to delegate to AI and how to accept the work

Task	Useful delegation	Acceptance evidence
Small internal service	Contract and one complete scenario	Errors, retries, permissions, observability and recovery
Existing repository	Reproduce a defect and make a bounded change	Original failure now fixed; regressions checked; understandable diff
Analysis	Compare sources, form hypotheses, draft SQL	Data provenance, assumptions and verified calculations
Migration	Plan, script and invariant checks	Rehearsal, compatibility, locking behaviour and rollback
Tests	Boundary cases and observable scenarios	The test detects a known fault instead of repeating the implementation
Architecture	Alternatives and failure consequences	Load, boundaries, operating cost and the cost of a mistake
Documentation	Explain confirmed behaviour	Claims grounded in code and sources

An agent can produce both an incorrect function and a convincing test of the same mistake. Acceptance needs an independent reference: a contract, invariant, control example or known defect. For architecture, I ask the model to expose assumptions and challenge alternatives. A person accountable for the system makes the decision.

Models worth evaluating now

I have worked with Astra and other models through Codex, as well as Claude, Grok, GLM, Kimi, Qwen, Alice and GigaChat. These were different tasks and versions. That experience does not support a universal numerical ranking.

The table lists pilot candidates. Prices are USD per million input / output tokens for ordinary API use, excluding cache discounts, batch processing, tools and taxes. Reasoning tokens may add to billed output. Long-context pricing can differ. App subscriptions have their own limits and are not API tariffs.

Model	Input / output, USD	My starting hypothesis for a pilot
OpenAI GPT-6 Astra	10 / 50	Difficult investigation, architecture and long multi-tool tasks
OpenAI GPT-6.1 Sol	2 / 10	Everyday engineering with a quality/cost balance
OpenAI GPT-6 Luna	0.10 / 0.50	Bounded transformations and volume work with inexpensive validation
Claude Fable 5.1 / Opus 5.5 / Sonnet 5.5	10 / 50; 4 / 20; 2 / 10	Compare difficult reasoning, sustained coding and routine work on the same tasks
Grok 4.7	2 / 6	An alternative for analysis and coding; verify tool behaviour and latency
GLM-5.3 / GLM-5.3-Flash	1.40 / 4.40; 0.15 / 0.50	Compare a primary model with inexpensive bounded work
Kimi K3 / K2.7 Code	Check the selected model’s tariff	Evaluate coding and long-context tasks
Qwen3.8-27B	Infrastructure or hosting cost	Available weights when deployment control matters

For Kimi, I link to the tariff without quoting a numerical snapshot. Its API charges cache writes separately by TTL. OpenAI figures use Standard short-context rates; the pricing page separately covers long context, cache writes and service tiers. Astra applies higher rates to the full request above 272,000 input tokens. Grok 4.7 applies higher pricing above 200,000 context tokens. Check the endpoint, region and tier before budgeting a pilot. A large context window does not make repeatedly sending the entire repository free.

Alice AI and GigaChat merit a separate evaluation when Russian-language tasks, existing tools and purchasing conditions matter. I like Alice, but it has not become my daily tool for intensive coding and analysis. That describes my workload, not an objective verdict on the model. Yandex offers Alice AI LLM Flash. Check GigaChat’s terms and tariffs for the relevant customer type and access method; an older price list may not apply.

A provider’s country is not a substitute for assessing quality, contracts and data handling. Less expensive alternatives deserve testing. Claims that “everyone has switched” need evidence I do not have.

Five decisions before choosing

1. May this service receive the data? If not, exclude it before discussing intelligence or price. Consider an approved internal service or self-hosting.
2. How will I verify the result? A strict transformation may need a validator. Architecture needs expert review. Weak verification increases risk.
3. How difficult is the task? Start complex investigation with a strong model. Test cheaper candidates for repetitive bounded operations.
4. Does the integration support the work? Check tools, structured output, images and filesystem access. A good chat answer does not prove agent suitability.
5. What does an accepted task cost? Include retries, human review, corrections, waiting and defects.

One possible arrangement uses a strong model to clarify a plan, a general model to implement bounded tasks and a cheaper one for bulk operations. This is a hypothesis. If handoffs consume the savings, one reliable executor beats a subscription collection.

Tokens are only part of the bill

API cost = input tokens × input rate
         + output tokens × output rate
         + paid tools and infrastructure

Divide token counts by one million when using the table’s rates; account for caching separately.

Illustrative arithmetic: 100,000 input and 20,000 output tokens, no cache or tools, within ordinary pricing thresholds. Astra costs $2, Sol $0.40, Grok $0.32, GLM-5.3 $0.228 and Luna $0.02. These figures do not buy demonstrably equivalent results. Each model may use different token counts, require more attempts or fail altogether.

Five retries and an hour of review can erase a cheap model’s advantage. Using the strongest model to rename fields can waste money in the other direction. I care about the cost of accepted work.

Self-hosting and quantisation

Self-hosting requires available weights and a suitable licence. An API account does not grant either. Not all Chinese models are open, and closed OpenAI or Anthropic models cannot simply be downloaded onto a GPU.

Quantisation reduces weight precision and memory use. At four bits, 27 billion parameters amount to roughly 13.5 GB for weights alone. This is not a GPU requirement: runtime overhead, metadata and the KV cache need more memory. Context length and concurrent requests matter. Evaluate the particular quantised build on your tasks.

The Qwen3.8-27B card specifies Apache 2.0. Check the selected derivative and its components too. A deployment plan should cover:

• the choice of model and a review of its licence;
• quality, latency and memory at the required context length;
• concurrency and hardware cost;
• authentication, updates, monitoring and recovery;
• outbound tools, external search, telemetry and logs.

Local weights do not make an entire agent workflow local. A remote tool can still transmit information. For a small team, an approved API is often simpler. Infrastructure ownership should answer a real data, workload or control requirement.

Buying a server just to put “sovereign” on a slide is an expensive way to decorate a presentation.

A comparison that can support a decision

I would select 10–20 representative tasks: a defect, a small feature, a dependency investigation, SQL and testing. This is a proposed protocol, not a completed benchmark of every model above.

Freeze inputs and acceptance criteria; specify time and cost limits. Record exact model versions, settings, agent environment and date. Give each candidate comparable context. Have a reviewer assess results without model names where practical.

Measure	What it reveals
Independently accepted tasks	Working results rather than plausible answers
Time through acceptance	Preparation, review and corrections as well as generation
All-attempt cost	Retries and context growth
Error type and severity	Cosmetic issues versus data loss
Behaviour with missing information	Clarification versus invented assumptions
Repeated runs on a subset	Stability rather than a lucky success

Select by task class instead of crowning a universal winner. A useful historical warning is METR’s July 2025 study: experienced open-source developers in that setting took 19% longer with early-2025 AI tools. That study involved 16 developers and 246 issues in particular repositories, not all developers or October 2026 models. In its 24 February 2026 update, METR reports indications of greater speedup but says participant and task selection prevent a reliable estimate of its magnitude. Both accounts support measuring the actual workflow rather than transferring a percentage into a budget.

From assistance to autonomous delivery

In LAF, I connect task definition, a queue, isolated execution and checks. I have tested workflows with Claude, Codex, Grok, GLM and Kimi. I want reviewable changes while I work on other decisions.

That requires access boundaries, budgets, stopping conditions, saved context and an explicit release decision. An agent repeatedly fixing its own test all night is busy. It is not necessarily useful.

Start with one complete scenario, written acceptance criteria and two suitable candidates. Measure the cycle and decide what to expand. For an AI pilot, architecture review or LAF adoption, bring me your task. A working path from request to accepted result is more useful than a debate about favourite logos.

Yours, DPUPP