What we talked about
Anton Pleshivtsev spent over eight years at Bravado, climbing from Head of Engineering to VP, before stepping into a new chapter as Director of Engineering at Sendblue in the San Francisco Bay Area. He talks about the pivot from hands-on engineer to Engineering leadership, what it’s like to join a small, fast-moving startup after a long tenure at one company, and how he scaled, coached, and developed engineering teams as Bravado grew.
Show notes
Anton Pleshivtsev spent eight and a half years at Bravado, rising from Head of Engineering to VP, before stepping into a new chapter as Director of Engineering at a small, fast-moving startup. His technical roots are in Python, Django, Redis, and high-load systems, and the conversation traces what changes when an individual contributor becomes a leader, and what keeps external vendor relationships from breaking down.
What we covered
- The pivot from hands-on engineer (Python, Django, Redis, high-load systems) to engineering leadership, and the shift in mindset that move requires.
- What it’s like to join a small, fast-moving startup after a long tenure at one company, and the value of in-person team interactions.
- How he scaled, coached, and developed engineering teams as Bravado grew, building trust and relationships along the way.
- Navigating the challenges of management, and how he thinks about the engineering versus management career tracks.
- How he thinks about external vendors and contractors, what makes those relationships break down, and what makes them stick.
- The role of AI in engineering and management, interviewing for new engineering roles, the evolving role of product managers, and creating context for engineering tasks.
About Anton
Anton Pleshivtsev is an engineering leader specialized in search, infrastructure, and team growth, currently Director of Engineering at Sendblue. He previously spent 8.5 years at Bravado, rising from Head of Engineering to VP of Engineering, with early experience building high-load systems at companies including Aviasales, Virool, and Instacomm.
- LinkedIn: https://www.linkedin.com/in/antonpleshivtsev/
- Website: https://sendblue.com
Episode 159 of the PreVetted Podcast.
Full transcript
Federico Ramallo (00:00) Welcome back to the Pre-Vetted broadcast where we spotlight extraordinary people and remarkable talent reshaping our world. Today I am joined by Anton Pleshivtev, Director of Engineering at Sendblue, a Bay Area startup behind the iMessage API that businesses use to reach customers through native blue bubble messaging. Before stepping into this role, Anton spent more than eight years at
Rabado, the sales community and hiring platform, rising from head of engineering all the way to VP of Engineering. He brings deep Python and high load systems roots and the kind of leadership experience you only get by scaling a team over many years through real growth. Antom, welcome to the show.
Anton Pleshivtsev (00:48) Thank you, and thank you for having me.
Federico Ramallo (00:51) I am honored to have you here today. so for people meeting you for the first time, can you tell us a bit more about what you do?
Anton Pleshivtsev (00:58) Yeah, so right now I am working, as you mentioned, as director of engineering at Sunblue. So I am leading two teams at a company mostly focused on product development and platform development, which means the product development is mostly customer-facing UI features and platform development is mostly developer-facing features like API development.
experience CICD workflows infrastructure related stuff so I work with both teams to make sure things are delivered in time the quality is under control and the Kanban board is clean and has no bottlenecks
Federico Ramallo (01:42) Right. Right. I’m I’m sure you have a lot of challenges of just you know, managing these two teams. there are plenty of of of challenges to overcome.
Anton Pleshivtsev (01:53) Yeah, the the interesting thing is I was kind of consulting the team before I joined full time. And
Initially we didn’t even think about me joining, but at some point it just became clear that th there is a lack of specific expertise in a team and I have this expertise and it just it’s not very convenient for us to, you know, hop on these constant calls where I need to explain how to do this and how to do that. It would be just easier for everyone, including myself, to just join full time
and just you know work directly with people, processes, you know, source code and infrastructure instead of just answering questions and you know learning about stuff based on people’s feedback.
Federico Ramallo (02:42) Right. Right.
Anton Pleshivtsev (02:43) So
so I had a flight so after consulting the company for a while, I took a flight from Bay Area. The the so you you mentioned the company is based in Bay Area. It it is actually based in New York.
Federico Ramallo (02:55) interesting.
Anton Pleshivtsev (02:56) after after finishing the YC initial program. So I took a flight from from the Bay where I mostly live, to New York. So I spent some time offline with the team to figure out like what what what is the biggest issue, like how
how to plan the roadmap for the next few months and what is the current priorities and then just right after that I just joined full time.
Federico Ramallo (03:24) Right, right. I I I f I feel that there is a lot of value on meeting the team in person because you know you turn an an avatar or a you know, a person on you know on the other side of the Zoom call or whatever it is you’re using, to a much deeper relationship where that increases the communication and the understanding on what what are the issues and what needs to be done to
make the team effective, right?
Anton Pleshivtsev (03:55) I’ve yeah, frankly speaking, I have never done the the other way. every t so I was I was mostly working remotely through my whole career. and I was always starting from
meeting people offline. Even though I was working remotely, I was investing a little bit of time for travel and spending some time offline with these people to make sure you know we have the matching vibe and the communication is better. also sometimes when you just texting with people it is unclear like you know i y y you just don’t understand
And the emotions people try to express, you don’t feel like the intentions they try to express, but when when you meet them, when you can read, you know, the mimics, when you can read the nonverbal signs, it makes it so much easier to communicate that it it’s just such a no brainer. I I mean i
I I I I think the company should it should have some budget. Every single company who is working remotely should have some bad budget plan for this. For example, at Bravado, through the eight years of the company, we were the remote first company, and the company was always investing into offline experience. So, for example, we had engineers and business people in the US, and we had roughly half of the team in Europe. So the company
was constantly investing into offline events so that for example one event we had like in Mexico so that the team gathered in Mexico and we worked together for a week to make sure
you know, we know each other, we we have a better communication, we have a better contact, better human relations. I it also you you can also see that it helps with the business outcomes. And also tequila is great in Mexico.
Federico Ramallo (05:49) Right. Yeah. and I I think that the having those offline experiences enriches the relationship and the and as you said is you know, you you build that personal report that otherwise wouldn’t, right? Then after after you build it, when you work remotely, you carry on that that that personal relationship and that that it’s much better for the whole team.
Yeah. And the the other thing I’m I’m notice is about the these this this per interpersonal relationships is that people are more open to share feedback or speak up when they they have that level of trust that they know that they can share you know they can share their mind with you without being, you know, ostracized or you know having a
you know, ha having a risk of of of of of their job stability because it you know, you build that trust on the offline experiences, right?
Anton Pleshivtsev (06:47) Yeah, and also it helps you with your future employments because once you build trust with people and for example you sell the company,
you will keep you you you still save the professional connections and these people will invite you to work with them or which happened in my case I managed to bring a lot of prof a lot of great professional engineers with me to the new company and since we had this great offline experience we know each other we trust each other they know that they can safely follow me and they they they will be treated
Federico Ramallo (07:29) Right, right. That that’s another interesting point. I I’ve seen directors are doing the same thing where they they have a crew of people that they already built a relationship with and and they they kind of know how how they they figure out how to work together and and that that al allows to reduce the friction on on on the work that they need to do.
Anton Pleshivtsev (07:53) Yeah, some people I have worked with together since twenty twelve across three different companies and we and we still have communication between us, we still share professional experience and
Federico Ramallo (08:01) wow.
Anton Pleshivtsev (08:10) One of the guy I just we just he just recently joined a different company, but we were working together for like the last fourteen years.
Federico Ramallo (08:20) wow. Right. That’s amazing.
Anton Pleshivtsev (08:22) Yeah, so tha that’s
the power that’s the power of professional and personal relationship you build.
Federico Ramallo (08:28) Right. Right. Interesting. And and how did your job change when you moved from head of engineering to VP of engineering?
Anton Pleshivtsev (08:37) Well, it th the reason why the title changed was because the scale changed. The initial initial scale was basically the seed round company with just me and a few founders building initial concept of the product. And then we had some budget to hire just a few engineers.
But at s at some point when we managed to raise CRS A, it became pretty clear we need to scale the team first. And in order to scale the team, you cannot focus solely on development. You need to focus on hiring, managing, building the development process, managing the development process, managing performance. So I basically moved from
playing coach to mostly like a manager. if if we speak in terms of like a football club when I was like running the hiring process, dealing with hiring agencies, giving them feedback, interviewing people, running
key meetings with the existing team to make sure the delivery pipeline is healthy and all the existing bottlenecks are resolved. So I I kind of changed I I moved from the worker side to the manager side. But again, this was pretty clear just because of the change of the scale that the company was operating on.
Federico Ramallo (10:01) Right, right. Very interesting. The I think that there is a fundamental change on on the type of work you do when you are a individual contributor to a manager or or team leader, because on the individual contributor, as a software engineer it’s you and the machine, right? It’s you and the code, right? It’s a it’s a thing challenge. But then when you go to management, it’s a people.
Anton Pleshivtsev (10:21) Mm-hmm.
Federico Ramallo (10:27) people challenge, right? It’s a different kind of of challenge, right? and and then the the natural escape from
Anton Pleshivtsev (10:32) Yeah, I I I I have a few comment I I
have a few comments here. Th there is a confusing part which which is confusing for young managers specifically, which is when you work with the code, you have a clear definition of
s something that is called definition of done when you you can clearly say that the task is finished, right? It’s whether your tests are green or your PM is saying that the feature is working as expected, or you just get the computation that you were working on. So something is very clear that you have this like feeling of accomplishment. while
with with people there is no clean signal saying that you solve the problem. For example, an engineer who is not performing well enough, and you give them feedback and you maybe you change a process, you give them feedback
Like th there is no clear th nothing clicks to say you that the problem was fixed or it wasn’t, right? So you have to do something else. You you kind of lose this clean feedback loop, clear feedback loop, and instead you are operating under a certain amount of uncertainty, and you have to accept that this is the new reality. And a lot of people get frustrated about that because they don’t want
they they don’t want to lose this feeling of accomplishment when you have like green tests and change it into something unclear and something that they didn’t they they haven’t seen before.
Federico Ramallo (12:03) That that’s a a really great way to put it. I I completely agree. what you’re kind of describing is that the the the machine problem is much more deterministic and the people problem is less deterministic, right?
Anton Pleshivtsev (12:18) It’s it’s completely non deterministic, I would say
Federico Ramallo (12:20) Right.
Anton Pleshivtsev (12:21) So that in in some cases you
have you you even have to figure out you know tricky ways of collecting feedback or making them to answer questions that they don’t want to answer, or you know, collecting feedback from their peers and stuff like that. So it i it’s a problem that that has a straightforward solution becomes a problem that has like millions of potential solutions and no clear definition of
Federico Ramallo (12:46) Right, right. And the and a lot of these problems they y you don’t see them until they they blow up out of proportion.
you know, and it’s your manage management experience that allows you to work on these issues before they become a big problem.
Anton Pleshivtsev (13:08) Yeah, th that’s why companies or most companies would prefer to hire managers with experience because
If if you’re an engineer, experience you can compensate with education and books you have read, but when you’re a manager, the amount of cases that you are facing is it’s basically you you cannot learn something you from the book. You need to learn this from the practice. And this is why I’m not a big fan of like promoting people from engineers to managers.
especially if they didn’t ask for that because usually when you promote someone from engineering to management position you’re losing a good engineer and getting a bad manager.
Federico Ramallo (13:56) Completely agree. It’s a I I thought that that was a natural progression of of of you know promotion, but I I had a few cases where eventually I realized that so for me became having this clarity allowed me to stop pushing for for that type of promotion and understanding that it’s okay if you want to continue being an individual contributor and read between the lines whether that person has the
the the skill or even the desire to learn about this this new people challenge problem, right? a a lot of engineers don’t want to. And if if if we push them as manager, they might say yes, but then that that could backfire because you know you you get a bad manager but now it’s hard to go back, right? And and go back to become an individual contributor, right?
Anton Pleshivtsev (14:47) Yeah, so a few things here. First of all, y y you should probably provide two clear tracks for them in terms of career growth, which is managerial and engineering track.
a lot of engineers think they can follow the managerial track, and if you ask them who they want to be, which position they want to take the next, they will tell you something like, I want to be a team lead. But there there is no clear definition of what team lead means actually. And mo what most people mean by team lead is basically having all the benefits of being a manager without taking all the uncomfortable parts. Meaning
They want to have like a higher salary, they want to be able to delegate boring tasks, they want to have this like ego boost by being a manager, but no one wants to deal with what actually means to be a manager, which is giving uncomfortable feedback.
firing people, you know, trying to resolve problems that are unclear and no one wants to look into. And so this is why it is so hard because a lot of people will tell you they want to become an engineering leader, team leader, but in what what they mean by that is not what you need by that.
Federico Ramallo (16:06) It’s a the the expectations are are not clearly defined and sometimes th they they want to yeah.
Anton Pleshivtsev (16:11) Mm-hmm. Th this i I I actually
I actually polished this position
a lot because a lot of people told me they want to be the manager, but when they tried to do the managerial track or when they when they asked follow up questions, they were like, yeah, that’s this is actually not what I wanted to do. So a lot and in this case the better track for them is just to become like a senior engineer and then a principal staff engineer. So basically be become more and more senior without changing
the technical track into something else.
Federico Ramallo (16:45) And and I think that a lot of the desires o of the as you mentioned the
Hierarchy boost can be done by helping coach others and helping support the quality of the code, which is it’s stepping a little bit on on the managerial side, but very heavy technically. So having that coaching role becomes a great way for the software engineer to not only be become a content contributor, but also help leverage the the the the the productivity of the rest of the team, right?
And and that that is much safer than going full managerial, right?
Anton Pleshivtsev (17:26) Yeah, I would say this used to be the case a few years ago, but I don’t think it is the case today because who would hire a junior engineer if you can just get an
cloud subscription and one senior engineer can manage like ten agents who can do exactly the same as ten junior engineers. Obviously there always will be strong engineers and like you know mid-level engineers and they obviously need to learn but what companies used to do they used to hire like interns and really junior level people and just have senior people mentor them
I think big companies can still do that, but average sized companies like fifty, a hundred, a few hundred people, I I don’t think it is the right thing to do for them.
Federico Ramallo (18:17) Right. I I I agree. I mean the right now the expectation of a senior is to manage these agents. So it’s it’s becoming a an engineering manager without the the the the people the the people factor, right? It’s it’s an individual contributor plus agents, right?
Anton Pleshivtsev (18:35) Yeah, and th this is actually a great thing because you cannot blame the junior engineer anymore. If if something doesn’t work, it’s on you. And it it actually makes the the supervisor’s job a little bit easier because you don’t have to trace the whole thing up to like a junior engineer who doesn’t perform or the manager who is complaining about their team. Because right now you have just one point of contact that is responsible for running these agents.
and not giving them any feedback, not man mentoring them. So it’s it’s just, you know, the feedback loop becomes much easier for you as well because you now know that this is probably just the wrong person if this person being the senior engineer and managing the pool of agents cannot deliver the result that you would expect from him. that that’s totally on him. That’s not because you provided him with the wrong people.
Federico Ramallo (19:30) Yeah, I I I I’ve been thinking about this idea of who who is accountable for the agent’s work, right? And I think that the answer is the s the senior software engineer that it’s responsible for their work, right? because it’s as if he wrote it, right? he he’s in charge of that supervision, right?
Anton Pleshivtsev (19:51) Yeah, the one who is running them is responsible because two senior engineers can run their agents in a very different way. One will provide them with great prompts, will provide additional comments, stop to review their changes, test their changes and review the final PR, and another one will just copy paste ticket numbers and push them into production.
Unfortunately this is happening a lot. A lot of people who used to be who used to be considered junior engineers are now thinking about themselves as senior because they can now ship a lot more code w which is just wipe coded by the agent and they think they they have the skill which which is just not true, right? This is this is this is actually something that is making a little bit
Federico Ramallo (20:35) Right. Right.
Anton Pleshivtsev (20:39) tricky to hire an engineer because
Previously you could have sent them the technical assessment and see their output. You can see the code quality, test coverage, the quality of the technical solution. And usually it is very clear if the person is senior or not. But today everyone will just vibe code the solution. And you are not checking the person’s skill, you’re just checking the output of the agent.
And this may this kind of changes the way the hiring process works because you need you know, need to ask follow-up questions, you need to make sure the person understands what their agent is doing. So this this also changed the way we interview people. Instead of focusing on technical assessment, we are now focusing on technical interview where I have direct conversation with this person and I need to dig deep enough to understand if this person is
Technical and senior enough, or this person can just send prompts to an agent and click approve.
Federico Ramallo (21:43) Right. I I I wanted to ask you about how
How how in more detail how do you feel that should be interviewed for for for these new positions or what advice would you give to the to the audience that are you know trying to figure out how they should change their their hiring practice?
Anton Pleshivtsev (22:03) I can say based on my experience, again, we used to heavily focus on the technical assessment. So we
moved a part of the technical problem that we solve internally into a technical assessment description which we offer our candidates to solve. Since we solved this problem internally, we know we know it pretty good. We know like what are the potential solutions, pros and cons for each of them, the solution that we have chosen and
I I also have seen a few good solutions from other candidates, so I I kind of know everything. It’s like, you know, if you changed oil like a hundred times in your car, you you know everything that can go wrong with the process, right? And y if you ask someone to change the oil, you will clearly see if they have done it previously or not. The same is here with the technical assessment. if the engineer is senior enough, you will see it right away.
The now the problem is that engineers started outsourcing using the agent. And with the agent, everyone is sending roughly the same because they probably use the same agents, the same LLMs, and they are sending us roughly the same quality source codes and the same quality solution. So just reviewing the source code is not enough anymore. I have to hop on a call with the with
Engineer and ask more fundamental questions like why did you choose this algorithm? What other algorithms did you consider? What are the benefits? What are the pros and cons? Like, how would you scale this solution? can you move from like one user to a hundred, a thousand, a hundred thousand users from this solution? if if yes, then how would you upscale your
Your
application, what are the bottlenecks? How would you run the infrastructure? what things in your infrastructure would you monitor? So I I kind of basically ask all the follow-up questions. Obviously, some engineers will better know like backends and algorithms, some of them will better know the infrastructure side of things, but in the end of the day, it gives you a picture of the person as a whole. You understand if this person can only
only vibecode which is not who you want to hire or if this person can send a good prompt to an engine agent but then also provide you with a great assessment of the agent’s output and
maybe you know bring some corrections and add additional prompts for the agent to polish the solution and this is the person that you probably want to hire because this person knows what they are doing, they’re professional enough, and they they will generate great result.
Federico Ramallo (24:51) Right, right. I I I think you you’re touching very interesting points. I I think that finding candidates that have a T shaped knowledge where they have deep knowledge on the specific areas and and well the way that I understand it is functionally, right? I mean if you can understand functionally how each
component within the layer of of of of the process sh should work, what it does, then it becomes less relevant to know the specific syntax or on how to write it. But but understanding the the the functional role, the trade offs, the pros and cons, and then from there being able to make the decisions, then you can you can leverage the agents better because you can supervise and guide them
towards the solution that based on your experience you know that it’s going to be the best for that specific you know, challenge or problem or or feature, right?
Anton Pleshivtsev (25:48) Yeah, yeah. That’s exactly my point.
Federico Ramallo (25:52) Interesting. I I I’m writing a book about managing teams and I call it the invisible distance, which is you know it’s a reference to these invisible problems that that that kind of show up through all the time. And my thesis is that you know related to AI, that context is the most important leverage, right? I mean having a long-term team that can guide, that understand the business problem, that can guide
the agents that has a deep technical knowledge that can that can guide the agents towards what are things that they need to avoid, what are things that they need to build and and kind of understand the how’s and the whys. It’s it’s where you can get the most out of of those agents because what’s a point of speed if you’re going the wrong direction, right?
Anton Pleshivtsev (26:41) Yeah, w w one thing that we noticed internally is that if few years ago we would set up like linters and basically automated checks.
Right now we are focusing on setting proper context. So for example, for the repository responsible for API endpoints, the context contains like who are the users, how they are using usage patterns, a little bit of statistics based on logs because it is important to know that for example there is extremely high usage during daytime in the US.
and it it drops significantly during night time. So for example, some heavy crons we can we should probably run during night time or s some specific endpoints are used more heavily and they should have
close to 100% test coverage because it is a very sensitive part of the business. And so we are actually focusing a lot on providing the proper context for each repository so that even if the person who is making a change is not like a the strongest engineer in the team, they still have this harness that will help them to make the right solution.
Federico Ramallo (28:01) I I used to think of test coverage as, you know, a hundred percent line.
But then I realized, yeah, you can have that, but you can still miss what’s value for the user, right? So having tests that actually validate the expected behavior from the user perspective is much more valuable than a hundred percent code test coverage, right?
Anton Pleshivtsev (28:25) Mm-hmm.
Federico Ramallo (28:26) Yeah, and and in the age of AI, I think that having clear RFPs and being able to provide those specific sp level of specificity, it becomes a game changer because with that you can have automated tests, you can’t delegate more to the agents to build code, but based on those specifications, right? that that becomes much more important and
actually in the long term saves you tokens and time.
Anton Pleshivtsev (28:56) Yeah, we we all we also changed so to your point, we also changed the requirements to the ticket format.
Because initially the CSM would file a ticket with just a little bit of description and that’s it. And this is not very helpful because you probably need to investigate something or you know check user session. But if the ticket contains enough context, for example, several screenshots and additional description of the feature, an additional description on this customer. For example, this customer is like VIP who is using
like this and that endpoints because they you know the business is focused on this and that then it becomes way easier for you to run the agent that already understands more about the problem
instead of you trying to configure the right context for it so that the ticket becomes the right context. And it i the the level of automation that we are getting close to is when I open the Kanban board, I see let’s say I have like five tickets in to-do column. Let’s say these this is the five tickets reported for this week, like technically bucks.
And I can just run an agent which will figure out that it needs to spawn five parallel agents. Each one will take their context from each of these tickets and will work on them in parallel.
And for me it’s just one prompt, but on the background the there is the whole thing happening, like running additional parallel agents, all collecting details and context from these tickets and moving them through the border.
Federico Ramallo (30:42) Right. Right. That’s interesting. I mean I on on on a few teams I’ve done this
transf organizational transformation where I would involve the product owners with designers to provide clear requirements on on the new features so that the engineering team would have all the requirements, not only the happy path but also the unhappy path. And then less dependencies, they can move faster, they can build more reliably and more and have more reliable estimations, right?
I I’ve been wondering how I would change that workflow. I that was pre pre AI, right? So I’m wondering how I would change that workflow now because the the expectation of the product owner and the software engineer, they they are they they are kind of overlapping a little bit, right? The engineer needs to learn more about the user and the product owner needs to be able to get more technically
or or vibe code a little bit more, right? Or that’s what I’ve been that I’ve seen that is happening, right? what I did is I turned the, you know, long RFP that most people would not read or by the time they read and have questions already too late to a storytelling from the product owner. So that that changed the dynamic of how people would be open to actually were excited to go and to these meetings, right? so I’m wondering
how we change that with with AI, right? I’m wondering how you’ve been able to solve that issue now that you’re talking about tickets.
Anton Pleshivtsev (32:10) Wait wait, what what is the question?
Federico Ramallo (32:12) So how basically how what is the social contract between the product people and the engineering teams regarding to tickets and, you know, new feature requests?
Anton Pleshivtsev (32:23) To be fair, we don’t have product people and this is how we work for the last few years at least, including my previous company, it’s not that we I don’t want to say that we don’t need product people, but we we need different product people. So instead of people who would you know
provide like long descriptions, like analysis and stuff. Th this is something that engineer can do right now, right? You you don’t need a product person to check analytics on a given customer and see their usage patterns and their needs and understand like what they’re doing, right? Because you can just run the agent and the agent will do this for you in like five minutes.
The same is true for for the post-deployment stage when the feature is released and someone needs to monitor and see how it works. And usually the the classic way would be the engineer would switch to something else and the product person will set up some analytics dashboard and then check how the feature is being used, if it is useful, maybe A B test it. instead, you can just run a loop or schedule.
Federico Ramallo (33:11) Right.
Anton Pleshivtsev (33:38) Scheduled agent command, which will just keep checking it once a day to make sure everything is working as expected, and maybe even send you a final report one week later. So it’s it’s the the PM’s role became very automatable, and PM is someone who I would say should be the member of the engineering team, focusing on more like a data and
and slash analytics type of things like constantly check how things are working, run check graphs, check usage patterns, check logs, and provide feedback for the team based on the data.
Federico Ramallo (34:20) that’s very interesting. I actually I I when I was saying that there was an overlap, it probably I was under describing it because I’ve seen as you said, I I’ve seen engineers take over the product role, right? and I’ve seen particularly technical product managers, technical product owners getting more and more deep into the into the the code because now they can have agents bu building code. So they they’re kind of taking more of a
software engineering role. so I I I’ve seen that overlap happening, right? it’s very interesting that that you don’t need a product team.
Anton Pleshivtsev (34:52) Yeah. In
in Semblu a lot of people who previously used to be like you know PMs managers, customer success people.
Since we have the hardness in place, since we have a lot of context added to the repository, agent instructions, and a lot of context is living in a ticket. They technically for for for a simple problem, they don’t need an engineer. They can just run the agent in the repository that it will pick up all the relevant context files, and it will add the problem context from the ticket.
There there is a high chance it will one shot the problem for them. We
In fact, you only need engineers for tricky cases when there is like you know, DNS routing, something that you need to, you know, combine several data sources to understand what’s happening and you know, use some tricky MCP integrations and stuff like that. And even in this case, the problem is more is becoming more of like reading outputs and guiding agents instead of like doing things manually.
Federico Ramallo (36:03) Right, right. That’s interesting. I I haven’t thought it that way. Yeah. The w what I’ve been able to say recently is that once you have all the requirements and all the expected behavior, it’s it’s the underlying technology becomes less relevant in the sense that it it’s easier if you want to just change the technology because you know what what we’re having
a a a costly migration years ago. Now you can say with all these requirements, just rebuild it in this new language or this new tool or whatever it is, right? and it’s much faster to do for for the models thinking on one language, coding language or one other code language or human language, it’s it becomes indistinguishable, right?
Anton Pleshivtsev (36:49) Yeah, I was initially confused by this. Y I I guess you have seen, Claude, they Anthropic released this new command called call. So you basically set the call for the for the for the agent. And I initially was confused by the use case of this. And then I realized I need to fix something and my first approach
Yeah, I I basically make a code change, push it to the CI C D instance, and then it runs and if it it doesn’t pass the test case, I need to make a change locally and then push again and see if it passes. And
At some point I realized I’m making like a cycle type of work, right? Yeah, I make a change, I push, wait, then I make a change, I push. And so this this is where it clicked. I was like, the this is where the goal should be used. I was like, your goal is to make sure it will pass CI C D checks. And I I just my computer was open for like the whole night. I I was sleep sleeping like a baby and the agent was like
Just trying to achieve its goal, right? It was making changes, doing its research, pushing to CICD, waiting for CICD run to complete, then making additional changes. And it was actually a pretty tricky bug to fix, but Magent managed to achieve its goal in like six or maybe eight hours, mostly because it has to wait for CICD runs, but I didn’t have to do
do
anything, I was just sleeping. So th th this this is just just you know w one recent example where the goal command was like really really useful for me.
Federico Ramallo (38:27) Amazing, amazing. That’s very interesting. I I I’m I’m exploring that that higher level functionality on on being able to delegate more complex tasks long run and see what happens, right? with good results and some you know, frustrations throughout the process, but it’s mostly positive, right? w we’re running out of time. I truly appreciate Anton you being here today. any final feedback, any final advice about
you know, the strong engineering culture that you’re building with your with your teams.
Anton Pleshivtsev (39:00) Yeah, just just one thing. Never stop learning. Things are changing faster than ever. And the only way to stay
to stay up to date with the current things is to constantly learn, aggregate knowledge, y feel free to use summarization because you know, every time I open hacker news I see like so much information to learn that I will probably have to do this as a full time job if I want to read it all, but
again, y ask your agents to aggregate, provide you with summary, and check what is the most important things and make sure you understand technical details because this is what makes the difference between senior and junior people.
Federico Ramallo (39:47) Amazing. Anton, thank you very much for joining us today.
Anton Pleshivtsev (39:53) Thank you.