Coding with AI

What exactly are models good at in coding?

There is a clear pattern, and once you see it the rest of this lesson gets simple: models are good at work whose shape is repetitive and whose judgment content is low. The closer the work gets to decisions specific to your project, the more quality falls off, and it falls off quietly, because the code still runs.

Things they genuinely do well: writing code whose like has been written a thousand times, such as reading a file, validating a form, or a network request with its error handling. Translating from one language to another. Converting data from one shape to another. Writing tests for a function you wrote yourself. Explaining code somebody else wrote that you are a stranger to. And the one almost nobody uses, which pays back the most: critiquing code you wrote yourself.

The work where they fall short shares a pattern too: anywhere the right answer depends on something that is not in the conversation. Architecture decisions that turn on your scale and your team. Code that has to fit the unwritten conventions of an old project. Anything that depends on the latest changes in a library. And security, which the risks section returns to.

Our position is simple: put the model on work you could have done yourself but do not want to, not on work you do not know how to do. Because in the first case you can judge the output, and in the second you can only hope.

What do developers who use these tools every day actually say?

Instead of guessing, look at the largest public survey in the field. The 2025 Stack Overflow developer survey says 84 percent of respondents use or plan to use AI tools, and 51 percent of professional developers use them daily. So the "should we use them" argument is over.

But the same survey says a second thing that gets quoted far less. Asked how well the tools they use handle complex tasks, 4.4 percent said very well and 25.2 percent said good but not great. Against that, 22 percent said bad and 17.6 percent said very poor. Another 14.1 percent said neither good nor bad, and 16.8 percent said they do not use these tools for complex tasks or do not know. In other words, the people with these tools in their hands every day are more negative than positive about complex work.

And a third number that sums up this whole lesson: the biggest single frustration, at 66 percent, was "AI solutions that are almost right, but not quite". Almost right is the worst possible state. Completely wrong code is caught by the compiler or the first run. Almost right code passes both and shows itself months later in one particular case.

The rest of that same frustration list is worth reading too, because it shows the shape of the cost: 45.2 percent said debugging generated code takes more time, 20 percent said they have become less confident in their own problem solving, and 16.3 percent said it is hard to understand how or why the code works. At the other end of the list, only 4 percent said they had run into no problems at all.

One note about these numbers, since this is also a lesson in honesty: they are what people report, not a measurement of code quality. They tell you what developers experience, not how good the models objectively are. For this lesson the first is what matters.

Which tools, and which of them can you actually reach from Iran?

Tools come in three shapes, and choosing between them depends less on the model than on where you work.

An editor extension suggests while you type. GitHub Copilot is the best known. Its advantage is that it interrupts nothing; its cost is that because it always suggests, you get used to accepting without reading.

A separate chat in the browser, such as Claude or Gemini. Better for thinking, critiquing and understanding than for writing, because it separates the code from the project context, and that separation forces you to state the problem yourself.

A command line agent or an agentic editor, such as Claude Code or Cursor, which read and write files themselves. The most powerful shape and the most dangerous: when a tool changes ten files without showing you each change, review becomes the only thing standing between you and an invisible bug.

Now access from Iran, which for this page reader is the real question. There is an important difference here that is rarely stated: GitHub is not like the others. GitHub own trade-controls page says it holds a licence from the US Treasury Office of Foreign Assets Control covering its cloud services for developers resident in Iran, both free and paid. We quote that sentence and claim nothing beyond it; whether payment goes through with an Iranian card is a separate matter we have not tested, and the buying guide covers that layer on its own.

On the other side, Anthropic supported-countries page does not include Iran, and Google own page about the Gemini web app gives a list of more than two hundred and thirty countries and territories that Iran is not on. Cursor publishes no supported-countries list that we could find, so we claim nothing about it; its prices can be read off its own page, a free plan and a professional plan at twenty dollars a month.

There is a fourth route that means more in Iran than elsewhere: open-weight models. You can take the weights and run them on your own hardware or at any provider, so the access question changes shape. Their quality trails the closed models and that gap keeps moving; our up-to-date ranking with a source for every number is at the best AI for coding, and we deliberately name no version here, because any number written into a lesson is stale in three months.

The workflow that holds quality: test first, small diffs, real review

Three habits separate someone who works faster with a model from someone who produces technical debt with one. None of them are about the model; all three are yours.

Test first, then code. Before you ask for an implementation, ask yourself how you will know this works. Write that answer down and you now have an objective standard neither you nor the model can argue with. Order matters here: if you take the code first and then ask the same model to write its test, you get a test that carries the same assumptions as the code, and both are wrong together. The best move is to state what the test must prove yourself, even if you hand the writing of it to the model.

Small diffs. Ask the model to do one thing in one change and stop there. A fifty-line change that alters one thing can be reviewed; a five-hundred-line change that alters four things does not get reviewed, it gets approved. Those are very different, and the difference is exactly where bugs get in.

Real review. Review means being able to say, for each line, why it is there. If you hit a line you do not understand, you have three options: ask, work it out, or delete it. The fourth, which everybody picks, is to leave it because the rest works, and that line is precisely the one you come back to in six months.

There is a cheap fourth habit almost nobody uses: ask the model to critique its own code in a separate message. In a fresh message with no conversation history, paste only the code and ask what is wrong with it. You get answers you would not have got by asking in the same thread, because inside the thread the model role is to defend what it just built.

What must never go into the message?

This section is short because its rule is short: anything you put in the message leaves your hands. Depending on the service, the plan and the settings, it may be retained, it may be reviewed by a human, and it may go to training. Each service data-usage page is the only right place to learn this, not what people say.

So four things stay out: keys, passwords and tokens, even inside a snippet you sent only as an example; real user data, especially a log with emails and phone numbers in it; a client codebase, when your contract did not allow it; and anything you signed a confidentiality undertaking for.

The practical route is simple. Replace the key with a meaningless string, and if you ever pasted a real key into a chat, that key is no longer valid and must be rotated; not because it is certainly leaked, but because you no longer know where it is. For user data, build a few made-up rows with the same shape. The shape of the data is what the model needs, and its contents are not.

If you are a beginner, where should you start?

There is a real worry that deserves a straight answer: if the model writes the code, when do I learn?

The risk is real, and the same survey shows it: 20 percent of respondents said they have become less confident in their own problem solving. The mechanism is clear too: learning comes from being stuck, and a tool that removes being stuck has removed the thing that was teaching you.

But the answer is not "do not use it", because the person who does not use it is both slower and ignorant of what everyone else knows. The answer is order. For anything you have not learned yet, write it yourself first, even badly and incompletely. Then ask the model to critique it. That order gets the same work done and keeps the learning, because being stuck stays where it was and only gets shorter.

And a simple test that tells you where on that spectrum you stand: close the code the model wrote and explain the same thing from memory. If you can say what it does and why it does it that way, good. If you cannot, that code is not yours yet; it is rented, and you pay the rent on the day it breaks. The rest of the foundations that make this test possible are in the programming learning path.