On coding with AI

Lately I’ve been experimenting with AI-assisted coding and I want to share what I’ve learned.

For context, I studied Computer Science and have about six years of experience. In the past I’ve worked as a full-stack software engineer and data engineer. Since January I’ve been helping companies profit from AI, mostly through strategy and acting as a technical lead on projects. Three months ago I took on an enterprise project where I did most of the programming myself.

The project is about building an MVP for a domain-specific application that makes use of AI to help speed up processes and use internal knowledge sources effectively (RAG). The app has a React frontend, uses FastAPI as a backend and Langgraph as the AI agent framework, together with various Azure services. Even with some constraints to follow the company’s internal guidelines, it’s mostly a greenfield project.

I’ve used this project as a testing ground for learning how to effectively use AI for coding (I used Cursor), testing different approaches and trying to find its limitations. Not everything worked out of the box, but overall I saw a 2–5x productivity boost. That number sounds high, but it makes sense for a greenfield MVP and for someone like me: a generalist who knows the fundamentals but is rusty on details. An experienced engineer working in a familiar stack would likely see much smaller gains.

I’ve experimented with “vibe coding” (i.e. asking the model what you want and not looking at the code). I found it to work surprisingly well with the frontend. I migrated the frontend from Streamlit to React in about four hours without writing a line of code and with minimal review. The UI wasn’t too complex, but with my poor React skills it still would’ve taken at least a week otherwise. The code quality is likely poor, but for an MVP I don’t care.

Vibe coding didn’t work as well for backend tasks. Even in tasks with much smaller scope than the React migration, it often failed or made bad design choices. I had to reduce the scope of the tasks significantly and provide much more detailed descriptions of what I wanted. The most important thing is to make sure the overall system design is good and the interfaces between components are clean. If a component’s input and output are well-designed, you can afford to let AI implement with less control.

I noticed that it worked better for FastAPI tasks than for Langgraph tasks. FastAPI is a mature framework while Langgraph is rapidly changing and the model’s knowledge of it is often outdated. A trick that helped for Langgraph tasks was to force the model not to rely on its own knowledge, but to search for code examples on the internet or check the latest documentation. Still, after learning how to work with it I also found a decent productivity gain in backend tasks.

AI was least useful for tasks that involved database schema design. Without careful discussion it made poor choices and created technical debt, probably because those tasks need more context than the model has.

In practice, this is the loop I ended up using:

1. Learn about the topic (if needed): If you’re very unfamiliar with the topic you’re working on, you’re better off dedicating some time to learn the basics. This will help you know what to ask and how to guide the conversation. AI is amazing for learning new things.
2. Describe what I want and ask for approaches: Explicitly tell the model not to write any code yet, just suggest high-level approaches. The more context you provide, the better (e.g. which files it should look at, why you are making this change).
3. Challenge the AI’s response: Ask about the parts you don’t understand or don’t agree with. Play devil’s advocate.
4. Decide on a plan: After the discussion, explain your final decision to the AI and give details on how to implement it.
5. Have AI implement it.
6. Review and test: If the task has broad scope, review it carefully; if it’s smaller, you can be less strict. If the solution doesn’t work, you can paste the error message to the AI and ask it to fix it. This often works, but if it isn’t solved in two or three iterations it can lead to time-consuming rabbit holes. It’s usually better to discard what you have and go back to step 2.

One unexpected new challenge I noticed is cognitive load, since AI takes care of much of the “easy” work. In the past, writing boilerplate occasionally gave my brain a rest. Now I need to deliberately slow down or take breaks to avoid burning out.

If AI Were Nearly Perfect

I often think about how coding will change as AI improves. To explore this, I like to imagine the most optimistic case: what if AI were almost perfect? What would remain of my coding loop?

I’m sure there are tasks where AI has struggled to implement in my project that won’t be an issue in the near future. For example, I couldn’t make AI correctly switch my Langgraph agent from sync to async code and use streaming mode. My description of what I wanted should’ve been enough. I think this will be achieved in the coming years. It’s likely that the underlying AI model is more intelligent, there are better ways for it to pull context from the Langgraph library or code examples, and the coding agents can try and test things autonomously more effectively. If that’s the case, I would spend less time (or none) in step 5 and perhaps be lazier in steps 2, 3 and 4.

The biggest leap for AI would be long-term memory and the ability to gather context like a human. Cursor doesn’t have access to meetings, chats, or stakeholders. It doesn’t know about the tool OpenAI released last week. It also lacks the cultural context I get from real conversations with customers.

I don’t think this will happen any time soon. Some limited version of it could happen, for example by letting AI securely access chats and meeting transcripts, having almost real-time knowledge of the online world, remembering all my past interactions with the AI. But let’s say it is achieved completely for this thought experiment. I wouldn’t need to write that we need to use a certain database, that a certain model is not available for use, that there’s a newly released API that does the job better, or that the IT department of my customer doesn’t want me to change a certain part of the codebase. The AI would just “get it”. Taken to the extreme, this could replace steps 2, 3, 4, and 5 with a single step: “describe what I want without much detail”.

Even a superintelligent AI can’t decide what humans want in the first place. That’s our job. AI won’t have lunch with a customer or notice the pain points of daily work, but humans can. Developers will still need to understand people, build trust, and spot problems worth solving. That’s where software development will remain a human craft.