Forem: Ash G

AI-Assisted Coding: The Hype vs. The Hidden Risks

Ash G — Thu, 20 Mar 2025 16:58:06 +0000

Photo by Nahrizul Kadri on Unsplash

“Vibe coding” or AI-assisted coding has become popular in the past few months. It simply means prompting the AI to generate your codebase. If a bug occurs, instead of digging into the code, you tell AI to fix the bug. Some are even claiming it could allow anyone, without any software development training at all, to easily build software.

Now, AI-assisted coding is fantastic for non-technical founders with basic coding skills, indie developers, and small teams building CRUD apps, MVPs, simple mobile apps or automating repetitive tasks. It accelerates iteration cycles, allowing more people to test ideas with minimal development effort. In tech and startup community circles like HN, Product Hunt etc., there’s often a sample bias, where everyone is in the startup space, using AI tools or building AI agents.

However, once you move into enterprise applications, especially those dealing with critical sectors like banking, healthcare, cybersecurity and government systems, the stakes are entirely different. Enterprises have regulatory requirements, compliance concerns, and internal security policies that make them extremely cautious. They simply cannot afford to let any third-party AI company touch their codebase, as it poses risks to security, compliance, and long-term maintainability.

First, there are serious concerns about protecting intellectual property with AI-assisted coding. If you suggest that their code will be sent to a cloud-based LLM, good luck navigating that conversation. They are deeply protective of their proprietary codebases, and sending any part of it to an external LLM(hosted by a third-party) is a non-starter.

Second, AI frequently produces bug-ridden code, and an oversight by an "experienced" developer is constantly needed to effectively use AI. AI coding assistants work best as enhancements for experienced developers, not as a replacement. Subtle logic bugs, poor optimization, and architectural inconsistencies can add up and lead to performance degradation, scalability challenges, and hard-to-debug failures that compound over time.

Third, a huge and under-discussed issue. The security risks that AI can possibly introduce into the code are significant. AI models trained on public codebases often inherit bad security practices, which means they are likely to produce insecure code. While this might be tolerable for a fun weekend project, in an enterprise setting, these risks are unacceptable, potentially leading to security vulnerabilities.

Fourth, unchecked AI usage will accumulate massive technical debt. If you let AI generate code without understanding what each line is doing, the technical debt will accumulate at an alarming rate. When things go awry, you won't know where to start looking to fix them. In any firm, the ability to debug and refactor existing code is a huge part of a software engineer’s responsibility, more so than writing code from scratch. If you’re blindly accepting AI suggestions, your codebase will become an opaque box, resulting in code that is hard to debug and an architecture that will not scale.

In my software engineering career, I have been taught to write "every line of code with a purpose." You should know why you wrote that line, what it is doing, and how it will affect other parts of the code. AI will not replace strong engineering fundamentals, but it will make good engineers more productive while amplifying the mistakes of bad ones.

If you're a software engineer, it's crucial to be aware of AI's limitations and associated risks. Cautiously explore its potential through side projects or weekend experiments to stay up-to-date with emerging AI technologies. Again, there is absolutely no replacement for strong software engineering fundamentals. If your goal is to progress further in this profession, mastering the ability to understand, navigate, and debug complex code will always be more valuable than relying on AI tools.

AI-assisted coding is here to stay, but its role in professional software development will depend on the context. Startups and solo founders can reap significant benefits, while enterprises, understandably, will remain skeptical, especially when it comes to security, compliance, and long-term maintainability.

Hi, I’m Ash. With 10 years of experience in software engineering, I’m passionate about using technology to improve efficiency and create real value.
I also built Brisqi, a personal Kanban app designed to help people stay organized and in control.
Outside of work, I spend time hiking in the mountains or snowboarding — nature is where I recharge and find much of my inspiration.

Achieving More: How software engineers can benefit from Kanban

Ash G — Sat, 26 Oct 2024 05:12:15 +0000

I worked as a Software engineer for more than eight years. I've navigated countless projects, deadlines, and team dynamics. Managing my workload effectively was essential for my productivity and I’ve found Kanban to be an invaluable tool for task management.

