9 Using AI for Coding in Empirical Research

Artificial intelligence tools have transformed how programmers write code. Large language models can explain syntax, generate functions from natural language descriptions, and debug error messages in seconds. For students learning Python for empirical finance research, these tools offer an appealing shortcut: why struggle with cryptic error messages when an AI can explain them? Why write boilerplate code by hand when an AI can generate it instantly?

This chapter addresses a fundamental tension. AI coding tools can genuinely accelerate your work and reduce frustration, but they can also undermine the skill formation that makes you a capable researcher. The difference between these outcomes depends entirely on how you use these tools. Used wisely, AI becomes a force multiplier for your growing expertise. Used carelessly, it becomes a crutch that prevents you from developing the understanding you need.

We begin with the core trade-offs, then cover the practical landscape of AI coding tools, and conclude with a workflow designed to help you benefit from AI assistance while still building genuine programming competence.

9.1 Why This Chapter Exists

The premise of this chapter is straightforward: AI can accelerate learning, but it cannot replace it. If you cannot read, understand, and debug the code that AI produces, you are flying blind. Learning Python remains non-negotiable for credible empirical research. AI shifts where your effort goes, not whether effort is required.

Consider what happens when an AI writes code for you. The tool produces syntactically correct Python that might even run without errors on your first attempt. But what happens when you need to modify that code for a different dataset? What happens when it produces incorrect results that look plausible? What happens when a collaborator asks you to explain your methodology? If you cannot answer these questions, the AI-generated code is a liability rather than an asset.

The goal of this chapter is not to discourage you from using AI tools. They are genuinely useful, and most professional programmers now use them in some capacity. The goal is to help you use these tools in ways that build rather than erode your capabilities. This requires understanding what AI tools can and cannot do, recognizing when to rely on them and when to step back, and developing habits that keep you in control of your own code.

AI does not understand your research

AI coding assistants have no conception of what makes empirical research valid. They cannot distinguish between code that runs and code that correctly implements your methodology. They cannot verify that your variable definitions match your research design. They cannot ensure that your sample selection avoids look-ahead bias. These judgments require domain expertise that only you can provide.

9.2 AI, Skill Formation, and Career Constraints

The most important reason to develop genuine Python skills, even when AI tools are available, is that over-reliance on AI slows long-run skill acquisition. Programming proficiency comes from struggling with problems, making mistakes, and building mental models of how code works. When AI removes that struggle, it also removes the learning.

Think about the difference between using a calculator for arithmetic and understanding how arithmetic works. Calculators are faster and more reliable for computation, but if you never learned arithmetic, you cannot estimate whether an answer is reasonable. You cannot catch errors. You cannot extend the calculation in ways the calculator does not support. The same dynamic applies to AI and coding. AI can produce code faster than you can type it, but if you never developed the underlying understanding, you cannot evaluate, modify, or debug what it produces.

9.2.1 The industry reality

Many financial institutions restrict or prohibit external AI tools. Banks, asset managers, and hedge funds handle sensitive data and proprietary strategies. Sending code snippets or error messages to external AI services creates compliance and security risks that many firms will not accept. Some institutions run air-gapped systems where internet access is simply unavailable. Others have policies that prohibit sharing any code or data with third parties, including AI providers.

If you are targeting industry roles after your degree, this matters. Code you write with AI assistance still needs to be maintained without it. When you join a firm with restrictive policies, you need to be able to read, understand, and modify code on your own. The skills you develop now determine whether you will be effective in those environments.

Even in academic settings, AI dependence creates problems. Universities and journals increasingly have policies that restrict or require disclosure of AI use in research. Peer reviewers may ask you to explain or modify your methodology. Collaborators may need to extend your code. You may need to debug issues years after the original analysis. In all these cases, you need genuine understanding of what your code does and why.

9.2.2 Building transferable skills

The bottom line is that AI is a supplement, not a crutch. The goal is to develop skills that remain valuable regardless of what tools are available. This means understanding Python syntax, data structures, and control flow well enough to write code from scratch when necessary. It means being able to read and understand code you did not write. It means having mental models of how your analysis works that go beyond the specific implementation.

