Forge Fate
English
AI

AI Keeps Getting Better. What Should I Learn as a Developer?

6 min read

I use Codex to solve development problems by writing prompts. That makes it hard to relate when I hear that I should learn more ways to use it. If I can already get the results I want, what would change if I spent time learning another feature? How much do I need to understand about how it works? These are questions I’m asking, not conclusions drawn from measuring my work. [S1]

Trying to keep up with every change to the tool feels like an endless course of study. Yet I’m not sure that getting results with prompts is enough reason to keep working exactly as I do now. I keep coming back to three questions: When is more learning worth the effort? How deeply should I understand how an agent works? Where should I invest my limited time?

What would I gain from learning a new way to use it?

A new feature takes time to read about, try in my own work, and assess for future use. That investment needs a more concrete payoff than simply knowing one more feature. Would it save me from repeating the same instructions? Would it help me notice decisions I’m overlooking during a task? I can’t answer without looking at my work.

There’s no guarantee that a useful technique will stay useful. OpenAI advises revisiting existing prompts, project instructions, and Skills when models change, and trimming instructions that have become too long or outdated. That is the maker’s guidance for a particular model; it is not evidence that shortening instructions would improve results in my project. [S2] Learning to use these tools may involve deciding which habits to retire as well as which ones to add.

Delegating more work could also create a different need to learn. OpenAI describes workflows in which a person redirects work in progress, reviews code changes, and handles approval requests. In one engineer’s account, a person reviews the plan while the process records execution results and reasons for decisions. [S4][S5] I don’t yet know whether those decisions will matter more as I delegate more of my own work. But the larger learning challenge may turn out to be deciding what to delegate and when to step in, rather than memorizing feature names.

The impression that a prompt solved it

When I write a request and receive a result, it’s natural to feel that the prompt solved the problem. What actually contributed to the result is a separate question. I don’t have records of my own tasks for this article, so I can’t establish the respective roles of my prompt, the existing code, project instructions, and tool output. [S1]

Official examples make the question more specific. OpenAI says Codex Code Review can use rules in a repository’s AGENTS.md. Other accounts describe recorded commands and results, verification commands, and human review. [S3][S5][S6] That doesn’t mean those elements played the same roles in my work. It does give me questions to ask the next time I accept a result: What did the existing code tell the agent that my request did not? Which execution results led it to change course? What did I check myself before accepting the change?

I’m not trying to discount the value of a good prompt. I want to identify what I’m already doing well and where learning something else might actually help.

How much do I need to understand about how an agent works?

“Understand how it works” covers too much ground. I find it more useful to think in three levels.

The first is reading the work record. Can I follow what changed, which commands ran, and how their results informed the next decision? OpenAI’s published accounts describe recording commands, results, and reasons for decisions, as well as setting checks for each stage of a task. [S5][S6] If I can read that record, I may be better able to choose what to inspect when a result seems wrong, instead of rewriting my prompt without a clear reason. Whether that helps me is a hypothesis I want to examine.

The second is understanding the conditions of the task. What context and project instructions can the agent draw on? What has it checked with tools? Which actions require permission or approval? In OpenAI’s descriptions, prompts, instructions, repository review rules, and approval flows each have a role in the work. [S2][S3][S4] If I need this level of understanding, I can start by making the conditions of a delegated task clear before studying every detail of the model.

The third is the execution architecture and the model’s internal workings. A problem that the first two levels cannot explain, or a particular technical decision, may give me a reason to study more deeply. But the material I have now cannot tell me how much that study would help with my development work. I’d rather start with the problem I need to solve than with “deep understanding” as a goal in itself.

How should I judge the value of learning?

Token use and the time it takes to get a result seem easy to compare. They aren’t the only things I care about. How many times did I have to explain the same point? How often did I intervene? How much effort did reviewing the changes take, and did I have to redo work after accepting them? Above all, do I understand why the code changed, and can I decide where to look when the next requirement arrives?

These are questions for reflecting on future work, not a proven formula for productivity. The approval steps, reviews, and decision records in the official accounts give me things to consider; they do not establish that the same practices would benefit me. [S3][S4][S5] How should I value a quick answer if I don’t understand the change and get stuck again on the next task? And how valuable was learning a new feature if I spent time on it but never need it again?

When learning might help, and when it can wait

The next two situations are hypothetical examples. They are not tasks I performed or compared.

Suppose I have to explain the same rule to an agent every time I work in a project. If that repetition is burdensome, I have a reason to learn how to organize project instructions. OpenAI’s descriptions of instructions used in agent work and code review make that an option worth considering. But instructions also take work to maintain, so I would still need to see whether they help in that project. [S2][S3]

Now suppose I request a small change, understand and can review the resulting code, and know where to make the next edit. Continuing with my current approach may make sense. The distinction between these examples isn’t which feature is better. It’s whether I have a recurring burden and whether learning something new could address it.

The questions that may outlast the tools

I wonder whether time spent defining problems clearly, gathering evidence for decisions, verifying results, and explaining design choices will help me longer. That, too, is a hypothesis to examine. It isn’t a declaration that general development skills always matter more than knowing how to use a tool. Depending on how I set project rules and decide which changes to accept, using the tool well may itself be an important form of judgment. The rules, reviews, and decision records in the official accounts help me think about that relationship, but they don’t prove the long-term value of one skill over another. [S2][S3][S5][S6]

In this series, I plan to start with whether further learning is needed. From there, I want to consider how deeply to understand agents, how to delegate and make decisions, how to judge code, the cost of creating and maintaining rules and Skills, and a tentative order for what to learn. Those six questions give me a starting direction. Questions that arise along the way may expand the series to around twelve articles. That is a path for inquiry, not a fixed schedule or a set of conclusions.

Think of one recent development task you worked on with AI. What felt easy? Where did you have to make a decision yourself or intervene repeatedly? Naming one of each might make your next learning question clearer. That is where I want to begin the next article: How much do I need to understand about how an agent works?

Sources

Report an error or share feedback

Open a draft with this article’s title and URL. Review the message and recipient before sending.

To: [email protected]

Open email draft

If no email app opens, copy these details into your usual email service.

Contact information

Related posts