LLMs in Professional Programming What Experienced Practitioners Actually See

Opening

If you are reading this, you probably have mixed feelings about large language models. You may have used one and been impressed. You may have used one and been unnerved. Both reactions are reasonable.

About me: I have worked as a programmer previously, I mentor people entering the field, and I use LLM tools daily. In early 2026, I designed a survey about real-world LLM usage in programming and sent it to six experienced practitioners, all working in the tech industry but with different backgrounds and current places of employment. Each of them also sat down with me for an individual interview. Their careers range from 3 to over 20 years, from FAANG to boutique consultancies. I deliberately chose mid-to-late career people because I wanted depth of judgment from people who have watched this industry change before.

They disagreed with each other. Often sharply. That turned out to be the most useful part.

This guide is built from those seven survey responses and interviews, including my own. The names used throughout are pseudonyms. The practitioners’ identities have been hidden to protect their privacy and at the request of their employers. The sample is small and curated; I will not pretend otherwise.

The practitioners disagree on how much to trust LLM output, when newcomers should start using the tools, and what the profession will look like in ten years. I am not going to resolve those disagreements for you. What I can give you is the questions that came up when experienced people talked honestly about what is changing. If you carry those questions into your own work, you will be better equipped than most.

Let us start with the most basic one.

1. What are you actually working with?

Before we talk about productivity, careers, or team dynamics, we need to settle something more basic: what is this thing you are using when you open an LLM-powered tool and start typing?

The short answer is that you are working with a next-token predictor. The model has been trained on enormous quantities of text from the internet, and when you give it a prompt, it generates the most statistically probable continuation based on that training data. It does not reason. It does not understand. It matches patterns from its training data.

Every practitioner I spoke with uses these tools daily. Six of the seven use Anthropic’s Claude models frequently or always. Two respondents, Kai and Samir, use OpenAI products frequently, though only Samir is also a frequent Claude user; Kai works primarily through Copilot, which routes to multiple providers. One respondent uses Google’s models frequently, and another uses them occasionally. The tool landscape at the time of survey (early 2026, shortly after the release of Opus 4.6) converges heavily on Claude for professional programming work, but it is shifting constantly. Specific product names will be dated within months. What matters is the underlying mechanism, because that does not change as quickly.

The technology only reached sufficient maturity for serious professional use recently. Two of the practitioners, Ben and Samir, specifically recommend Andrej Karpathy’s materials on LLM internals as essential background. Luca recommends Simon Willison. Dani and Noel both emphasize learning by doing: Dani’s recommendation is blunt (“no reading, just practice”), while Noel advises people to practice on their own and discover patterns through experimentation. The message is consistent: understand how the machine works before you trust it with your work.

The practical consequence of the mechanism is something I have seen repeatedly in my own work: the more unusual a project is, the more the LLM will try to steer you away into a more common area. Truly novel projects do not do well with LLMs. This follows directly from training-data dependency. If your task closely resembles patterns the model has seen millions of times, the output will be competent. If your task is genuinely new, the output will pull you toward the familiar whether you want it or not.

How much understanding of the internals is enough? That question is not fully settled. Ben’s compiler analogy suggests a useful floor: you need enough to reason about the tool’s behavior at a high level, not enough to rebuild it. But the floor is firm. No magic, next-word prediction, training-data-dependent. If you carry only those three ideas into the rest of this guide, you will make better decisions than most people who use these tools every day.

2. Does it actually make you faster?

The headline claim is “10x productivity.” The data from the practitioners I talked to says something more complicated.

I asked each person to rate the impact of LLMs on their time, on a scale where 1 means significant time savings, 3 means no change, and 5 means significant extra time spent. The median was 3. Three respondents reported no change. Two reported some time savings. One reported significant time savings. And one reported spending more time than before. The range ran from 1 to 4.

Most people, then, either save time or break even. But the experience is uneven, and where you land depends heavily on what kind of work you do.

