Find the right AI use cases before investing in development.
Connect AI to your existing systems and workflows.
Build autonomous AI agents that automate complex tasks.
Design and develop AI solutions tailored to your business.
Build secure, scalable AI systems for enterprise environments.
Capabilities
Want to start a software project with us?
Book a time with our technology experts →
Make informed technology decisions before investing in development.
Validate your product idea with user and business insights.
Define the right scope to launch faster and reduce risk.
Confirm your idea is technically viable before you build.
Legacy software modernization →
Upgrade outdated systems for better performance, security, and scalability.
Everyone has an opinion on what AI did to software engineering. Almost all of them agree on one thing: writing code matters less now.
I talked with Aleksandr Volodarsky, CEO of Lemon.io, about which skills engineers actually need in this market.
Aleksandr has spent about a decade matching vetted engineers with startups, mostly in the US. He’s not an engineer, and he brings it up himself. His view comes from the buying side: what clients pay for, and why projects go wrong.
His take pushes back on the premise: nothing about what makes a good engineer has changed. What changed is how much one person can produce.
In this article, I’ll break down Aleksandr’s view on how the hiring market has transformed, which skills now separate senior engineers from everyone else, and what he would tell an engineer to work on next.
Lemon.io is a hiring platform that connects startups with vetted software engineers.
It started in 2015 and now has more than 1,500 engineers on the platform, spread across 40 countries and four continents.
The business is built on filtering. Sourcing, technical vetting, and screening happen before a client ever sees a candidate, and the client gets a shortlist rather than a pipeline.
source: Lemon.io
That means Lemon.io absorbs the cost of every bad match, which gives the company a sharp incentive to know exactly which signals predict a good hire.
That’s why we wanted Aleksandr’s perspective for this piece.
He sees the demand side and the supply side at volume, across hundreds of engagements, and he can tell you what changed in client requests month by month rather than in the abstract.
If you want to know which skills matter, look at what buyers are willing to pay for.
The clearest change Aleksandr sees is in seniority.
Until about a year ago, larger non-technical companies would tell him they could work with a mid-level to senior developer. Senior-only requests were roughly 40% of the total.
Now that split looks very different:
Now, I think it’s like 80% of requests are for senior developers. So no one even wants to talk to a mid developer anymore.
Aleksandr Volodarsky, CEO at Lemon.io
Both numbers are approximate. The direction is what matters, and it runs against the assumption that AI would let companies hire cheaper and coach people up.
His explanation is that AI is badly overestimated on exactly this point.
It can help a junior developer produce code. It cannot give them the judgment that makes a senior worth hiring.
As he put it:
You cannot close the gap between a lack of knowledge and senior expertise by just talking to AI.
Aleksandr Volodarsky, CEO at Lemon.io
He’s careful to caveat the whole topic.
Silicon Valley giants and outsourcing companies in Eastern Europe, for example, think very differently about how to use AI in development, and everyone is a few years into a transition with no settled view.
The senior shift has a knock-on effect on how people enter the industry.
Aleksandr mentioned a story about how one large player in the market grew hard from roughly 2020 to 2023 by training junior developers and placing them into big organizations.
That model was its strength. Now it’s a liability, because demand for junior work keeps shrinking.
Seniority isn’t the only thing that changed. The mix of skills clients ask for looks different too.
Domain experience in industries like healthcare, security, or fintech accounts for roughly 25% of what clients specify. Soft skills take a bigger share, and Aleksandr expects that share to keep growing.
Two client types behave very differently in his experience.
Next, we’ll look at the skills that the market rewards, starting with soft skills.
Soft skills are the vaguest item on any hiring wishlist. Everyone says they want them. Almost nobody can say how they’d test for them.
The name doesn’t help. It makes them sound like a bonus on top of the real work. But soft skills are what most projects fail on.
They matter more now because teams are smaller. When five people can ship what fifteen used to ship, every decision covers more ground, and fewer people check it.
Lemon.io has churn, like any business, and Aleksandr knows where it comes from:
Ninety-something percent of it is soft skills. Not because the developers couldn’t deliver, but because of the soft skills, miscommunications, and tension.
Aleksandr Volodarsky, CEO at Lemon.io
In short, the code is rarely the problem.
Communication in engineering is a narrower skill than the word suggests. It isn’t charisma, and it isn’t being pleasant in meetings.
It’s the ability to make your reasoning clear to someone who wasn’t in your head when you made the decision. In day-to-day work, that shows up as:
AI raises the stakes on all four. A model can produce a big change in minutes, and that makes it much harder to review.
The only thing that helps is the engineer explaining what the change does and why they kept it. Code nobody can explain is a risk, whoever wrote it.
Two of the four skills Aleksandr would tell an engineer to build are about communication: explaining the problem, and making the case for the solution.
He also expects an engineer to talk to a client directly, without a project manager smoothing it over.
Ownership is the difference between finishing a ticket and finishing a job.
An engineer with ownership treats the outcome as theirs. Does the feature work in production? Does anyone use it? Did it leave a mess for whoever picks it up next? An engineer without it stops at the ticket.
This matters more when work happens faster. More gets done in a week, which means more small decisions, and most are too small to ask anyone about. Someone has to make them without being told to.
At Lemon.io, ownership isn’t a preference. It comes with the job. Most clients aren’t hiring developer number 1,000. They’re hiring developer number two, three or five.
That’s close to founder-level responsibility, and it rules out one familiar excuse:
It’s not that you can hide behind, like, I’m just a coder over here, I’ll just do whatever you want.
Engineers who clearly care about the product tend to get their contracts extended.
Clients see that care and stick around, which is how a soft skill turns into repeat work.
Autonomy gets confused with working alone. It’s really about what you do when the ticket stops telling you what to do.
Every task has gaps. The ticket won’t say what happens when the request fails.
An autonomous engineer spots the gap, picks an answer, and tells people. A developer who doesn’t know how to work independently waits to be told, or guesses and says nothing.
It’s worth more now because seniors have less time to check things. They review more work each week than they used to. Every team can carry only a few people who need direction, and that number just got smaller.
Aleksandr has wanted the same thing since the company started. He can list it from memory: someone who brings solutions, thinks a problem through, understands it, and can talk to a client about it.
Ten years ago, when every feature had to be hand-coded, clients still put that at the top of the pyramid.
Whether you wrote clean code sat, in his words, “much, much lower in the chain.”
That’s the whole argument. The hierarchy people think AI created was already there.
Prioritizing used to be someone else’s job. Product managers and tech leads decided what came next, and engineers built it.
Choosing what to build is a trade-off between impact and effort: how much something is worth against how long it takes.
When effort was the bottleneck, the choice made itself. You could only do one thing, so you did the obvious one.
Now the effort is cheap. That leaves impact as the only thing separating one option from the next.
And impact is the harder half. You can estimate effort from the code. You can only judge impact if you understand the business and the people using the product.
Aleksandr sees this as a backlog problem. Companies want to move faster and out-compete each other, so the extra room fills with more work:
When there’s so much capacity open, there are more things piled up, and then you have to think about prioritization even more. I have this much capacity, what can I attack?
That call used to be made above the engineer. Now the engineer has to make it.
Product mindset comes up more than anything else in Aleksandr’s answers, so it’s worth being clear about what it means.
A product-minded engineer starts from the problem instead of the request. They want to know what the user is trying to do and what the business gets if it works. Then they decide what to build.
An engineer without it builds whatever they’re handed, and stops there.
Both can write good code. The difference is what they catch.
One builds the button as described. The other asks why the button is needed, and sometimes saves the team a month of unnecessary work.
Aleksandr says this was always at the top of the list. AI didn’t create the requirement.
Working out what a request is for is its own skill. It’s usually a few plain questions. Who has this problem? What do they do about it now? Why is this the fix, and not something simpler?
This is also the part Aleksandr thinks engineers are most likely to hand over without noticing.
Ask a model to build what the ticket describes, and it will. It won’t ask whether the ticket describes the right thing.
Asked which skills are at risk of atrophying, Aleksandr was tentative and said so. The one he named without hesitation was product thinking:
If they’re outsourcing their product thinking to AI, I think this is a big problem.
So ask the questions first. Who has this problem, what they do about it now, why this is the fix. A model won’t ask them for you.
Once you know the problem, someone has to decide how to solve it. For an individual engineer, that mostly means unglamorous choices like:
None of these have a right answer.
They’re trade-offs, and they depend on things a model doesn’t know: how long this has to last, how much the team can maintain, what the company will want in six months.
Aleksandr’s phrasing is blunt. You have to act like a solution architect, and if you don’t, you get wrong solutions.
An engineer who takes whatever the model produces stops having any say in the product. He goes even further: the effect they do have turns negative.
The economics here are simple. When something gets cheap and everyone can do it, it stops setting you apart. Nobody gets hired for being good at version control.
Aleksandr gets to the same place from a more personal angle, starting with a question he asks about himself rather than about engineers:
Right now, everything is slop, and the problem with slop is that it basically equalizes everyone. Everyone is the same.
If he uses a model to write something and the person next to him uses the same model, he can’t tell the difference.
As he put it, he isn’t saying anything. He’s using a model to say it.
Aleksandr puts it even more bluntly:
Zero to one is done by LLM. It has no value.
So do the first part yourself. Work out the problem and decide how to solve it, then let the model write the code. The thinking is what you’re paid for, so don’t give it away.
None of the above works without strong technical fundamentals, and Aleksandr is unambiguous here despite being non-technical himself.
This is where a lot of AI commentary goes wrong. If judgment and product thinking are what get rewarded, it’s easy to assume the technical side matters less.
It’s the other way around. Judgment is built on technical knowledge, and you can’t weigh a trade-off in a system you don’t understand.
In short, fundamentals mean you understand how the software you build actually works.
Things like:
You don’t need any of that to build a prototype. You need all of it the moment real people use the thing. That’s why something built with AI can look finished and still fall over on day one.
If you’re going to do something for 5,000 users or a million users, you need to know the fundamentals. There’s no way around that.
You need both fundamentals and AI fluency in the current market. One is much easier to pick up.
When Lemon.io hired a head of engineering recently, they skipped tool checks on purpose, since anyone can learn a new framework or tool in a couple of days.
They tested whether the candidate understood what the technology can do now, and how models and training work.
Easy to learn doesn’t mean safe to skip, though.
Developers who refuse to touch AI at all, a position you’ll find defended at length on Reddit, are, in Aleksandr’s words, being “ignorant and unnecessary.”
His comparison is factory automation decades ago, which let people produce more instead of putting them out of work.
“Taste” has become the standard shorthand for the thing senior engineers have and junior engineers don’t.
It’s a bad word for hiring, because you can’t test for it and two people using it rarely mean the same thing.
I asked Aleksandr about it anyway. He pushed back before he’d answer:
Something you cannot measure, I think it’s irrelevant in the conversation.
He cited the clip of Rick Rubin saying he can’t play an instrument, can’t sing, doesn’t know music, and gets paid tens of millions for his ability to express his taste.
Fine for a producer. Useless as a hiring criterion for software engineers.
Then he gave a definition that does work for engineering: taste in coding is knowing the basics well enough to understand the consequences of structuring a solution one way instead of another.
The useful part is that you can interview for it. Ask what breaks if this gets ten times bigger. Ask what this choice makes harder to change next year. Ask why this approach and not the obvious one.
Nobody can memorize their way through those answers.
Most coverage of AI code quality focuses on whether the code is correct. Aleksandr’s take is that it’s the wrong place to look.
It’s not about bugs, because AI testing is as good as AI coding. So bug fixing is not a problem.
The trouble is where new code meets old code.
Any change to an existing system inherits assumptions that aren’t written down anywhere: what a shared function is used for elsewhere, which callers depend on the current behavior, what the data means as opposed to what type it is.
A model working from the code in front of it doesn’t have that, and its output can be locally correct and globally wrong.
Aleksandr’s framing is that an engineer still has to be a moving part in the machine, and that means understanding how the machine works.
He also names the cause. Speed is why people skip this step.
When it feels like you can go as fast as you want, you don’t ask how this works in the system you already have.
So the upside creates the downside.
People who hand over the whole task run into delivery problems, and they don’t see them coming, because nothing in the output looks wrong.
Aleksandr treats using AI as non-optional and unremarkable. The interesting question is what you’re doing while the model works.
There’s a real distinction between prompting a model and directing one, and it’s mostly about who holds the plan.
Prompting is describing an outcome and accepting what comes back. Directing means scoping the task before you start, supplying the context the model has no way to know, reading the intermediate output, and stopping it when the approach is wrong rather than fixing the result afterward.
It’s closer to running a competent contractor than to searching.
That distinction is now something Lemon.io tests for. Two things changed in how they vet developers, and only two. The fundamentals of their process stayed the same.
The first is that they test whether a candidate can direct a model rather than talk to one:
Writing a few prompts is not a skill, but directing and having, and I hate this word, taste in how you work with LLMs, this is what we’re trying to test for.
The method is hands-on and hard to game. They sit with the developer, watch them work, ask them to complete something, then ask them to explain what the model did and how it arrived at that conclusion.
The second change comes from growth. They’re vetting more people than before, so they need faster ways to spot a good one.
What they look for is how someone thinks through a problem, not how they write code.
Speed is the one place Aleksandr says the bar genuinely moved, and he doesn’t hedge it. Nothing else comes close.
It’s worth being precise about why speed matters.
Faster execution shortens the loop between having an idea and finding out whether it was right, which means a team can be wrong more often at lower cost.
That changes what’s worth trying, not just how fast the work gets done.
What’s interesting is what it used to cost.
Before, speed of execution was a very elite thing. I think it still is, but it’s easier right now to get to it.
Moving fast used to mean hiring a bunch of engineers, feeding 10 times more people, keeping an office running around the clock.
It was available to scale-ups like Stripe and to top-tier Y Combinator companies, and not to anyone else.
Now it takes one developer who wants to move fast, wherever they happen to be.
It comes down to the order you work in, and the same order works for code and for writing:
If everyone works the same way with the same models, nobody stands out.
I closed by asking what an engineer should invest in over the next few years. Aleksandr’s answer contained no technologies:
If you consider yourself a decent engineer, what will take you to the next step is not being an even better engineer, but having better skills of: how do I understand the problem? How do I think about solutions for this problem? How do I communicate my problems? How do I vouch for the solutions?
Four things, in that order. Understand the problem. Think about solutions. Communicate them. Defend them.
If 80% of requests are senior-only, the obvious question is how can anyone break into the market and get their first job?
Aleksandr raised it himself, and his answer runs the other way.
He thinks starting a career got slightly easier. You can now ship something real in your first six months, or before your career even starts, while you’re still in college.
Bring something significant to market, and you can count as mid-level from the beginning, because you can point at a thing that exists.
What changes is the evidence:
The skill wouldn’t be that, oh, I’ve coded 10,000 lines of code. It would be like, this is how I understand the problem. This is how I came up with the solution to the problem.
That changes what a portfolio is for. A pile of work used to prove experience, because you couldn’t fake the hours.
Now what counts is the reasoning: what you were solving, what else you considered, and why you picked this.
There’s nothing dramatic in what Aleksandr describes. He isn’t predicting a new kind of engineer. He’s pointing at the things clients always wanted most, and saying AI made them easier to see.
For engineers, that makes the plan simple, if not easy. Fundamentals decide how far you can go. Product thinking, ownership, and communication decide how far you get.
Work out the problem and the solution yourself, then let the model write the code.
That’s almost exactly how DECODE works too.
We hire from the top 1.5% of applicants, and every engineer works on one project at a time, so they have room to challenge decisions instead of waiting for tickets.
We use AI agents with senior engineers supervising, which keeps the thinking with people while the code gets written faster.
And if you’re hiring, you can test for all of it.
Watch someone work with a model and ask them to explain its choices. Check whether they can read a system before changing it. Skip questions about tools.
If the engineers you need don’t seem to exist in your pipeline right now, that’s usually a solvable problem.
An inside look at how DECODE uses AI to build software faster, smarter, and with the same high engineering standards.
Expert interview with Ion Hrytsku of SapientPro on what AI can and can’t do in software development, with practical advice on using it without lowering quality.
A CTO's guide to hiring, building and supporting a high-performing software development team.