When you use AI tools, pay attention to whether you are learning or just producing output. If you find yourself repeatedly asking the AI to solve similar problems, that is a signal to step back and build understanding. If you cannot explain what the AI-generated code does, you should not use it.

9.3 Ethical, Academic, and Scientific Constraints

Before discussing how to use AI tools effectively, we need to address the constraints that govern their use in academic and professional settings. These are not optional guidelines. They are requirements that determine whether your work is acceptable.

9.3.1 Academic integrity and authorship

The fundamental principle is simple: responsibility for correctness always lies with the researcher. When you submit code as part of a research project or assignment, you are asserting that the code correctly implements your methodology and that you understand what it does. AI assistance does not change this responsibility. If AI-generated code contains errors that invalidate your results, you bear the consequences.

Different institutions and courses have different policies about AI use. Some prohibit it entirely for certain assignments. Others permit it with disclosure requirements. The specific rules vary, but the underlying principle is consistent: you must be able to explain and defend every line of code you submit. If you cannot, the work is not genuinely yours, regardless of how it was produced.

9.3.2 Reproducibility and auditability

Empirical research must be reproducible. Other researchers should be able to examine your methodology, run your code, and verify your results. This requires that your code be inspectable and explainable. AI-generated code that you do not understand fails this requirement, even if it produces the correct output.

When reviewers or collaborators ask about your implementation, you need to be able to explain why you made specific choices. Why did you winsorize at the 1st and 99th percentiles rather than the 5th and 95th? Why did you cluster standard errors at the firm level rather than the industry level? These questions require understanding that goes beyond the code itself to the research design it implements.

9.3.3 Data confidentiality

Never paste proprietary data, credentials, or restricted information into AI tools. This applies to actual data values, but also to code that reveals the structure of proprietary datasets or the logic of trading strategies. Most AI tools send your input to external servers for processing. Even tools that claim privacy protections may retain data for training or analysis.

In practice, this means being careful about what you share. Error messages that include data values should be sanitized before sharing. Code that implements proprietary methodology should be described in general terms rather than pasted directly. When in doubt, assume that anything you share with an AI tool could become public.

A simple rule for submissions

If you would not submit work without AI, you should not submit it with AI. AI can help you produce better work faster, but it cannot make you capable of work you could not otherwise do. When you submit code, you are asserting that you could have written it yourself given sufficient time. If that is not true, the submission is not appropriate.

9.4 Mental Models for Using AI Effectively

The key to using AI tools effectively is having the right mental model for what they are and what they can do. This section provides frameworks for thinking about AI that will help you use it productively, especially as a beginner.

9.4.1 AI as a junior assistant

The most useful mental model is to think of AI as a junior assistant that writes drafts quickly and carelessly. Like a junior employee, AI can produce output fast, but that output requires review and correction. The assistant has broad knowledge but limited judgment. They will confidently produce work that contains subtle errors. They will follow instructions literally even when those instructions are ambiguous or misguided.

This mental model has several implications. First, you should expect to review and edit everything the AI produces. Just as you would not submit a junior employee’s first draft, you should not use AI-generated code without careful examination. Second, the quality of your instructions matters enormously. Vague requests produce vague outputs. Specific, well-structured prompts produce better results. Third, you remain responsible for the final product. The assistant helps, but you make the decisions.

9.4.2 Why precise prompts matter

Precise prompts matter more than model choice. The difference between a good prompt and a bad prompt often exceeds the difference between AI models. A well-crafted prompt includes context about what you are trying to accomplish, specific requirements for the output, and examples of what success looks like. A poor prompt leaves the AI guessing about your intentions.

Consider the difference between these prompts:

Poor: “Write code to calculate returns”
Better: “Write a Python function that calculates simple returns from a list of prices. The function should take a list of floats representing daily closing prices and return a list of floats representing daily returns. Handle the edge case of the first day, which has no previous price, by returning None for that position.”

The second prompt specifies the input format, output format, programming language, and edge case handling. It gives the AI enough information to produce something useful. The first prompt leaves all these decisions to the AI, which may or may not match your needs.

