David C. Young, Author

By David Young.

September, 2025.

Those of you familiar with my blog and LinkedIn posts know that I have a healthy dose of skepticism about everything, and about AI aided software development in specific. This is for a number of reasons.

• I’m picky about software development processes, testing, and adherence to project standards. On a big project, I recommend having new developers engage in some pair programming with exiting developers who do good work, before letting those new developers loose on the code base unsupervised.
• Software is very unforgiving. A single wrong character can create a bug that is painful to track down.
• There has been a lot of over-exaggerated hype about using artificial intelligence (AI) for writing software.

There has also been a lot of work and money invested in making those AI programming tools better. As such, here is an update on that topic, as seen from my skeptical view point.

You heard that artificial intelligence (AI) could be used to write software. You immediately think of asking it to write a massive program that would take you years to write. Or have it do the part you don’t understand how to do. Or have it invent some new type of software. These are probably the worst ways to use AI in software development. These might be tasks for an AI a hundred years from now, but not for today’s AI technology. However, there are ways that the current generation of AI models and products can help with software development.

Don’t expect artificial intelligence (AI) to replace human programmers. AI can be a useful productivity tool to help human programmers get more done more quickly. The human programmers are going to have to put time into learning and experimenting with AI tools to find out when and how to use them effectively before you see that productivity. Articles like this one can give the programmers some guidance, but the programmer will still have to experiment with what works best for the specific tasks they are working on, and the AI they selected.

Much of this article’s author’s experience is with scientific software development, so many of these tips are useful within that context.

For writing code, reasoning models (also called logic models) are step better than their large language model (LLM) predecessors, but still far from perfect. Reasoning models do better than LLMs at analyzing the code for potential bugs or security vulnerabilities. That said, simpler tasks can be done well with smaller, cheaper models.

Check whether a given programming tool can auto-choose a model parameterized for coding, or will let you choose one of those models. When this article was written in September 2025, some of the better options were O1, R1, and Claude Opus. Also test large language models that have a large percentage of programming code in their training set, such as GPT-3, GPT-4, and Grok. Some programmers like Claude 3.5 Sonnet, because it doesn’t over-engineer the code. Some AI software development products have used fine tuning or RAG tecniques to make smaller models work well for certain software development tasks. A good discussion of selecting AI models for coding is at https://frontendmasters.com/blog/choosing-the-right-model-in-cursor/

Some people like the flexibility of using general purpose AI tools like Perplexity, Claude, or ChatGPT for software development. Other people like using AI applications specifically designed for software development, such as Claude Code, Github Copilot, Cursor, Aider, Tabnine, AskCodi, or Replit AI. The software development AI products have some features that are useful for programming, but they also are designed to be used with certain workflows, project organization, source code repositories, types of software, etc. Sometimes the marketing department refers to these as pair programming tools, but using them does not duplicate the classic pair programming driver-navigator relationship. Think of them more as a very literal minded intern on their first day of work.

The capabilities of dedicated AI programming tools are still changing rapidly. Here are some notes based on some of the products that were popular or had notable features when this article was written in September 2025. These are far from comprehensive. They are just some items that struck us as significant.

GitHub Copilot

• As one of the first AI coding tools released, GitHub Copilot had an early lead in market share, but has lost users as competing products were released, and users of the product became disillusioned from unrealistic expectations.
• Integrates with VIM, neovim, and a number of popular IDEs
• Versatile enough to support multiple programming languages and frameworks
• Designed to be used with GitHub
• Can generate documentation
• Can generate code
• Works with a number of AI models

Claude code

• Runs in a terminal
• Made for access to the whole project
• Made to work with Git
• It can help manage code base, and update style
• Considered the best for codebase wide help

Aider

• Open source tool that runs in a terminal
• Uses ChatGPT, o1, Claude variations, deepseek variations like r1, Gemini, and more through OpenRouter
• ONLY works with a git repository
• Can do code reviews
• Sets up a typical project template, files, etc.

Cursor

• Autocomplete for writing code (usually a line at a time)
• Auto chooses the best AI model for a given task
• Accepts natural language prompts
• Based on VS Code
• Can use VS Code extensions (i.e. vim, or a Remote – SSH extension)
• Lets you approve code sections one-by-one
• Open a new chat for each new feature, so it doesn’t get confused.
• Context tagging. Use @Name to search documentation, including @web to search web
• Can modify all requests based on cursor rules or an AGENTS.md file
• Points out potential bugs
• Full codebase awareness for a given project (directory tree)
• A very rich set of configuration settings
• Designed for use with git repositories, but can work without it.