In this blog, I’ll share how software engineers can utilize Kanban to organize projects, enhance focus, and streamline their work. Best of all, no special software is needed to follow a Kanban workflow, a simple Excel sheet with columns and cells can do the job just fine.

Benefits of Kanban

Before diving into the specifics, let’s quickly highlight the key benefits of using Kanban for personal task management:

Visual Organization: Kanban offers a clear visual layout of tasks, making it easy to see what needs to be done at a glance.
Increased Focus: Limiting work in progress (WIP) to a maximum of two tasks reduces cognitive load and minimizes distractions.
Adaptability: Kanban allows for quick adjustments to priorities, enabling effective responses to changing circumstances or urgent tasks.
Time Management: Kanban simplifies task estimation, making it easier to plan time effectively and allocate resources where they are needed.

Setting Up the Kanban Board

Step 1: Defining the Workflow

The Kanban board can be structured into the following lists:

Icebox: A collection of new ideas and future tasks for later consideration.
Backlog: A list of tasks to be implemented.
To Do: Items prioritized for immediate attention.
In Progress: Tasks that are currently being worked on.
Code Review: For tasks that require peer feedback.
Testing: For quality assurance checks.
Done: The section where completed tasks are stored.

This layout mirrors the software development lifecycle, from initial ideation through testing and completion.

Step 2: Creating Task Cards

Each task card includes:

Title: A clear and concise description of the task.
Description: A detailed overview of the task, including acceptance criteria that outline the specific conditions that must be met for the task to be considered complete.
Due Date: A deadline to assist in effective prioritization of tasks.
Labels for Estimation: Instead of traditional story points, labels can be used to indicate the estimated effort for each task. The labels represent time estimates as follows:
- 0.5d: Half a day
- 1d: One day
- 2d: Two days
- 3d: Three days
- 1w: One week
- 2w: Two weeks
- 1mo: One month

This system provides a clear overview of the time commitment required for each task, allowing for effective workload planning.

Here’s a screenshot of Kanban lists created in Google Sheets:

Step 3: Time Blocking

To maintain focus, use time blocking to allocate specific periods for different tasks. For instance, you might dedicate the first two hours of the day to coding new features, followed by a block for addressing bugs or participating in code reviews. This method minimizes context switching, which improves productivity in software development.

Step 4: Work in Progress (WIP)

Establish WIP limits for the “In Progress” column, typically setting it to two tasks at a time. This principle is rooted in Lean methodology and helps you avoid multitasking, a common pitfall that can lead to reduced quality and slower progress. By limiting WIP, you can focus on completing tasks before taking on new ones, ensuring a more efficient workflow.

Step 5: Breaking Tasks into Smaller Components

For larger tasks, breaking them down into smaller, manageable chunks is crucial for building momentum. This approach makes it easier to tackle complex projects and keeps motivation high. For example, when implementing a new feature, tasks might include:

Gather Requirements: Understand the specifications.
Design UI/UX: Create mockups and user flows.
Develop Backend: Write the necessary code.
Unit Testing: Ensure functionality works as intended.
Code Review: Gather feedback from peers.

Each of these subtasks becomes its own card on the Kanban board, making it easier to track progress and maintain momentum.

Step 6: Review progress

Regularly reviewing the Kanban board is essential for assessing progress and adapting to changing circumstances. During this time, customer requests can be identified and addressed, and tasks can be reprioritized based on new information or shifting needs.

Step 7: Recognizing Milestones

It’s key to celebrate milestones, whether it’s moving an important task to the “Done” column or wrapping up a tough project. Taking a moment to acknowledge these wins boosts motivation and highlights the importance of delivering quality work.

Leveraging Kanban for Personal Development

In addition to task management, the Kanban board can be used to track personal development goals. Whether learning a new programming language, exploring a framework, or contributing to open-source projects, creating specific cards for these initiatives ensures that time is set aside for continuous learning. Staying on top of personal growth is important in the fast-changing tech landscape.

Final thoughts