9.4.3 The iteration loop

Effective AI use follows an iteration loop: prompt, inspect, test, revise. You start with a prompt describing what you need. You inspect the output to understand what the AI produced. You test the code to verify it works correctly. You revise either the prompt or the code based on what you learned.

flowchart LR
    A[Prompt] --> B[Inspect]
    B --> C[Test]
    C --> D{Works?}
    D -->|No| E[Revise]
    E --> A
    D -->|Yes| F[Done]

Figure 9.1: The AI-assisted coding iteration loop

This loop emphasizes that AI assistance is not a one-shot process. You should expect multiple iterations, especially for complex tasks. Each iteration teaches you something about both the problem and the AI’s capabilities. Over time, you learn to write better prompts and to anticipate where AI is likely to make mistakes.

9.4.4 Treat every response as a hypothesis

Perhaps the most important mental model is to treat every AI response as a hypothesis, not an answer. The AI is proposing a solution that might be correct. Your job is to test that hypothesis by reading the code, understanding what it does, and verifying that it behaves correctly.

This mindset prevents the most dangerous failure mode: accepting AI output without verification. When you treat AI responses as hypotheses, you naturally engage your critical faculties. You ask questions. You check assumptions. You test edge cases. This engagement is precisely what builds understanding.

9.5 General-Purpose Chatbots for Research Coding

General-purpose AI chatbots are the most familiar category of AI coding tools. These are web-based interfaces where you type questions in natural language and receive conversational responses. The major tools in this category include OpenAI ChatGPT, Anthropic Claude, Google Gemini, and Microsoft Copilot in chat mode. Each has different strengths and pricing, but for most research coding tasks, the differences are less important than how you use them. For research coding, they serve as explanation-first tools: they excel at helping you understand rather than at producing production-ready code.

9.5.1 What they are good at

Chatbots excel at explaining syntax and error messages. When you encounter a Python error that you do not understand, a chatbot can explain what went wrong in plain language. It can describe what the error message means, why it occurred, and how to fix it. This is often faster and more helpful than searching documentation or Stack Overflow.

They are also good at translating ideas into rough code sketches. If you have a conceptual understanding of what you want to do but are unsure how to express it in Python, a chatbot can provide a starting point. The code may need refinement, but it gives you something concrete to work with and learn from.

Clarifying library usage is another strength. Python has thousands of packages with varying documentation quality. A chatbot can explain how to use a specific function, what parameters it accepts, and what it returns. It can compare alternatives and explain trade-offs. This is particularly helpful when learning new libraries.

9.5.2 What they are bad at

Chatbots are poor at designing correct empirical workflows. They do not understand your research question, your data structure, or the methodological requirements of your field. The most recent models, especially those with reasoning capabilities, are improving in this area, but not yet to the point where you can trust them to be reliable without verification. They can produce code that runs but implements the wrong analysis. Detecting these errors requires domain expertise that the chatbot lacks.

They also struggle with understanding your project context by default. Each conversation with a chatbot starts fresh. The AI does not know what code you have already written, what data you are working with, or what you have tried before. You need to provide this context explicitly, which is time-consuming and error-prone.

9.5.3 Typical research uses

For empirical finance research, chatbots are most useful for:

Debugging tracebacks: Paste an error message and ask for an explanation. The chatbot can often identify the problem and suggest fixes.
Refactoring simple logic: Describe what your current code does and ask for a cleaner implementation. Review the suggestion carefully before adopting it.
Learning new concepts: Ask for explanations of Python features, statistical methods, or library functions. Use the chatbot as an interactive tutorial.
Generating boilerplate: Request template code for common patterns like reading CSV files or setting up matplotlib figures. Customize for your specific needs.

Using chatbots for learning

Chatbots make excellent tutors. When you do not understand a piece of code, ask the AI to explain it line by line. When you are confused about a concept, ask for multiple examples at different difficulty levels. When you get stuck on a problem, ask for hints rather than solutions. This approach builds understanding rather than dependence.

9.6 In-Editor Code Completion and Inline Assistance