Mentat

• Runs in a terminal
• GitHub integration
• Open source
• Locally executed for privacy
• An agent page shows what it did
• Paid based on each action
• Assumes an open source development model

SonarQube

• Focused on scanning code for bugs, vulnerabilities, quality issues
• Suggests bug fixes
• Used with other AI code generation tools, to fix bugs they create
• Cloud based

tmux AI

• Good for shell programming

Amazon Q Developer

• Designed for end-to-end software development
• Focused on AWS workflows
• Works with many popular IDEs

Windsurf

• Monitors code, command history, clipboard, and browsing.
• Can act as an agent (writing code) or copilot (making suggestions)
• Can execute shell commands in the integrated terminal
• Image to code for making a UI from mock ups.
• GitHub integration
• You can tell it to ignore some of the code

Tabnine

• Code completion for lines or functions.
• Supports over 30 languages
• Integration into popular IDEs
• Trained on open source code only
• Cloud or full off-line on premise deployment
• Multiple AI models including bring your own
• Customization options
• Automated code review
• Image to code
• License provenance checks

Replit AI

• Multiple products for coding (agent), design, database, security, mobile, and more are bundled into one subscription.
• Known for coding, debugging suggestions, and understanding code
• Real time collaboration, and pair programming support
• They offer integrated hosting and database management services
• It has versioning and rollback features
• Replit runs in a browser

Qodo

• Works in terminal or several IDEs
• Use for generating code, fixing bugs, code review, and testing
• Popular for its code review and testing features
• Customizable workflow and agent scripting
• Scans the repo to automatically learn the project coding standards
• SOC 2 Type II support
• Has a list of one-command features accessed with a forward slash

OpenAI Codex

• Natural language code generation works particularly well for Python, JavaScript, and Ruby.
• Context-aware autocompletion and logic suggestions
• Writes complete features from specifications, fixes bugs, refactors code
• Generates documentation
• Manages tests
• Runs in secure, isolated cloud sandboxes
• Works in IDEs including VS Code and Cursor
• Works with GitHub
• You can put your coding standards in an md file
• Can generate deployment scripts

Grok Code Fast

• High speed code generation
• Some people claim it is the best for agentic coding tasks such as multi-step development, debugging, bug fixing, scaffolding, and project refactoring.
• Uses the Grok AI model from xAI
• Strong proficiency in TypeScript, Python, Java, Rust, C++, and Go.
• Compatible with IDEs and platforms like GitHub Copilot, Cursor, Cline, and others.
• Generates visible reasoning traces
• Low cost per token use
• Although highly effective for most development tasks, it may under perform on edge cases or specialized frameworks (e.g., Tailwind CSS), making it best suited for routine, real-world coding and agentic automation.
  More AI centric programming tools are being released almost daily.

When choosing an AI tool, be critical in making your own judgements about them. The one that has gotten the most press or advertising recently may not be the best one for your needs.

Consider the needs of the type of software you are creating. Science and engineering software require a great depth of domain knowledge. Security software requires some heavy testing tools. Games, websites, and Linux kernel modules are all very different. Consider which AI option is expected to be best for your software, or which is used by other people making that type of software. I use Perplexity for discussions of algorithms for scientific software, because it can search for domain-specific information. I use Cursor for working on the code base.

Once you choose an AI product, test it. If you want to use it to start new projects, start some similar ones. If you want to use it to help with an existing project, make an instance of a similar open source project and try some of those tasks. Get comfortable with using the tool in that test environment before letting it modify the project you have already put years of work into.

Many of suggestions in this article are based on using Perplexity and Cursor.

• Perplexity searches the web for information then auto-chooses an AI model best suited for the task. This allows Perplexity to base its answer on the most current information available, and on information very specific to a given field.
• Cursor was selected based on a review of features and online discussion as a good choice for scientific software development. Cursor also has a good feature to auto-choose the best AI model. One of our projects has some one-off style guides that don’t completely match what is found in open source software, so the cursor rules function and AGENTS.md file are places where we can teach the tool those rules.

Some tips for using Perplexity for scientific software coding help.

