I've actually gone through some sort of an existential crisis, to be honest, where you kind of think what the hell is going on and where is this all headed, sort of thing.
I think we are headed
people need to start thinking product more.
Yeah.
product engineer thing is really kind of happening.
Yeah.
Guru prasad Venkatesh, Guru to his friends, joined the ThoughtWorks Bangalore office in 2006, where he continued to work for 12 years.
Guru and I got to work together in Cincinnati, Ohio for Kroger, the big grocery chain.
After ThoughtWorks and a brief stint at Cloudera, Guru went on to co-found Beskar Technologies, where he serves today as chief architect.
In addition to their custom software development services for customers, Beskar is also building Baid an agentic AI dev tool, and
Guru is our guest today on the Engineering with AI podcast.
Guru, thanks so much for joining today.
I really appreciate it.
Hi Kyle, yeah thanks for having me here.
It was really nice working with you as well at Kroger in Cincinnati.
For sure, those were the good old days.
I remember you endlessly running JMeter to fix performance problems that the team and I had made.
So thank you.
So let's kind of start with you.
Yeah,
Beskar there are two other partners that we started Beskar with.
And one of them, Jake, is an ex-thought worker.
In fact, he was the one who referred me to ThoughtWorks back in 2006.
And interestingly, we are school buddies.
I've known him from my third grade, third class, class three to class eight, after which he moved out our town.
His dad got transferred to Gujarat.
And we kept in touch after that.
And he came back to Bangalore.
And he had started this other company called Mavenhive once he left ThoughtWorks.
And that got acquired.
And then he wanted to leave that new company.
And then I had left ThoughtWorks and joined CloudEra because I was very interested in data engineering and data science and that domain.
But then after
I think one and a half years at Cloudera I decided to move on and at the same point he was leaving his new company.
So we both got together and decided that, yeah, I mean, he always was, tried to hire me into Mavenhive.
And then at some point we decided, yeah, it's a good time to start.
So him, Nitin is the other partner and me, we started Baskar.
the core...
philosophy, mean the ideas, the way we work, it's very ThoughtWorks influenced because a lot of, mean the folks that we worked with spent many years at ThoughtWorks.
Yeah, so it's pretty, it's quite interesting.
We've not grown a lot.
We're just like 14, 15 strong after five years.
Yeah, so that's the best.
When you say ThoughtWorks like some of our audience will know what that means.
For the rest, I think very extreme programming oriented, so test-driven development and continuous integration, continuous delivery.
the other thing that comes to mind for me is,
very different hierarchical or no hierarch.
I remember telling everybody I'm sure I didn't have a boss for a lot of years, like where I didn't know who my boss was at least, and pretty sure I didn't have one.
So I wonder like how about those parts?
did that also come through?
Yeah.
Yeah, yeah.
I mean, I think that's one of the things that I had a hard time dealing with after I left ThoughtWorks because it's so transparent and you don't actually report to anybody or ask
anybody for...
I mean, you share your leave plans beforehand, but apart from that, there's nothing.
Yeah, mean, so Beskar is, yeah, it's similar.
We three are partners, but we are the same.
We kind of work on projects just like everybody else.
We don different hats.
in pursuing leads, like I might play the tech architect role when somebody is asking for an RFP for a new project, things like that.
Jake might be involved initially.
It actually totally depends.
But it's pretty fluid and we've kind of grown organically as well.
And the ways of working that's very thought works influenced in the sense that, like you said, it's very extreme programming.
very visible short sprints like we try and show our work as often as possible yeah all that good stuff
Well, I like to start with how you personally are using these tools and being the chief architect, like maybe you're coding every day still.
You tell me, but I can tell you probably got some use of these tools.
So what do you like?
Maybe a little bit about like what
languages you're working in, but more importantly, what Gen.AI tools are you using and what's working for you and what's not working for you?
What do you like, personally?
Yeah, so I've kind of dabbled with LLM's Gen.AI from GPT 3.5 days, like 2022 initially when it was released.
at that point, we working with
this company that was trying to solve interesting problems in the recruitment space, trying to improve an interviewer's process and make interviewing better And this LLM GPT
3.5 fits so perfectly there because they were trying to summarize interview notes and do things like that that actually help in the interviewing process.
And this is even when lang chain was not a thing.
So we had to develop our own.
AI client that now people call agents.
So essentially that had to build that system and use a prompt and keep sending it to the LLM to give back answers.
We had to interpret answers, build those chains and things like that.
So yeah, mean, at that point, it was very interesting, but I didn't have a lot of confidence because there were so many hallucinations and...
you ask it for a yes or no answer and it kind of always, that doesn't give you that consistently, right?
But then it kept improving.
That's what I've seen over the years.
And one of the things that we used is the function spec, wherein you can say that I want the answer in this format and you can share a function spec with it.
So that improved the quality of answers and things like that.
personally, I've used ChatGPT right now.
I use ChatGPT for a lot of the personal stuff.
like managing health or basically asking it for diet.
I go to the gym so it kind of plans my meal plans or workout what I should be doing and things like that.
In fact, we were discussing some product ideas around that.
But yeah, I use Claude code heavily.
And Claude code is one of the best tools, think, out there.
Played around with WindSurf a little bit.
Yeah.
with GitHub Copilot.
I thought it was really, really good.
Magical, basically the way it kind of generated your code based on context.
But at that point, my thought process was that it is good for eliminating the need to write or type plumbing code.
So based on the code in a file, can just auto-generate stuff.
But it kept getting better and better.
with Claude Code, in Beskar, I've been the most skeptical in using any of these tools.
And I've always been played the devil's advocate when people have conversations around this saying, about this?
It made this mistake and things like that.
And I still am quite skeptical.
But yeah, Claude Code I think, is very powerful.
And that's what we use on a day-to-day basis.
Yeah.
And also one other really powerful tool is Kiro I don't know if you've kind of heard of it, it is primarily a spec-driven development tool.
It is like, yeah, yeah, yeah.
So it's basically based on Visual Studio Code and...
they've introduced this workflow.
So they are kind of having an opinion on how you should go about using AI agent in code coding assistance.
So it starts with writing a specification and then that gets converted to your user stories and then tasks.
And they have this sort of a markdown template where you can go and click on a task and say, want to execute this.
So I found that to be really useful.
And I think that's the way we are advocating the usage of Claude Code as well right now.
So yeah, think Claude Code is the primary coding tool we're using.
That's interesting.
The first mention I'd heard of Kiro, we had Tim Cochran on the show recently.
I think he's the latest article right now, though Chris Ford's will drop on Sunday.
yeah, and he uses it because he's at Amazon, right?
And they're the ones that make it.
And I think there's a rule.
I think they have to use it.
I don't think they have an option.
And so, but you're actually almost telling me more about how it works than he did.
He just sort of assumed some knowledge.
Anyhow, you're making me want to go try it.
That's cool.
do you use it somehow in conjunction with Claude Code or you, or it's just sort of like, nah, you, you like the spec driven in part, but it's, it's not as good at code.
So you don't use it.
Like how, help me tease out your thoughts there.
Yeah, mostly it was an experiment with Kiro Just to was curious on that way of working.
Because it sounded really interesting and in line with the way we do things usually.
Like we don't kind of give a general prompt and say, hey, build this whole entire system.
We kind of break it down and then do it a uh thin slice and in iterations.
So.
Yeah, I I've played around with Kiro but haven't used it heavily, to be honest.
And one of the distinguished engineers in Amazon who I follow, he was kind of advocating Kiro.
And that's how I got to know about it.
And I was interested in learning about it.
Cool, cool.
I like how you talked about originally as plumbing code.
I think one of my first ever interactions, it was actually ChatGPT that made me think, wow, this thing can write code.
I was working on an aviation project and I wanted to deinterlace.
radar signals.
I had, it looked like I had an airplane that was jumping all over the screen and it didn't make any sense.
But what was really happening is it was a time signal from 10 a.m.
and another signal from 11 a.m.
that had been like merged as though it was a time zone problem, right?
And so the 10 a.m.
flight and the 11 a.m.
flight were like being merged like a zipper together and that's why it didn't make any sense.
So I went and asked Chat GPT like is there math that can help me do this?
And it was like, here's the history of radar and how this has worked.
I'm like, oh, and then at the end, here is like 25 lines of Python and they worked.
And that was like one of my first introductions to like, yeah, this thing, this is more than just, you know, vibe coding.
There's something really here.
Yeah, but like you say, the plumbing code, taking the drudgery away, I think that's an early like win, I think, that gets a lot of people interested.
Yeah, but it sounded like you're doing more than just plumbing code now, but you also said your approach is normally to break things down into smaller pieces.
Can you talk more about what sorts of guardrails you do use when you're approaching things?
Yeah, so I don't write a lot of code on a daily basis now.
I'm mostly involved with client, maintaining client relationships and architecture and things like that.
So I use Claude in the plan mode mostly just initially to come up with ADRs.
Basically, you use it as a bouncing board just to figure out what the architecture options are.
trade-offs of you going down one path, uh things like that.
And it's very good.
It's very powerful because it's yeah, it's like talking to another senior developer and bouncing off ideas, right?
So uh that's very good.
But yeah, when I have done development, I start out with plan mode and try and, like, if I had to do a big refactoring, right, where I wanna migrate.
Like I want to improve the quality of code in certain parts of the code base.
I try and break it down and basically ask Claude Code in the plan mode to do it.
And then it comes up with a plan and then I kind of review it and then go and see what can be improved there.
And then do it step by step.
think the idea is to avoid making big bang changes as much as possible.
Yeah.
keep things a little more controlled because it can actually go berserk sometimes and it also sometimes complicates things.
Like you have to point out that the problem is already solved in a script somewhere and you can just reuse that rather than write another new script.
Things like that.
I have fallen in this trap where you kind of give it access to everything like AWS CloudWatch logs.
go and look at your CI failures and everything.
And then you keep saying, yes, yes, yes to our whatever it does and then become lazy.
It actually does a decent job most of the times, but it can get into a loop and the solution usually is very simple.
Like it would have been using the wrong binary on your machine.
Like that's built for Intel rather than for, and then it'll crack its head.
And then I'm like, yeah.
It just keeps working hard.
There's a lot of trial in the way it does things sometimes.
And I think when you step in at that point, you have to nudge it.
whatever we have thought of and ideas that we come up with, we see that Claude or Anthropic.
They implement that in a week or so.
So every week, they come up with these features that are kind of really...
very powerful, like for example, the skills feature, or you can have your own agents, or the tools you can use, the memory tool especially, things like that.
recently we've started to do trainings with companies where we kind of train on how to use coding agents like Claude code effectively.
One of the main things there is to do this breakdown of tasks into small tasks and then use the plan mode, use skills, use memory as much as possible and try and be efficient
about the usage of context basically the idea is that you have this sort of structure in the way you approach.
you're utilizing Claude Code and have certain things in place, like a skill set, basically workflows for solving various problems, very, very different hats, like for example, a QA
hat or a Cloud Architect hat or a security SecOps hat.
And then look at your statement, like basically problem statement in these different angles, right?
Yeah, so some of that.
like saying, Claude, act as a quality assurance person in that kind of style where you're giving it like an agent's description.
Yeah, got it, got it, got it, for sure.
that this particular folder has some changes that are related to authentication or RBAC or things like that.
And we want to be doubly sure that we're not breaking anything.
So essentially, you ask Claude to execute a story that is maybe related to introducing some sort of token-based authentication mechanism.
And then you use one of these agents, sub-subagents, that can use a particular skill set to verify that change and ensure that nothing is broken.
I mean, of course, that can also be done with tests, but just use the non-deterministic nature of things.
You ask it to verify as well.
Let's start thinking about also the teams that you serve, right?
So not just your own work, but teams at Beskar, maybe customer teams that you can see when you're working on custom software development.
What kinds of changes are you seeing in?
And maybe if you want to think about this in terms of what a mature team is doing versus what teams that are new are doing, whatever stories you want to share are interesting.
But how are you seeing this impact teams in a big way?
Yeah, I think in general, right now the expectations are high.
essentially, people, customers expect you to be very productive, given that you use these powerful tools.
That's one change.
yeah, I mean, just in terms of the usage of tools themselves, customers have come to us asking for help.
in figuring out how to use these tools effectively, like I was saying.
So essentially, how to avoid just vibe coding and just build something up very quickly that quickly becomes unmaintainable.
That you have so much code and that it's hard to debug.
You just put that in production and then it becomes difficult to debug and maintain in production.
So those are the kinds of problems that customers come to us with.
What changes are you seeing in product management and in story breakdown and these kinds of things?
Oh yeah
absolutely.
mean, Claude can help with that as well.
So essentially, you think of an inception in ThoughtWorks where you kind of get gathered at a client site and brainstorm and come up with these ideas and the output of that whole
Declan inception is a master story list, right?
Where you have like a very refined set of stories that your team can get started with.
I think Claude Code and
ChatGPT and tools like that can really help in breaking things down, given a set of criteria.
Like we did this for one of our clients where we said, this is a product requirements document, and I want you to break it down into features where you capture the story
description, the volatility of the requirement, any questions, a high level estimate based on what you've done.
and things like that.
And it's really powerful, and it can actually do a really good job there as well.
And so generally, think you can be very fast.
I mean, you can move really fast when it comes to understanding, like breaking things down and things like that.
ah
fast reader.
It's funny when you're, when you're talking about this, I'm thinking about an inception Kroger in fact And a previous, sort of waterfall process had generated like an 80 page,
you know, product requirements document, you know, business analysis, you know, package.
like job number one was reading that thing, you know, and it wasn't necessarily internally consistent with itself.
Like what, what it was saying.
And, and, know, we did, we, we sat down and plowed through it and tried to find, okay, this is, this is.
where it says this way that way and says it that way over here and like which one is right and Claude would have done a very quick job of that.
it would have done that in minutes you know and it it took us hours so but when you when you say like breaking a PRD down into stories you guys probably wrote the PRD in the first
place I guess or tell me how that goes.
Yeah, it was written manually by somebody from the client side, a product owner from the client side.
But the interesting thing is also that with persistent memory with Claude a lot of this can be captured as specifications that Claude will actually remember.
It can be checked in as part of your code base.
And it can be used as, I mean, we used to acceptance tests that ensure that.
like that.
so the whole idea of breaking a PRD, which to begin with is a document that people shouldn't be writing, think.
That's not how you should be doing it.
But it's what a lot of people do.
So Claude can really help in breaking that down into not only stories, but stories with acceptance criteria, which can be converted into a bunch of acceptance tests.
Or your
specifications which you adhere to right like and these can these can change over time and you can go and edit them and yeah
Yeah.
Yeah, I love that.
Especially the acceptance test part.
That's neat.
I hadn't thought of that.
So my next question is usually architecture and planning.
And you've talked about that a little bit, using Claude to generate ADRs and things like that.
uh Anything else coming to mind?
No, think so.
We had to choose between
systems.
Like basically, we looked at
kind of forget the names but back in Kroger we used Shiro if you remember
yeah, yeah, yeah.
Are you thinking of like Auth0 and OKTA and things like that?
Got it.
Yeah, yeah, key cloak.
Yep.
loaded a bunch of these options and yeah, I mean, as a technical architect, you kind of think of these parameters that you assist these options by, right?
Like how many users can you, mean, how many concurrent requests can you make or what is the feature set or how stable is it and what is the odd option?
generally and what is the support like for these open source solutions or things like that.
So as an architect, you think of these things, but I think Claude, when I've used it, has been very helpful in uncovering other aspects that you would have missed.
um And also it can do research for you.
So basically it pointed me to a benchmarking blog, which was kind of authoritative, which kind of said, OK, this is how
this tool performs with this kind of framework performance and this load, you know, like under these conditions with this hardware.
So just from a research point of view as well, it's very useful.
Oh, actually, I forgot to mention perplexity, which is kind of what we use for research I it's heavily, I think even Gemini does that for now, but it is citation based, right?
Like any question you ask, they kind of ensure that they...
cite very authoritative sources of information in coming up with an answer.
I think uh even perplexity is something that we can use for coming up with good ADRs.
ah
I'll have to look at that.
That's cool.
I'd heard the name, but nobody had actually described to me what it is.
So yeah, you're the first.
Fantastic.
Okay, cool.
So perplexity for research.
obviously software development itself, it changes.
But what comes to mind for you when you think about how teams operate and how does software development change with these Gen.AI tools?
Yeah.
Software development change.
I think it can go a lot faster.
I think we have to be mindful and go slower maybe because basically the idea is that you can do so much in like a day that you can also incur a lot of tech debt.
just in terms of software development, think like we were discussing before, you have to
ensure that you have the right sort of guardrails in place.
You are actually understanding what Claude is doing.
And although Claude is writing code, you're still accountable for that code written and you're still accountable for that working in production environments, right?
from a software development point of view, I think you need fewer people maybe to get the job done.
ah
pairing, I don't know if is relevant anymore because yeah, like basically Claude Code I found that it can be a very good pair when it comes to debugging issues in production or
debugging issues anywhere.
In fact, it's kind of so helpful and it can weed out issues that you would, it would take you like a day to figure out that it's some sort of a DNS issue somewhere, but it.
can do that very, quickly.
So that whole loop, that's very powerful.
I mean, there are downsides to it, like we discussed, where it can go into its own rabbit hole.
But ah I think, overall, your development process, can go a lot faster.
it's still, I mean, I'm still to speak to somebody who's done this on a project for like six to eight months and put something in production and seen it work.
with a lot of users and I don't know, I it just seems like everybody is jumping on this bandwagon and people want to start using it.
I think a lot of the learnings over the last 10 or 15 years that we apply from an engineering practices, engineering principles standpoint still applies, right?
Like we still need to...
we still need to learn to design systems well.
We need to think of edge cases.
We need to be mindful of how much we building, things like that.
But yeah, in the right hands, uh Claude Code or a coding tool like this can be very, very powerful.
Yep.
Yeah.
No, for sure.
Totally agree.
interesting, I normally ask about pair programming and mob coding too.
And yeah, I'm so torn, right?
Like I really came to love pair programming, working at ThoughtWorks.
Like we were pair programming six, seven hours a day, you And it felt so powerful at the time.
But to your point, it doesn't feel as needed anymore.
But doesn't that cause new problems?
Like around like team alignment, team cohesiveness around the code base?
Like, do you have any concerns there?
uh I think some of those can be addressed if everybody is using.
So one of the really good things with the previous way of working pre-AI was that, like if you remember in Kroger, all of us used the same set of tools, right?
And you could switch to any developer's machine and you could simply start writing code without kind of...
And we had a set of good uh guardrails in place.
Like we had static type, static code checking.
static uh code analysis, things like that, a right set of safety nets in place.
And I think that still applies.
So even when you're using AI, if everybody in the team is using the same set of instructions in the form of Claude MD file, or the set of instructions that you pass on to
the LLM, which can be a skill set, which can be your memory, lot of that can be shared between team members.
Yeah.
and checked in as part of the code, right?
So that way a lot of the context is shared and the coding agent becomes an active team member.
ah So I think that does solve part of the problem that you're talking
I think you're right.
I think some of that, like keeping the code cohesive is maybe not.
It may be our responsibility, but not our job anymore.
We're accountable, not responsible, something.
But I also like what you're getting to there around like checking things in.
That's been a question that's bugged me a few times.
It's like, should we check everything in?
Like from my experience, I'm normally working solo.
So I can just check everything in and not think about it, not worry about it, you know?
But on a team where you might have multiple developers going, does it make sense for, okay, so yes, check in your Claude.MD I agree.
To me that sounds like totally right.
Check in skills, yes, right?
Wait, does it make sense for there to be guru skills and team skills and maybe Beskar wide skills?
Like, I don't know.
Is there anything you shouldn't check in that can you think of?
Yeah, I mean, you can have personalized skills, I think, override what you're checking in.
Yeah, yeah.
but can you does it make sense to or should we or does it make sense to go towards sharing everything?
Like, can you think of a what would be outside of a share everything?
Yeah, I can't think of anything that...
I mean, basically, there's no data issue here, right?
There's no data privacy issue here.
It's just a set of guidelines and interacting with the LLM.
And it's good for a team to share those guidelines so that you're...
so that...
it's a little bit deterministic, at least, the way Claude answers your questions, or, you know, like the way it goes about solving the problem.
Yep.
and with persistent memory where it can retain that context across coding sessions that kind of becomes important because there's uniformity there and every developer works their
own way and they can have their own set of skills or their own style uh but from a yeah yeah
or something.
So maybe, but nothing, so far I have not really seen anything where it's like, no, never check in your plan files.
Like no, check in the plan files.
of course, people, yeah, you want to be able to see them.
Okay, cool.
I mean, of course, should be avoiding checking in files with sensitive content in it, some sort of a key, API key or password or whatever.
As long as you're avoiding that, I don't see any.
file filled with social security numbers, like yeah, PII, things like that, no, for sure.
that would have applied before, there's nothing new about that.
yeah, okay, cool.
You talked a little bit about testing earlier.
You talked a little bit, I love how you talked about like a PDR can become an acceptance test suite, for instance.
Really, really cool.
Are you seeing testing change in any other way?
I think testing like development has become pretty easy.
uh It's become very easy to write integration tests because Claude can do a lot of the heavy lifting where you spin up a bunch of microservices using Docker compose, get that
running in GitLab CI or wherever.
It's become so easy to do that right now because if you would spend a of effort would go in.
to getting an end-to-end integration test to work, but that has changed.
And from a unit testing point of view, think we discussed this sometime back within Beskar but basically the idea should be to have Claude generate your tests and be very thorough
with it, review them, and essentially ensure that they're testing the right set of things.
there is this whole argument of classist versus mockist sort of testing and essentially ensuring that you're not actually testing you should be testing your the values and
function returns
rather than going and testing that the function is calling another, making another function call with an object within it, sort of a thing.
basically, good tests are important.
So spend time reviewing that.
And then ask Claude to pass those tests with, do the red-green refactor.
Make that a skill, sort of thing.
So the whole red-green refactor implementation could be a skill, a workflow, where
you it generates a set of tests for you you review those tests and then you invoke a skill to kind of say okay hey you have this sort of test go ahead and write code to pass them.
interesting.
Okay, cool.
Cool.
I hadn't thought of that.
So, okay, but let's see, let's get beyond the test suite.
Let's get beyond like integration testing and unit testing and sort of the literal QA, right?
And so for instance, personally, I'm still desk checking work, you know, like when, especially if it's like an experience improvement.
Like I want to look at it.
I don't want to just tell Claude, like make the experience better in the following ways and just cross my fingers.
You know, I want to see it.
want to, you know, on, some level that helps me feedback into product design.
You know, that's where some of the creativity happens.
so how are you seeing that change in terms of like how you interact with UI And how do you like the manual testing, the error guessing, you know, sort of the, the, the, the actual
active quality.
quality assurance, not just the test suite itself.
That's an interesting question.
I've not actually seen tools come across tools that can actually solve that problem.
I think you still rely on Selenium or tools.
What is the...
Playwright, yeah.
Playwright tools like that.
But yeah, I think you can still use Claude or Codex or coding agents like that to...
invoke those tests, but it's a good point.
basically how would you, I don't know, like I'm not, they've not done that sort of thing.
think mostly there are still automatable wire coding agents, I would say.
Nice.
like, I like you're sticking to automation.
Like I like it.
That's a good thing.
Okay.
What about so integration?
What about the, and, on, and on some level, think integration here, I mean, obviously you continuous integration, continuous delivery, those kinds of things.
But I think also just the literal sort of act of integrating multiple code bases.
Like if you.
suddenly need to start using an API service that's part of one of your enterprise customers that you didn't use before, you know, and now you need to integrate with it and
you weren't before.
Like, that sort of literal act of integration in as much as like continuous integration and builds and all that.
Yeah, what are you seeing changed there?
I think it's kind of remained the same.
basically, mean, sorry, could you kind of repeat the question?
it's an awkward question.
keep trying to, I'm maybe trying to conflate multiple things, but I think of it this way, like Kroger Pharmacy, right?
One of the things that they had to do was integrate with an existing enterprise database.
You know, and they couldn't really change it, you know, and that was always one of the big risks for that project.
You know, we kind of knew like, yeah, here's the PRD for this code that we have to write.
We're going to write it, you know, and we're going to write, you know, the, backend and we're going to write the UI and they're going to talk to each other.
So there's not a lot of integration risk because we're coding the backend and we're coding this, but we also needed to talk to this other thing over here that we could not control.
And so I kind of mean that when I'm saying integration right now, you know, the, the act, the literal act of integrating was something
and not just sort of integrating code that, you know, person A and person B on the same team wrote, but like integrating with stuff which is external to you.
Like, has it changed any of that?
I don't think there's a lot that has changed.
You still rely on your contract testing.
basically, I think it's become very easy to mock things out.
Like if you had to, I just generate a mock that maybe meets this sort of, if you have like swagger docs, just generate mocks.
And I think there are some third party services that support that, but building something like that in-house has become so easy that you can.
I mean, in fact, that's true for a lot of other things as well, if you want to.
Yeah.
So I think.
that just reading that swagger, it's gonna go from here's the swagger URL to here's a working client so fast.
So yeah, think it does speed, just inherently, just its ability to read documentation speeds that up quite a bit.
Yeah.
yeah, absolutely.
might not necessarily see that there is like a different paradigm on the other side of that.
Like it might just sort of create a mapper and not very thoughtfully convert our object to their object or something like that and not really realize that, this, ugh.
So I still think you need to like think through the domain a little bit with it.
But the literal act of reading a swagger and building a client, like it can do that incredibly quickly.
Yeah.
Cool.
What about when it comes to deployment and infrastructure?
Are you seeing any changes there?
We actually, I was heavily involved in getting infrastructure automated for one of the previous clients and Claude did a fantastic job.
He used Terraform and Terragrunt mostly.
I read somewhere that these coding agents are not really good at coming up with an initial cut.
uh
from a code quality standpoint that they're not great.
And you have to tweak and tune and set it up properly for it to do a good job.
for IAC, I saw that it was actually doing a really good job.
Like basically it broke things down into modules, stacks, and that TeraGrunt configs for every environment.
That was so neat.
Like basically, I think it was very kind of.
nice to work with.
something that would have taken like a week or two weeks, you can kind of do it in two days.
So yeah, I mean, it really works beautifully with infrastructure as code And it kind of makes it easy to test it as well.
So one of my things, and I think this is mostly from Sharan his...
Go to tool for any kind of build activity is make, Makefile right?
So you kind of put everything in a Makefile and any kind of build or test or integration test, or run anything, you do it via make.
And I asked, I kind of put that as a guardrail and so you can just say make TF plan or make TF plan this particular stack of services.
And it doesn't really, I mean, it just goes ahead and does that.
So yeah, mean, it's really crazy how efficient you can be in building some of these things.
yeah, so it does understand terraform I mean, again, you can actually inform about various environments and which AWS profile to use for which environment and configs like that.
You can put that in your Claude.md
You just have to ensure that the right set of instructions are in place, then it's your buddy can actually do lot of things for you.
nice, yeah, totally.
I normally ask about debugging next, but you already talked about that, and I agree with you, it's incredibly good.
Refactoring, we've already covered.
uh dependency management.
Are you seeing anything there?
I have a team right now that's got a dependency on Quarkus, you know, and it's a little bit out of date and now it's time for them to go update it, you know, and they're going
through the motions of making that safe, you know, and so that kind of dependency management maybe if you've taken a dependency on a framework and you now need to update
it.
But of course, we're also seeing like Shai Hulud and the recent worms kind of running through uh
GenAI tooling and all of this.
How are you thoughtful about dependency management these days?
I mean, in the projects that I've worked on, we've not done anything special apart from using a skill just to ensure that you're on the latest version or, know, like basically
ensuring that, I mean, actually with vulnerabilities, AWS itself does a good job, right?
Like, because you get those alerts and they run these scans that tell you that you're using a package that is actually has this vulnerability.
So yeah, think writing a workflow, I mean, you can do these hooks as well with Cloud, where you can say that, hey, uh this part of the code base is kind of sensitive.
basically, if anything changes there as part of a commit, I want you to run this script just to ensure that the dependencies are in order and things like that.
I can think of those kinds of ideas.
But yeah, basically,
Some of these things can be built into the Claude tool set just to ensure that you're on the latest possible version.
Yep, 100%.
Okay, so in you working
Working at a company that focuses on custom software development for clients, think this, and you've kind of hinted at this earlier, right?
You started to say like, you need fewer developers.
So, but a question I often ask is, what are you noticing about team roles and team ratios, right?
Like in the old days, we might've said like, six pairs of developers, you need two BAs and you need one QA, you know?
that wouldn't be work for everything perfectly, but that was a decent,
you know, get started template.
What are you seeing these days for like ratios?
Do we need more of a certain role and less of like fewer developers like you've said, but what other impacts are you seeing on teams and how they get built?
Yeah, so I think more of like basically you need somebody who is good at design and who is kind of good at system design, architecture, somebody who's a senior developer and like a
bunch of mid-level developers who can actually use Claude code effectively, right?
Guided by the senior team member.
So, I mean,
Yeah, like basically I think for junior developers especially it according to me it looks like it's going to be a problem because Claude Code can act as one of your junior dev
pairs where it guided in the right kind of way, can do a lot of things for you.
I think that's where teams mostly will cut costs in kind of hiring freshers or
Yeah.
lot of experience.
there are still things to figure out there.
Like for anybody who wants to enter the IT industry right now, it's going to be very difficult because you have something that's solving a lot of the problems that they would.
And people are being productive as well.
So the entry barrier is high.
Yeah, yeah, getting higher.
Yep, yep, agreed, agreed.
Okay, but what about other roles?
earlier when I was asking about testing, leaned into we automate everything.
So I'm not hearing a lot of like, we have more QAs because there's more software.
Okay, I'm not hearing that.
But.
Are you hearing anything around like product management?
Do you need more access to SMEs, Subsect Matter Experts?
Do you need more access to product management to answer questions?
Or does that mean that you need differently shaped developers that can sort of do that on their own?
how is it impacting like the other roles on the team?
Yeah, definitely from what I've seen, There is a need for developers to think more from the product angle because a lot of the implementation has been taken off their hands,
right?
So essentially, product managers and somebody who can guide or have a clear vision and roadmap for a product, that becomes really important.
I think the term is product engineers, I really don't like actually.
But I prefer software engineers.
yeah, that's kind of beginning to.
I mean, with this whole thing,
I've actually gone through some sort of an existential crisis, to be honest, where you kind of think what the hell is going on and where is this all headed, sort of thing.
I think we are headed where people need to start thinking product more.
Yeah.
product engineer thing is really kind of happening.
Yeah.
Yeah, a hundred percent.
I keep telling people, I don't know if I'm right, but the thing that I keep telling people instinctually is talk to Claude about the domain, right?
If this is quick service restaurants, talk to Claude about the hamburgers, right?
Talk to Claude about the point of sale system.
Talk to Claude about, talk to it about the domain.
Don't talk to it about the curly braces and where to put them.
It doesn't make any sense.
The more it knows about the domain, the smarter it's going to be at writing software for you.
So yeah, that totally
lines up with what I'm seeing, what you're talking about, that we all, you want to be talking about it more.
So that means you need to know it.
You can't avoid it.
You know, I feel like teams used to have sort of, you know, a developer, maybe two that were so focused on the code and not so much focused on the actual domain.
And I feel like there's less room for that person right now.
Yeah.
Okay.
So I've kind of seen that lot of people are coming up with these Claude skills, right?
Like where they have their own set of roles or that sort of thing.
And I've seen one of those repositories where it was really interesting where a CTO was a skill.
I mean, basically.
So any feature that needs to be implemented,
it has to kind of go through that and you can kind of see, you can vet with the CTO or CEO just to kind of see if it's in line with the product vision or not sort of a thing.
So like you said, basically that can be made a part of your whole code base and you can kind of ensure that you're doing the right thing.
Yeah.
Yeah, you could.
That could be a git hook or not a get hook or Claude hook, for instance, or git hook either.
Yeah.
Ooh, I like that.
Yes.
OK.
Has it changed how you hire staff, train, mentor when you think about those aspects?
Absolutely, I think it definitely has changed the way you onboard new folks to the team.
Because now you can have all of this context with the powerful features that Claude Code have added, with memory, with skills and stuff like that.
It's become very easy to ask questions about the project, the problem you're solving, as well as the code base.
Like you saying.
what are we trying to solve from a business model standpoint, and how is the code based solving the problem?
And it's become very easy to ask Claude to teach you something.
So you can say that, I'm new here, and just tell me how I can do this.
So I've paired with an in, like a.
funny side note where I've paired with ThoughtWorks folks where they kind of grab a new developer joining a project, they just grab the keyboard and they say that, just tell me
what to do and I'll do everything.
I want to get ramped up on the project and that's really annoying.
like gone are those days.
You don't have to do that.
Like Claude can be your onboarding agent and can answer all the questions for you.
think onboarding people has definitely changed.
Cool.
Okay.
How are you enabling teams with these tools?
you said you're pretty stable headcount wise.
So maybe you're not, you're onboarding people to projects more than you're onboarding people to Beskar.
did you go through a phase where you were kind of deciding what to do?
You talked earlier about how we sat down and talked about it and we agreed that, you unit tests should be classist not mockist and things like this.
What different processes do you have?
an organization around how you decide how to use these tools?
Do you enable people in order to get them to use the tools better?
Those kinds of things.
Yeah, mostly who are joins kind of goes through, used to go through this object bootcamp sort of thing where they learn about professional programming principles like this whole
classist versus mockist or why immutability is so important, things like that.
So you have sort of these really good engineering programming principles that you have to learn, right?
And I think those are still relevant to some extent.
Because you as an engineer, need to learn that, according to me.
My personal take is that.
anybody who's joining Beskar, right now we have a set of clear opinions on what tools to use.
And when it comes to GitHub Copilot versus Claude Code way of working, how you should go about managing context, context windows, and things like that.
how you should manage your cloud coding sessions.
Basically the idea is that should be able to exit a cloud coding session and enter it or start a new session without a lot of fear.
Basically it should not be like you have a huge conversation that you lose if you exit a session.
your Claude Code setup should be such that a lot of that is already built in and it's able to pull stuff from memory pretty easily.
So we have some opinions internally and I think Baid is like a result of that sort of thing.
So yeah, basically that's kind of how we are doing it right now.
Interestingly, we have not actually, I mean, we have a plan, but we've not hired anybody and we've not had the need to do that.
But yeah, that's the plan.
Essentially, go through an object boot camp and also this set of training sessions where you learn about opinions on some of these things and how to use them.
yeah.
Maybe tell us a little bit about Bait.
We kind of skipped past that, right?
You guys do a lot of custom software delivery, but you also have this product, this generative AI.
Do you guys use it internally, or do you guys have customers using it, and where does it fit in the landscape?
Yeah, actually, it's still evolving.
We started a podcast series recently.
And uh basically, uh we have a discussion every week on new stuff that people have found interesting in the AI space and things like that.
And the way it is kind of a result of that, where we thought that
Like OpenClaw, OpenClaw was a very kind of interesting development, right?
So the idea of a Bait, like the Bait bot, we call it Bait bot, and that's one aspect of it.
But the idea is to build this autonomous bot that you can chat with from WhatsApp or Slack, which can help a team member, which can act as a personal assistant to a team
member.
So there is a a lobby bot that helps you onboard.
you know, to Bayport and then you can ask it to be your personal assistant.
So you can kind of say that I'm a DevOps engineer, I want to kind of monitor that this particular service is behaving properly, just go ahead and do it.
And you can chat with it from WhatsApp, can kind of say from Slack, you can kind of add it and say that I want to do this.
So it's controlled actions with persistent memory.
So essentially, have a bunch of these agents that specialize in things.
And they can help you do day-to-day work.
They can do things like that.
the idea is to also try and see if we can build proxy team members.
So let's say you're not able to attend a meeting.
your proxy does that, right?
And that proxy agent has all your context because it has all the conversation history.
So it kind of knows you as a personality.
essentially with OpenFlower, there's this concept of a soul for every bot, right?
So we are kind of going with the same kind of approach where every soul in the team, basically every team member has a soul.
And then you kind of can make, I mean, this is just a...
theory that we want to start, but it can take notes for you and then action items can be passed on to you or things like that.
So the bot can attend the meeting and I think Granola is a startup that's solving a lot of these problems around meetings where it can take notes and stuff like that.
But our idea is to extend that and make it more interesting.
like if you had a, if it's a meeting where you're doing a technical
architecture review and you want to quickly ask, I mean you've been having these recurrent meetings and you want to kind of go back in time and figure out why you decided on a
certain path.
You can ask this bot for it and say hey babe by the way tell me why we chose to do this or whatever.
So that's the general idea.
to your point, if your entire job is going to meetings, then one of these meeting note taker AIs is very helpful.
But if your job is composed of many things, then it's less helpful.
So this kind of ties that together with anything else that you might have asked it to do.
that's cool.
OK, now I want to use Bait.
Yeah, mean, it's still in beta.
We're still trying to, still testing it out.
But as soon as it's out, I'll you know.
Yeah.
No, definitely I'll appreciate your feedback on some of this.
so we are, I definitely appreciate your time today and we are coming close to the end.
There's three more questions I wanna ask and these are kind of getting more into personal and less about the generative AI.
In fact, the first question I'm gonna ask is something you've had to change your mind on, right?
Or something that was unintuitive.
And so far, almost every guest has said, I was wrong about AI.
I didn't think it would be as important.
So, okay, that's fine, but try to think of something else also.
So here's the first question, something you've had to change your mind on or that was unintuitive at first.
I was going to answer the same.
Yeah, I think.
You mean from an AI standpoint or just generally?
light perspective, yeah.
think of I mean, general life perspective, don't think of anything.
But yeah, I mean, from an ESF standpoint, like I said, I've always been a skeptic and I've always played the devil's advocate and I think Lord Code, I've definitely come around now.
Yeah, it seems like and it's getting to a point where you like I've seen developers who don't even have intelligent idea or any other idea open.
All they have is terminal.
yeah, that's me.
yep, that's me.
Yeah, it's funny.
At first I thought, oh, this is like when Stack Overflow showed up.
Stack Overflow felt like cheating for a little while.
It was like, wow, this is great.
And before that it was like internet mailing lists felt like cheating, because you didn't have to open the manual.
And at first I thought, oh, this is just like that.
But I'm starting to think, no, it's much bigger.
It's almost like before the internet, kind of bigger.
So yeah, think, yeah, it's a good answer.
All right.
So next question, something you are most proud of.
I think, yeah, mean, leaving the regular job sort of thing and being kind of brave enough to go and start something on your own, yeah, I think that is something that, can be proud
of.
Yeah, basically to, and to start with no clients and just to kind of quit one day, not having anything else.
to have the courage to start something.
Yeah, I think that's something that's interesting.
what's something that's giving you joy right now?
I've started gymming I have a good routine now and I'm really enjoying that.
So it's both gym and running, actually.
That's kind of giving me joy, apart from the work.
Yeah, yeah, yeah.
Yeah, of course.
Of Yeah.
We have to we have to do other things too.
Awesome.
Guru, thank you so much for being on the show today.
Really appreciate you.
This is great.
Thanks, Kyle, fun being here
Okay.