In-editor completion tools provide a different kind of AI assistance. Rather than conversational interaction, they offer continuous, low-friction suggestions as you type. The major tools in this category are GitHub Copilot, which integrates with Visual Studio Code and other editors, and Cursor, an editor with deep AI integration built in. Cursor is a fork of VS Code, so it offers a familiar interface and supports most VS Code extensions, excluding those published by Microsoft. These tools analyze your current file and context to predict what you are likely to write next, then offer to complete it for you.

If you have used auto-complete on your phone, you already understand the basic experience. The AI predicts what you are likely to type next and offers to complete it for you. Most of the time the suggestions are helpful and save keystrokes. But occasionally the AI makes silly mistakes, inserting words that are grammatically correct but contextually wrong. Code completion works the same way: usually helpful, occasionally nonsensical, and always requiring your judgment about whether to accept.

9.6.1 How completion differs from chat

The interaction model is fundamentally different from chatbots. With a chatbot, you formulate a request, submit it, wait for a response, then evaluate and possibly revise. With completion tools, suggestions appear automatically as you type. You accept with a keystroke or ignore by continuing to type. The feedback loop is measured in seconds rather than minutes.

This difference has important implications. Completion tools are embedded in your normal workflow. You do not need to context-switch to another application. The AI sees your entire file and often your entire project, so it has much more context than a chatbot conversation. Suggestions are smaller and more incremental, completing lines or functions rather than generating entire programs.

9.6.2 Why this is often safer for beginners

In-editor completion is often safer for beginners because it produces smaller changes that are easier to evaluate. When a chatbot generates a 50-line function, understanding and verifying it requires significant effort. When a completion tool suggests finishing the line you are already writing, you can evaluate it immediately. The suggestion is within the context you already understand.

The immediate visual context also helps. You see the suggestion alongside your existing code. You can compare it to what you were planning to write. Obvious errors are more apparent because they conflict with the surrounding code that you wrote and understand.

9.6.3 Common risks

The primary risk with completion tools is silent logical errors. The AI might suggest syntactically correct code that does not do what you intend. Because suggestions appear quickly and accepting them is easy, you might accept code without fully processing what it does. This is especially dangerous for statistical operations where the code runs without errors but produces incorrect results.

Over-engineered suggestions are another issue. The AI might suggest more complex solutions than necessary, introducing abstractions or edge case handling that you do not need. This complexity makes the code harder to understand and maintain. Simpler code that you fully understand is usually better than sophisticated code that you do not.

9.6.4 Improving suggestions with context

Completion tools work better when they have more context about your code. The AI analyzes your file and project to understand what you are trying to do, and richer context leads to better suggestions.

Type hints and docstrings, discussed in Chapter 4, serve double duty here. They make your code more readable for humans and more understandable for AI. When you declare that a function takes a pd.DataFrame and returns a float, the AI can suggest code that correctly uses DataFrame methods and returns an appropriate value. When you write a docstring explaining that a function calculates annualized volatility from daily returns, the AI understands the domain and can suggest relevant implementations.

This creates a virtuous cycle. Writing type hints and docstrings is good practice regardless of AI tools. But if you use completion tools, that investment pays additional dividends through better suggestions. The same practices that make your code maintainable also make it more AI-friendly.

Conversely, poorly documented code with no type hints gives the AI little to work with. Suggestions will be more generic and less likely to match your intent. If you find that completion suggestions are consistently unhelpful, consider whether adding context to your code might improve them.

9.6.5 When to accept a suggestion

A useful rule of thumb: accept a suggestion when you could have written it yourself, just more slowly. This standard ensures that you understand what you are accepting. The AI is saving you keystrokes, not doing your thinking.

If a suggestion surprises you, pause before accepting. Either you are learning something new (good), or the suggestion is wrong (bad). Either way, the surprise is a signal that you should engage more deeply rather than just accepting. Take time to understand why the AI suggested what it did.

9.7 Coding Agents

