Can anyone code using AI? Yes and no. Can someone with zero experience of tech or coding simply get up one day and create an app with the help of AI tools? Chances are very very slim if you are doing it alone. Perhaps my experience is coloured by already having some background in creating a prototype app and working as a business side consultant on another app development. Perhaps a total beginner will find innovative ways to use LLMs to their benefit. Sometimes having no baggage helps.

Building an app is not just about application logic. You need to be aware of the various layers and how they work together – Database, backend, frontend, cloud. Then you need to worry about performance and bugs which means you got to write tests and implement caching and audit your code for processes that are slow and possibly blocking or breaking other processes. Sometimes things will appear to be working under ‘ideal’ circumstances but break under others.

In social chatter, coding is often equated with writing complex algorithms that only those with IQ 200 can accomplish. This is far from reality. Most of the time you are not writing algorithms, but fetching data, unpacking it, making sense of its structure and then using it. The proliferation of posts like “Top coding tests at Netflix” or “What they ask you in Google interviews” makes it appear as if every day in the life of a programmer is a hackathon. The reality is more mundane and tiresome. In my personal experience, I have spent about 25% time writing code, 25% time deliberating on design choices and 50% time debugging and doing performance improvements. I am sure seasoned programmers spend less time on bugs.

Coming to Ensymbol, here is some background on what the app is all about, so I won’t be spending any more time on it. The tech stack for Ensymbol is – FastAPI backend with Postgres DB and ReactJS frontend. The choice of React was easy – I was already familiar with it. I had very little experience with Python, but considering that I wanted to incorporate some Machine Learning elements into my app, I decided to go with FastAPI and not NodeJS for the backend. During the course of developing the app it struck me that my app (as it was that time), did not actually need a backend at all for prototyping. All I was doing was making calls to external APIs to fetch news and stock data and this could be achieved from the frontend also. There was also no data being persisted onto a DB. But eventually having a backend worked out better because there are a lot of calculations that the data has to go through, which the pandas library in Python is very good with. Your frontend is best left to deal with rendering logic, and your backend with application logic and math.

About 50% through my project I realised a I needed a DB because there was only so much analysis I could do with externally fetched data. Moreover, 70% of the data was static (declared financial statements) and there was no point fetching it again and again. So I decided to batch process data for 750 NIFTY companies and saved it to a Postgres DB. Now I could run SQL queries and create dashboards which were not possible with simple manipulation of raw jsons. Maybe there are ways to do it, but I am not experienced in these things, and it was not worth the exploratory time. I was already familiar with SQL so setting up a DB was a no-brainer. This also saved me API costs and speeded up the app significantly. Now I only fetch recent news and prices from external APIs.

If you are a total beginner, you will be tempted to ask LLMs about everything and probably follow their advice blindly. This project has taught me more about LLM strengths and weaknesses than anything else. They are incredibly good with some things and painfully frustrating with others. In another post I will cover this in more detail. For now, you need to know that you can’t rely on them completely. Let no influencer tell you otherwise. If you are planning to build something with the help of LLMs (vibe coding), please take at least one preparatory course each on SQL, one programming language, and one course which walks you through building a web app (this will cover HTML and CSS too). It need not be a web app only, but there are more tutorials on such apps. An end to end implementation will familiarise you with the ‘non-coding’ part of tech – command line interface, environment variables, git, HTTP requests, error logging in terminal and browser console, package management, version conflicts, deployment challenges, CDNs, caching and familiarity with cloud hosting platforms. If you like any of this, you can decide which area to dive deeper into. Chances are that if you are reading this, you are more interested in building from a business perspective and not looking at tech as a career in itself.

Ensymbol itself is quite buggy at the moment. This is not entirely my doing. The data is inconsistent but yeah, errors need to be handled more gracefully. The things is that by know I know all the bugs and it is a bit like knowing all the rattles and strange sounds in your car. You know something is not right, but you know what that ‘something not right’ is. Making a highly performant, feature rich, bug free app is a lot of hard work and requires professional expertise beyond the scope of a handful of people, let alone a single individual. As you develop, you start respecting apps which perform fast, flawlessly. But don’t get disheartened. Like I said, you are almost certainly not someone who wants to code for a living. You need to be an expert in your domain first. There is no point fiddling around with tech if you don’t know what you want to do with it. I am neither a techie, nor an experienced financial analyst, so building the right features has been a challenge. As I use my own app, I will realise I need to drop some dashboards and create some new ones. It’s ok. I can live with a scrappy app. The thing is it has 70% of what I need as of now, and it’s a start. It’s simply impractical to try to build a comprehensive and polished product when you have never done so single handedly. Moreover, tech is a rabbit hole and you can get distracted by what it can achieve. You need to curb your temptations. Learn to walk before you try to sprint. Build some features and start using them.

Coming to LLM specific learnings. I feel that LLMs are enthusiastic by design. They are trained to keep on offering solutions, because that keeps users engaged and converts them into paying users. I have not encountered a single LLM till now which has admitted that it does not have a solution for a problem. If you keep on pushing it endlessly, it will go round and round in circles and you will only get frustrated. Bafflingly, I have observed that LLMs tend to get some basics wrong, while excelling at complex tasks. As such, you need to have some training or experience so that you can work collaboratively with them and extract yourself out of a seemingly unsolvable problem. LLMs struggle massively with CSS. A lot of us struggle with CSS in terms of identifying the right element to target, so it is understandable that something that cannot ‘see’ struggles with it even more. Curiously, LLMs also struggle a lot with UI design. Due to the constant hype around image generation capabilities of LLMs, I was led into believing that they are incredibly creative. Maybe they are, but in a different way. They get layouts wrong many times, and it is best if you design your own UI. Once you have decided upon what you want, they will help you implement it.

