Which software engineering skills matter in the age of AI?

retained text

If you ask a developer about their workflow, they can tell you how much faster the latest model is, what their coding agent can now handle, and which new tool has improved the way they work. Kunal Kushwaha has a follow-up question.
“What about you?”
I recently sat down with Kunal, the founder of WeMakeDevs, at CodeRabbit’s San Francisco office for an episode of The Merge. We talked about what software engineers should learn as AI takes on more implementation work and how they can continue improving alongside the tools they use.
Kunal’s answer starts with the work that still belongs to the engineer. They need to understand the problem well enough to choose an approach and explain the reasoning behind their decisions. Whatever tools they use, they remain responsible for what ships. He also pointed to a practical way for engineers to develop greater technical depth: running an LLM locally.
Figure 1. Engineering judgment depends on understanding how the pieces of a system fit together.
When a 12-year-old can build a product in eight hours
At a recent hackathon, Kunal met a 12-year-old who had registered but was still on the waitlist. His dad had already dropped him off, and Kunal let him join the event.
The young developer’s project became one of Kunal’s favorites from the past ten hackathons. It could research a user’s idea, generate a website around it, and identify people the user could contact. Kunal was impressed by the interface, documentation, and how the project brought the tools together. The demo video on LinkedIn also includes a brief role-play.
Kunal said the whole thing came together in eight hours. For engineers who spent years learning languages, frameworks, and the relationship between software and hardware, watching a 12-year-old create a substantial application in an afternoon can be unsettling. It led us into a more uncomfortable part of the conversation: what this shift means for engineers whose roles are centered on implementation.
Kunal is enthusiastic about what these tools make possible, but he recognizes that the transition will be harder for some engineers than others. Someone doing narrowly defined implementation work, with few opportunities to move into another role, may be affected very differently from someone with more options.
His advice is to examine what you bring to the work as more of the implementation becomes automated.
Fundamentals help engineers see past the hype
Technical fundamentals still matter because they give engineers a way to evaluate what AI tools produce and the claims made about them. When I asked Kunal if learning the low-level details still matter, he put the benefit plainly: “You learn how to escape the hype cycle.”
Understanding the basics makes it easier to ask what a tool actually changes, which part of the system it helps, and where its limitations matter. Without that grounding, it is easy to mistake a better demo for a better solution to the problem in front of you.
That does not mean engineers need to know everything. Kunal has worked deeply with Kubernetes and still encounters unfamiliar parts of Kubernetes, Linux, and networking. His hands-on experience gives him enough context to investigate what he does not know and make informed decisions.
He applies the same reasoning to learning with AI. A student can use an agent to build an entire website, but the learning should not end there. They should read what it produced, ask how the functions work, and use the implementation to deepen their understanding. What matters is whether each project leaves them better able to explain, change, and debug the next one.
Product judgment matters more as implementation gets easier
Kunal proposes a simple way to assess product judgment in an interview: give the candidate a URL and say, “Talk to me about this website.”
He wants to hear how the candidate breaks down the product, what they would change with creative control, and how those decisions could affect the business. Their response shows if they can identify what deserves attention and explain why their proposed changes would matter.
This echoes our conversation with Kent C. Dodds about what work will look like for "the last software engineer." Kent argued that as agents take on more implementation, engineers will spend more time deciding what to build, shaping the system, and judging the result. Kunal reaches a similar conclusion through his work with students, engineers, and hackathon teams. He also sees collaboration, empathy, and an understanding of the people who will use the software as essential to the job.
Hackathons also give him a practical view of execution. In those environments, Kunal looks for the same kind of judgment in how teams decide what to build and present their work. The strongest teams get one main feature working, save a usable first version, and build from there. They also make the result easy to try.
Kunal’s emphasis on execution sparked a discussion about how much weight should be given to the idea. He suggested that ideas matter less than execution, while I argued that as implementation gets easier, choosing a valuable problem should matter that much more. Kunal qualified his point: an ambitious idea still needs a working implementation. A small, well-executed product can beat a bigger idea that never gets built.
Figure 2. A small working product gives people something they can try and respond to.
How far automated code review can go
Our sharpest disagreement was over how far automated review will go. Kunal expects agents to handle more of it and thinks humans may eventually stop reviewing code altogether. At the same time, he believes the stakes should determine how much attention a change receives. He used a hypothetical Black Friday incident at a large company to illustrate where he would still expect human review. If an agent produced a fix during a major sale, he would still want a person to check it.
While we differed on how much review agents will eventually handle, we agreed that responsibility for the result does not shift to the agent.
“If something messes up, you’re the one who is responsible,” Kunal said.
The conversation turned to what happens as agent-generated changes accumulate in a system. I described a project I had been building with coding agents for about a year. Early on, I understood what they were putting together. As more agents contributed, maintaining that understanding became harder, although the automated checks continued to pass. We discussed maintenance, performance, and security problems that may surface only after a change passes its tests and reaches production.
That led us to discuss the blast radius of a change. Reviewers need to see how it affects the wider application, including areas they did not expect the agent to touch. At CodeRabbit, we built Change Stack to provide that expanded view. It organizes pull requests into logical groups and layers so reviewers can follow dependencies across the change.
Learn to run LLMs locally
When I asked Kunal for a specific technical skill engineers should learn next, he suggested something quite different from another coding-agent workflow.
“Learn how to run LLMs locally.”
His recommendation is to run a model locally and then explore fine-tuning and what it would take to run it at scale. Kunal says the exercise exposes engineers to the infrastructure behind the interface, including how the model runs, how its components communicate, and the deployment choices involved.
He compared the experience with learning Kubernetes. An engineer may use a managed service in production while still benefiting from having built and operated a small cluster. That experience helps them understand what the managed service is doing on their behalf.
The same principle applies when a team chooses how to serve a model. An API, company-owned hardware, and a managed platform come with different tradeoffs. Working through a local setup gives engineers more context to ask better questions about the various options.
Figure 3. Running a model locally exposes the components behind an AI service before you consider deployment at scale.
Build experience through open source and sharing
Open source gave Kunal a way around a familiar problem early in his career: an internship application asks for experience, but getting it seems to require an internship. Rather than wait for an opportunity, he built experience in public by contributing to Kubernetes, taking part in Google Summer of Code, and eventually mentoring others.
He would still recommend that path to an engineer starting today, despite the proliferation of AI tools. Kunal sees projects, open-source contributions, and hackathons as opportunities for developers to build skills and share what they learn. Posting that you completed a tutorial marks your progress, but explaining a concept from it invites feedback that can test and deepen your understanding of the material.
For engineers preparing for their next role, Kunal recommends that they study the work the job involves and the AI tools and systems people use to do it, then put that knowledge to work in a project. Sharing that work gives other people a chance to try it and offer feedback. A developer who understands a project well enough to explain it, improve it in response to feedback, and stand behind the result has a concrete answer to Kunal’s opening question: “What about you?”

document fetched 2026-10-24 11:26