Coding agents represent the most powerful and most dangerous category of AI coding tools. Unlike completion tools that suggest small changes, agents can make extensive modifications across multiple files. Unlike chatbots that produce isolated code snippets, agents can execute code, observe results, and iterate. The major tools in this category include GitHub Copilot in agent mode, Anthropic’s Claude Code, and OpenAI Codex. Both Claude Code and OpenAI Codex are available as command-line tools and as VS Code extensions. Cursor also includes deep agent integration. These tools evolve rapidly, so specific recommendations become outdated quickly, but at the time of writing, Claude Code with the Opus 4.5 model is my tool of choice.

For all AI coding tools, but especially agents, reading the product documentation is essential to achieve the best results. Each tool behaves differently, with its own strengths, limitations, and recommended workflows. Adapting your approach to the specific tool you use will greatly improve the quality of the output you get. Time spent learning the tool’s features and best practices pays off quickly.

Video

In this video, I go through an example use case of Claude Code with a financial research application.

9.7.1 What coding agents actually do

Agents operate with a significant degree of autonomy. You describe a goal, and the agent takes a series of actions to achieve it: writing code, running tests, reading error messages, and revising its approach. Some agents can browse documentation, search codebases, and even interact with external services. They do in minutes what might take you hours.

This capability is transformative for experienced developers who can evaluate agent output quickly. An agent can implement a feature, write tests, and handle edge cases while the developer reviews and directs. The human remains in control but operates at a higher level of abstraction.

9.7.2 Why they are dangerous for novice programmers

For novice programmers, agents are dangerous precisely because of their power. An agent might modify your code in ways you do not understand. It might introduce bugs that are difficult to detect because you do not know what was changed. It might solve problems in ways that work but that you cannot maintain or extend.

The core issue is verification. When an agent makes changes across multiple files, verifying correctness requires understanding all those files. A novice lacks this understanding. They may accept changes that seem to work but contain subtle errors. They may lose track of what their code does and why. They may find themselves unable to make further modifications without agent assistance.

The danger of “fix everything” requests

Never ask an agent to “fix everything” or “make it work” on code you do not understand. This request gives the agent maximum autonomy with minimum oversight. You have no way to evaluate whether the resulting changes are correct. Even if the code runs, it may not implement what you intended. Even if it produces plausible output, that output may be wrong.

9.7.3 Appropriate research use cases

Agents are appropriate when you already understand the code being modified. Useful applications include:

Refactoring code you already understand: If you know what the code does and want to improve its structure, an agent can help. You can verify that the refactored version preserves the original behavior.
Generating tests or documentation drafts: Agents can produce initial test cases or docstrings that you then review and refine. The human provides the specification; the agent provides the implementation.
Applying consistent changes across files: When you need to rename a variable, update a function signature, or apply a similar change in many places, agents can do this quickly and reliably.
Rapid prototyping: Agents can quickly produce working code to test whether an idea is feasible or to explore how a library works. Treat this as throw-away code for learning and experimentation, not as the foundation for your actual analysis.

9.7.4 Inappropriate use cases

Agents are inappropriate when you cannot verify their output:

Writing core empirical logic: The code that implements your research methodology must be code you understand. Agents should not write this code for you.
Modifying unfamiliar code: If you do not understand code before the agent modifies it, you definitely will not understand it after.
Debugging without understanding: When code does not work, the solution is understanding, not automation. An agent might fix the symptom while leaving the underlying problem.

9.7.5 Version control is essential

Using version control with Git is not optional when working with coding agents. Agents make extensive changes across multiple files, and you need the ability to review those changes before accepting them and to revert if something goes wrong. Git’s diff tools let you see exactly what the agent modified, line by line. Without version control, you have no systematic way to understand or undo what the agent did.

Commit frequently when working with agents. Before asking the agent to make changes, ensure your working directory is clean. After the agent finishes, review the diff carefully before committing. If the changes are wrong, you can discard them and try a different approach.

For advanced workflows, Git’s worktree feature lets you maintain multiple working directories from the same repository, each on a different branch. This enables running multiple agents in parallel on separate tasks without conflicts. Each agent works in its own worktree, and you merge the results when ready.

Video

For a quick introduction to git worktrees, see this video.

9.7.6 Security and permissions

