At first, many dismissed AI as a temporary bubble, but now that engineering organizations are adopting agentic workflows at scale, it is much harder to negate this new reality. Naturally, this shift has triggered a wave of industry anxiety. Engineers are looking at the landscape and asking a frantic question: What skills do I need to keep my job?
For decades, developers prided themselves on memorizing syntax, writing algorithms from scratch, and passing LeetCode interviews by repeating patterns. The pivots we made in the past were typically centered around the framework of the week (especially in the JavaScript world). Switching frameworks only required relying on the strong foundational software engineering skills picked up at school, in a coding bootcamp, or even from a YouTube video. But now that AI agents can produce code in seconds, developer egos are crumbling.
In pursuit of relevance, developers have to sift through the noise of industry influencers pushing various strategies: Agent Skills, MCP, Gas Town, or building custom agents from scratch. Yet every one of these strategies boils down to a single foundation. That same foundation remains the number one skill for developers today, just as it was before the AI boom: communication.
Code alone does not make a great developer. When coupled with strong communication skills, it becomes a distinct competitive advantage. However, we often overlook these skills because our industry excuses poor communication, hiding behind the stereotype that software engineering is an isolated job for people who just want to avoid human interaction.
Early in my career as a junior software engineer, I struggled. It was not due to technical aptitude; instead, I simply struggled to verbalize my thoughts well. For example, when I was stuck on a problem, I didn’t understand how to ask for help. I would write essay-length questions on Slack, burying my actual problem in a mountain of unnecessary context, or I wouldnt provide enough information at all. Either way, my teammates werent motivated to help me because they didn’t understand what I was trying to say.
I finally made progress in my career when I learned how to communicate with clarity. That realization eventually propelled me out of junior loops and into senior leadership roles in developer advocacy, where communication is the core focus.
This requirement is evident in the way our industry identifies talent. In technical interviews, the engineers who get hired are the ones who vocalize their reasoning, explain their trade-offs, and talk through their strategy as they adapt to new constraints. The candidates who pass are rarely the ones who silently type out a perfect linked list.
// Detect dark theme var iframe = document.getElementById('tweet-2060553984947950017-785'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2060553984947950017&theme=dark" }
Coding agents have increased the need for clear communication. To have a successful session with an agent, you must be able to clearly express your intent. I find that when engineers claim coding agents are hard to use, unreliable, or hallucinate too much, or when they rely too heavily on overly complex workflows to guide an agent through a codebase, their communication skills often need improvement.
Methods like context engineering, planning, and leveraging Skills are simply different user experiences designed to help engineers better communicate with their agents. For example, while you can create a plan with an agent before starting work, using a command like /plan
ensures you provide the right details upfront and saves an artifact of that plan in a markdown file.
As agent harnesses and models improve, and as executive leaders demand more output, engineers are getting creative to work faster. One common solution is orchestration. In practice, this means you act as a manager of multiple agents working simultaneously, even while you sleep, and you simply review the output at the end.
AI engineering leaders are starting to point out the trade-offs of this approach. @addyosmani wrote an article about it titled The Orchestration Tax.
// Detect dark theme var iframe = document.getElementById('tweet-2059844244907696186-700'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2059844244907696186&theme=dark" }
While your agents might produce a massive amount of work, you now have to review a mountain of output. My main issue with this setup is that the underlying reasoning behind the output often gets lost.
// Detect dark theme var iframe = document.getElementById('tweet-2061159078479663601-885'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2061159078479663601&theme=dark" }
To solve this, we have to start treating agent sessions as durable engineering artifacts. Just like we use version control for our lines of code, we need an audit trail for our agent interactions. You should be able to go back and view the transcripts, the prompts, the tool calls, and the trade-offs an agent made, giving you the context you need to answer for your architectural decisions.
This is one of the many tools my team is building at Entire. We wanted to create that missing track record for agentic workflows. Now, if I open a commit from last week and see a vague message like fixed
, I dont have to wonder what happened. I can run a simple command like:
entire checkpoint explain
Entire then surfaces what was asked, what files changed, what the agent reported back, and which commit it belonged to. It is incredibly useful because I can even ask my agent to look at those tracked sessions to help me better understand and expand on the context. This allows me to keep honing my communication skills and progressing as an engineer.
Ill be vulnerable. Yesterday, I published a blog post on our company website. While the tests for the blog post passed in staging, when I merged it to production, it failed to deploy because of a failing Cloudflare test. I worked with my coding agent to diagnose the problem, and then I learned I had to revert a PR from the Head of Design Engineering where he had bumped our Node version up. Someone approved my PR to revert his code, and I merged it. I did this without him knowing because we are in different time zones. However, I anticipated that the next morning, he would want to know why I reverted his code, and I needed to be able to explain myself.
The problem was that I do not have direct access to Cloudflare since I am not on the core engineering team. I didnt fully understand why he made his original PR, or exactly how my deployment broke it. So, I spent a lot of time asking my agent what happened, why it happened, and how I could fix it. I knew that by the next morning, I would probably forget some of the major details, especially since a lot of the troubleshooting happened at 10 p.m.
But I used Entire to help remind me. First, I ran a simple terminal command:
bashentire checkpoint list
This command surfaces a clean snapshot of my history, giving me a list of various checkpoints and commits from my session with the agent.
Normally, I would choose a specific checkpoint from that list and run entire checkpoint explain
to get an explanation for each individual moment. But because there were so many checkpoints, I wanted to fast-track the process instead of digging through them one by one.
Fortunately, I have agent skills installed that teach my agent how to interact with Entire commands and execute custom workflows. I handed the agent that same screenshot of my checkpoint list and gave it a simple prompt: Can I get an explanation of each of these checkpoints?
My agent responded by explaining the decisions from beginning to end, covering my initial workaround attempts, how I got confused with the version numbers, and how we finally identified a fix, so the next day I would be able to respond to my coworker.
It’s a strange world. The best engineers are no longer defined by how well they memorize syntax. At first, the developers who stand out will be the ones who work the fastest, spinning up multiple subagents and impressing everyone with their raw speed.
But very soon, the most valuable engineers will be the ones who can bring clarity back to the humans on their team. When a system inevitably breaks down, they will be the ones who can look back at their sessions, trace exactly what the agents did, and explain the choices to their team.
Code is cheap, but clarity is getting more expensive.
You can get that clarity today with Entire.