Implementing Kanban for personal task management has transformed the way I approach my tasks. Its flexibility, focus on flow, and alignment with Lean principles make it a great fit for handling complex tasks. By using techniques such as time blocking, breaking tasks into smaller components, and employing Kanban color coding alongside time estimation labels, I can manage my workload effectively while maintaining a high standard of quality. If you're looking to boost your productivity and streamline your workflow, consider adopting Kanban. It might be the missing piece for optimizing your personal task management and achieving your professional goals.

For all my personal projects, I use the offline Kanban app Brisqi for personal task management. This tool provides a level of privacy and control that’s essential for my workflow and having a private space to manage tasks allows me to keep my thoughts and projects secure.

How I designed an offline-first app. An outline.

Ash G — Thu, 01 Jul 2021 21:24:27 +0000

Last week I wrote a blog post on how I built my app in React, React Native and NextJS. This blog post gives an insight on how I made it into an offline-first app. There are many ways to build an offline-first app so this is a general outline of how I built it and what worked for me. I use NoSQL database so I use the word 'documents' throughout the blog post, but you can think of them as a record of a table in a SQL database.

Offline-first? What does that even mean?

I had to understand what offline-first apps really meant. I found different definitions of it around the internet. Partial offline functionality, partial offline data etc. but I wasn't satisfied with any of those, so I settled with the following definition:

Offline-first apps are apps which can run and function completely offline or without needing the internet for an indefinite amount of time. To offline-first apps, providing all functionality offline is the primary objective and any online functionality such as syncing to cloud is secondary.

There's also another category - offline-tolerant. Offline-tolerant apps provide functionality offline for a limited amount of time or provide partial functionality and sooner or later they would require the user to sync data to the cloud. The amount of time is dependent on the type of functionality of the app and how the data is stored. Offline-tolerant apps mostly store partial data in a temporary cache, whereas offline-first apps store all it's data in a dedicated local database.

Keep. Things. Simple.

Offline-first architecture can get overwhelming, so I made sure to keep things as simple or primitive as possible when I started out. I didn't get into conflict resolution strategies or tried to handle poor network connection immediately. I worried about that stuff later.

I worked with happy path and assumed that there were only two things I need to take care of - online and offline. When the app is offline, I track actions performed by the user. When the app is online - I replay those actions.

This might seem a bit different compared to conventional way of doing things which is to track "changes" instead of actions. Tracking actions was so much easier than tracking changes. I don't have to keep a record of hundreds of changes a user might have made to a document in the database. I only track actions and replay them. That's it.

Let's look at the following scenarios

When the app is online

User performs an action (add, modify, delete etc.).
Store changes in local database.
Push changes to the server.

This is straightforward. When the app is online, I just push out changes to both local database and server.

When the app is offline

User performs an action.
Store changes in local database.
Track actions in a queue and also store them in the local database.

When the app is offline, I track what action(add, modify, delete etc.) was performed and the unique Id of the document so I can retrieve it later from the local database.

When the app is back online again

Get tracked actions.
Replay those actions one by one skipping local database and push them out to server.
Retrieve data from the server and merge the data.

I get the actions either from the local database or from the queue if still in memory and call the functions corresponding to those actions one by one. Each of those functions now also know to skip the local database and to call the server API directly. Finally, I retrieve the data from the server and merge it back into the local database (more on this later).

It all seems doable right? Keeping things simple was key here.

How should I detect if something changed?

I needed to figure out how to track what documents changed. I tried following techniques:

Storing timestamps when the document changed and then comparing timestamps.

I didn't go with this one because there were lot issues with this technique. What if a document was changed at the same time from two different devices. It could happen when there are multiple users modifying data or if the date and time of the devices are out of sync(its rare but it can happen).

Versioning documents.

Every time a change is made, a new version is created and the latest document along with version history is pushed out. I didn't go with this either as this would've made things too complicated, again I wanted to keep things simple. Git and PouchDB/CouchDB do this and they both do it in a really efficient manner, but I was using Firebase not CouchDB for reasons which are out of scope for this blog post. I needed a new strategy.

Generating a new changeset ID each time a document is changed.

