Artificial intelligence has not made software engineers obsolete; it has made their work faster, broader, more demanding, and in some ways more psychologically expensive. The central challenge is no longer simply writing code. It is deciding what should be built, directing increasingly capable AI tools toward that goal, and accepting responsibility for every defect, vulnerability, dependency, and architectural compromise that arrives in the finished product. That is the reality described by software engineer Manoj Agarwal, whose account of AI-assisted development captures a profession being reshaped by acceleration rather than straightforward replacement. Jawlah’s reporting places the engineer—not the model—at the center of accountability.
For Windows developers, enterprise IT teams, and independent builders alike, that distinction matters. Tools such as GitHub Copilot, Claude Code, and other coding agents can draft features, diagnose bugs, produce tests, summarize repositories, update dependencies, and prepare pull requests at a pace that was difficult to imagine only a few years ago. But software is not valuable merely because it compiles. It must be secure, maintainable, compliant, observable, compatible with existing systems, and understandable by the humans who will inherit it.
The AI era is therefore creating a paradox: more people can create software, yet the value of seasoned software engineering judgment is becoming more visible, not less.
Agarwal’s argument begins with an obvious but profound shift. AI coding tools lower the barrier between an idea and a working prototype. Developers can describe an intended feature in ordinary language, request an implementation, and then iteratively refine the result. A programmer who lacks familiarity with a particular framework, library, language, or testing convention can often get past the blank-page problem much more quickly than before. Jawlah reports that Agarwal sees this as a major expansion of what programmers can attempt without a skills gap immediately stopping them.
The market evidence suggests that this is not a niche workflow. In Stack Overflow’s 2025 developer survey, 84% of respondents said they were either using AI tools in development or planned to do so, while 51% of professional developers reported daily use. Stack Overflow’s survey data makes clear that AI assistance is rapidly becoming part of the normal software development environment rather than an experimental side activity.
That adoption matters particularly in the Windows ecosystem. A developer working in Visual Studio or Visual Studio Code can use AI to produce C#, PowerShell, TypeScript, Python, infrastructure-as-code templates, SQL queries, unit tests, documentation, and troubleshooting suggestions in one continuous workflow. GitHub notes that Copilot can offer suggestions across a broad range of languages and technologies, including C#, C++, PowerShell, Python, JavaScript, TypeScript, Dockerfiles, and infrastructure-related tasks. GitHub’s Copilot documentation also makes clear that those suggestions can range from a symbol or line completion to larger multi-line changes.
This is a genuine productivity opportunity. Routine scaffolding, repetitive refactoring, release-note drafting, test creation, code explanation, and basic bug triage can consume a surprising amount of engineering time. Claude Code, for example, is designed to read a codebase, edit files, run commands, work across tools, create commits and pull requests, and automate tasks such as dependency updates, lint fixes, merge-conflict resolution, and test writing. Anthropic’s product documentation describes an agentic environment capable of operating across multiple files and development tools.
The important word is capable. Capability is not the same as correctness.
This is the defining tension of AI-assisted software development. The model can generate a large volume of plausible code, but plausibility is not proof. Good code review has always required attention to logic, edge cases, performance, security, readability, and compatibility. AI expands that job because it can create more code in less time.
In other words, AI can reduce the time needed to produce a change while increasing the time needed to trust that change.
Stack Overflow’s survey provides useful context for why developers are cautious. 46% of respondents said they actively distrusted the accuracy of AI tools, compared with 33% who trusted them; only 3% reported highly trusting the output. The survey also found that experienced developers were especially skeptical, a result that should not be mistaken for resistance to progress. Senior engineers are often responsible for systems where an apparently small defect can have expensive or irreversible consequences.
The same survey found that developers’ biggest frustration was receiving AI output that is “almost right,” cited by 66% of respondents. Another 45% said debugging AI-generated code was more time-consuming. Stack Overflow’s developer findings reveal the core problem with an answer that is 90% correct: the final 10% may contain the hard part.
A missing null check, an unsafe default, a nonexistent API method, an incorrect concurrency assumption, or an overly permissive authorization rule can hide inside code that otherwise looks polished. That makes AI-generated code potentially more dangerous than obviously broken code. Obvious failures are easy to reject. Elegant-looking mistakes can survive superficial review.
GitHub’s own discussion of AI-powered code reviews stresses that tests are necessary but not sufficient, while human review remains critical for logical correctness, consistency with the broader codebase, and alignment with organizational priorities. GitHub’s guidance on human oversight also warns teams against treating an AI review with little feedback as a comprehensive validation of a change.
That warning should resonate with every Windows administrator and developer who has inherited a sprawling line-of-business application. The difficult engineering questions are rarely isolated to one method:
This changes the emotional rhythm of development. Before AI, a programmer might spend much of the day slowly constructing a feature and then reviewing peers’ changes. With AI, a developer may produce several alternative implementations quickly, ask an agent to modify numerous files, receive a large diff, run an AI review, and still need to carefully inspect what happened. The speed of generation can create pressure to approve at the speed of generation.
That pressure is dangerous.
GitHub’s observations from engineering teams underline several emerging responses:
Even so, the concern is credible because junior engineering roles have traditionally served two purposes at once. They deliver useful work, and they create the next generation of senior engineers. New developers learn by fixing minor defects, writing tests, handling support tasks, reading established code, receiving code review feedback, and gradually acquiring a mental model of real production systems.
AI can automate portions of exactly that work.
The risk is not merely that fewer junior developers are hired. It is that organizations may unintentionally weaken their own talent pipeline by expecting new hires to arrive already fluent in architecture, debugging, data modeling, secure design, deployment practices, and AI-assisted workflows. Those capabilities are not acquired simply by asking a model to generate an answer.
The Stack Overflow survey offers an important counterpoint to simplistic assumptions about inexperienced workers and AI. It reports that most respondents are not “vibe coding”—defined there as generating software from large-language-model prompts—and that AI agents were still not mainstream for many developers. Stack Overflow’s AI survey found 52% either did not use agents or stayed with simpler AI tools, while 38% had no plans to adopt agents. Adoption is broad, but professional practice remains uneven and far from fully autonomous.
Effective early-career development programs should include:
Prompting matters because an AI system produces better work when it receives better constraints. A useful coding prompt includes the task, relevant files, expected interfaces, architectural constraints, style rules, security requirements, testing expectations, and a definition of success. “Build a dashboard” is not a serious software specification. “Add a dashboard endpoint that uses the existing authorization middleware, queries the approved reporting view, returns paginated results, logs no personally identifiable information, and includes tests for permission failures” is closer to one.
But prompt fluency alone can be overrated.
The engineer who can write the most persuasive prompt still needs to identify false assumptions, reject a flawed design, understand the runtime environment, and decide whether the implementation fits the product. AI does not eliminate the need for engineering knowledge. It changes where that knowledge is applied.
Claude Code’s own documentation illustrates the scope of modern agentic tools: they can read codebases, edit files, run commands, automate testing and dependency work, integrate with development environments, work with version control, and connect to external tools through the Model Context Protocol. Anthropic’s overview shows why the question is no longer whether AI can write a helper function. The question is whether teams have the controls, permissions, review practices, and architectural discipline to manage software agents that can touch large portions of a project.
That is especially relevant for Windows-centered enterprises, where a developer’s environment may link local code, corporate repositories, cloud services, internal documentation, issue trackers, CI/CD systems, and production-adjacent credentials. An AI assistant that receives extensive access can become exceptionally useful. It can also magnify the consequences of poor access control or careless instructions.
That is the right lens for evaluating the future of software engineering jobs.
The increasingly valuable engineer will not be defined only by typing speed or memorization of syntax. Those skills remain useful, but they are no longer sufficient differentiators. The advantage will belong to people who can:
The more accurate view is harder but more useful: AI is a force multiplier for software engineering, and force multipliers reward disciplined operators while exposing weak processes.
But the gains are not automatic. Faster generation can create larger review queues. More capable agents can create broader security and governance risks. Reduced demand for routine coding can make the path into the profession more difficult for junior developers. The expectation to continually learn new AI tools can also become another source of burnout if organizations treat it as unpaid, endless self-training rather than part of the job.
Agarwal’s advice not to fear AI is sound, provided it is paired with a second principle: do not confuse using AI with delegating responsibility to it. Jawlah’s coverage rightly emphasizes that developers who learn to work effectively with these tools will have an efficiency advantage over those who refuse them. Yet the winning engineers will be those who combine that speed with careful review, strong technical judgment, and a clear sense of ownership.
In the AI era, the best software engineer is not the person who generates the most code. It is the person who can ensure that the code—however it was generated—deserves to run.
For Windows developers, enterprise IT teams, and independent builders alike, that distinction matters. Tools such as GitHub Copilot, Claude Code, and other coding agents can draft features, diagnose bugs, produce tests, summarize repositories, update dependencies, and prepare pull requests at a pace that was difficult to imagine only a few years ago. But software is not valuable merely because it compiles. It must be secure, maintainable, compliant, observable, compatible with existing systems, and understandable by the humans who will inherit it.
The AI era is therefore creating a paradox: more people can create software, yet the value of seasoned software engineering judgment is becoming more visible, not less.
Background: Software Development Is Becoming AI-Assisted by Default
Agarwal’s argument begins with an obvious but profound shift. AI coding tools lower the barrier between an idea and a working prototype. Developers can describe an intended feature in ordinary language, request an implementation, and then iteratively refine the result. A programmer who lacks familiarity with a particular framework, library, language, or testing convention can often get past the blank-page problem much more quickly than before. Jawlah reports that Agarwal sees this as a major expansion of what programmers can attempt without a skills gap immediately stopping them.The market evidence suggests that this is not a niche workflow. In Stack Overflow’s 2025 developer survey, 84% of respondents said they were either using AI tools in development or planned to do so, while 51% of professional developers reported daily use. Stack Overflow’s survey data makes clear that AI assistance is rapidly becoming part of the normal software development environment rather than an experimental side activity.
That adoption matters particularly in the Windows ecosystem. A developer working in Visual Studio or Visual Studio Code can use AI to produce C#, PowerShell, TypeScript, Python, infrastructure-as-code templates, SQL queries, unit tests, documentation, and troubleshooting suggestions in one continuous workflow. GitHub notes that Copilot can offer suggestions across a broad range of languages and technologies, including C#, C++, PowerShell, Python, JavaScript, TypeScript, Dockerfiles, and infrastructure-related tasks. GitHub’s Copilot documentation also makes clear that those suggestions can range from a symbol or line completion to larger multi-line changes.
This is a genuine productivity opportunity. Routine scaffolding, repetitive refactoring, release-note drafting, test creation, code explanation, and basic bug triage can consume a surprising amount of engineering time. Claude Code, for example, is designed to read a codebase, edit files, run commands, work across tools, create commits and pull requests, and automate tasks such as dependency updates, lint fixes, merge-conflict resolution, and test writing. Anthropic’s product documentation describes an agentic environment capable of operating across multiple files and development tools.
The important word is capable. Capability is not the same as correctness.
The New Bottleneck Is Verification, Not Generation
The most consequential point in Agarwal’s account is also the least glamorous: the engineer remains responsible for the source code. AI can suggest an approach, write a module, explain a stack trace, or produce a patch. It cannot be held accountable when that patch fails under load, exposes data, violates a license, breaks a payment flow, or introduces a subtle privilege escalation flaw. Jawlah’s coverage identifies that responsibility as the practical burden that remains with the human developer.This is the defining tension of AI-assisted software development. The model can generate a large volume of plausible code, but plausibility is not proof. Good code review has always required attention to logic, edge cases, performance, security, readability, and compatibility. AI expands that job because it can create more code in less time.
In other words, AI can reduce the time needed to produce a change while increasing the time needed to trust that change.
Stack Overflow’s survey provides useful context for why developers are cautious. 46% of respondents said they actively distrusted the accuracy of AI tools, compared with 33% who trusted them; only 3% reported highly trusting the output. The survey also found that experienced developers were especially skeptical, a result that should not be mistaken for resistance to progress. Senior engineers are often responsible for systems where an apparently small defect can have expensive or irreversible consequences.
The same survey found that developers’ biggest frustration was receiving AI output that is “almost right,” cited by 66% of respondents. Another 45% said debugging AI-generated code was more time-consuming. Stack Overflow’s developer findings reveal the core problem with an answer that is 90% correct: the final 10% may contain the hard part.
A missing null check, an unsafe default, a nonexistent API method, an incorrect concurrency assumption, or an overly permissive authorization rule can hide inside code that otherwise looks polished. That makes AI-generated code potentially more dangerous than obviously broken code. Obvious failures are easy to reject. Elegant-looking mistakes can survive superficial review.
Why “It Passed the Test” Is Not Enough
Automated tests remain essential, but they do not remove the need for human judgment. Tests can prove only the behavior they are designed to cover. They may not test the right threat model, unusual customer data, production-scale load, cross-service failure behavior, backward compatibility, or the business rule that was misunderstood at the prompt stage.GitHub’s own discussion of AI-powered code reviews stresses that tests are necessary but not sufficient, while human review remains critical for logical correctness, consistency with the broader codebase, and alignment with organizational priorities. GitHub’s guidance on human oversight also warns teams against treating an AI review with little feedback as a comprehensive validation of a change.
That warning should resonate with every Windows administrator and developer who has inherited a sprawling line-of-business application. The difficult engineering questions are rarely isolated to one method:
- Does this change respect the organization’s authentication model?
- Does it create a new dependency that will be hard to patch later?
- Does it behave correctly with existing Active Directory, Entra ID, SQL Server, Azure, or on-premises integrations?
- Can another developer understand and safely modify it six months from now?
- Is sensitive telemetry, source code, or customer data being exposed to an external service?
- Does the new automation make a bad decision faster?
Code Review Is Faster, but the Review Burden Can Become Heavier
Agarwal argues that AI can make code reviews faster and more precise, while also creating a heavier review burden that contributes to burnout. Jawlah’s report captures a concern that many developers will recognize: the developer is not merely reviewing code from a colleague who understands the team’s conventions and product constraints. They may be reviewing a high-volume output generated by a system that has access to context but no durable stake in the result.This changes the emotional rhythm of development. Before AI, a programmer might spend much of the day slowly constructing a feature and then reviewing peers’ changes. With AI, a developer may produce several alternative implementations quickly, ask an agent to modify numerous files, receive a large diff, run an AI review, and still need to carefully inspect what happened. The speed of generation can create pressure to approve at the speed of generation.
That pressure is dangerous.
GitHub’s observations from engineering teams underline several emerging responses:
- Request an AI review before human review.
- Keep pull requests small enough to remain understandable.
- Use AI to identify possible issues, but retain skepticism about what it may have missed.
- Conduct deep semantic and architectural reviews in environments suited to concentrated inspection rather than relying on quick browser-level review alone.
- Preserve human ownership of the final change. GitHub’s code-review analysis
A Better AI Code Review Standard
Teams adopting AI coding tools need an explicit definition of done. A useful standard should include more than an agent’s claim that it completed the task.- State the intended behavior first.
Write acceptance criteria, expected inputs and outputs, failure behavior, security constraints, and compatibility requirements before asking AI to implement a change. - Review the diff, not the summary.
AI summaries are useful navigation aids, but reviewers must inspect the actual changed files. Pay particular attention to authorization checks, error handling, serialization, database changes, command execution, and dependency modifications. - Require evidence from tests and tooling.
Run unit tests, integration tests, static analysis, linters, secret scanning, dependency checks, and—where appropriate—performance tests. Do not accept “tests passed” without knowing which tests ran and what they actually cover. - Keep generated changes narrow.
An agent that modifies dozens of files may be impressive, but a huge pull request is difficult to validate. Small, scoped changes improve review quality and make rollback more manageable. - Assign a human owner.
The person approving a merge must be able to explain the design and accept responsibility for the result. AI should never become the unnamed author of production risk. - Treat prompts as engineering artifacts.
For consequential work, the instructions given to the agent should be reproducible, documented, and reviewable. Vague prompts often produce vague requirements disguised as finished code.
The Junior Engineer Problem Is More Than a Hiring Problem
Agarwal also raises a difficult workforce question: if AI allows a smaller team to complete work that once required more engineers, entry-level positions may become harder to find. He suggests that a project needing ten engineers two years ago might now need about half as many, while available roles increasingly favor people experienced enough to use AI effectively. Jawlah’s account presents that ten-to-five comparison as his personal estimate, not a universal industry benchmark, and it should be read with that caution.Even so, the concern is credible because junior engineering roles have traditionally served two purposes at once. They deliver useful work, and they create the next generation of senior engineers. New developers learn by fixing minor defects, writing tests, handling support tasks, reading established code, receiving code review feedback, and gradually acquiring a mental model of real production systems.
AI can automate portions of exactly that work.
The risk is not merely that fewer junior developers are hired. It is that organizations may unintentionally weaken their own talent pipeline by expecting new hires to arrive already fluent in architecture, debugging, data modeling, secure design, deployment practices, and AI-assisted workflows. Those capabilities are not acquired simply by asking a model to generate an answer.
The Stack Overflow survey offers an important counterpoint to simplistic assumptions about inexperienced workers and AI. It reports that most respondents are not “vibe coding”—defined there as generating software from large-language-model prompts—and that AI agents were still not mainstream for many developers. Stack Overflow’s AI survey found 52% either did not use agents or stayed with simpler AI tools, while 38% had no plans to adopt agents. Adoption is broad, but professional practice remains uneven and far from fully autonomous.
How Teams Can Protect the Talent Pipeline
The answer is not to shield junior developers from AI. That would leave them at a disadvantage. The better approach is to teach them how to use it without outsourcing thought.Effective early-career development programs should include:
- Code reading before code generation. Junior engineers should learn to trace existing execution paths, understand system boundaries, and identify dependencies.
- AI-assisted debugging with explanation. Rather than accepting a patch, developers should explain why the issue occurred, why the fix works, and how the test proves it.
- Structured human mentorship. A model can provide examples, but it cannot replace feedback from an experienced engineer who knows the system’s history and trade-offs.
- Architecture exposure. Junior engineers need opportunities to see how requirements become interfaces, data models, deployment plans, monitoring, and incident response.
- Security and privacy habits. Teams should teach developers what data may be safely shared with an AI service and what must remain within approved boundaries.
- Ownership of small production features. The goal is not just to produce output; it is to build confidence in operating, supporting, and improving software after release.
Prompting Is Becoming a Core Skill—But It Is Not the Core Skill
Agarwal says prompt writing has become an essential part of his daily work and that he spends a few hours per week tracking developments and experimenting with tools through side projects. Jawlah’s reporting also notes that he personally spends roughly $100 per month on AI products including Claude Code, Microsoft Copilot, and Lovable. That spending figure is an individual account, not a reliable indicator of a typical developer’s budget, but it illustrates how quickly AI tooling has become part of the professional toolkit.Prompting matters because an AI system produces better work when it receives better constraints. A useful coding prompt includes the task, relevant files, expected interfaces, architectural constraints, style rules, security requirements, testing expectations, and a definition of success. “Build a dashboard” is not a serious software specification. “Add a dashboard endpoint that uses the existing authorization middleware, queries the approved reporting view, returns paginated results, logs no personally identifiable information, and includes tests for permission failures” is closer to one.
But prompt fluency alone can be overrated.
The engineer who can write the most persuasive prompt still needs to identify false assumptions, reject a flawed design, understand the runtime environment, and decide whether the implementation fits the product. AI does not eliminate the need for engineering knowledge. It changes where that knowledge is applied.
Claude Code’s own documentation illustrates the scope of modern agentic tools: they can read codebases, edit files, run commands, automate testing and dependency work, integrate with development environments, work with version control, and connect to external tools through the Model Context Protocol. Anthropic’s overview shows why the question is no longer whether AI can write a helper function. The question is whether teams have the controls, permissions, review practices, and architectural discipline to manage software agents that can touch large portions of a project.
That is especially relevant for Windows-centered enterprises, where a developer’s environment may link local code, corporate repositories, cloud services, internal documentation, issue trackers, CI/CD systems, and production-adjacent credentials. An AI assistant that receives extensive access can become exceptionally useful. It can also magnify the consequences of poor access control or careless instructions.
The Real Competitive Advantage Is Systems Thinking
Agarwal’s most durable insight may be his insistence that AI still needs the seasoned engineer. Models can generate implementation options, but they do not possess a complete, reliable, organizationally grounded understanding of how a system should be designed. Jawlah’s report frames the enduring value of engineers as accumulated knowledge and deep understanding of how systems work.That is the right lens for evaluating the future of software engineering jobs.
The increasingly valuable engineer will not be defined only by typing speed or memorization of syntax. Those skills remain useful, but they are no longer sufficient differentiators. The advantage will belong to people who can:
- Translate messy business problems into testable technical requirements.
- Design systems with clear boundaries, failure modes, and ownership.
- Evaluate AI output for correctness, risk, and maintainability.
- Understand security, identity, data governance, and compliance constraints.
- Diagnose failures across services, infrastructure, client software, and networks.
- Communicate trade-offs to product leaders and non-technical stakeholders.
- Build development processes where AI increases quality rather than merely increasing output volume.
The more accurate view is harder but more useful: AI is a force multiplier for software engineering, and force multipliers reward disciplined operators while exposing weak processes.
Conclusion: Use AI Aggressively, Own the Result Completely
The software profession is entering a period in which producing code is cheaper, faster, and more accessible than ever. That is a powerful opportunity for developers working with Windows, cloud platforms, enterprise applications, open-source projects, and personal tools. It can help small teams tackle larger projects, reduce repetitive work, improve documentation, speed up experimentation, and give engineers more time to focus on difficult problems.But the gains are not automatic. Faster generation can create larger review queues. More capable agents can create broader security and governance risks. Reduced demand for routine coding can make the path into the profession more difficult for junior developers. The expectation to continually learn new AI tools can also become another source of burnout if organizations treat it as unpaid, endless self-training rather than part of the job.
Agarwal’s advice not to fear AI is sound, provided it is paired with a second principle: do not confuse using AI with delegating responsibility to it. Jawlah’s coverage rightly emphasizes that developers who learn to work effectively with these tools will have an efficiency advantage over those who refuse them. Yet the winning engineers will be those who combine that speed with careful review, strong technical judgment, and a clear sense of ownership.
In the AI era, the best software engineer is not the person who generates the most code. It is the person who can ensure that the code—however it was generated—deserves to run.
References
- Primary source: jawlah.co
Published: 2026-07-26T13:41:53+00:00
Software engineers face significant challenges in the age of artificial intelligence | Jawlah
The software development profession has seen major shifts with the growing use of artificial intelligence tools in recent years. According to Manoj Agarwal, a software engineer at a major tech company who assumedjawlah.co - Related coverage: itpro.com
How AI coding is transforming the IT industry in 2025 | IT Pro
IT roles are shifting to accommodate AI coding – and organizations are transforming how they build, test, and deploy productswww.itpro.com