• Pay for the Pro subscription.
• Select Research mode.
• Set sources to both Web and Academic.

Some tips for using Cursor.

• Pay for the Pro subscription at the least.
• Have your project in a version control system, and make frequent tests and commits.
• Cursor Rules and the AGENTS.md file are powerful tools. Learn to use them.
• Specify files to act on clearly, such as “Do X to all files with names ending in .cpp”
• If you don’t like some aspect of its behavior, there is often a configuration setting to change it.

If you are analyzing code that someone else wrote, attach or paste the file into the AI, then ask it to generate a call graph. Ask it other questions about the code. Cursor was able to look at the whole project directory tree and did a surprisingly good job at generating a user manual and programmers guide.

If you ask the AI about some high level method (i.e. configuration interaction in quantum chemistry software), it will give a general knowledge answer. If you ask it about a specific step in that method, it will give a more specific answer. As such, use the AI for general knowledge questions about high level methods, and ask it for more code-specific help about individual steps within that process.

Realize that code specific help from an AI may give an answer based on a different internal architecture, data structures, etc. from what you are using. If there are open source codes using the same architecture that you are using, you may be able to give the AI that information to get a more relevant output. Using an AI tool designed to look at your code base usually does better on this score than using a general purpose AI tool.

Asking an AI to generate pseudocode from a specific source code file will be only as good as the comments and variable/function naming in that file. A better option is letting the AI use it’s internal capabilities to respond to a two step prompt. For scientific work, the first of these prompts often gives a mathematical description.

1. Describe the algorithm for the X step in the Y method.
2. Express the Y step in terms of a computer algorithm.

These seem to be asking the same thing, but the first one is more likely to give what we show students first (the mathematics), and the second one may prod it to answer in computer code terms instead.

Asking for an “algorithm” may give more readable results than asking for pseudocode or C++, Python, etc. This seems to give the AI more flexibility to give a readable answer, instead of following some established format.

One use of AI in software development is as a learning tool. If you don’t remember the syntax for a particular feature of the language, ask the AI. If you are looking at someone else’s obtuse syntax and don’t understand what it is doing, ask the AI. If you need a third party library, ask the AI which are available, which are most popular, and the pros and cons of each.

Use the AI as a smart search function. Here is an example prompt. “Tell me which lines of which source code files are where the X data structure is set to non-zero values.”

If you have a documented process for something, tell the AI to follow those directions. Add words like “following the directions in the file programming_guide.md”. This type of project knowledge is a good thing to put in a project-wide configuration file like cursor rules or AGENTS.md file.

AIs do better with clearly defined, logical rules. If you are giving it a configuration file of variable naming conventions, indentation rules, etc. ask the AI to examine that file and tell you if any of the rules appear to be inconsistent or confusing. Information that seemed clear to you may still be confusing to the AI and thus best stated even more clearly. Only give it rules specific to the programming language being used. Try to fix the worst of these then rerun the AI consistency check. It may always give some picky little comment, even when your file addresses that exact item.

Give the AI scope, but realize it is a suggestion not a hard constraint. I created an AGENTS.md file to give the AI a new set of variable naming conventions for the project. When I asked the AI to update local variable names in one specific function, it also updated variable names in the main program.

Monitor the AI to learn how long it takes to perform certain tasks. If it is spending much longer than usual, that section of code is probably too complex for that AI. Killing it will save on both time and money. If you rerun the same prompt, specify a larger AI model.

Use the AI to translate between programming languages, then test.

Asking the AI if a section of code can be refactored for better performance, readability, or maintainability sometimes works. Sometimes letting the AI make that change works. Sometimes the process leads to a new set of bugs to be fixed, so test it carefully.

You can ask the AI to generate documentation or in line comments. This works best when you have very well named functions and variables. It can work well for generating API documentation that lists the functions and their arguments. It will be less reliable at annotating limitations on those arguments (i.e. must be greater than zero). Expect it to do poorly at explaining the underlying theory, and unable to discuss architectural decisions. Leave writing theory manuals and design decisions made by humans up to humans. Read over what the AI generates and update any wording you don’t agree with while you are working on that section of code. Here are a couple sample prompts for an AI coding tool that can see the entire project directory tree.