Changeset ID is just an ID which changes whenever anything changes in that document. If changeset ID is different, that means something has changed so the document should be updated. This technique was simple enough for me to experiment with and implement so I went ahead with this approach.

Conflict resolution strategy

Now, I needed a strategy to handle conflicts. There were two I could think of - either I merge all the changes coming in, or I take last write wins(LRW). I went ahead with last write wins. The strategy you pick is dependent on the type and importance of data you're merging. If you are building a note taking app then merging text data would make sense.

In my case, I was developing a personal Kanban app and only a single user would be syncing data to other devices. Last write wins made sense in this situation. If something got overwritten, its expected that the user knowingly made the change and would fix the changes if necessary. Its far easier to deal with LRW strategy when syncing data both ways. Keeping things simple.

Syncing and merging documents from the cloud

With everything I now had, i.e. unique reference Id for each document, changeset Id to detect a change in the document and LRW strategy, syncing documents with the local database became straightforward. Since I was using Firestore, Firestore query listeners gets called when something changes on the cloud. Think of them as an event listener which are called when Firestore SDK detects a change. If I wasn't using Firestore, I would build some kind of polling mechanism to detect any changes on the server side.

To sync data, I do two things - Push first, then pull. Push the pending actions in queue to the cloud if there are any, then pull the data from the server. Pushing and then pulling makes things simple as this way the user's data is always up-to-date. The recent changes made by the user don't get overwritten by the changes on the server. This also aligns with my LRW conflict resolution strategy.

Pushing data to the server

I've already talked about pushing the actions before. You just call the corresponding server API functions and push the changes while skipping local database.

Pulling data from the server

To pull the data I employed two methods here:

Getting all the user's documents from the cloud and comparing them with local database to identify which one got added, modified and deleted, and then updating the local database accordingly.

This is a very broad technique, I made it more efficient by limiting the number of documents I get based on a subset of data, you'd have to figure out based on your needs how you can limit the amount of data. In my case, I was working with Firestore query listeners, each collection would have different query listeners and I wanted to work with minimum amount of listeners as possible so this technique works for me. I use this technique for my desktop app as I want "all user's data" to stay up-to-date.

Only getting added, modified and deleted documents for a collection/table.

This strategy worked when getting all of the user data wasn't necessary. Especially in mobile app, to conserve user's bandwidth, the app would only retrieve data which the user wanted instead of fetching everything.

Merging documents

Merging documents from the cloud to the local database involves adding new documents, updating modified documents or deleting "deleted" documents. Remember, I had unique reference ids and changeset Ids for each document? I would iterate through the both local data and retrieved data(from the cloud) and compare the changeset Ids, and then update the corresponding document in the local database if need be. It was time consuming to write the logic but it wasn't that bad.

Here's what I did for each case:

Detecting new documents: If a new document is on the cloud, iterate through local collection, check if reference id exists, if it doesn't, its probably a new document so add it to the local database.

Detecting modified documents: Compare the changeset Ids, if changeset Id is different, update the document in the database.

Deleting "deleted" documents: By "deleted" documents I mean documents which don't exist on the cloud anymore. To delete those documents, for each local document iterate through cloud's data and find out if it doesn't exist, then delete it in the local database.

That's all for now

That's it for an outline. Using changeset Ids to detect changes made my life a lot easier. I also use them in the mobile app for comparing and updating data on the global state which improved overall performance of the app. There are so many things I didn't mention here as it would make the post too long. Besides if you don't do some research on your own, you won't learn ;)

Follow me on Twitter for behind the scenes of the app I'm building. I love connecting with new people and learning something new.

All the best!

I built my app in React, React Native and NextJS. Lessons learned.

Ash G — Thu, 24 Jun 2021 19:47:53 +0000

I developed an offline-first personal Kanban app called Brisqi and launched it for 5 different platforms. I started this project with 2 purposes - to learn React and to build my own offline Kanban app as I always wanted one. I've been working on Brisqi since June last year.

Here's the tech stack I used in case you're curious:

ReactJS + BlueprintJS + custom styling for desktop app.
React Native + React Native elements + custom styling for Android/iOS App.
NextJS + BulmaCSS for the website.
Firebase Auth for authentication + Firestore for the database.
Google cloud functions - to handle backend operations.

Electron framework was the obvious choice to make it cross-platform as it has good eco-system around it so I went ahead with it as the underlying framework.

Following are the things I learned and followed specific to React, hope its helpful to you:

Start with Context API for state management if your app is small, learn how it works. This will get you use-to the reducer pattern in React. Don't worry about the performance in the beginning, React is smart enough and optimizes rendering for you. Optimize for performance or re-renders only if performance becomes an issue. And only move to Redux if you feel your app needs more than a simple state management.

Learn Immer and how it works. It's a great library to modify state in an immutable way. It makes life so much easier by modifying the "draft" of a state directly without the use of spread operators if the state is made of nested objects. It also comes in handy when implementing reducers with Context API.

If you move to Redux, use Redux Toolkit. It's a great toolkit made by the same people who made/maintain Redux.

It states following on their website:
"Redux Toolkit is our official, opinionated, batteries-included toolset for efficient Redux development. It is intended to be the standard way to write Redux logic, and we strongly recommend that you use it."

This one's subjective I feel. Learn how to use Functional Components and Hooks effectively. All my apps are written using Functional components and Hooks. I personally feel they are easier to read and understand, it certainly helps in avoiding the need of HOC or render props which is a plus for me. If you're starting new projects, start using Functional components and Hooks.

Optimizing performance in React Native can be a tricky thing to do if you have lot of data to display. If you're using lists, use FlatList instead of iterating over values using map function or similar. Using Redux here can be beneficial to you here so you can avoid unnecessary re-renders. Remember, in Context API, using useContext within a component will re-render that component and child components everytime unless you use React.memo on child components. Check out this Github link to learn more. In Redux, accessing part of state using useSelector hook prevents re-rendering if that part hasn't changed.

Speaking of unnecessary re-renders, learn how to use React.memo(), useCallback() and useMemo() effectively. Learn them, understand them and use them to avoid re-renders if performance becomes a problem. If you're using Redux, learn about Reselect library to create memoized selector functions. All of this helped me a lot in improving performance of Brisqi mobile app. If you're developing on iOS first, you might not see performance issues immediately, test it on Android. In my personal experience, an app written in React Native performs better on iOS than Android. I go by this rule of thumb, if it's performant on Android, it probably performs equally well or better on iOS, but I still test thoroughly on both platforms.

Break components into smaller components if possible. Smaller components are re-usable, easier to work with when using React.memo(), easier to manage state in them and code is easier to read and maintain when you come back to it after a couple of months.

Use third-party utility libraries sparingly. Use them if you think you cannot reproduce that functionality on your own "reliably". For example, I wrote my own Keyboard avoiding/aware view from scratch because - 1) I could simplify it, 2) tweak it according to my needs , 3) adapt it for both Android and iOS platforms and 4) I'd avoid external dependency. I'm not saying that other solutions are not good enough, they might be and some are, but less dependency = more stability because you know the functionality in and out.

For styling/convention, be consistent with whatever you pick. Airbnb style guide can be a good starting point, however I don't follow everything they say. For example - I disagree with them on the usage of single and double quotes. I use double quotes everywhere to be consistent where as they use both single quotes and double quotes.

Keep things simple, don't over-complicate your architecture. Add things as you go along. Similarly, don't prematurely optimize for performance, do it when it becomes an issue.

NextJS is for websites or multi-page apps and React(CRA or manual setup) is for single page apps. I personally don't try to adapt one into another. Makes things easier that way.

Keep refactoring as you find out better approaches of doing things. It's part of the learning process.

Keep learning, don't stop and share your knowledge with others.

Links:

Follow me on Twitter for behind the scenes.
Brisqi

Little trick to stay motivated and beat procrastination ✨

Ash G — Thu, 11 Feb 2021 01:53:15 +0000