Where gains are consistent, they are consistent across the board. All 7 respondents report noticeable improvement in ideation, refactoring, and support work like triaging issues and collecting data. Test code is effectively unanimous as well. Run-time data mining (log analysis, trace analysis) is close behind at 6 of 7. These are tasks that are repetitive, well-patterned, and where a competent first draft saves the human from a cold start. But only 3 of 7 report improvement in initial product delivery (actually shipping a finished feature). Only 2 of 7 report improvement in performance work like profiling and benchmarking. The gains are concentrated in specific task categories.

The tool landscape reflects this. The seven respondents use Copilot, Claude Code, Cursor, and OpenCode. 5 of 7 use sub-agent orchestration for one-shot delegation. One, Luca, does not use orchestration at all. No single tool is dominant, and none is prescribed here. The tooling matters less than understanding which tasks benefit and which do not.

The enjoyment numbers add context. The median is 6.5 out of 10, with a range of 5 to 7. Most people feel moderately positive. But Samir’s sharp split between work and personal enjoyment (3 versus 6) shows that how an organization deploys these tools matters as much as the tools themselves.

If you are entering this profession expecting a revolution in speed, recalibrate. Most practitioners report modest time savings or no change, concentrated in specific task types. The more useful question is what skill separates the people who get value from those who do not.

3. How do you tell it what to do?

If LLMs write the code, what does the human need to be good at? The answer from every practitioner I spoke with is some version of the same two things: directing and reviewing. This section is about the first. Reviewing gets its own treatment next.

Directing means giving the LLM enough context, constraint, and structure to produce useful output. Think of it less as “prompting” and more as managing a fast but unreliable junior employee who never pushes back. You have to know what you want, break it into pieces the tool can handle, and encode your standards so the tool can follow them without being reminded every time.

The practitioners who get the most from these tools invest heavily in that encoding. Luca’s entire approach to LLM-assisted work revolves around rule files (configuration documents that tell the tool what standards to follow, what patterns to use, and what mistakes to avoid). He publishes his rule files openly and treats them as the core artifact of his workflow.

Problem decomposition (breaking a large task into pieces an LLM can handle) emerges as the skill that separates productive use from frustrating use. Luca’s automation session was not a single prompt. It was a structured sequence of directed steps. Samir’s review practice (described in the next section) depends on understanding the task well enough to know what the output should look like. The common thread: the human does the thinking about what needs to happen and why. The LLM does the typing.

4. How do you catch what it got wrong?

The other half of the skill is review. And on review, the practitioners I spoke with hold strong opinions that do not always agree.

The data makes the consensus visible where it exists. When specifications are unclear, 5 of 7 respondents always review the output before submission, and the remaining 2 review most of the time. This is the tightest consensus in the entire survey. Nobody relaxes scrutiny when they are unsure what the code should do. Three of the seven (Luca, Noel, and I) apply more scrutiny to unclear-spec work than we would to equivalent human-written code. Nobody applies less.

But the consensus frays as the stakes appear to drop. For small or repetitive changes, only 2 of 7 always review. I rarely review them myself (I am the outlier there). The spread is even wider for complex changes where the spec is clear: Ben rarely reviews those, while Samir always does. The practitioners agree on the principle that review matters. They disagree, sometimes sharply, on where to draw the line.

Three of the seven flag the same obstacle for junior developers: they cannot assess output quality. They cannot tell a hallucination from truth. Ben put it bluntly: “It’s all LGTM in their eyes.” Two others, Samir and I, identified a related problem: juniors do not think about the problem themselves. They prompt, accept, and move on. The core issue is the same in both cases. Review requires understanding, and understanding is exactly what newer developers have not yet built.

Between these poles — Samir’s thoroughness and Ben’s deliberate selectivity — the rest of us find our own positions. The standards are still forming. Context shapes where you draw the line: the stakes of the code, your experience, the maturity of the codebase.

The deeper issue beneath all of this is accountability. The code has your name on it. You committed it. You deployed it. If it breaks in production at 3 a.m., you are the one who gets the call. LLMs do not bear responsibility. People do. As I wrote in my own survey response: people cannot let LLMs take decisions in their name without deep understanding of the consequences. If something bad happens, the human user is on the hook. That reality does not change because the tool is convenient. Reviewing code is part of it. The harder part is accepting that the code is yours, regardless of who — or what — wrote it.