• Write a user manual for this program. The program takes input from a file piped to stdin. There are examples of these files in the examples directory. Include a sample input and all input flags. Use both the examples directory and any code that takes input from stdin. Format the user manual in md format. Save it to a file named user_manual.md in the top level directory of the project.
• Write a programmers guide for this project. Realize that some developers are computer science experts with limited domain knowledge, while other developers are domain experts with modest computer science skills. Format it in md format. Save it to file name programmers_guide.md in the top level directory for the project.
• When I asked Cursor to write a programmers guide, it prompted me that it could write API documentation or make call graphs. I told it make those, but put them in separate files. I specified the API document in md format. Letting it choose the call graph format, it chose mermaid format, but gave me a second option.
• In all of the source code files in this project, add comments where they would help a new developer on the project understand the code better. Signify every comment you add with the words “AI GENERATED”. Insert comments in files with names ending in cpp and hpp
• For documentation, before you close out the chat session, read what it wrote. If you want more information about a specific topic, give it a second prompt asking for more detail on that item to be added into the file.

I was testing on an open source scientific software code that I didn’t write. The original developers had not written a programmers guide. I deleted the programmers guide I had made, and had the Cursor AI make one. Comparing the programmers guide it made to what I made:

• It was a small edit for me to put in my preferred build flags.
• The AI listed the prerequisites. I listed the prerequisites and put in the Debian commands to install them. You could give the AI a second prompt to add those.
• The AI did a good job of summarizing what was in most of the source code subdirectories, but left out the ones it couldn’t figure out.
• The AI wrote a “Data Flow and Major Stages” section, which was useful.
• The AI noted the use of a third party library, but didn’t catch the fact that naming conventions from that library made some variable declarations misleading.
• The AI put in a section for “Key Entry Points and Types”, which was mostly redundant with information elsewhere in the same document.
• The AI gave one sentence suggesting which sections of code a new developer should read first.
• The AI put in a section on “Coding Style and Conventions”. It’s impressive that it did this, but the comments in this section were pretty cryptic.
• The AI did not comment on the original developer’s variable naming conventions. To be fair, the original developers didn’t have one. When I write a programmers guide for an existing application, I may throw in some adjectives like “amateur” or “unwise” or “improvement is needed”, but the AI keeps all of its writing very factual.
• The AI put in short procedures for how to add a new keyword, a new property calculation, and a new post-SCF method. These were useful documentation that I hadn’t yet written.
• The AI put in a “Testing and Validation” section with a small test procedure, but it wasn’t very good compared to what I wrote.
• The AI put in a “Debugging Tips” section which was useful if minimal.
• The AI put in a “Performance Notes” section. It was short and useful. It put in best practice items. However, it missed many important algorithmic items that someone with domain knowledge would have included.
• The AI noted what domain-specific standard some of the data files used.
• It had a section on how to contribute to the project, but it had a few generic coding tips instead of how to submit a pull request, or what to do before submitting a pull request.
• The AI added a “Contact” section, but put in a generic sentence because it didn’t have a way of knowing how to contact the developers. Still it’s useful to remind the developers to add that information.
• Overall, the AI was following a useful template, but kept its information fairly brief. The AI seems to have a preference for brief correct information over more detailed but possibly incorrect guesses. The next time I analyze someone else’s code, I will probably use an AI to do the first pass on the programmer’s guide, then add additional information manually after that.

Sometimes the AI misses things. When I asked it to insert comments in all source code files in the project, it inserted comments in some, but not in others. A second prompt in the same AI chat session asking why it didn’t put comments in one of the files prodded it to do the rest. It did explain that it had put comments in what it saw as the most important files, before completing the task. It will sometimes skip files that are too complex for it, so consider selecting a larger AI model when asking it to complete the work. An AI tool that auto-chooses the model may do this automatically.

WARNING: Cursor gives you prompts to accept or reject changes it made to file. One time, I rejected the change, but it deleted the file instead of just removing the new lines it had added. I hadn’t asked it to delete any files, and it never asked for permission to use the Linux “rm” command. The lesson learned is that you should use a version control system and make frequent commits.

Specify file names or extensions. I asked Cursor to operate on all source code files thinking it would operate on the .cpp and .hpp files. It also modified .md files.

Cursor saw I wasn’t managing the project with git and created a .gitignore file to exclude everything in the project. If you later decided to manage the project with git, that could hae unexpected consequences.

