I use AI every day. Claude Code, Codex, Gemini, DeepSeek – for PowerShell, SQL, Python, debugging problems, reviewing designs. The productivity gains are real, and this is not an argument against AI. The narrower question I want to answer is: what does the real-world evidence tell us about AI-assisted software development today?
My conclusion is practical. Today's AI models are remarkably capable. But the engineering processes built around them are still immature.
What AI Already Does Well
AI now belongs among the most significant productivity tools of my career, alongside virtualization, cloud computing, Git, and PowerShell. None of those technologies eliminated the need for skilled professionals. They allowed those professionals to spend less time on repetitive work and more time solving harder problems. AI is doing the same.
Learning and research
Instead of spending hours searching documentation and forum posts, I can have an interactive conversation that explains concepts, compares approaches, and answers follow-up questions. Research that once required reading dozens of pages can now begin in minutes.
Coding
AI generates useful first drafts of PowerShell scripts, SQL queries, Python utilities, HTML, JavaScript, and configuration files. It explains existing code, suggests improvements, and converts ideas into working prototypes. The first draft still needs review, but the time from idea to reviewable code shrinks dramatically.
Troubleshooting
Instead of investigating one possible cause at a time, AI can quickly surface several hypotheses based on logs, error messages, and configuration details. Even when the first answer is wrong, the conversation narrows the search faster than working alone.
Experimentation
Because generating code is fast, I try more ideas. A prototype that once took hours can be built in minutes, evaluated, and discarded if it fails. That encourages creativity and often leads to better solutions.
Expanding scope
Projects that originally seemed outside my experience became achievable because AI could explain unfamiliar concepts, generate examples, and answer questions as I worked. AI does not just produce output – it helps engineers learn while they build. Several systems I developed would have taken significantly longer without AI. Some might never have been attempted at all.
The Limits That Daily Work Reveals
Product demonstrations make AI-assisted development look seamless. Real engineering projects are different: requirements change, conversations grow long, files multiply, and new information constantly replaces old assumptions. These conditions expose limits that benchmarks do not measure.
Context
Every decision made yesterday affects the decisions made today. As projects grow, so does the amount of information that needs to remain available. During long projects I have experienced earlier design decisions being forgotten, previously agreed requirements having to be explained again, and important details disappearing as new information entered the conversation. The result is that engineers spend time rebuilding context instead of building software.
Usage limits
Every AI provider has limits based on infrastructure, cost, or capacity. The problem is not that they exist – it is when they appear. They tend to appear after hours of valuable work, forcing engineers to wait for resets, switch models, start new sessions, or compress previous conversations. None of those activities improve the software.
Platform reliability
The development experience depends on everything surrounding the model: APIs, authentication, IDE integrations, internet connectivity, and cloud infrastructure. During one session, an internal API error stopped a workflow mid-task. The model's reasoning was fine – the platform around it was not. AI-assisted development depends on the reliability of the entire system, not just the intelligence of the model.
Model consistency
Different AI models produce different answers to the same question, and the same model can produce inconsistent answers across a long session. There is no single perfect model. Some excel at reasoning; others write cleaner code; others handle large contexts better. That is not a flaw – it is an argument for using multiple perspectives rather than depending on one.
Why the Field Is Still Maturing
AI models are improving much faster than the engineering processes built around them.
When I look at mature technologies – SQL Server, networking, source control, cloud computing – I see industries that spent years developing standards, best practices, certifications, and governance. Different teams implement those standards differently, but there is broad agreement about the fundamentals. AI-assisted development is not there yet.
The field currently sees active debate between prompt engineering, agents, retrieval-augmented generation, orchestration frameworks, and the Model Context Protocol. Many of these approaches have real value. The challenge is that very little evidence exists about which approaches consistently work best across different types of projects. Two experienced engineers can build excellent AI-assisted workflows that look completely different.
The AI expert cycle
In the beginning, I followed many self-proclaimed AI experts. Some advice was useful, but much of it created confusion. Every few weeks there was a new "best" workflow, a new required tool, or a new claim that the previous approach no longer mattered. For someone seriously trying to learn AI-assisted development, that noise became one of the biggest obstacles.
The problem is not that people share what works for them. The problem is when temporary personal workflows are presented as universal rules.
The Essential AI Skill Keeps Changing – This Month It's Loop Engineering
Every few weeks, the AI world seems to discover a new "core skill" that everyone is suddenly supposed to master. Not long ago, it was prompt engineering. People were told that writing the perfect prompt was the key to using AI properly. Then, almost overnight, prompt engineering became old news because the model could supposedly do that work for you. Now the new buzzword is loop engineering, and once again the message is the same: if you are not doing this, you are behind.
I find this cycle ridiculous.
The people most harmed by it are not experienced engineers. They are ordinary users who have never done much with computers beyond Google search, Word, Excel, email, and basic office tools. They are trying to understand AI in good faith – many of them after watching someone online claim to make $10,000 a month using it – but every few weeks the experts and gurus move the target. Yesterday's "essential skill" becomes today's obsolete idea, and a new expensive-sounding concept takes its place. That is not education. That is confusion dressed up as expertise.
The idea of loop engineering also exposes a deeper contradiction. If we are talking about intelligence, then intelligence should not mean producing a weak answer, debating that same weak answer for hours, generating more variations of the same mistake, and then selecting one of them after enough tokens have been spent. Being wrong is not the problem. Humans are wrong too. The problem is pretending that repeated self-review is the same as understanding.
If the same model is generating ideas, reviewing them, critiquing them, and approving them, it is acting as judge, jury, witness, and appeals court all at once. Running longer as an agent in a loop does not magically create independent thinking. In many cases, it simply gives the model more time to reinforce its own assumptions.
The real question is not "How long did it run in a loop and how many ideas it reviewed?" The real question is "Who or what challenged it?"
A loop can be useful when it brings in new evidence: tests, logs, source code, user feedback, external documentation, a second model with a different role, or a human reviewer. But Claude debating Claude is still Claude. The same is true for Codex, Gemini, DeepSeek, or any other model. Without outside pressure, loop engineering becomes another business hype cycle, selling repetition as wisdom and making users spend more tokens while calling it progress.
Software engineering itself took decades to mature. Version control evolved. Testing practices evolved. Continuous integration evolved. Security practices evolved. AI-assisted development is going through the same process, and right now the industry is still in the experimental phase. The measure of a workflow should not be whether it follows the latest trend, but whether it consistently produces reliable results.
Trust AI's Creativity. Verify AI's Work.
Working with AI has made one distinction especially clear: trust and verification are not the same thing.
AI often produces excellent work. Occasionally it produces incorrect work that sounds completely convincing. Experienced engineers have encountered something similar before – not from AI, but from people. People make mistakes. Software contains bugs. Requirements change. Engineering has never assumed perfection. Instead, it assumes that mistakes will happen and builds processes to detect them before they become serious.
Consider how modern software is developed. Code reviews. Unit testing. Integration testing. Static analysis. Security scanning. Continuous integration. Change control. None of these processes exist because developers are unskilled – they exist because everyone makes mistakes. Verification is what makes systems reliable. AI should participate in those same processes.
A real example
During a normal Claude Code development session, I maintained a document containing a project rule – a required step Claude was expected to follow before performing certain work. The rule was not hidden or ambiguous. Claude had access to it throughout the session. The first sign of the problem came when I switched to a new project and Claude skipped the required pre-flight check entirely – without mentioning it.
When challenged, Claude acknowledged reading the rule – and still not following it.
When I asked why, the explanation was worth noting.
Claude said that reading an instruction and consistently applying that instruction are not the same thing. Its behavior is probabilistic, not deterministic. A rule being present in the conversation does not guarantee it influences every response.
More importantly, Claude did not recommend better prompts or more detailed instructions. It recommended using external hooks to enforce important pre-flight checks. That is a principle engineers have understood for decades: critical processes should be enforced by software, not by memory. Instructions are guidance. Enforcement is a different mechanism.
This example does not prove AI is unreliable. It demonstrates a clear engineering principle: the existence of an instruction is not the same as its reliable enforcement – and that applies to people just as much as to AI. The answer is not to stop using AI. The answer is to build processes that assume occasional mistakes can happen and catch them before they reach production.
How AI Changes the Engineer's Role
The biggest change in my own work is not that AI writes code for me. It is that I spend less time on syntax and more time on the questions that have always mattered: Is this the right design? Is it secure? Will it scale? What happens when it fails? How will someone maintain it two years from now?
As AI generates more of the implementation, engineers increasingly shift toward reviewing, validating, and judging AI-generated work. That does not make engineering easier. Reviewing code responsibly often requires more experience than writing it. You must recognize subtle mistakes, incorrect assumptions, security risks, and long-term maintenance issues that the AI missed or glossed over.
Good questions also become more valuable. A vague request produces a vague answer. A well-defined problem produces a much better result. Success depends less on typing speed and more on clearly defining problems, understanding constraints, and asking precise questions.
Some people assume AI reduces the need for experience. What I have seen points the other direction. Experienced engineers know which questions to ask, which assumptions to challenge, which shortcuts are unsafe, and which AI recommendations should not be accepted without further investigation. AI can generate possibilities. Experience helps identify the right one.
One important distinction will not disappear: when a production deployment fails, the AI does not join the incident call. When auditors ask why a decision was made, the AI is not accountable. Organizations assign responsibility to people. Intelligence and accountability are separate responsibilities.
What Mature AI-Assisted Development Could Look Like
The direction is becoming visible, even if the destination is not.
Standards. Every mature engineering discipline eventually develops shared standards. Teams will stop reinventing their own AI workflows and start converging on common practices for verification, code review, context management, and audit trails.
Better context management. Engineers should not have to repeatedly explain the same requirements, architecture, and previous decisions. Future systems should maintain project knowledge across long sessions, reducing context rebuilding and freeing engineers to solve problems instead.
Predictable limits. Engineers beginning a large project should understand expected context capacity, usage limits, and what happens when those limits are reached. Operational limits should not be discovered mid-session.
Verification by design. Testing, code review, quality gates, approval workflows, and security scanning should be built into AI-assisted workflows from the start, not added afterward. The example above makes this point clearly: Claude acknowledged a project rule and still failed to follow it. Its own recommendation was to enforce important checks with external hooks. That is verification by design.
Clear accountability. AI should recommend; people should decide. As AI generates more of the code in production systems, clear human approval chains become more important, not less – especially in regulated industries.
Audit trails. What did the AI change? Why did it recommend that change? Who reviewed it? Who approved it? These questions need simple, auditable answers in enterprise environments.
Defined security boundaries. Organizations need clear policies about what company data may be shared with AI tools, what must remain internal, and how AI-generated code should be reviewed. Security should be part of AI-assisted engineering from the beginning, not treated as an afterthought.
Practical Starting Points
These are not final industry standards. They are a starting point for using AI responsibly in real engineering work.
- Use AI for acceleration, not blind approval. AI produces excellent first drafts, alternatives, summaries, and prototypes. Validate assumptions and decide whether the output belongs in the system.
- Verify AI-generated changes. AI-generated code should go through the same review process as human-written code: tests, code review, linting, security checks, and deployment validation.
- Automate critical rules. Important project rules should not depend only on chat instructions or model memory. When a rule matters, enforce it with scripts, hooks, CI checks, or other deterministic controls.
- Preserve project context outside the chat. Long-running projects need durable context: requirements, decisions, constraints, test results, and known issues. Reducing repeated context rebuilding makes the entire workflow more reliable.
- Keep humans accountable for production decisions. AI can recommend. People must approve. Higher-impact systems need clearer ownership and review paths.
- Maintain evidence trails. Teams should be able to answer: What did AI change? What evidence supported the recommendation? Who reviewed it? What tests passed?
- Use multiple perspectives when risk is high. A second model or review pass can reduce mistakes on important decisions. The goal is not to prove which model is best – the goal is to improve confidence in the result.
- Treat the workflow as evolving. AI tools will continue changing. Evaluate outcomes, keep what works, discard what does not, and avoid over-dependence on any single vendor or model.
Final Thoughts
After months of daily AI use, my conclusion is neither optimistic nor pessimistic – it is practical.
AI is one of the most valuable engineering tools I have ever used, and it has permanently changed how I work. But building software has never been only about writing code. Production systems require good architecture, security, testing, documentation, maintenance, and accountability. AI helps with many of these. It does not eliminate the need for them.
Much of today's debate asks whether AI will replace software engineers. That question misses a more immediate opportunity: helping experienced engineers solve larger problems, build better systems, and spend more time on work that requires judgment and accountability. If AI allows one engineer to accomplish what previously required two or three, that transformation is already happening – and it is worth taking seriously on its own terms.
AI models will keep changing, context windows will grow, and reasoning will improve. The engineering principles in this post are more likely to endure than any specific model or workflow. Reliable software requires verification. Important systems require accountability. Evidence matters.
I started this career when the fastest consumer PC I could dream of ran at 4.77 MHz. Today's CPUs boost past 6.0 GHz. That is a 125,700% increase in clock frequency alone – and clock frequency is only one dimension of how far computing has come. I have watched many technologies arrive with the same energy AI has today: necessary, transformative, and surrounded by noise that eventually settles into practice. The engineering principles that survived those shifts are the same ones I expect to survive this one.
My generation spent thousands of hours building the infrastructure that AI depends on today: the databases, the networks, the operating systems, the server platforms. Using it feels less like adopting something foreign and more like seeing a return on work we were already part of. One thing I notice is how many people still feel they need to hide that they used it. I used AI to write this article. The ideas, the observations, and the examples from my own work are mine. The structure and much of the language came from a collaboration with a model. If AI is worth using as an engineering tool, and I believe it is, then it is worth being honest about using it.
Engineering has never depended on trust alone.
Very useful information and frankly I found Claude one of the best AI tools for SW development.