Coding agents require significant permissions to do their work. They need to read your files, write new code, and often execute commands. This power creates security risks that you should take seriously.

Be cautious about what you allow agents to access. An agent with permission to execute arbitrary shell commands could potentially damage your system, exfiltrate data, or install malicious software. Most agents have safety measures, but these are not foolproof. Never run agents with elevated privileges, and be wary of granting access to sensitive directories or credentials.

Development containers, discussed in Chapter 10, provide an effective safety layer. By running agents inside a container, you isolate them from your main system. Even if something goes wrong, the damage is contained. The container can be reset to a clean state, and your host system remains protected. For any serious agent use, especially with less-established tools, running in a devcontainer is a sensible precaution.

9.8 AI-Assisted Workflow for Research

This section presents a workflow designed to help you benefit from AI assistance while maintaining understanding and control. The principles apply regardless of which specific tools you use.

9.8.1 Start from human-written pseudocode

Before asking AI for help, write pseudocode describing what you want to accomplish. This forces you to think through the logic before delegating to AI. The pseudocode becomes both your specification for the AI and your reference for evaluating its output.

Pseudocode does not need to be syntactically correct Python. It should describe the steps of your computation in terms you understand:

# Calculate portfolio returns for each month
# For each month:
#   Get the weights at the start of the month
#   Get the stock returns during the month
#   Multiply each weight by its corresponding return
#   Sum to get portfolio return
# Return the list of monthly portfolio returns

With this pseudocode, you can ask AI to help implement specific steps. You have a clear reference for whether the implementation matches your intention.

9.8.2 Use AI to reduce syntax friction, not to invent logic

AI should help you express ideas you already have, not generate ideas for you. If you do not know what analysis to run, AI cannot tell you. If you know what analysis to run but are unsure of the Python syntax, AI can help.

This distinction keeps you in the role of researcher rather than consumer of AI output. You make the methodological decisions. AI helps you implement those decisions efficiently. The resulting code reflects your understanding because it implements your logic.

9.8.3 Run and test after every AI-assisted change

Never accumulate multiple AI-generated changes before testing. After each change, run the code and verify it behaves correctly. Check edge cases. Compare results against manual calculations or known benchmarks. This immediate feedback catches errors early when they are easy to diagnose.

If you accept several AI suggestions before testing, and something goes wrong, you do not know which change caused the problem. You may need to undo everything and start over. Testing incrementally avoids this.

AI-generated tests require careful review

AI tools are good at writing tests, which can accelerate your workflow. However, when AI writes both the code and the tests, you lose an important check on correctness. Review AI-generated tests carefully to ensure they actually test the right behavior and cover edge cases. A test that passes is only meaningful if the test itself is correct.

Be especially careful with coding agents. When tests fail, agents have a tendency to modify the tests to make them pass rather than fixing the underlying code. This defeats the purpose of testing entirely. Always review diffs carefully to ensure the agent fixed the function, not the test.

flowchart TB
    A[Write pseudocode] --> B[Implement one step]
    B --> C{AI help<br>needed?}
    C -->|Yes| D[Prompt AI with<br>specific request]
    D --> E[Review output<br>line by line]
    E --> F[Modify if needed]
    F --> G[Test immediately]
    C -->|No| G
    G --> H{Works<br>correctly?}
    H -->|No| I[Debug with<br>understanding]
    I --> B
    H -->|Yes| J[Commit to<br>version control]
    J --> K{More steps<br>remaining?}
    K -->|Yes| B
    K -->|No| L[Done]

Figure 9.2: AI-assisted workflow for research coding

9.8.4 Use version control aggressively between iterations

Commit working code to version control before making AI-assisted changes. If the changes break something, you can easily revert. This safety net encourages experimentation while protecting against mistakes.

Good commit messages document what you changed and why. When you later review your project history, you can see the evolution of your analysis. This is valuable for debugging, for collaboration, and for your own understanding. AI coding assistants are good at writing detailed commit messages that summarize the changes made. Just make sure you review the message before submitting the commit to ensure it accurately describes the work.

