Agentic software development means building software with AI agents that write, change and test code, while engineers direct the agents and review what they produce. For a buyer, that means the code itself is now cheap to produce, so the value of a firm sits in how well it understands your business and how carefully it checks the work.
Most developers now use AI tools. In Stack Overflow's 2025 Developer Survey, 84 percent of respondents said they use or plan to use them in their development work. So a firm saying it builds with AI cannot tell you which one to hire, and you need questions that can.
The Gnar Company builds custom software this way, with senior U.S. engineers and a price fixed before work starts. Below are the questions to ask any firm, with Gnar's own answers where it has published them.
What is agentic software development?#
Agentic software development is a way of building software in which AI agents do much of the writing, changing and testing of code, and engineers direct them and decide what ships.
It is easy to confuse with building AI agents. That is a different service, in which the agent itself is the product, for example an agent that reads emailed orders for your staff. A firm can be good at one and new to the other, so ask which one it is selling.
For the tools and the engineering side, see Gnar's guide for technical leaders.
If AI writes the code, what am I paying a firm for?#
You are paying for the parts AI does not do for you: understanding how your operation runs, deciding what to build, checking every change, and standing behind the result. Gnar puts it this way: "Producing code is close to free now. Understanding your operation is not."
The same point comes up when buyers compare a U.S. firm with an offshore team. Gnar's answer: "The reason to go offshore was cheap code production, and code production is nearly free now. What you are paying the premium for is the communication, and that is the part that decides whether the thing you get is the thing you asked for."
So ask each firm where its people spend their time. Look for answers about talking to your team, mapping your workflows and reviewing changes, along with the tools they use.
Should building with AI make the project cheaper?#
Not necessarily, so judge each firm on a price in writing, fixed before work starts. A firm that builds with AI should be able to say what the build costs before you commit.
AI output also needs work after it is written. In the same Stack Overflow survey, the most common frustration, cited by 66 percent of developers, was "AI solutions that are almost right, but not quite," and 45 percent said debugging AI-generated code is more time-consuming. Someone has to find and fix the almost-right parts, and that time belongs in the price.
At Gnar, builds are priced by milestone, and the price is fixed before work starts. The first step is Gnar Discovery and Design, published at $15,000, $20,000 or $30,000 for two, four or six weeks. It maps the problem, the workflows and the architecture, and ends with a milestone plan with a fixed price you can take to your CFO. The builds these plans scope are typically $150K to $300K+.
Who checks the code an AI agent writes?#
A named engineer should review every change before it ships, and automated tests should check that the software still works after each change. Ask the firm to show you both: the review step and the tests.
Developers themselves are cautious about AI output. In Stack Overflow's 2025 survey, more developers said they distrust the accuracy of AI tools (46 percent) than trust it (33 percent), and only 3 percent said they highly trust it.
At Gnar, the rule is that no code ships without human eyes on it. AI-generated code gets reviewed at each step of a build plan. On Gnar's code migration work, new code comes with automated tests, small programs that check it still works, and a second engineer reviews it too.
If you already have software that an AI tool built, the same checks apply. Gnar's work on hardening AI prototypes adds the security, testing and monitoring that demo-grade code lacks.
Who owns the code, and who fixes it when it breaks?#
You should own the code, it should sit in your own repository, and the firm should be on the hook in writing to fix what does not work as agreed. Ask for all three in the contract, whoever or whatever wrote the code.
On a Gnar build engagement, the codebase is yours, in your repository, documented for hand-off. The twelve-month bug-free warranty on build engagements obligates Gnar to fix non-conforming code, independent of any ongoing contract.
The guarantee on Gnar builds reads: "Three commitments on every build engagement: a fixed milestone price with any overage on us, a guaranteed outcome meaning the software works as specified or we fix it, and a twelve-month bug-free warranty. It covers Discovery, Build, Forge and Maintain. It does not cover Embed. On Compass, Immerse and Integrate, ask us."
How do you tell whether a firm really builds this way?#
A firm that really builds this way can show you one change going from request to release, with the review and the tests, and can name software it built this way that is running today. Ask each firm the same questions in the table below, in your first two calls.
| Question to ask | What a good answer includes |
|---|---|
| Can you show me one change going from request to release? | A real example, with the review and the tests shown |
| What do the agents do, and what do your engineers do? | Named people who decide what to build and approve each change |
| What did you build this way that is running today? | Named clients and software in daily use |
| How is the price set? | A price fixed before work starts, by milestone |
| Who owns the code when we leave? | Your repository, with documentation your team can follow |
| Who will build it? | The same people you met in the sales process |
The last question matters because a team can pitch with senior people and staff the build with others. Gnar's line on it: the people who pitched are the people who ship.
Judge the firm's review, testing and planning habits, since Google's DORA 2025 report on AI-assisted software development found that AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses.
What should a firm learn about your business before writing code?#
Before any code, a firm should learn how your people do the work today, which systems they use, and where the work breaks down. Ask how the firm will find that out, and who it will talk to.
Gnar's custom software page says Discovery maps the problem, the workflows and the architecture before quoting. On one project, for a U.S. insulation distributor, the work started with a diagnosis, described on Gnar's order management page. Gnar interviewed people across the distributor's branches before building one system for orders and deliveries.
Listen to the questions the firm asks you on the first call. If they are only about deadlines, ask how the firm will learn how your operation runs.
When should you not hire a firm at all?#
Do not hire an outside firm when your own engineers have the capacity and the direction to do the work. Do it internally. An outside firm makes sense when your engineers have no time for the project, or no clear direction for it.
Gnar's answer to "we have people for this" is the same: "Often you should use them. If your own engineers have the capacity and the direction, do it internally and we will say so on the call."
If your engineers are already using AI agents and want a shared way of working, Gnar's post on Context-Driven Development describes the method Gnar uses.