Imagine a ball made out of concrete. When you try to push it, it takes tremendous effort to get it rolling. To stop it from moving, you just need to keep nudging in the direction you want and it keeps rolling. You don't need to push it as hard anymore as you did when it was at rest. Now, every time you give it a nudge you keep adding a little more force to it, not too much, just a fractional amount. What happens? It starts rolling faster and faster. The more you do it, the faster it goes, and what does it take? Just a fractional amount of work. Now if you want to stop it from rolling, it takes some effort - this is where you want to be.

There's a term for this - Momentum. That concrete ball has build up some momentum. Great! now you know how to stay motivated. Kidding! Well that's the gist of it. No, Really!

What about that "tremendous effort" in the beginning? I don't want to do that, isn't there some easy way? Well there is, just don't put that much effort in the beginning. Yes, you read that right. Don't put that much effort immediately in the beginning. Put a fractional amount. But, do it consistently.

When I say fractional amount, I mean it. Amount equivalent to the tiny spec of dust in the universe. If you do that, overtime that fractional amount is compounded and you start gaining momentum.
When you start a new project or learn something new. It takes substantial effort to get started. The moment you think about how much you have to do, a huge boulder weighs on your mind and you may incline towards giving up before you even started. The trick? Again, put a fractional amount.

Let's say you want to start getting into the habit of reading books. You read just one word on the first page and keep the book away. Next time you pick up the book, you read the next two words, then the next three.
This process removes that heavy boulder off your mind because now it's not hard anymore. It's easy as reading few words. Similarly, you can apply this for writing, write one word, then write two more words and so on. Every time you come back, you up your fractional effort by tiny amount.

Now, we know we are not perfect, there would be times when we would stop putting that effort completely. That's okay! Don't beat yourself for it. Instead, you have pat yourself on the back and tell yourself I needed that break and that you're back again. By doing this, you instantly clear up guilt from the mind and it sets you in a positive mood. Get back up, start with the fractional amount again. I'm repeating fractional amount over again because it's important you don't forget about it.

I've been doing this since I became an indie developer and have been consistently doing it. There have been times when I had stopped working for few days. I'd lose momentum, but then I'd start again applying the same technique I mentioned above. In my case, it would be just staring at the code. Not writing. Just looking at the screen and staring at it for 10 minutes. Next time I'd come back, my mind would be thinking about the code I had been looking and I'd start gaining momentum.

Start with a fractional amount, up it by a notch next time you come back and do it consistently.

In case you’re wondering, I’m building Brisqi - a personal Kanban app. It’s what I use to plan my day, work and life in general. Feel free to check it out.

Git remote backups

Ash G — Mon, 11 Jan 2021 22:47:55 +0000

As part of my development process, I've made a habit of keeping two remote repositories for every project I work on. One remote repository is on services such as Github, Gitlab etc. and second remote is on a separate/external hard disk.

It has saved me lot of hassle when I accidentally made some mistakes while committing or shouldn't have committed something in the first place and want to backtrack, and it's always good to have a backup, in case something goes wrong with your computer.

So here's how you do it:

Create an empty repository i.e one without a working tree.
Add the empty repository as a remote from your project's git repository.
Push your changes to the empty repository.

Step 1: Create an empty repository i.e one without a working tree

You can create this repository anywhere you like, I usually create it on an external hard disk. Now open your terminal and run following command:

git init --bare /path/to/external_hdd/remote_backup.git

Make sure you change the path above.

The --bare flag tells git to create a repository without a working tree because we won't be working with the files directly. We will only sync our changes with it.

Step 2: Add the empty repository as a remote from your project's git repo.

Add the remote_backup.git as a remote so we can push changes to it, it is just how we push changes to Github or any other git service you use.

git remote add backup /path/to/external_hdd/remote_backup.git

Great, you can check by running following command that the remote was added correctly:

git remote -v

Step 3: Push your changes to the empty repository

git push backup master

I'm pushing master branch here, you can push changes from any branch, just like how you would push changes to Github.

That's it!

Whenever you make changes, push to both repositories.

I hope this tip comes in handy, especially to beginners who are starting out. I remember when I first started using git in a professional setting few years ago, I was afraid of making mistakes, but making mistakes is the first step in mastering something. All the best!