9.8.5 Never merge AI-generated code you cannot explain line by line

The final check is simple: can you explain every line of the code? If someone asked why a particular line exists, could you answer? If the code stopped working, would you know where to look?

If you cannot answer these questions, you should not use the code. Take time to understand it, or ask the AI to explain it, or write it yourself. The short-term cost of slower progress is worth the long-term benefit of genuine understanding.

9.9 Local and Open Models

Cloud-based AI tools are convenient but not always appropriate. This section covers alternatives that run on your own hardware, avoiding the need to send data to external servers.

Local models address several concerns that matter for research. Your prompts and code never leave your machine, eliminating concerns about data retention, training on your inputs, or security breaches at the provider. Organizations that prohibit external AI tools may permit local ones since the code stays within your controlled environment. Local inference has no per-token charges, so after the initial setup, usage costs only electricity. And local models work without internet access, which matters for air-gapped systems or unreliable connections.

Running AI models locally requires significant computing resources. Effective local models require Apple Silicon Macs or PCs with modern GPUs; older hardware often cannot run useful models at reasonable speed. Memory is usually the binding constraint, with larger models requiring more of it. On Apple computers, the system uses unified memory where RAM is shared between the CPU and GPU, so a machine with 32GB or more of RAM can run substantial models. On PCs, the relevant constraint is typically VRAM on the GPU rather than system RAM, since the model must fit in GPU memory to run efficiently. Model files themselves are large, often multiple gigabytes each, so keeping several models available requires substantial storage. Local AI also requires more technical setup than cloud services: you need to install software, download models, and configure integration with your editor.

Two popular options for running AI models locally are Ollama and LM Studio. Ollama is a command-line tool that makes running local models straightforward, handling model downloads, memory management, and inference. Many editor integrations support Ollama as a backend. LM Studio provides a graphical interface for downloading and running local models, making it more accessible for users uncomfortable with command-line tools, and includes a built-in chat interface.

Several tools support local model backends for coding assistance. Some configurations of GitHub Copilot allow using local models instead of cloud APIs, though capabilities may be reduced. Open-source alternatives like Continue provide Copilot-like functionality with local model support. Command-line agents like Claude Code can also be configured with local model providers, though this requires additional setup.

Local models currently trail cloud models in capability. The most capable models require hardware that exceeds what most individuals own, so local models are typically smaller and less capable. Cloud providers invest heavily in tooling that local solutions cannot match, and you are responsible for updates, troubleshooting, and configuration. These trade-offs may be acceptable when privacy or institutional requirements demand local operation, but for learning purposes, cloud tools are usually more practical.

9.10 Summary: Rules You Should Actually Follow

This chapter has covered many considerations, but effective AI use comes down to a few key principles:

If you cannot read the code, you should not use the code. This is the fundamental rule. AI can help you write code faster, but you must understand what you are using. If you cannot explain it, you cannot debug it, maintain it, or defend it.

AI accelerates feedback, not understanding. The AI can produce code quickly and identify errors quickly. But understanding comes from your engagement with the code. Use AI to speed up the feedback loop, not to skip the learning.

In research and industry, credibility beats convenience. Your reputation depends on the quality and correctness of your work. AI-generated code that contains errors damages your credibility. Code you understand and can explain builds it.

Start with what you know. Write pseudocode before asking for help. Use AI to implement your ideas, not to have ideas for you. The research decisions are yours; AI helps with the implementation.

Test relentlessly. Every AI-generated change should be followed by testing. Catch errors early, when they are easy to diagnose. Never assume that code is correct because AI produced it.

Maintain version control. Commit working code before making changes. Create a safety net that lets you experiment confidently and recover from mistakes.

Treat AI responses as hypotheses. The AI is proposing solutions, not providing answers. Your job is to evaluate those proposals critically, accept what works, and reject what does not.

These principles will serve you regardless of how AI tools evolve. The specific tools will change. The specific capabilities will improve. But the fundamental dynamic remains: AI is a tool that amplifies your capabilities, for better or worse. Used wisely, it makes you more effective. Used carelessly, it prevents you from becoming effective at all.

The choice is yours.