AI for development: a guide from task to delivery
Choose models, tools and permissions around real tasks. Evaluate code, cost, context and releases while keeping the project under control.
A team does not need to begin AI adoption with the highest-scoring model of the week. It needs a task, a definition of a good result and a decision about access. Without those, a quick demonstration can become review work that is difficult to measure.
This guide organizes decisions for people building software or commissioning it. The examples are proposed uses, not reports of results achieved by Inkdesign.
Understand the choice
The model produces responses from supplied context. The product or tool defines the user experience. An agent combines generation, decisions and tools to execute steps. Anthropic’s architecture guide distinguishes predefined workflows from agents that decide how to proceed. Choose the complexity the task requires.
Explaining a function may need read-only code access. Fixing it requires edits and tests. A release introduces credentials and external effects. These tasks do not need identical permissions.
Start with a problem you can verify
A reproducible failure in a known route makes a useful pilot. Supply current behavior, expected behavior, relevant files and a test case. Ask for evidence before a proposed change. Avoid starting with “improve the entire system,” because evaluation remains too open-ended.
Record a baseline from the current process: execution, review and correction time. Compare assisted work under the same conditions. Count discarded attempts and human interventions; generation time alone hides a substantial part of the cost.
Build context without handing over everything
Include data contracts, project conventions, related code and relevant tests. Remove credentials and unnecessary information. If the model needs a service, prefer access limited to the pilot’s purpose.
A large context window allows more material, but the team still determines what is current and reliable. Read about long context to assess the need and AI product architecture to organize the integration.
Evaluate delivered work, not just an answer
Check whether the change fixes the problem, preserves permissions and includes tests that distinguish the original error. Read the code and observe the browser flow when there is an interface. GitHub’s responsible-use guidance recommends reviewing and testing generated code. A second AI answer does not replace verification.
For candidate selection, use model evaluation and choosing a model for SaaS. Kimi K3 is one example whose documentation should be compared with the actual task, without assuming a universal winner.
Separate changes, authorization and release
Use an isolated copy or branch, keep changes reviewable and identify who can approve external effects. Define execution limits, stop conditions and recovery of the previous state. Sending messages, changing permissions or applying migrations must fall within an explicit scope.
The NIST AI RMF provides a reference for organizing AI risk management. Translate that into owners, checks and records the project team can use.
Choose the next reading by decision
- For everyday delivery: AI from briefing to release.
- For agent boundaries: automation and governance.
- For a team pilot: the adoption checklist.
At the end of the pilot, retain what helped the team finish and review the work. Expand by verified task, preserving a comparison method when the model, tool or process changes.
About the author
Tiago F SantiagoComments
No comments yet
Share a question or an experience related to the article.
Related articles