Many of the AI programming tools can work with git, and some must work with git. Since the version control system is a safety in case the AI breaks something, I prefer to type version control commands myself, instead of letting the AI run them. It might be safer yet, to use a different version control system, like Mercurial, so the AI wont be pre-programmed to run those commands.

Understand if the software is agentic. Does it remember all past prompts from my account, for a given project, within a given chat session, or not at all.

• Cursor, Perplexity and many of the current big name products (as of Sep 2025) remember past prompts within a given chat session. Because of this, it’s best to open a new chat when beginning a different type of work, or working on a different section of code.
• When you start a new AI chat session, make your first prompt the most specific, what file format, where to put it, one file or multiple files, made to work with a certain test harness, etc. On subsequent prompts in the same chat session, it will presume a lot of these same settings unless you tell it otherwise.
• If you want the AI to know information across multiple chat sessions, use a configuration mechanism like cursor rules. Cursor can also auto generate long term memories from working with you, but seems to do so rarely.

For automated testing, AIs can do better than humans at including edge cases and trivial cases. This works best for unit testing, and second best for integration testing. For automated test generation, it may be best to use an AI tool designed for this purpose, such as Qodo AI or ACCELQ.

Use AI tools for code reviews. They can identify sections of code with too few comments, or confusing syntax that should be separated into multiple lines of code. Give it details of your variable naming and function name conventions, then ask it to find ones that don’t follow the convention.

Use AIs for tasks you would give an inexperienced intern. They can be good for automating repetitive tasks.

Use AI reasoning models to help with the initial software design. Give them the project requirements and ask them to suggest design patterns or database schemas. Ask which options lead to more performant or scalable software. This wont replace having an experienced lead software architect, but it gives your lead architect a second opinion on the design and someone to discuss design options with.

Give the AI user stories and project documentation, then ask it to identify vague or conflicting requirements.

Use an AI to analyze large amounts of data. Give it all of the open and closed bug tickets, then ask it to identify problem areas that might benefit by being refactored with a more robust architecture. If you have a large amount of historical data on how long it took your team to implement various items or fix various bugs, give that to the AI and ask it to predict how long future tasks are expected to take (provided they are similar to things the team has done before). When asking an AI to analyze data, keep in mind that a small AI model can do well at summarizing frequently encountered item, but a large AI model is needed for analyzing complex or interdependencies.

About asking the AI to generate source code.

• If modifying existing code, it will determine the language. Otherwise, specify what programming language you want it to use.
• It may suggest importing third party libraries that you don’t want to use, unless you tell it not to.
• Ask it to write a well-defined, self-contained function.
• Use the AI to generate small pieces of code, not a massive program.
• When using an AI autocomplete, do one type of change to the whole file or program, then make another type of change. This will tell autocomplete what type of change you want to make. Autocomplete will suggest changes many other times, but will be wrong a significant percentage of the time.
• If you are combining editing a file both in and out of the AI tool, edit in the AI tool, close the file, edit outside, close the file, repeat. Don’t have the file open in both.
• AIs can do very well at giving you boilerplate code, small sections of code that are frequently used with little modification.
• Have a clear understanding of the expected input and output before asking the AI to write code.
• If there are two well known algorithms (i.e. one recursive, one not), specify which algorithm to use.
• Read any notes it gives you about limitations of the method it wrote. If it doesn’t give any, ask for them in a second step. The programmer may have to take the next step of writing error traps based on the limitations.
• Let the AI write the function with its choice of variable names and formatting, or create a project configuration telling it what naming convention to follow.
• Test the function the way the AI wrote it.
• Once you are happy that the function is working correctly, then use a linter, AI, or manual editing to get it to conform to your style guidelines, variable naming conventions, etc. Some coding AI products accept a configuration file where you can specify the project style guidelines.
• If the AI modifies the code and breaks it, you have three choices. 1) revert the change 2) debug it by hand 3) ask the AI to fix it. I most often revert the change, then either do the work by hand, or ask the AI to do the work in smaller pieces.
• If you are asking it to act on a collection of files, it may skip some of them (to avoid hallucinations when the file is too complex for it). If you rerun the command on the files that were missed, choose a larger, more expensive AI model. Some products that auto-choose the model will automatically do this when you ask it to correct a previous oversight. This is often silent, so include something in the query or a subsequent query like “list any files that were not modified”.
• Some of these tools have an “undo” button, which goes away when you close out the AI chat session. Test the changes the AI made before closing the chat session. However, the automatic undo feature is not substitute for a version control system.

