Our tech firm, Red Eagle Tech, builds bespoke software, automation and integration solutions for SMEs. Over the past year we have gone from experimenting with AI coding tools to embedding them into many stages of our delivery. The productivity gains we've seen are real, but it's good to remain aware of the risks if you get the adoption wrong.
This is what we have learned in delivering real, impactful, quality client work with AI assistance, and where we still draw hard lines.
The real issue has never been the tech
When we first introduced Claude Code to our engineering team, the technical capability was obvious. The tool could generate working functions, scaffold services, trace build configurations across dozens of files. What it could not do was understand why we had made certain architectural decisions for a specific client.
The early temptation seemed to be to treat it like an autocomplete on steroids. Paste in a task, accept the output, move on. The code would compile and pass basic tests, but it would introduce patterns that did not align with the conventions already established for that project: a different error-handling approach, an ORM we had deliberately chosen not to use, a data structure that did not match the existing contracts.
We caught all of this in review, but it taught us an important lesson. Technically correct and contextually right are not the same thing, and the gap between them is exactly where problems can hide.
What changed: treating AI as a junior engineer, not a magic box
We stopped letting the tools generate code in isolation and started treating them more like a junior developer who is brilliant at syntax but has no institutional memory.
That meant:
Always providing project context first. Before asking for any code generation, we feed the tool our architectural decision records, naming conventions, and existing patterns. A prompt like "write me an API endpoint" became "read the existing controllers in
/src/controllers, understand our validation middleware pattern, and generate a new endpoint that follows the same structure."Review everything as if a human wrote it. We already had code review processes. We simply applied the same standard to AI-generated code. If anything, we review it more carefully because the tool does not know what it does not know.
Using AI for the tedious middle, not the critical edges. Boilerplate, test scaffolding, data transformation utilities, documentation drafts — this is where we see the biggest time savings. Architectural decisions, security-sensitive logic, and anything touching client data still go through senior engineers with full context.
A concrete example: CI/CD pipeline generation
One of our recent projects involved a microservice architecture with multiple deployment pipelines. Each service had its own GitHub Actions workflow with staging and production environments, approval gates, and shared environment variables.
When we needed to add a new service, instead of manually copying and adapting an existing workflow (which inevitably introduces drift), we pointed our AI coding tool at the existing pipeline configurations:
"Read the GitHub Actions workflows in .github/workflows/ and the service structure in src/. Identify our naming conventions, build steps, test configuration, environment variable patterns, and deployment targets. Generate a complete CI/CD workflow for the new service, following the same patterns."
The tool scanned the existing workflows, traced the patterns across our services, and produced a complete workflow file. It took about four minutes. Manually, this would have been a couple of hours of careful copy-editing, and the result would still have needed review for inconsistencies.
The generated workflow needed two adjustments: an environment variable reference that was slightly off, and a missing approval gate for the production deployment. Both were caught in review, corrected in minutes, and the workflow deployed cleanly through staging on the first run. Total time saved on that single task: roughly 80%.
Where we still will not use it
There are areas where we do not let AI tools operate unsupervised, regardless of how good the output looks:
Security-critical code. Authentication flows, encryption, access control, anything handling credentials. AI models are trained on vast datasets that include outdated and insecure patterns. A function that looks correct might rely on a deprecated library or a known-vulnerable approach. We write this by hand and we audit it by hand.
Client-specific business logic. When domain rules are complex or unusual, the AI has no way to know what is intentional versus what is a mistake. Business logic with edge cases that only make sense in context — these need human understanding of the problem, not pattern matching from training data.
Architectural decisions. Which database to use, how services communicate, what the deployment topology looks like. These decisions have long-term consequences and require understanding the client's growth trajectory, budget, and technical constraints. No AI tool has that context, and prompting it in is not reliable enough for decisions of this weight.
**
The productivity shift is real, but it is not what people expect
The conversation around AI coding tools tends to focus on replacement: will AI take developer jobs? In our experience, the answer is clearly no. What it does is shift where developers spend their time.
Before AI tooling, a senior engineer might spend 40% of their day on implementation — writing the code that turns a design decision into a working system. Now, a meaningful chunk of that implementation work is accelerated or handled by AI. But the time freed up does not disappear. It gets absorbed by the work that actually matters: understanding client requirements, making architectural trade-offs, reviewing outputs, and solving problems that require genuine judgement.
The developers on our team are not doing less. They are doing more of the hard stuff and less of the repetitive stuff. That is not replacement. That is leverage.
Practical advice if you are starting out
If you are a small team or consultancy considering integrating AI coding tools:
Set context before you set tasks. Spend time building good prompts that include your project conventions. The five minutes you spend on context saves thirty minutes of fixing bad output.
Do not skip code review. Ever. AI-generated code is not tested code. It is not reviewed code. It is a draft.
Start with low-risk, high-repetition tasks. Test generation, boilerplate, documentation, data transformations. Build confidence and process before touching anything critical.
Keep your architecture human. Use AI to implement decisions, not to make them. The tool does not understand your client's business, your scaling plans, or your team's capabilities.
Measure the actual impact. We track time-to-delivery on comparable tasks before and after AI tooling. The numbers are what convinced our more sceptical engineers — not the hype.
AI coding tools work. They work well enough to change how software gets built. But they work best when experienced engineers are directing them, reviewing their output, and making the decisions that actually matter. The tool is not the architect. The tool is the scaffold.
Top comments (0)