I found LLMs to be extremely good at Devops work. They give very clear and correct commands and are familiar with the menus of all major cloud platforms. Deployment is a breeze as long as you tell LLMs to go slow with their instructions. They have a tendency to dump dozens of instructions at a time, and generally have this approach – “If A doesn’t work, try B, if B doesn’t work, try C and so on”. You have to be very very specific that you need to go one step at a time. Once you have overcome all the errors (and there will be plenty along the way), you can make a cheatsheet that helps you deploy quickly subsequently. LLMs have a tendency to over engineer and provide too many options. Stick to one workflow that works for you. Don’t fall into the ‘best practices’ rabbit hole that they will try to suck you into.

The ‘best practices’ over eagerness applies throughout your project. ChatGPT in particular is extremely over eager. Even if you tell it to stick to one thing, it tends to forget it over the course of few messages or if your tone becomes chatty again. But by far the biggest challenge in using LLMs is context retention. If you are not very familiar with LLMs, or haven’t used them for long in a single chat, chances are you haven’t run in to the problem of context. Put simply, context is memory of what has transpired previously in the chat. This memory helps the LLM to ‘evolve’ its solutions as the chat progresses and not make the same mistakes again (although it does). If your chat gets interrupted or the speed crawls due to too much chat history, you will have to move to a new chat and all context will be lost. Every new chat is like talking to a new developer that has zero context.

What I started doing after a point was that in a long chat I would ask the LLM to summarize everything we had done thus far. This would include things like project structure, paths to key files, a brief on tech stack being used, sample of how a certain reusable logic has been implemented so that you can provide it in the next chat. LLMs make pretty good handover notes, but you will still need to provide some context in the new chat. Once you master this, the path becomes a lot easier. Then you only need to worry about how soon you will hit chat interruptions. Using free tier is out of the question. LLMs have insane investment needs and their owners have pulled the plug on liberal free tier. ChatGPT with the Rs.399 plan will mostly last you full day (albeit with warning messages that your quota with the latest model is over for the day and you are being downgraded to the an older model). Claude will hit this limit much faster even though you are paying more (about Rs.2200 per month). I have not tried paid version of Gemini. Deepseek does not have a paid version and I somehow never took a fancy to Mistral. I found Claude to be better at coding tasks, but not significantly so. The price to performance ratio is clearly in the favour of ChatGPT. What I like about Claude is its artefact feature. It writes the code in the artefact and in subsequent iterations I see it altering only what has changed. In contrast ChatGPT types the entire code again and takes longer. These artefacts also serve as the ‘current’ version of the code and thus your chat is not cluttered with iterations. Anyway, these are considerations you will want to look at much later into the project. You can get started with either of them depending on what your monthly budget is. Claude next tier is almost Rs. 12,000 a month and too steep for me. So Chat GPT is that friend who will take care of you tirelessly for very little, even if it is not the smartest kid on the block.

Some guidelines on how to use LLMs effectively for building:

1. Do not jump head first into tech elements. At the same time, do not waste too much time on the project design. I had to scrap 2 designs after significant amount of coding because I thought I had made them unnecessarily complex
2. Prompting is the single biggest skill you will need to develop. Write intelligent prompts. Don’t outsource that bit of ‘intelligence’ to LLMs. It is easy to allow the LLM to lead, because they pre-empt you a lot and you will constantly be dealing with feelings like ‘Ah, that was exactly what I had in mind’. You are dealing with a machine that can jog on endlessly. You have to learn to set the pace.
3. LLMs tend to get stuck with a problem. If one LLM is not working, port the problem to another LLM. I have often come unstuck by doing this. It is quite incredible how a problem one has been struggling with for hours gets resolved in a few minutes by another.
4. LLMs are sycophantic. They will agree with you quickly, even if you take contrasting approaches. ChatGPT’s “Perfect!” and Claude’s “You are absolutely right!” are practically meme materials now. Do a bit of non LLM research on what is the correct approach. If required ask the LLM to provide you pros and cons of every approach. They are pretty good at this. For important decisions, check with multiple LLMs. Do not ask leading questions. Do not allow it to feel that you prefer one thing over another.
5. Dig deeper for important technical questions. When I asked ChatGPT which server side caching strategy is better – endpoint side or data fetcher side, it initially said fetcher side, very confidently. Then I passed the same question to Gemini and Claude, who were unanimous that endpoint caching is better. When I went back to ChatGPT with the additional analysis I had from the other LLMs, it changed its recommendation. It was not entirely wrong the first time, but the point is that more context is better.
6. LLMs will not help you design a sexy UI. Absolutely not. Drop the notion entirely. Come up with your own UI, or get it designed by someone if you are not good with these things
7. Do not dive into it as a complete tech beginner. Regardless of how much you ask an LLM to slowdown and babysit you, it will assume you know certain things. In any case, I strongly recommend not trying to build anything unless you have done those 3-4 tutorials I wrote about earlier. Completing them will set you back by a month or 2, but it will be worth it. I am not going to recommend any particular one. On Udemy there are plenty. If you want to play it safe, pick one with a large no. of ratings, and check in the reviews if there are complaints about content not being updated. Content not being updated is not a deal breaker really. Some packages may not work, but you can always Google about these things.