Always test any code the AI writes. Test typical cases, trivial cases, corner cases, large test data sets, comparison to a known working code, and comparison to experiment. As with human-written code, assume it is broken, wrong, and buggy until tests have shown it is working correctly.

Unit testing is a powerful tool. It looks like more work at the time, but it is way better than having a half million lines of code that generate no errors but give incorrect outputs. Use unit tests to validate code written by both AIs and humans. Try letting the AI create unit tests, but have a human hand check them.

Debugging is often the most challenging part of software development. Likewise, it can be the place where the AI is most likely to fail. Here are some tips for using AI tools for debugging.

• Do a commit or make a backup copy before using an AI for debugging.
• An AI can easily fix very simple bugs, like syntax errors or a mis-spelled variable name.
• Using the AI to debug one function at a time is more likely to succeed than asking it to debug the whole program.
• Try to fix one bug at a time.
• Do some debugging without the AI. Figure out what function has the bug, and what type of input data it handles incorrectly. Then give the AI a prompt like “This function does X in Y way. It doesn’t work correctly with Z data. Fix it if you can.“
• Use unit tests to check for typical input data, trivial cases, corner cases, and cases where the function should throw an error. Then explain to the AI which types of tests fail, and what the function should do for that type of input.
• Write, test, and debug small sections of code. Try to break massive functions into multiple functions that are more reasonable size.
• For more complex bugs, ask the AI to analyze the code, without modifying it, and tell you what it thinks the problem might be… but make the edits by hand.
• Pushing an AI to fix a bug that is beyond its capabilities can be a way to make one bug into three bugs.

Mistakes to avoid when using AI tools for software development.

• Don’t copy and paste AI generated code without understanding what it does and doing your own human code review of it. A large percentage of AI written code (sometimes over 50%) contains errors.
• Humans are better than AI at making architectural decisions and problem solving. Use the AI for suggestions, but let the humans make the final decisions and do the problem solving.
• Don’t expect AI to replace programmers. Use it to help good programmers be more productive.
• Don’t expect AI to fix things when the problem is that the employee doesn’t have the ability to do the work without the AI.
• Don’t skimp on security testing. AI generated code frequently contains security vulnerabilities. The use of a non-AI security testing system is still recommended.
• Don’t trust code until it has been heavily tested, regardless of whether it was written by a human or an AI.
• Don’t get overwhelmed with AI suggestions that are trying to take the project six directions at once. You have to keep your AI focused on current tasks, just like you do with some of your human programmers.
• Don’t try to push the AI beyond its abilities. It can’t learn and and grow like a human employee can. A very big part of utilizing AI tools is that the humans using it have to learn what the AI can do well and what it can’t.
• An AI can do the more routine parts of code reviews. In our tests with Cursor, the code review information provided by the AI was correct about 90% of the time. An experienced human programmer will be able to recognize problems the AI can’t, and recognize when the AI is wrong.
• Avoid AI created technical debt. A quick solution that the AI generates may still be a bad choice if you are going to have to go back and rearchitect it later.
• Don’t ignore accessibility. AI code generation often misses accessibility features.
• Don’t become over-dependent on one AI tool. Companies are going to try to create vendor lock in, so you can’t do your work without their tools. If a tool is going to prevent you from easily swapping out development tools in the future, don’t start using it.
• Don’t expect the AI to come up with a very innovative solution to a problem. AIs are statistical models based on their input data, so they will offer a typical solution to a problem.
• Realize that autocomplete is just trying to guess at what you are going to type next, assuming you are making a similar change multiple places in the code. It will not give you any warning if you think you are making formatting changes, but you are actually changing the functionality. This is a situation where a true pair programming navigator would have given you useful information that the AI didn’t in our tests.

Another aspect of using AI for coding is cost. Many services now give you a certain number of tokens with each price tier. Here are some suggestions for minimizing the cost of AI coding tools.