5. When should you put it down?

Every practitioner I spoke with uses LLMs. Every one of them also has boundaries: tasks, contexts, or career stages where they choose not to use the tool, or where they advise others not to.

The clearest boundary line runs through early career development. I asked each respondent whether they push mentees toward learning about LLMs right away, gradually, or not at all. The answers split almost perfectly into thirds: 3 said right away (Kai, Luca, Dani), 3 said gradually (Ben, Noel, and I), and 1 said no.

The early-career boundaries extend beyond just code generation. Kai warns against fully delegated agents consuming project tickets. That approach is not adequate for early-career developers who need to build a deep understanding of the project. I recommend against using LLMs for planning in early career: if you have not yet developed the judgment to evaluate a plan, having a machine produce one does not help you and may actively mislead you. At any career stage, Kai draws a firm line at giving agents full access to production systems or personal data.

But it is not only juniors who put the tool down. Ben, despite being one of the more trusting users in the group, deliberately avoids using LLMs for performance work. He could dump performance data into the model, but he feels he wants, and is responsible, to develop a deep mental model of how the technology works himself. He has not yet had the opportunity to direct an LLM to work with graphical representations like traces and flame graphs, on which his intuition currently relies. Only 2 of 7 respondents report improvement in performance work at all (Dani and I), suggesting this is a domain where the tool genuinely falls short for most.

The dependency concern runs deeper than any single task. Samir sees a structural risk: if the rate of adoption outpaces the rate at which we develop safeguards, by the time the problem is visible it may already be too late to correct. When LLMs fail, humans will need to fix the issues, and they will need the understanding that was never developed. Whether the low-level knowledge that junior developers are no longer acquiring is permanently lost or merely deferred is a question none of the practitioners I spoke with can answer. What they can tell you is that the question is real, and that knowing when to put the tool down is itself a professional skill.

6. How does this change working with other people?

LLM use is usually framed as an individual productivity question: does it make you faster, does it make your code better. But programming is team work, and the most surprising findings from my conversations were not about personal workflow. They were about what happens between people.

Team awareness of LLM usage is uneven. I asked each respondent to rate, on a scale of 1 to 5, whether all members of their team are equally aware of everyone else’s LLM usage. The median was 3, the range 2 to 5. Three respondents (Kai, Noel, and Samir) reported full awareness. Two (Ben and Dani) reported low awareness. Teams do not uniformly know what their members are doing with these tools, even when 5 of the 7 respondents work at organizations where LLM use is mandated.

The social friction is new. It did not exist a year ago.

The team norms for LLM-assisted work are still being invented. Knowledge transfer happens through a patchwork of methods: show-and-tell sessions, shared rule or skill file repositories, published MCPs (a standard that lets LLM tools connect to external data sources and services), dedicated knowledge transfer days, demos, and proactive sharing. Samir’s organization mandates knowledge transfer and facilitates it with dedicated days and shared repositories. But even there, he observes coworkers doing “something cool” only after the fact; he assumes people keep a lot of their inventions to themselves. The infrastructure for sharing LLM workflows is immature, and even well-structured organizations have gaps.

Luca’s observation that “reviewing is more tiring than writing” captures the imbalance that LLMs introduce into team workflows. If generating code becomes easy but reviewing remains hard, the bottleneck shifts to the people who must evaluate the output. His vision is that review expectations should eventually be encoded into bots: “If you can express your expectations into language, then the machines should be able to pick it up.” Whether that vision arrives soon enough to ease the current friction is an open question, but it points toward a future where norms are machine-enforced, not just agreed upon socially.

