The Real Work of Engineers: Why AI Should Tackle the Halo of Non-Building Tasks

In the fullness of time, all work will either be done by machines or done by people with assistance from machines. Whenever a transformational automation technology arrives on the scene, it’s worth stepping back to reassess what kinds of work belong in which category.

For example, switchboard operators have been entirely replaced by electronic switches, and women called calculators have been replaced by electronic calculators. (Naming the machines after the human role they replaced adds insult to injury, I think.)

When performing this reassessment, it’s important to remember that most jobs involve multiple kinds of tasks requiring a variety of skills. For example, sometimes all a doctor needs to do is clean out a cut and apply a bandage. I’ve done that for myself before, but that doesn’t make me a doctor. (I am a doctor, but not—as they say—the kind who helps people.)

In exactly the same way, proficiency at straightforward coding tasks does not make a model into an engineer. This becomes more stark as you rise in seniority. Indeed, much of what distinguishes a senior engineer from their juniors comes down to situational awareness. Can they persuade others about budgets and prioritization? Can they align stakeholders across teams? Can they elevate their peers and mentor their juniors? Can they advocate for themselves and their team? Can they communicate a technical issue to a non-technical audience? When people talk about “10x engineers,” they mean those that not only produce good code themselves but also help others do the same while maximizing the impact of what they built.

Can today’s AI replace human engineers for some well-defined or repetitive coding tasks? Yes, probably. Can it replace a senior engineer at a reputable company? I wouldn’t recommend it.

But what it can do today—what Graft can do today—is support them in the full breadth of tasks, including those requiring rich context from across the business and in a variety of forms.

So let’s reassess a specific role today: software engineers. What does the job actually involve and what role will technology play in it?

Breaking Down the Engineer's Workload

Industry surveys, and personal anecdotal evidence, suggest that engineers spend the majority of their time not coding. Here’s where engineering time actually goes:

• Interdepartmental Communication (18–22%): Engineers frequently respond to queries from sales, marketing, and customer support about features, timelines, and technical feasibility. They also convey information outward about technical risks, feature scope, and so on.
• Documentation Maintenance (12–15%): Writing and updating API docs, system architecture diagrams, and runbooks.
• Meetings (10–14%): Daily standups, sprint planning, post-mortems, all-hands, and I could keep going but you know what your calendar looks like.
• Code Review & Quality Assurance (8–12%): Ensuring high-quality code requires support from their peers  to review pull requests, provide feedback, and audit test coverage.
• Project Management (7–10%): Engineers juggle backlog grooming, dependency mapping, and status reporting, constantly switching between technical and organizational tasks.
• Production Support (5–8%): On-call rotations, monitoring alerts, and incident response are often mandatory aspects of the job..

All of these activities are necessary parts of software development, but many don’t leverage engineers’ primary strengths—problem-solving, designing, and building software. Instead, they introduce inefficiencies and context-switching that slow down the entire development process.

Amdahl’s Law and Engineering Efficiency

Amdahl’s Law states that the speedup of a system is limited by the fraction of time spent on the part that can’t be improved. In this case, the bottleneck isn’t the engineers’ ability to write code faster—it’s everything around coding that slows them down.

If you want to improve engineering efficiency, optimizing only the coding process will have limited impact. Instead, companies should focus on streamlining the “halo” of non-coding tasks that take engineers out of their flow state, including the following:

• Automating responses to common internal questions by surfacing relevant past conversations and documentation.
• Generating and maintaining documentation directly from code comments and commit messages.
• Reducing meeting overhead with AI-driven summaries, action item tracking, and optimal scheduling.
• Enhancing code reviews by prioritizing PRs, detecting bottlenecks, and structuring technical debt tracking.
• Predicting project risks by analyzing historical velocity and dependency complexity.

Notably, most of these tasks involve processing large amounts of unstructured data spread across multiple systems, require capabilities beyond simple generative AI (e.g., bulk semantic analysis and structured analytics), and must be flexible and steerable enough to adapt to organization-specific processes and expectations.

How Graft Helps Engineers Stay in Their Flow

So, what is required to meaningfully improve engineering productivity? More than a coding assistant, and more than a naked foundation model or RAG pipeline, certainly. Much of this halo of non-building tasks requires structured analytics (via generated SQL), predictive analytics (via multiple methods including supervised classification), and bulk semantic analysis, for starters.

At Graft, we recognize that the real short-term opportunity for AI isn’t in replacing engineers—it’s in supporting them across the breadth of their role so they can do their best work. By automating and optimizing the non-building parts of the engineering workload, we help teams produce better outcomes and reduce costs. That means more focus, fewer interruptions, and a development team that can spend more time doing what they were hired to do: build great products.

References

• https://www.linkedin.com/pulse/how-much-time-left-coding-does-software-engineer-spend-ali-dasdan
• https://blog.arkency.com/2017/07/non-coding-activites-in-a-software-project/
• https://www.shortcut.com/blog/why-you-should-teach-your-non-engineering-team-members-to-code
• https://infycletechnologies.com/can-i-get-an-it-job-without-coding-knowledge/
• https://tosbourn.com/essential-non-programming-skills-for-engineers/
• https://kissflow.com/no-code/no-code-overview/
• https://www.forbes.com/sites/laurencebradford/2017/03/07/16-tech-careers-you-can-land-no-coding-required/
• https://www.youtube.com/watch?v=cVxQIHCRdRE‍
• https://www.indeed.com/career-advice/finding-a-job/computer-science-jobs-without-coding