Let us tell you what we're not going to do here: pretend AI is going to 10× your engineering team's output, or that it's going to eliminate the need for senior developers, or that you should panic because your competitors are "doing AI" and you're not.
Because after a year of actually using these tools in production, across legacy modernization, greenfield development, and everything in between, we can tell you what's real and what's expensive theater.
The conversation has moved past "Will AI replace us?" Now teams are asking the right questions: How do we adopt this without breaking our delivery commitments? What actually gets better? And how do we tell clients "no, your AI-generated PR is not 90% done" without sounding like we're resisting progress? Let's talk about what we've learned.
Here's what actually happened to the software engineering job market over the past 18 months: it didn't shrink. It got more interesting.
The demand for software is still massive, nowhere close to being fulfilled. But AI did something unexpected. It convinced companies that legacy systems they'd written off as "too expensive to modernize" might have another decade of life in them. With the right tools and the right team, that clunky ERP system from 2008 doesn't need a $5M rewrite. It needs smart refactoring, automated testing, and engineers who know how to guide AI tools instead of just hoping they'll figure it out. That opened up a whole market. One where firms like ours, teams that understand both the technology and the governance, have a genuine edge.
But the nature of the work changed:
AI makes us human less doers and more designers, designers of everything. Designers of software solutions, designers of automation test frameworks, designers of product concepts. Our brain should work on a little bit higher level and solve more design and innovative tasks, while quite a big share of plain manual work shifts to AI.
The entry bar went up. You can't start with just basic JavaScript or Testing skills anymore. That's too basic now. You need to know how to work with these technologies. But for people already in the field? This isn't a threat. It's honestly more interesting work than converting Figma designs into React components for eight hours a day.
You know what kills AI adoption faster than anything? Announcing a big initiative, buying enterprise licenses for three different platforms, and expecting teams to "figure it out" while still hitting their sprint commitments.
Here's what works instead:
Pick one painful thing. Not "improve productivity", that's useless. Something you can measure: cut log analysis time during incidents by 40%. Reduce test case generation time by 30%. Speed up dependency upgrades when CVEs hit.
Pick one workflow where you do this thing repeatedly and context can be made explicit.
Don’t start by buying licenses for three tools “just in case.” Take a week to evaluate options, identify what fits your specific pain point, and then pick one to pilot. The discipline isn’t in ignoring other tools — it’s in committing to one at a time until it proves value.
Start with a single tool and a small scope. Pilot it. Four weeks is plenty.
Measure before and after. Then decide: scale it, tweak it, or kill it. If it works, expand the scope and if needed - add another tool and repeat the same prove-and-scale cycle.
We've watched this pattern work across small clients and massive enterprise teams. The enterprise ones add procurement cycles and security reviews, fine. But the core pattern stays the same. Don't platform-shop before you have a working example.
There's no glamour here. That's the point.
Let's be specific about what we've seen work in production:
Code review on PRs. AI can flag obvious issues, suggest improvements, catch patterns before a human reviewer even opens the diff. Doesn't replace review. Makes review time more effective.
The draft-and-refine pattern. Test cases, API docs, deployment runbooks, AI drafts it, engineer refines it. When you get the context right, you're cutting initial drafting time in half.
Now here's where it falls apart:
Complex test automation. You can generate a simple login test easily. But real scenarios?
Everyone says everything is easy, tests can be generated, and you can write six times faster. But unfortunately, it works with fresh and not complex products mainly. The architecture for your test automation framework should be built by humans. AI doesn't take into account edge cases. You can easily build a simple automated test with AI, but when it turns to real life scenarios that contain 15, 20, 25 steps with complex UI, AI cannot produce anything without an architectural framework produced by a human. It simply doesn't work.
We're seeing maybe 2× improvement in test automation speed. Not 6×. And only after significant upfront investment in framework design.
Architectural decisions. AI will not design your system. It won't tell you whether to use event sourcing or REST. It won't evaluate CAP theorem tradeoffs for your distributed system. That still requires engineers who actually understand the domain.
Incident triage. When you've got structured logs and good context, AI can surface patterns fast. One team cut their initial triage time by about 40%. The engineer still investigates, but the starting point is way better than grep and hope.
Security patches and dependency hell. When a CVE drops or a library gets deprecated, you need to move. We've had cases where the fix was proposed in 5-10 minutes, library upgrade, compatibility changes, basic tests generated. The validation still takes time (sometimes a lot of time), but the proposal phase went from days to hours.
Speed without guardrails creates technical debt and compliance nightmares. The teams scaling AI successfully set constraints on day one:
Enterprise accounts only. No personal ChatGPT on client code. Ever. Full audit trails, data residency controls, retention policies that match client requirements.
Client policy is law. You don't get to pick the model, set retention rules, or choose regions. That's in contracts and security reviews. Follow it.
Humans own every merge. AI can propose changes. It can open draft PRs. It cannot merge to Production. The engineer whose credentials approved the change owns it. You can't blame the AI when it breaks Production.
Instructions live in the repo. Treat prompts like code. Version them. Refine them. Keep them close to the work. Generic prompts produce generic garbage. Task-specific instructions that reference actual files and constraints produce useful output.
This isn't red tape. It's the minimum structure that lets you move fast without creating incidents.
Two patterns dominate:
Prompt-first: Write a detailed instruction, review what AI generates, refine it, validate behavior, open PR.
Code-first: Write the implementation yourself, ask AI to review and suggest improvements, incorporate what's useful, open PR.
Both work. Both save time. Neither eliminates the need for judgment.
The role shifted. Less time typing boilerplate. More time on architecture, edge cases, and decisions that determine whether software actually works when customers use it. Clients still see us as engineers who design solutions. AI is a tool that makes us faster. The accountability didn't move. The leverage did.
Here's the problem dynamic:
A client sees a demo where AI cranks out impressive-looking code in 30 seconds. They assume their backlog can move 5× faster now. Some start sending massive AI-generated PRs to the team with notes like "I did 90% of the work, just review and merge this."
Let's be blunt about this:
"A pull request produced by AI is not 90% done. It's good if it's half of the work done, in reality. All this requires review, requires modification, requires further testing, sometimes completely goes to garbage, because if the architecture isn't proper, AI code means nothing."
That "90% done" code might be 50% done if your architecture is solid. It might be 10% done if it's not. Complex systems with actual business logic don't yield to generic prompts.
What works is transparency. Show how the work actually happens. Show what the tool proposed versus what shipped. Make the review gates visible. Track real metrics, cycle time, defect rates, rework, not vanity metrics like lines of code generated.
When clients understand that AI gives you 30-50% improvement in targeted workflows (not 5× across the board), expectations align with reality. And teams don't get crushed.
You'll hear it: "We need AI in the product roadmap."
Sometimes it's strategic. Sometimes it's competitive pressure. Sometimes it's just momentum, everyone's announcing something, so we should too.
Don't say no. Say "yes, to what’s meaningful."
Pick one use case with a clear problem and measurable success:
Ship it small. Measure carefully. See if users actually find it valuable, not whether it gets mentioned in a press release.
One real win beats ten aspirational roadmap bullets. And it gives you credibility for honest conversations about what's worth building next.
At Forte Group, we started internal AI features this year. We had about 40 ideas on the list. After thinking practically about ROI, we gave the green light to two. Because it's not everywhere. It only makes sense in specific scenarios. And those scenarios aren't as common as the hype suggests.
People keep asking for the playbook. The problem? AI tooling is changing too fast for carved-in-stone practices. What works today might be outdated in six months.
We tried to copy our test automation AI practices from one product to another. Realized pretty quickly we couldn't just hand over a document. It's iterative experimentation, try something, watch outcomes, adjust, try again. By the time you write the definitive guide, the tools have evolved and half of it's obsolete.
But some principles hold:
Start with measurable pain. Find a workflow that's slow, error-prone, or repetitive. Measure it. Improve it. Measure again.
Make context explicit. AI output quality is directly proportional to the context you provide. Clear instructions, relevant files, architectural constraints, examples.
Fix your architecture first. AI amplifies whatever patterns exist in your codebase. If your architecture is sound and tests are reliable, AI helps you move faster. If your architecture is tangled and tests are flaky, AI will magnify that dysfunction.
Share what works (and what failed). Build a living library of effective prompts and workflows. Treat it like a learning document, not a policy manual.
Scale deliberately. After a successful pilot, expand with discipline. Add teams, add use cases, add tools, but always measure, compare, decide.
This isn't a playbook. It's a practice.
At Forte Group, we're bringing AI into client work the same way we brought agile, DevOps, and cloud-native patterns: with patience, discipline, and a bias toward outcomes over announcements.
We're not promising autonomous development or 10× miracles. We're delivering measurable improvements in specific workflows, faster incident response, more efficient test generation, accelerated legacy modernization, backed by governance that protects client data and maintains accountability.
The teams winning with AI aren't the ones with the biggest budgets or earliest access. They're the ones who start small, measure honestly, and scale what actually works.
If you're figuring out how to adopt AI without the hype, or you're trying to reset expectations after an expensive false start, let's talk. Not to sell you a platform. To share what we've learned across a dozen different client contexts. And help you avoid the mistakes we've already made.
Because the real opportunity isn't replacing developers.
It's giving experienced engineers better tools to solve harder problems.
And that market is only getting bigger.
We combine deep technical expertise with disciplined adoption of emerging tools, including AI, when it actually improves outcomes. This perspective reflects hands-on experience integrating AI workflows across multiple client engagements.
Ready to talk about what AI can actually do for your delivery organization? Let's have that conversation.