I want etiquette rules to be taught early: what is polite and not polite to do with LLM use in a team. The threshold for “too simple a question to ask a person” has shifted, as Luca noted; more people now have a good intuition about which questions an LLM can answer easily. But the threshold for “too lazy an output to submit for review” is not yet established. When you submit LLM-generated work, whether it is code, a review comment, or a specification, you are making a claim about the effort and attention you invested. If your colleagues cannot tell whether you thought about the work or just accepted the first output, the social contract of professional collaboration is under strain. These norms will settle. But they have not settled yet, and if you are entering the profession now, you will be part of shaping them.

7. Will you still have a job in ten years?

This is the question behind all the other questions. If you are considering a career in programming, or if you are early in one, you want to know whether the field you are investing in will still exist in a recognizable form.

I cannot give you a certain answer. Neither can the practitioners I spoke with, and their experience ranges from 3 to over 20 years. What I can give you is what they actually said.

All seven recommend learning about LLMs. The median recommendation score is 6 out of 7, with a range tightly clustered at 5 to 6. Nobody says do not bother. But nobody is at the ceiling either. Even the most enthusiastic practitioners stop short of unconditional endorsement. When I asked whether they push mentees toward LLMs, the 3/3/1 split (right away, gradually, not at all) maps directly onto different theories of how careers will develop from here. The confidence in recommending the tools does not translate into consensus on how or when to start.

The practical advice that emerges from the data is consistent: invest in the skills that are harder to automate. Architecture, problem decomposition, verification, specification work, communication. Ben framed it as an amplifier effect: “LLMs are amplifiers. You need to be a good software engineer to start with before the technology can amplify your work.” The tool makes a competent engineer more productive. It does not make an incompetent engineer competent. Two of the seven respondents specifically want architecture and design covered in a guide for early-career professionals. The human skill is moving upward in abstraction.

Ben added the labor-market dimension from the employer’s side: LLMs enable delaying hires and keeping teams small. “Keeping the team small is key from a strategy perspective,” he said. This is already happening. If fewer junior positions are created because a small team with LLMs can do the work that used to require a larger one, the entry path to the profession narrows. Luca sees this too: “People get fewer opportunities to make mistakes.” The paradox is real. If junior roles shrink, how do people build the experience to become senior? Luca acknowledges the tension but has no answer. Neither does anyone else.

There are two things I can tell you with confidence. First, the profession is changing, not disappearing. The practitioners here, people who build and maintain real systems for a living, all still believe the work matters and that learning the field is worthwhile. Second, the skills that will matter most are the ones this guide has been describing: understanding what the tool is, knowing when to use it and when to put it down, reviewing output critically, communicating clearly with other humans, and thinking about problems at a level of abstraction that machines do not yet handle well. The ground is shifting, and nobody can tell you exactly where it will settle. But the direction of the shift is visible, and you can move with it.

8. What do you actually do with all this uncertainty?

Every practitioner I spoke with recommends learning about LLMs. The median recommendation was 6 out of 7. The range was 5 to 6. Nobody hit the ceiling. These are people who use the tools daily and still stop short of full endorsement. They have seen enough to know the tools are valuable. They have also seen enough to know the story is unfinished.

I cannot tell you how much review is enough. Samir reviews everything, always, because his name is on it. Ben deliberately reviews less when the stakes are lower. Both positions are considered. Both come from experience. The line you draw will depend on your context and your own developing judgment.

I cannot tell you when to put the tool down. Luca watches his team members lose opportunities to make mistakes. He does not know whether that lost knowledge will come back through other doors. Neither do I.

I do not know whether the junior roles that train people into senior roles will survive in their current form. I do not know whether the review burden will break teams before better tooling arrives. I do not know what these tools will be capable of in two years. Nobody does, including the people building them.

Here is what I do know. The practitioners who get the most from these tools experiment constantly. They notice when the output feels wrong. They build mental models of where the tool works and where it fails, and they update those models when the tools change. They stay curious without becoming dependent.

Stay skeptical. Stay curious. Learn the fundamentals well enough to judge what any tool produces. Talk to experienced people and notice where they disagree. Uncertainty is uncomfortable, but in a field that changes this fast, it is also the right response.

The ground is moving. Keep your eyes open.