The Object Oriented Life

An experiment with Vibe coding on replit - where it works and where it fails

AI Coding Agents

AI coding agents are advanced tools designed to assist developers in writing, debugging, and optimizing code. These agents leverage artificial intelligence and machine learning models to understand natural language commands, generate code snippets, and even handle full-stack development tasks.

Vibe Coding
Vibe coding is a programming technique where developers leverage AI tools to generate code based on natural language prompts, focusing on the desired outcome rather than the technical implementation. Instead of writing code, you describe what you want your app to do, and AI tools handle the technical aspects, including coding.

Replit

Replit is an online Integrated Development Environment (IDE) that allows users to write, run, and deploy code directly from their browser. It supports over 50 programming languages, including Python, JavaScript, and C++

Replit is designed for accessibility and ease of use, making it ideal for beginners and experienced developers alike.

Key features of Replit include:

Real-time collaboration: Multiple users can work on the same project simultaneously.
Built-in hosting and deployment: Users can deploy their applications directly from the platform.
AI-powered assistance: The Ghostwriter feature provides code suggestions, autocompletion, and explanations
No setup required: Everything runs in the cloud, eliminating the need for local installations
Replit is particularly popular for rapid prototyping, educational purposes, and collaborative coding projects.

Attempt to build an application on Replit

My objectives were, to create a fairly complex application, front-end, API Integrations, and Backend with DB.

So, this was the initial prompt,

A web-based Engineering Management Dashboard that aggregates team activities from GitHub and JIRA, providing consolidated insights for engineering managers to track their team's progress.
Core Features:
Team management with ability to create teams and add/remove developers
Integration with GitHub API to track code contributions (commits, pull requests, reviews)
Integration with JIRA API to monitor work item status and updates
Chronological activity feed for each developer combining both GitHub and JIRA updates with date filtering
Team dashboard showing consolidated metrics and individual developer summary screens
Visual References:
Inspired by GitHub's activity feed and JIRA's project dashboards, combining clean data presentation with actionable insights.

My Observations:

Excellent ability to create an initial prototype. It knows so much about the domain, to understood the context and did lot of customization by itself. For ex. Created widgets, used native Github and JIRA terminologies, . I liked the communication back to the user. You will be blown away by the output of the first version!

An application build plan was discussed and asked for approval. Code fairly well organized and easy to understand.

The choice of frameworks, components and node modules looks very new and modern.

Replit created the DB schema as below, It's very decent for the purpose.

I was very impressed by the creation of persistence layer, together with insertion of the seed data.

It would have taken around 20 hours for a developer to build this app, replit did it in 20 mins!.

Adding the first feature

I asked for this feature,

Ability to add team members in the team view with below attributes - Name, Email, GitId, Jira Id

Agent performed below task, and displayed below message. Again impressed by the communication.

I'm analyzing our current progress on implementing the "Add Team Member" feature.
✓ Created add-team-member-dialog component

✓ Created add-team-member-form component
✓ Created a dedicated add-developer page
✓ Updated the team page with an "Add Developer" button
✓ Added route for the add-developer page

But I could see that all the files were updated, but the feature was not working. I looked at the code and realized that it was not getting triggered. So, I manually triggered by custom url, the page appeared.

Next, I wanted to update the GitHub and JIRA API keys to test if they are working. I found it very difficult to navigate the flow and test the changes. As I was trying multiple attempt to debug the issues, I realized that I need to move to the "Developer" leading mode. Agent sounded confused for many questions.

At this stage, I could not continue on the replit agent, I took out the code to my local to continue with developer lead way (AI as assistant).

Conclusions

The ease with which non-developers can customize applications generated by AI coding tools varies depending on the complexity of the desired modifications and the specific platform being used. Non-developers should approach AI coding for prototyping with realistic expectations, recognizing that while these tools are powerful, they are not a substitute for software development expertise, especially when dealing with complex applications or aiming for production-ready code.

Agentic AI tools (Vibe Coding) are useful for non-developers to to create quick prototypes. It works best with UI heavy applications built with HTML, CSS, Java Script and Node. How ever further customization of the Agent build application will not be smooth sailing. There are rapid development in capability, but AI Agents are not reached a stage were one can create a production grade full-stack application without the involvement of expert developers.

Building Evolutionary Architectures - Book review

In this blog, I want to speak about the book Building Evolutionary Architectures by Neal Ford, Rebecca Parsons, and Patrick Kua. I have attended Neal's conference talk on this topic and heard from many other speakers about the fitness functions. That’s the reason I wanted to read and understand the concepts mentioned in the book.

As the title implies, the book talks about building evolutionary architecture. The question that the book trying to solve is, how do we make sure, our software architecture stays intact with the changing requirements? How do we build the system which can adapt to future needs or how do we know the decision that we are taking is not impacting the architecture of the system?

The book speaks about fitness functions, to solve this concern. An architectural fitness function provides an objective integrity assessment of some architectural characteristics. So, in a system there may be many characteristics that we want to measure, so you would write separate fitness functions for each of them. In the book, a fitness function is not defined in a concrete way but rather in an abstract form of graphs, tests or any other methods by which we know that our system is doing good with the change. This means you would still need to use your intellect not only to write the fitness function but also to make sense of them.

For me, the best thing about the book is, it provides software architects with a rich vocabulary to communicate their intentions behind their choices to a variety of audiences, including business stakeholders, teams, and engineering leadership. The book also gives you a survey of various architectural approaches. It also talks about some of the practical ideas on how do we implement evolutionary architectures I particularly like the focus on the organizational factors and how does it apply to the software architectures.