• Learn how the tool charges you for usage. How do you find out the cost of each task? This is often transparent until you run out of tokens and have to pay for a more costly subscription.
• In 2025, a number of the AI providers lowered their price structures or came out with more cost effective models. If pricing a year or more earlier was off putting, give the same service another look.
• Specify what function to work on. Instead of telling it to search for the function that does X then do something to it, look up the function name in the programmer’s guide or header file, then tell it the function name to work on.
• Don’t tell the AI to do something you could easily do with other tools. There are powerful features in IDEs, vi, sed, grep, and many more that should still be utilized.
• Give the AI suggestions on how to do the work efficiently. For example, “Use the project programmer’s guide to help find X, then do Y“, or “Look through the header files for function names that imply they do X, then do Y“.
• If you are doing common work, like making simple websites or math functions, take cost into consideration when choosing the AI tool to use.
• Choose smaller models for simpler tasks.
• If a task fails, the AI can go into an infinite loop trying to fix something it can’t fix. This can eat a lot of money quickly. Prevent this from happening by adding some wording like this to your prompt, “Only run ‘make’ once. If it fails, stop trying.”
• In some of these AI programming tools, every command you type to the AI costs you money, if only a couple pennies. It’s cheaper and easier to type ‘make’ in a separate shell window outside the tool.
• Don’t try to make the AI do everything. Some parts are very simple or fun to do by hand.
• Learn what types of things the AI tools don’t do well, and do those things yourself.
• See if open source tools or models will do some tasks well (i.e. Tabnine local, or AskCodi free).
• Non AI tools are often cheaper and more reliable for repetitive tasks.
• Don’t ask it to update style on the whole project if you are only working on one file.
• See if cheaper cloud instances (spot or preemptable) will do the task the majority of the time.
• If GPUs are used constantly, it might be cheaper to buy one for your local machine. If GPUs are used rarely, cloud instances may be cheaper.
• Do some small tests to see if the AI does a given task well (i.e. making unit tests) before asking it to do that task on your entire code base.
• Cull out bad data from good data before asking the AI to work on it.
• Have a more expensive model plan out big complex tasks (refactoring, architecting a solution) then put their plan in an md file. Review the md file by hand to make sure you agree with everyting. Then have a cheaper model implement that plan.
• A locally hosted model gives very low cost and ensures your code stays on your computer. This can be very slow unless you are working on very beefy desktop computer with plenty of memory and a high end GPU.
• Functions to auto-choose an AI model often go for best results, at the expense of using the most costly models. Investing in the time and effort to learn which cheaper models do well on certain types of tasks can save you money.
• Realize that labor is often more expensive than your development tools. Use the tool that saves you time. If two tools require about the same amount of time, use the cheaper tool.

Tips for privacy. Sometimes you don’t want your proprietary code going off to cloud servers.

• Have an AI write a self contained function that you can copy into your code. If you define the function well, it doesn’t need to see any of your code to do this.
• Use a locally hosted AI model. This maintains privacy and is low cost, but will be very slow unless your local computer has plenty of memory and a really beefy GPU.
• Look for configuration settings that tell the AI not to save your data. This may be listed as “quality improvement” or something similar.
• See if the AI respects configuration files to not touch files or directories that you don’t intend to access with the AI (i.e. .cursorignore or .gitignore).
• Investigate what cloud service the model is running on. If it is hosted by the model maker, it is probably mining data from your queries, unless you can find a configuration setting telling it not to. Better options are models hosted by a third party provider like Cursor, or setting up your own on-demand cloud instance.
• Investigate available encryption options. These typically affect data at rest or in transit. The data must be decrypted, if only in memory, for both you and the AI to work on it.
• Look for federated options that spread the information across multiple cloud servers.
• If doing web searches, use a privacy based search engine like Duck Duck Go or Startpage.

Here are some things I would like to have an AI tool programming for, but aren’t well handled by the current generation of AIs.

• Domain knowledge. Look at a few lines of code and tell me what it is doing in the language of a quantum chemist, or what matrix algebra task is accomplished by those steps.
• Integration with Mercurial
• Something that feels more like the pair programming driver-navigator relationship, with the AI able to take either roll.

Using AI for software development is a very fast changing field. Six months time can see a significant change in AI models, AI based tools, and in the capabilities of the AI tools you are already using. Make occasional reviews and testing of new tools a part of your process.

Other good articles on using AI for coding

• This is the best article we have found on getting coding help from LLMs (before the creation of reasoning models) https://simonwillison.net/2025/Mar/11/using-llms-for-code/
• A good discussion of choosing AI models for coding https://frontendmasters.com/blog/choosing-the-right-model-in-cursor/