LLMs Changed Developer Hiring—Here's What Actually Works

The client expectation compression is wild right now. Tapas Adhikary runs a 20-developer consultancy building software for companies worldwide, and he's watching timelines that used to span 20 days collapse to three. Not because developers got 7x faster at writing code—because the entire conversation around what's possible changed.

"The biggest thing that is changing in software engineering today is the expectation," Adhikary told freeCodeCamp's Quincy Larson on a recent podcast. "It starts with your end user, it starts with your customer... what customers are looking for, the users are looking for is speed, speed of execution."

Here's the thing clients don't always understand: just because you can Figma-to-React an entire app in an afternoon doesn't mean you should ship that to actual users. Adhikary's team deals with this reality constantly—clients who've vibe-coded a prototype and can't figure out why productionizing it takes weeks.

His response? Turn the question around. "Think that you yourself using something that I'm giving which is MVP—would you accept using that?" The answer is always no. That gap between "it works on my machine" and "it works for 10,000 concurrent users at 3am" is where actual engineering happens.

The MVP speed multiplier changes everything

But here's where it gets interesting: that compressed MVP timeline isn't just about managing client expectations. It's fundamentally changing how development teams operate.

"If there is a proof of concept required which probably used to take like 3 to 4 days, today it is half a day," Adhikary explained. That half-day turnaround means the feedback loop with clients accelerates dramatically. You're not spending three weeks building something only to discover the client wanted something completely different. You're iterating in days, sometimes hours.

The side effect? Development shops can take on more experimental projects because the cost of "let's try this and see" dropped through the floor. Adhikary mentioned cases where clients specifically ask for the quick-and-dirty MVP first—ship it to their users, gather real feedback, then decide whether to build the production version. That workflow didn't really exist before LLM tools made prototyping this fast.

Hiring for fundamentals plus tool fluency

The hiring implications are the part that caught my attention. Adhikary doesn't care much about years of experience anymore. "A two years experienced person who has dramatically good fundamentals... versus a five years experience software developer who doesn't have much of the fundamentals—I would prefer to go with that two years experienced developer."

With AI code generation tools, someone with solid fundamentals and two years of experience can produce work that used to require a senior developer. The gap between junior and senior is still there, but it's narrower. "Someone who is very AI minded, can use the AI tools with his fullest capabilities, know how to play with prompts—they will be much much productive than someone who has still not adopted it but like 8 years experience."

This is reshaping his entire recruitment strategy. Investment is going into tooling subscriptions instead of purely into senior salaries. Junior developers who understand how to prompt effectively and know when the AI is generating garbage can handle the initial implementation. Then senior developers step in to review, refactor, and make architectural decisions.

The fundamentals piece is critical though. Adhikary emphasized this repeatedly—he's that guy who "kind of preaches" about fundamentals until people find him boring. But with LLMs generating code, you need those fundamentals to evaluate whether what you're getting is correct. "I can do my own judgment whether it is giving me the right thing or not. I can again go back to the tool and ask for the right set of questions... because I have that fundamental."

Roles are merging whether we like it or not

The organizational structure is flattening too. A decade ago, you had clear hierarchies—intern, junior, senior, team lead, architect. Different people owned different parts of the process. Someone designed the solution, someone else wrote the code, someone else tested it.

"Today I think it is expected that even if a fresher is coming in they have some kind of solution mindset," Adhikary said. Even entry-level developers need to think like product managers and QA engineers because the speed expectations demand it. You can't throw work over the cubicle wall anymore—there's no time.

This is a mixed bag. On one hand, junior developers get to think about business value and user impact from day one instead of just executing tickets. On the other hand, that's a lot of context to load into your brain when you're still figuring out how async/await works.

The part nobody's talking about enough: this acceleration has side effects Adhikary only hinted at. When you compress 20 days into three, what happens to the thinking time? The "let me sleep on this architectural decision" phase? The part where you realize your initial approach was wrong before you've written 10,000 lines of code?

Speed is the client's top priority now. The question is whether development teams can maintain quality while delivering at these new velocities—or whether we're building technical debt faster than ever before, just with better tools.

Tyler Nakamura reviews consumer tech and gadgets for Buzzrag, with a focus on how tools actually perform in real-world conditions.