In conclusion, I would recommend this book to any software architect. Use it as your communication guide, use it to improve your vocabulary, use it to get a sense of what is happening across the industry, so that you could choose what best for your situation.

4 ways to contribute to the community for a software developer

If you are a software professional and looking for something new to start here are the 4 things to try for!

1. Attend a community event or user group gettogether or local meetup

2. Answer questions at the stackoverflow or contribute to support forums

3. Share your experience via blog or twitter or other forums with the community.

4. Contribute to opensource

When to stay with modular monoliths over microservices

We have seen the developments in the microservices architecture maturing, where by more and more people are trying to evaluate the benefits before jumping on to the unknown trajectory.

In the talk titled When to stay with modular monoliths over microservices at Oracle Code, Bangalore, I tried to discuss these points. You can view the slides below.

When to stay with modular monoliths over microservices from Manu Pk

According to me, Over simplified version of decision tree come down to two criteria's, Business Context & Relative Scaling. I tried to explore the same in my presentation. As Martin Fowler puts it, you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.

Here is a link to the YouTube Recording of the session. Let me know what you think about these topics.

Practical communication strategies for software architects

Here is a video recording of my session titled Practical communication strategies for software architects on Bangalore software architect meetup.

The session covers communication ideas for various stages and to different stakeholders in a project scenario.

Practical communication strategies for software architects from Manu Pk

Have a look at the video recording of the session

An approach to help developers write meaningful tests

Over the last few years we have been adding unit tests to our existing product to improve its internal quality. During this period we always had the challenge of choosing unit-vs-Integration tests. I would like to mention some of the approaches we have applied to improve the quality of existing system.

At its core, unit testing is about testing a single component at a time by isolating its dependencies. The classical Unit tests have these properties "Fast, Independent, Repeatable, Self-Validating,Timely". Typically in java a method is considered as a unit. So traditional (and most common) approach is to test the single method of a class separated from all its dependencies.

Interestingly there is no hard-core definition of "what makes a unit". Many times a combination of methods which spread across multiple classes can form a single behavior. So in this context the behavior should be considered as a unit. I have seen people breaking these units and writing multiple tests for the sake of testing a single method. If the intermediate results are not significant this will only increase the complexity of the system. The best way to test a system is to test with its dependencies where ever we can accommodate them. Hence we should try to use the actual implementation and not mocks. Uncle bob puts this point very well, "Mock across architecturally significant boundaries, but not within those boundaries." in his article.

If the software is build with TDD approach it might not be a challenge to isolate dependencies or adding a test for your next feature. But not all software's built like these. Unfortunately we have systems where there are only few or none of the test are written. When working with these systems we can make use of the above principle and use tests at different levels. Terry Yin provides an excellent graphics (which is show below) in his presentation titled Misconceptions of unit testing. This shows how different tests can add values and what are its drawbacks.

Many of our projects uses Java and Spring framework. We have used springs @RunWith and SpringJUnit4ClassRunner to create AppLevel Tests which gives you the objects with all its dependencies initiated. You could selectively mock certain dependencies if you would like to isolate them. This sets a nice platform to write unit tests with multiple collaborating objects. we call them App level tests. These are still fast running test with no external dependencies. A different term was chosen to differentiate itself from the classical unit test. We also had Integration test which would connect with external systems. So, the overall picture of developer tests can be summarized as below,

Tests	Naming convention	Runs at	When to use	Exec Time
Unit Test	Ends with Test	Every build	Rule based implementations where the logic can be tested in isolation	Few Milliseconds
App Level Tests	Ends with TestApp	Every build / Nightly builds (Teams choice)	Tests the service layers in connection with others. Frees you from creation of mock objects. Application context is loaded in the tests.	Few Seconds
Integration Test	Ends with TestIntg	Runs on demand when a special profile is used in build.	All the above + Use when you need to connect to external points like DB, web services etc..	Depends on the integration points.
Manually Running Tests	Ends withTestIntgManual	Manually running tests, Used debugging a specific problem locally	All the above - Can't be automated.	Depends on the integration points.

This approach gives the developers choose the right level of abstractions to test and helps in optimizing their time. Nowadays my default choice is App Level tests and I go to unit tests if I have a complicated logic to implement.

Do you need microservices architecture?

Over the last few years there has been lot of attention on microservices. After the initial "hype" we saw that what problems it solves and what it can not. I have tried to cover what are microservices and where it can be useful and where it is not. I want to share the guidelines which can be used to choose between a monolith and microservices.

I feel that one must answer the below questions before they choose a microservices architecture and it will be beneficial to you if the answer to these questions are "YES".

1. Does your services represents different business cases/domains..?

2. Does the services needs to be deployed and managed independently..?

3. Does different parts of the application has different scaling/Technology needs..?

A modular monolith can be transformed to a set of microservices in case the need arises. So, we should start with monolith when we are not sure about the future.

Do you need microservices architecture? from Manu Pk

I have spoken couple of times about the microdervices. In April 2016, I spoke at the Bangalore Software Architects Meetup on the topic "Do you need microservices architecture?". Later in 2017 April there was a brief introductory talk titled, Introduction to Microservices at the Microservices and Serverless event. I hope this post helps to complement the slides.

Introduction to Microservices from Manu Pk