What we talked about
Muhammad Atif, CTO and President of PureLogics, has spent nearly two decades building over 1,200 products across 30 countries. In this episode, he breaks down what it actually takes to deliver quality software at scale and why most companies get it wrong.
Show notes
Today I’m joined by Muhammad Atif, CTO and President of PureLogics, a digital product development agency he co-founded back in 2006 with a mission to turn ideas into reality.
Full transcript
Federico Ramallo (00:00) Welcome back to the pre-Vered podcast where we spotlight extraordinary people and remarkable talent reshaping our world. Today I am joined by Muhammad Atif, his CTO and president of PureLogix, a digital product development agency he co-founded back in 2006 with a mission to turn ideas into reality. Over nearly two decades, Muhammad has helped build over
1200 products for clients across 30 countries with a team of 400 plus engineers and more than 400,000 development hours delivered for startups, SMBs and enterprises alike. Muhammad, welcome to the show.
Muhammad Atif (00:42) Thank you. Nice to be on the show, Federico.
Federico Ramallo (00:45) I’m honored to have you here today. ⁓ So for people meeting you for the first time, can you tell us a little bit more about what you do?
Muhammad Atif (00:48) Same here.
Yeah, so as you already explained, my name is Mohammed Atif. I’m the founder, CTO, and president at PureLogics LLC. I started this venture about two decades ago with my two other peers. We started with three people. Now we are a global company with 500-plus engineers. We are headquartered here in New York City. In simple words, we do the custom software development.
If I talk about industry, we are doing lot of work in healthcare industry, at-tech, and a bit of work in FinTech as well. We are ISO 9001 2015 certified. We have standard processes throughout the organization. And we are CMM level 2 placed, which means that we have pretty well-defined processes, SOPs for delivering the quality software applications. And the idea behind was that, know, Federico, a lot of
entrepreneurs, lot of founders, they struggle to find the right engineering partner who can take their idea, who can understand their, like what they are looking for to help them build the right MVP and then supporting them in all the future phases so they can grow. And during this journey, we have the customer who are working with us from past two decades as well. We started with them with very small idea and it has now grown up to a full grown business operational stuff and added a lot of value on both sides.
Federico Ramallo (02:11) Oh wow, so you accompanied from being a startup to now scaling the company.
Muhammad Atif (02:18) Yeah, so as I mentioned, we work as an engineering partner with them. We help them to digitize digital transformation to walk them through all their experience. And nowadays, we help them with AI workflow automations and making sure that they are adopting the AI in the right way.
Federico Ramallo (02:37) Right, right, amazing. And you started as a software engineer and now you became a founder, right? What makes you take that leap?
Muhammad Atif (02:47) Yep, I started back in 2005 after graduation as a software engineer. I know I started working in .NET at that time, Visual Basic .NET. Back in 2006, when I saw first time .NET released EGX, which can make asynchronous call. I was really amazed to see that the pages are refreshing and all that. Now, where we are.
So it has been great journey. The code engineering thing, the innovation thing has always been part of the journey to keep exploring, to see, what are the trends and how we can adopt that to make the life easier and to solve the problems.
Federico Ramallo (03:24) Amazing, And how do you work in terms of quality on how do you build software? How do you keep the quality on the software you build for your clients?
Muhammad Atif (03:37) Yeah, so I think the quality starts from the day one. So whenever we onboard a customer, we try to have some pre-onboarding calls with our customer. We try to understand their pain points. We try to document each and every step. And then we have a solid team of product owners and solution architect who design a complete solution. And after that, once we onboard that,
any application or any project, we follow agile practices where we try to have daily standard meetings, we try to have like sprint planning, sprint retro, and also we try to make sure that the goals that we have defined for each sprint, are being met. And we try to control the quality communication gap on time. And that is one of the reasons that we are able to deliver quality application. And as I mentioned at the start of this conversation,
We are ISO certified as well and we are similar to Appraise. So we have a PMO department, project management, operational department, who does the internal audits of teams, like all the projects that we are working. They can pick up any project at any time and they can do the audit in terms of like how well they are managing their project management tool, how well they are writing, managing their GitHub repository or Bitbucker repository. And along with those PMO audit checklists, we also have like
some code reviews, some automation flaws, which tells us about the quality of the code or the output that is being generated. So there are different check and balancing and audit processes that we have in place along with Agile, ISO, and CMMI to ensure that we deliver the quality and how do we stand out among the crowd.
Federico Ramallo (05:19) Right, right, because I think quality is one of the key issues with remote teams and outside custom software development companies, right? The time zone, right, yeah.
Muhammad Atif (05:24) Yeah.
the time zone. Yeah. Yeah.
And this is where the Agile comes in process. And this is where I’m telling that we jump into the, we try to bond with the client from the day one. We try to document everything. And then we follow Agile very recursively to ensure that we are not missing any data point. And we have real-time feedback. It’s not something that we…
take an application for six months and then after six months we are giving some demos to the customer and customer is surprised what is this. So it’s day to day interaction. So we build, we show to the customer, take feedback and move on. So they know that what they are building and it’s built according to their expectations.
Federico Ramallo (06:11) Right. Right. Yeah, I am.
I’ve been coding for many years, and it took me a while to… I was this old when I realized that I used to be more focused on the quality of the code. my code is beautiful. does… On the technical side, right? And then I realized that matters, but what matters most is to be able to…
Muhammad Atif (06:17) Yeah.
You
Bye.
Yeah.
Federico Ramallo (06:35) deliver value to the user. So understanding what is the expected behavior, being able to put that into automatic tests, and then making sure that we’re building something that is going to provide value to the user. What’s in it for the user? Once I understood that, then I’ve been able to work better with product owners to kind of …
make sure that World War Building would make sense for them, right?
Muhammad Atif (07:03) Yeah, and I think another challenge that I have seen, Federico, that if you are trying to build an application where you don’t take care about technical debt, I mean, that is another major issue. And technical debt can be part of the application due to different reasons. I mean, it can be due to the business pressure that we have to launch it as soon as possible. It can be due to the poor planning or prioritization. It can be due to poorly written
code. It can be due to legacy issues that we are using old version of Python or Java or .NET or any outdated library. It can also be due to the lack of technical documentation that we have key documentation missing and if new team members are joining or if they are leaving so we don’t have any base that we can set as a base. And then the lack of automation. So these are the things that I have seen over the time. And then there comes a stage that when
when the customer says that, or the tech team says that we have to rebuild this application, we can’t further maintain or support this application. So this is very important aspect. You can’t eliminate tech debt, but you can minimize, you can manage it. And there are practices that a company can follow through that they can manage their technical debt. So if you really want to manage the quality over the time, tech debt is another area.
besides communication, agile and everything that needs to be managed to ensure that we have a stable application on the day end.
Federico Ramallo (08:33) Right.
Right, I completely agree. I think that sometimes we measure tech debt on terms of test coverage. we have low test coverage, then we have a lot of tech debt, which in part it is true, but I think that we’re measuring the wrong thing there because test coverage is on a line by line of the code, right? But are we test and we can have a green light on the release, but are we
we testing the right things? Are we actually testing what is the expected behavior of the application? I usually use this example of you go to the ATM, you ask for cash, you want cash. If the UI has a little bug or there are non-critical issues, they become less relevant to do I have the cash or not. Being able to test the right things becomes much more important.
Muhammad Atif (08:58) Yep.
Yeah.
Federico Ramallo (09:21) I work on these projects where we had this both unreliable CI where sometimes it’s green, sometimes it’s red, and we don’t know why. We have all these tests that we’re testing, and when you start reading them, you realize we’re not testing the expected behavior of the application, what the user expects from the application. So, refactoring all that to actually test that makes sense.
Muhammad Atif (09:31) Mm-hmm.
Federico Ramallo (09:50) which it is aligned to what BDD does, right? You build the test first. But that’s more about how we think about building the software. But what I’m thinking about is making sure that we’re testing the right things, right? ⁓
Muhammad Atif (10:03) Yep, testing the
right thing and also ensuring that we do have the right design about architecture. Like if I’m building an application which needs to deal with a lot of data and that is having a lot of AI or algorithm, I can’t choose a stack which doesn’t support all the future updates or enhancement. So I have to be very careful in choosing the database, the tech stack, the programming language and everything.
Federico Ramallo (10:31) that’s true. having solid foundations so you can build the features, it’s more important. Yeah, future-proof the application, yes. How have you seen, you know
Muhammad Atif (10:36) Yeah.
proof.
application.
Federico Ramallo (10:47) test automation and quality assurance in the world of AI when we have this non-deterministic process, how can we make sure that this non-deterministic process will actually deliver the expected behavior that we want?
Muhammad Atif (10:55) Mm-hmm.
Yes, I think if I, to be honest, I think these all automations, whether it is testing the usability, testing the functionality, or testing the security, compliance, or load testing, I think these all tools have made our life easier. We don’t need to have a dedicated human sitting to test all the user flows and everything. We can just automate these flows, do the scripting one time.
and next time if I’m releasing a new release I can just hit the button run the test cases if all green lights it’s good to go to the release if anything is broken it will just alert me you need to be careful a human can miss some of these cases but I guess these automations they can’t miss anything so but but you have to keep them up to date like whatever new features or at least your sanity checklist or the code feature which is the backbone of the application
They should always be automated in terms of look and feel, terms of code features, back end. And if your application is heavy on the user side, like you have a lot of user and it gets slow during the peak timings, you can do the load testing using the load runner and some other tools. If your application is compliance and security heavy, like you’re working in FinTech, banking or healthcare, you need to make sure there is no gap.
on the security and compliance side. So you can use these tools to pen test your application and if there is any vulnerability or any issue, it can pre-highlight before it goes to the production. So I think AI and these tools are making our life easier and it’s making less dependent on the human. We can keep the human in the loop, but still like it’s making the life easier.
Federico Ramallo (12:45) Right. Yeah, the automation that we’re getting now are amazing, and we’re getting better and better tools to automate and make sure that what we’re building makes sense. I’ve seen leaps of improvement throughout the years. I started coding with ASP, you mentioned .NET. I started with ASP. I helped launch
Muhammad Atif (13:00) Yeah.
Federico Ramallo (13:07) .NET and all the other languages back in 2000 something in Argentina. I was working at Microsoft, so I was part of that movement. And all of this was in an era that was before we had a strong non-linear revision system. I don’t know if you remember, you had to check in and check out.
files so you could make changes.
Muhammad Atif (13:31) Yeah, I remember a bit of ASP
like where you have to embed tag inside the HTML and you have to manage memory, you have to manage sessions. know every new page you have to manage the state of the page as well where you left off. And I think it was a lot of pain at that time to even to do the simple pagination for a logged in user. was sorting on simple table form. It was a lot of job at that time.
Federico Ramallo (13:39) Yes.
Yes, it was similar to what PHP is now. It’s kind of spaghetti code. You just have HTML code, SQL, all of that together. We come from that. We would actually make changes on the file on the fly, and you would see the changes in real time, similar to PHP. ⁓
Muhammad Atif (14:03) Yeah.
Yeah.
Federico Ramallo (14:21) Now that we have versioning control, we have CI, CD, we have so many tools that help us automate the workflow and make sure that what we’re building actually it’s safe to launch.
Muhammad Atif (14:32) Yeah, I think now we have the luxury that if I’m releasing a new piece of code, I can link my pipeline with SonarCube or any other code review. It can test the code quality. It can alert me. Then I can link it with our test automation pipeline. It can tell me how many test cases are passed or if any of them failing. It can deploy. even after the deployment, if something is broken, it can roll back to the previous table built. So…
Back in the days, this was all manual, but I think these all things have made the things possible, more reliable and more robust now.
Federico Ramallo (15:08) How do you work to make sure that the requirements are clear throughout the whole process to make sure that the developer understands the whole context in order to build the software, right?
Muhammad Atif (15:14) Mm-hmm.
Yeah, so I think this process start of Frederico at pre-sale stage. So we have discovery sessions. So during the discovery session, we try to understand like, what is the core, first of all, idea? And are you trying to build something new? Are you trying to build a competitor application? And if you are building a competitor application, what is the ROI? How your idea is better than the existing? Like if I say,
I wanna build clone of Guru Dash or Uber. So why? It’s already there until I’m offering something different. And then like, what are the core features? Who are the core users? What is the look and feel? What kind of like hosting do we need? Is it going to be on-prem, on-cloud? Or is it going to be hybrid? What kind of technology preference do we have? Talking about the look and feel. Is it going to be a mobile application, desktop or web-based application? Or is it going to be just a backend utility?
So we tried to capture all these points. Then we have a team of business analysts and product owners who try to format into a complete roadmap. And then once we log that with the customer, we are on the same page. Then we try to do some user flow diagrams. We try to do some architecture diagram. We also build some flow diagram. So we have the clear understanding on all the flows. And when it comes to the development or execution team, normally our team consists of a Scrum master who is the
You can say captain of the ship or the project leader who leads and is responsible for deliverables. And then we have a mix of team depending on the requirement. It can be front end, back end, or mobile engineer, including a partial QA and a DevOps. So that team try to follow Agile. So what they will do, they will pick up first of all, the very first print. They will try to define the epics. Under the epics, they will try to define user stories and all the tasks.
And this will all happen in the sprint planning meeting with the customer and taking all the feedback from customer side, from the internal team. They try to groom the stories and tasks as much as possible. Then they try to estimate those based on story points. And then throughout the sprint, when they make progress, they keep logging their input or day-to-day progress. That shows the complete burn-on chart. So I think this is a very systematic process. And then the continuous feedback that is coming.
through the Trello or Jira or whatever, monday.com or Asana we are using. So having all the right stakeholder on that and everyone is seeing, okay, at the end of the sprint, how many story points I have delivered, what is the open rate, what is the bug rate, and who is doing best, what is not, who is not doing best. And then also getting the core reports from code review tools like SonarCube. So mixing of all these parameters.
ensure the quality if there are any gaps or there is an improvement needed we try to like fill those gaps. I’m not saying it’s always 100 % success but there are these are the processes and measurements that help us to reduce the requirement gap.
Federico Ramallo (18:19) Right, right. I think that that process is, I’ve been on those processes and it’s a very well thought out process. Going through, being able to.
process requirements before they get to developers, getting the Scrum Master to coordinate everything, and then having a QA involved. So whatever we’re launching, it’s verified. think it becomes important. The other thing I learned to appreciate more is the definition of done and acceptance criteria, because…
most of the developers, especially the juniors, they say, but I’ve seen it senior as well, say, it works on my computer, right? So that’s great, but it needs to work here, right? So having a mature definition of them becomes much more important, right? Yeah.
Muhammad Atif (19:03) You
Yeah, so I think that comes to the again basic that you need to have a well-defined user story. You need to have a grooming session. A user story should be telling like what a user is able to perform after this feature is delivered and definition of done. DoD is very important part of that and also along with that we need to define priority any kind of dependency it can have and then who is the owner and
any kind of reference example. putting those, all these like attributes to a user story and I think this is where the product owner role is very critical. Whether it is played by a customer or in-house team, they play a critical role that they need to delegate it properly. Right? And I see there is a gap sometime here come as well that a product owner, whether it’s a customer or it’s in-house team, if they are not able to
fully elaborate the user story. The developer is already looking for shortcut to the point things. They will not ask sometime question as well. They will just say, okay, my job is just to write the code. I’m not going to like ask for any clarification and all that stuff. Yeah.
Federico Ramallo (20:24) Right, right. One thing that stood out when you were explaining your process is that
you’re doing the handoff between the pre-sales and then the technical team because I’ve seen projects like where the sales team over promise and then the technical team has to figure out how to build and that usually affects the quality. But in your case of having that handoff so then the scrum master and the scrum team can…
Muhammad Atif (20:46) Yeah.
Federico Ramallo (20:54) can work towards requirements and making sure that I do the grooming backlog and making sure that they can make a commitment that it’s achievable, right? And doing it with the client, I think that becomes much more important, right?
Muhammad Atif (21:09) Yeah. And I mean, still you, we try to involve sometime our execution team in preseal as well when the things really become critical to ensure they are comfortable and they understand. And we make them part of like at least the commitments that we are making. So it’s not something like totally new for them that we just tell them, do this. We have closed already. So they are somewhat part like 10, 20 % already during these.
especially technical discussions so they are comfortable when they are executing.
Federico Ramallo (21:41) Right. I wanted to ask you a question about other topic. What is the biggest mistake you’ve seen companies make when they’re hiring a software development partner?
Muhammad Atif (21:55) Yeah, so what I have seen that there are like multiple scenarios, but one thing I have seen that they are not looking for the right expertise in that particular industry. Like if I give example, like if one of my customers, they were looking to build a claims engine in the medical stuff. So they try to hire a team.
who are technical enough, but they don’t understand the industry jargons, like how this industry works, what are the compliances, how the things move from one place to other thing. And I have seen personally, the client spent over six months just to explain the core business logic. And it was just time wastage. I think when you are deciding the right vendor, you also need to see the relevant work history.
and experience in that industry. That can be a plus game because they have already gone through that pain. They know the jargons and that will save you a lot of time at the time of launch or production. Maybe you’re missing some critical part. So that is one of the main reasons that I have seen that should be part of the decision making.
Federico Ramallo (22:57) Right. And how do you help a client who has a great idea but is not sure where to start?
Muhammad Atif (23:04) I think there are two types of clients. One is technical, other is non-technical. Some people, the technical, the one who are technical, they are well known and they come mostly prepared what kind of tech, what kind of architecture they want you to go with. So they have done their homework. So it’s easier for them. But on the other hand, the one who are not technical, but they have a great idea.
So we try to help them through different diagramming, through different prototypes, POCs, visuals, so they understand what the end product will look like. And before we lock the deal, we want to make sure they are comfortable and we are on the same page. We are not making any commitments which we can’t deliver on a later stage. So having those different visuals, it can be low fidelity diagrams, low fidelity mockups. It can be visual like floor diagrams or architecture diagram that can help.
those founders or clients to understand what they are going to get in terms of final output and they can refine on top of that as well.
Federico Ramallo (24:03) Right, right, I usually joke about this idea that there is no.
there is no debris in software. We built something, and if we have to rebuild it, there is no debris. But if you build a house and you put the wall in the right position, you have to tear apart and it again. Now you see the debris. I think that starting with mockups and having the blueprints of the application, basically, goes a long way to make sure that…
Muhammad Atif (24:13) Yeah.
Yeah.
Federico Ramallo (24:33) By the time the teams start coding, they have a clear understanding of what they need to build, right?
Because that means that they can just hit the floor running because now they have all the requirements, there’s no back and forth, there’s no, know, tell me more, it’s just, this is what we need, this is why, go for it, right?
And what difference have you seen on working with startups and working with bigger enterprise clients in the way they build software?
Muhammad Atif (24:59) Yep. I think startups, they have certain timelines in their mind. They want you to go quick to the market. They are always working on some new ideas and working with startup is always innovative because they are trying to solve some good problems. yeah, so these are the things that I have seen with the startup. But if I talk about enterprises, they move a bit slow.
but they are pretty organized and they are heavy on compliances, on security side, on processes side and they love these kind of things. I mean, they want you to make sure that whoever vendor they are working with, they are well organized and they are adaptable to their practice and sometimes some vendor have training programs or onboarding program that you have to go through in terms of their security, compliances or certain processes they want to follow.
So yeah, that’s the main difference I have seen working with enterprises versus the startup.
Federico Ramallo (25:52) Right, right. Yeah, I’ve seen similar things with bigger enterprise. They move slower, but they expect higher quality on the product, on the software we built.
We have compliance, have a little bit more of red tape, more thorough testing before it goes live, right? But once it goes live, they scale it up much more, right? So they want to make sure that there are no failures on the new feature that we built,
Muhammad Atif (26:27) Yeah, they want to move slow, but they want to make sure that things are stable. But in case of startup, they want to just release, they want to keep pivoting, they want to keep experimenting, release, take feedback, keep pivoting, and move on.
Federico Ramallo (26:41) Right, Yeah, on startups, what I’ve seen happen on my experience is they want to take shortcuts, which sometimes we can, but sometimes I have to push back on saying we can, it’s, you know, but we have all this risk if we do that, right? Whether it’s security or performance or whatever, right? And I feel that I should.
Muhammad Atif (26:54) Yeah.
Federico Ramallo (27:00) highlight those because it could be a blind spot. Because they have the date on their mind, in front of their mind. It’s like, we have to launch this set of features by this date, at whatever it costs. And I sometimes try to push back and say, yes, we can work on that, not at whatever cost. need to make sure that it’s safe, that it’s reliable, that it’s stable as much as possible.
Muhammad Atif (27:02) Yeah.
Mm-hmm. Yeah.
I think budgeting is another issue. Startups have certain budget limits and they need to play within that. And in case of enterprises, though they have allocated budget, but in order to achieve that certain level of quality, it’s negotiable that we can extend the budget accordingly.
Federico Ramallo (27:39) Right,
when a client asks me, you build this stuff, whatever it is, ⁓ I’m like, yes, with infinite budget, they can build anything. Now, what’s your budget, right? And then we talk about budget, Yeah, yeah, yeah. And then with that budget, then we can figure out, OK, how much of whatever they want to achieve we can build, right?
Muhammad Atif (27:43) Mm-hmm.
Yeah.
Federico Ramallo (28:00) So how do you think AI has changed the way companies are building software?
Muhammad Atif (28:06) Yeah, so I think starting from 2023, you know, it was all about prompt engineering. Then came 2024, 2025, it became about wipe coding. And now we are talking about agentic, that having a team of developers which consists of human or base developer and some agentic developers working in parallel. So things are changing quite rapidly. And I think…
Nowadays, software development is all about adopting these tools, ensuring that we are taking the maximum leverage. And if we do it right away, an engineer can do 10x productivity, where we need to have a complete set team of engineers. Now we can use these tools and I think it can really expedite the output.
Federico Ramallo (28:56) Right, right. I interviewed an engineer manager. She said that she spends more time reading code that agents wrote than writing code herself, right, which is aligned to what you’re talking about.
Muhammad Atif (29:04) Yeah.
And I think this is the future that we need to be adaptive accordingly, especially with the latest release of Anthropic Cloud Code. I mean, you can launch multiple agents and sub-agents and you can define certain tasks per feature for them. And it can build your skills for certain part as well that are reusable. And that can be your templates as well that you can launch a new project. And if you want to
have the same skill like for payment integration or SSO, you can reuse those kind of skills as well. But on the other hand, you also need to make sure the compliance and security part is really taken seriously. We can’t give everything on the AI end. We need to have human in the loop. Because we, Peologists, work a lot in the healthcare. So the security, the HIPAA compliances, and all these different security protocols that we have to follow.
we make sure that they are not being overlooked and there are no vulnerabilities in terms of like prompt injection or anything else that can cause a lot of issue at a later stage.
Federico Ramallo (30:16) I see. Yes, the prompt injection is becoming an issue now, ⁓ particularly in HIPAA compliant projects where ⁓ the amount of information that we can expose, we have to follow the compliance, right? And we cannot expose patient information that they’re not supposed to access to. There’s so many, many things like that we need to take care of, right?
Muhammad Atif (30:20) Yeah.
Yeah.
Yeah, and HIPAA is like, you know, it has four major rules. One is a privacy rule, the second one is security, the third one is enforcement, and the last one is breach notification rule. The privacy rule says that as a developer, I can’t see any patient’s data without context, even if I’m troubleshooting and I need to see if something is going not okay with the patient information.
The second rule is security rule. We need to have all the best practices for security part. And then the enforcement’s rule that we need to ensure that we have the HIPAA rules and policies enforced on the server side, database side, core side. And if there is any breach, any kind of vulnerability, it is being notified and rectified at the right time. So if we consider that in terms of like, if we give everything to the agent to write the code and architecture,
I think there will be a lot of vulnerabilities. So the human has to be part of the loop to ensure that we are covering HIPAA end-to-end.
Federico Ramallo (31:39) Right, right, I think that’s where the guardrails becomes much more important for models, right? We have to be more strict on that, Yeah, I built a HIPAA compliant project from idea to launch. And I worked through the, we had to encrypt the memory of the database to make sure that no…
Muhammad Atif (31:46) Yes.
Mm-hmm.
Mm-hmm.
Federico Ramallo (32:03) data was exposed and then put audit logs to make sure who would have access to the servers, right? So because as a developer, we needed to have access to servers for troubleshooting, but we had to log every time we were in it, had to be logged to remote servers. we could have documentation that who…
Muhammad Atif (32:07) Mm-hmm.
Federico Ramallo (32:22) who had access when, where, and why, right?
And then I had to write the BAA, the Business Associated Agreement, to make sure that we were compliant. And then we passed the audit on the first time, which was amazing.
Muhammad Atif (32:39) Great,
great, awesome. Yeah, and I think when you are implementing the AI, like any kind of application, you need to make sure that the NIST and OSAP and some other disk management framework for LLMs and AI, they are being followed. We have seen cases like the bank staff is like putting all the like sensitive customer data into the personal GPT accounts and taking the decision.
As a developer, if I’m coding and I try to paste any sensitive coding or customer data into personal GPT and try to get some suggestion on top of that. So we need to have proper security guardrails. First of all, we need to have enterprise-level or team-level accounts with these GPT accounts. And then we need to have policies defined who is using what kind of why by agentic to help them in the engineering.
and what is the percentage being used, if they are sharing any sensitive data. So we need to have more data and we need to have some defined processes using this AI. It’s the same like the way people are buying personal Mac minis for deploying Cloud Code work, so it can work its own. They are not deploying it directly on their first computer because they are aware that it can…
like steal any other information or can do any prompt injection. So we have to have like certain policies. I can say it’s AI policy, AI engineering policy at organizational level and it should be adopted with all the security guardrails.
Federico Ramallo (34:19) Right. You’re talking about sandbox environments.
Muhammad Atif (34:22) Sandbox or team environment, like if you are a project manager, you can see, on your healthcare application, there are four engineers working and there are two boards. How much agent code they are writing, how much code is writing by them, and for what purpose they are using, what kind of commands they are giving. So you have full visibility on the admin control, whether you are using Cloud or Anthropic or maybe Cursor or any other tool.
So all these dashboards come with the team package that you can monitor your teams performance, usability, and all these parameters.
Federico Ramallo (34:55) That’s amazing. Talking about developers managing agents writing code. I’ve been trying to figure out this. How much is using agents and augmentation and when?
Muhammad Atif (34:57) Yeah.
Federico Ramallo (35:11) it’s become a crutch, right? That people use it instead of… So they look like they know their stuff, but in reality, they’re over relying on an agent or a model to come up with the answers, right? At what point do you feel that the developers are, you know, go from driving to the backseat?
Muhammad Atif (35:27) Yeah.
I think we are already seeing this is happening and this is where a lot of tech tech is being added. And the example you were giving that one of your engineer you were entering telling you that they spend more time to see the code written by these agents instead of writing their own code. but it has become a new like way of working. So I think engineers are these architect they need to adopt and they need to make sure that
Whatever code is being generated through vibe or agentic, it’s to the point and they are not adding too much garbage or detected to the end product and they are not relying on that and that can cause a lot of compliances, security or performance issues, like on certain PCs or certain complex functionalities.
Federico Ramallo (36:25) Right, think that…
We had the experience of working in these lowly automated environments where if you make the wrong move, everything breaks. With .NET, with ASP, we have those issues. Or no versioning, which was the other issue. So we have that experience of understanding what we need to build or reading a function and understand that it’s very inefficient.
Muhammad Atif (36:34) So.
Mm-hmm.
Federico Ramallo (36:51) So I think that to your point, the developer should be able to review the code and be accountable for the code that they generate through the agents as well,
Muhammad Atif (36:58) Yes.
At the day end, developer has to take the ownership. They need to be responsible for the end deliverables.
Federico Ramallo (37:06) Right, right. So at the end of the day, doesn’t matter if they worry to themselves or the agent. It’s just about that they are the owner, right?
Muhammad Atif (37:18) Yeah, and this is where like defining the AI policy, we need to make these things clear. The role of agenting or wipe coding versus what is the role of the developer? Who is the end, like auditable or unsalable of the end product?
Federico Ramallo (37:32) Right. Yes. I do the same with my, know, so for instance, if I write a piece of code, I can provide the agent the instructions of what I want to build and what I want to achieve, right? If I ask the agent how, then the agent could go, know,
We can spend a lot of time trying to figure out why and the answer I’m going to get is going to be very generic that may not apply to my particular problem, right? That’s where I think that we are using the agent as a crutch instead of we leading, right?
So what is one leadership lesson that you learned throughout your career that you could share with our audience?
Muhammad Atif (38:13) Yeah, so I think what I will say that don’t optimize for performance before you fully understand the constraint. Sometimes we try to start optimization too early and that can like not lead to the right results. And yeah, I think this is the one of the lessons that I have learned.
Federico Ramallo (38:34) Amazing. What advice would you give to a founder that is starting to launch their first product?
Muhammad Atif (38:42) Yeah, so I think I will give the same advice to you have learned from the lean startup that try to focus on the core like a problem and try to deliver that. Then keep pivoting and keep iteration based on the real customer feedback. Don’t try to build everything or extra features that are not required. Like just focus on the core problem or core feature that the problem is solving.
Just focus on that, deliver that, launch, go to the market and then keep repeating.
Federico Ramallo (39:16) Right. Right. Yeah, I read the book, the Linster book. It’s amazing. And this idea of validate, validate, validate. It’s, you I have to repeat myself. Yeah.
Muhammad Atif (39:25) Yeah. I have seen some
founders, they try to build all the balance in the initial shipment. And sometimes they just go deep focused and end up wasting a lot of time and money. And at the end, sometimes they start blaming the engineering partner as well on that part. So I think that is the thing, that they need to keep their focus sharp on the core problem first.
Federico Ramallo (39:51) Right, right. And moving through validation becomes much more important, right? Because we want to build. I I love building, so I usually get distracted by building and I get into that situation where I built more than it was necessary to prove that it was, you know, to validate that there is a need for this.
Muhammad Atif (40:07) Yeah.
Yeah.
Yeah, they need to find the right market right fit if it works. If it solves the problem, then they keep adding the features based on the real customer feedback.
Federico Ramallo (40:22) Right, right, yeah. And great product owners can help on that, understanding what are the, once you find that product market fit, once you have a little bit of traction, product owners can help you on understanding what is your user base and what they want to build, what they want you to build next.
Muhammad Atif (40:41) Yep. Great.
Federico Ramallo (40:45) So one last question before we wrap it up. What advice would you give to your younger self at the start of your career?
Muhammad Atif (40:52) Yeah, so I think the advice that I will give is.
It can be related to specific engineering, or it can be anything.
Federico Ramallo (41:00) It’s your career so it can be about what you feel best.
Muhammad Atif (41:04) Yeah, I think the advice is that don’t look for shortcuts. It’s try to play a stable long-term game. yeah, I think there are certain things that come on the time. So try to be patient. Yeah.
Federico Ramallo (41:23) Amazing, Mohammed, I’m truly honored to have you here today. I knew we were running out of time, so I wanted to wrap it up. But I’m honored and thankful for having you here today. Any final remarks before we wrap it up?
Muhammad Atif (41:43) Thank you, Federico. It was nice to talk to you. think this was really helpful conversation to unfold how this whole journey started and what are the current challenges with the AI and everything. So yeah, looking forward to have more in-depth conversation in the future if we get the time.
Federico Ramallo (42:03) That be lovely. I’m looking forward to that. We’re going to leave the links for PureLogix and your LinkedIn profile on the description so people can reach out and connect with you.
Muhammad Atif (42:13) Awesome. Yeah. Looking forward to that.
Federico Ramallo (42:16) Thank you.
Muhammad Atif (42:17) Thank you, Federico.