25 Years in Tech Taught Me What AI Still Can't Replace — Helkyn Coello's Developer Journey
Technology has changed dramatically over the past 25 years.
Desktop applications became client-server systems. Client-server systems became web platforms. And now, AI is changing how software is designed, built, tested, and operated.
For Helkyn Coello, that transformation hasn't happened from the sidelines.
He has spent 25 years building enterprise software, leading technology teams, modernizing legacy systems, and navigating the transition from traditional software development to AI-native systems.
Today, Helkyn is the Chief AI Officer at AccountTECH, where he leads company-wide AI adoption across products, operations, and team capabilities. His work spans enterprise RAG, AI governance, agentic AI, software architecture, and the challenge of bringing AI into production without breaking systems that already work.
His CoderLegion profile captures the philosophy behind that experience:
"The best AI in your stack is still the mental model in your head."
We spoke with Helkyn about 25 years of technology change, modernizing enterprise systems, AI in production, RAG, agentic AI, vibe coding, governance, and what developers need to understand in an AI-first world.
25 Years of Technology Change
Looking back across 25 years of technology, Helkyn says the biggest change isn't simply that software can now be built faster.
It's the distance between having an idea and having something running.
In the client-server era, trying something new could mean weeks or months of development, installing software on every machine, dealing with hardware configurations, and sometimes even preparing training for the people who would use it.
Today, a competent person can build and deploy something in an afternoon.
And that changes more than development speed.
It changes which ideas are worth trying because being wrong has become cheaper.
But Helkyn believes one thing hasn't changed nearly as much:
"Deciding what to build was and still is the hard part."
Requirements are still vague. Users often don't know exactly what they need until they see something that isn't quite right. Integrations with systems nobody wants to touch are still where projects can go wrong. Maintenance still consumes budgets that nobody planned for.
AI doesn't eliminate those problems.
Instead, it changes where the bottleneck is.
Coding is no longer necessarily the bottleneck. Producing the right specifications and giving AI enough context to build something correctly has become increasingly important.
Poorly documented requirements can send an AI model in completely the wrong direction. Detailed specifications can produce a much more robust result.
And Helkyn sees a broader shift happening:
"Non-coders are becoming software analysts and developers are becoming just reviewers, whether they like it or not."
Modernizing Legacy Systems Without Breaking the Business
Helkyn has personally experienced major technology migrations, including moving an enterprise system from an Access-based legacy platform to .NET and later transitioning from client-server architecture to a fully web-based system.
The biggest lesson wasn't technical.
It was:
Think about the customer first, even if that means sacrificing technical aspects.
A business cannot simply pause while its technology is being modernized.
That's why Helkyn favors incremental migration over clean-cut replacement.
Build capabilities in the new system gradually. Move customers across in chunks. Keep the old system running in parallel until the new system has earned customers' trust.
And much of the difficult work happens behind the scenes:
- Data migration schedules
- Daily releases
- Keeping old and new systems synchronized
- Handling edge cases
- Repurposing custom legacy code
- Maintaining continuity for existing customers
The reason is simple:
Customers must not feel any interruption.
That philosophy also influences how Helkyn approaches AI.
When someone proposes replacing an existing process with an AI-based one, his first question is:
What keeps running while the new system proves itself?
The second is:
How do we roll back when things go wrong?
If there is no way to reverse the change, Helkyn doesn't consider it modernization.
"It's a bet without plan B."
That's why he prefers putting AI into systems that already work and augmenting them rather than rebuilding everything around AI.
Why Experience Matters More in the AI Era
AI-generated applications can look finished.
The code can look plausible. The architecture can look reasonable. A fifty-page specification can look professional.
And that's exactly what makes AI so tricky.
Helkyn experienced this himself when a Business Manager gave him a detailed specification generated with AI. It was beautifully organized and confidently written, but it contained gaps that were only obvious if you understood the domain deeply.
The lesson was important:
"Plausibility used to be a decent proxy for competence. But it isn't anymore."
An experienced engineer doesn't only ask:
"Does it run?"
They ask:
- What happens with 10,000 records instead of 10?
- What happens when two requests arrive simultaneously?
- What happens when a third-party API fails at the worst possible moment?
- Who will maintain this eight months from now?
- Why was this approach chosen when the existing codebase already solves a similar problem?
Those questions aren't necessarily visible in an impressive AI-generated demo.
That's why Helkyn believes experience is becoming more valuable, not less.
AI can write code quickly and even produce strong architectures when given the right architectural requirements.
But it doesn't automatically understand the history and domain knowledge of a business.
A developer who understands that domain and knows how to use AI as leverage has a significant advantage.
"AI is becoming a commodity. Domain experience is what will differentiate developers."
From AI Experiments to Production
There's a huge difference between an AI demo and production AI.
Helkyn puts it simply:
"The demo only has to work once, for you, on the input you picked. Production has to work for everybody, on inputs nobody imagined, on a day when your model provider is having problems."
In production, non-determinism becomes a serious concern.
In a demo, slightly different answers can feel like intelligence.
In a system of record, they can look like bugs.
So part of the architectural work is deciding which parts of a process are actually allowed to vary.
Then comes the less exciting work:
- Permissions
- Logging
- Cost control
- Failure handling
- API outages
- Unexpected model responses
- User experience when something goes wrong
- Traceability
Traceability is particularly important.
Helkyn has seen AI systems that worked beautifully on day one but couldn't answer basic questions about their own outputs:
How much did this answer cost?
Who produced it?
What input produced it?
Why was the answer produced?
Without traceability, production AI becomes difficult to understand, audit, and improve.
And as organizations consider AI governance and regulatory requirements, that becomes even more important.
Production Over Pilots
Helkyn's approach favors production over pilots and integrating AI into systems that already work rather than rebuilding everything from scratch.
So why do companies struggle to make that transition?
Because pilots and production systems are judged by completely different standards.
"A pilot is graded on whether it impressed someone in a room. Production is graded on whether it survives next week."
A pilot can succeed through speed, novelty, and a controlled demonstration.
Production has to survive:
- Security reviews
- Permissions
- Error handling
- Support
- Real users
- Messy data
- Real operational conditions
Another problem is that pilots often avoid the hardest parts.
A company chooses a clean use case with tidy data because it wants to demonstrate a result.
But the process that would actually create business value might involve data spread across six different systems.
Helkyn also highlights another failure point: feedback that goes nowhere.
When users repeatedly provide feedback and nothing changes, they eventually stop reporting problems.
Silence then gets mistaken for success.
His approach is different:
Feedback should either result in a shipped change or an answer.
For moving from experiment to production, his advice is straightforward:
- Choose a process that is genuinely painful and genuinely messy.
- Build it small but end-to-end.
- Include permissions and logging from day one.
- Put it in front of real users early.
- Watch what users actually do instead of only asking what they think.
- Define what failure looks like before starting.
- Keep the old process running until the new one earns the traffic.
It isn't particularly glamorous.
But that's often what production engineering looks like.
Building an Enterprise RAG System
One of Helkyn's current projects is an enterprise RAG knowledge system built around training material, documentation, and video transcripts.
The problem wasn't a lack of knowledge.
The knowledge already existed.
It was simply scattered across formats that people couldn't search consistently.
So employees would ask other employees for answers.
That worked, but it didn't scale.
The goal of the RAG system is to make that knowledge easier to find for employees and customers.
But building enterprise RAG exposed challenges that aren't obvious in tutorials or demos.
The biggest warning?
Permissions.
A RAG system can become an extremely efficient way of leaking information if different audiences have access to different documents.
Internal information, customer information, and information belonging to different clients cannot simply be placed into one index and protected with a prompt.
Access control needs to happen before the model sees the document.
That's an architectural problem, not a prompt-engineering problem.
Another major lesson was understanding what the documents actually represent.
A training video, customer call, support ticket, internal conversation, and written article aren't equivalent pieces of information.
They differ in:
- Reliability
- Freshness
- Audience
- Tone
- Context
That means representation matters enormously.
"Retrieval isn't the answer, representation is."
The way information is indexed, chunked, categorized, and enriched with metadata can matter more than simply choosing a different model.
Helkyn is also clear that this project is still work in progress. The lessons are real, but final outcome metrics aren't available yet.
Where RAG Stops Being Enough
RAG is powerful, but it has boundaries.
At its core, RAG retrieves relevant information and gives it to a model.
But not every problem is a retrieval problem.
If someone asks:
"How many of these happened since March?"
That's a database query.
The answer should come from actual data, such as SQL, rather than asking a language model to perform calculations from retrieved documents.
Relationships create another challenge.
A document might explain a customer configuration.
Another might describe a support ticket.
Another might describe a release.
The interesting answer may depend on the relationship between all three.
That's where relationship graphs can become useful.
So when should you introduce agents?
Helkyn's test is practical:
An agent makes sense when a task genuinely requires a sequence of steps that cannot be known in advance.
But there's a second condition that matters even more:
"If you wouldn't give an intern unsupervised write access to that system, your agent shouldn't have it either."
He also challenges the assumption that every AI workflow needs to become "agentic."
If a process has clear inputs, clear outputs, and fixed logic, deterministic code may be the better solution.
His preferred architecture is often:
AI at the edges. Code at the core.
Let the model interpret messy input and explain results, while deterministic code handles processes with a single correct answer.
And when agents are involved, Helkyn prefers a model where:
The agent proposes. A human confirms.
At least until the pattern has earned enough trust.
Vibe Coding Won't Kill Developers. It'll Kill the Middle.
Helkyn recently wrote about the idea that "Vibe Coding Won't Kill Developers. It'll Kill the Middle."
For him, "the middle" isn't a statement about people's ability or intelligence.
It's about the market.
AI is increasingly capable of handling implementation against a known specification:
- CRUD applications
- Simple integrations
- Brochure websites
- Standard internal tools
That is precisely the kind of work AI can perform cheaply.
Helkyn compares it to photography.
Cheap cameras didn't eliminate professional photography.
They eliminated part of the market while making the high end more valuable.
The same pattern could emerge in software.
The uncomfortable question is what happens to developers whose careers traditionally depended on implementation against well-defined requirements.
The skills that become more valuable are different:
- Architectural judgment
- Security
- Performance
- Understanding what not to build
- Deep domain expertise
- Understanding production failure modes
- Knowing how to use AI without becoming dependent on it
And Helkyn identifies one particularly difficult question:
"What I don't have a good answer for is how somebody starting today gets those twenty years, when the work that used to build them is the work being automated."
That's one of the biggest unresolved questions of the AI era.
AI Governance Without Killing Innovation
Governance can easily become bureaucracy.
Helkyn's approach is to avoid treating governance as a document people are expected to remember.
Instead:
"Make it a property of the system instead of a policy about the system."
Helkyn explains that AccountTECH is US-based, so the EU AI Act isn't a legal obligation for the company. Instead, they use it voluntarily as a reference framework for thinking about defensible AI systems.
One practical approach is to make AI usage part of the architecture itself.
For example, instead of maintaining a separate spreadsheet asking where AI is being used, AI usage can be represented directly alongside the application's existing screen and permission structure.
Then the inventory becomes a natural side effect of building the feature.
The second principle is:
"Gate for promotion, not for exploration."
People should be free to experiment.
The friction should appear when an experiment is ready to become production.
That's where review, permissions, logging, ownership, and other safeguards become mandatory.
As Helkyn puts it:
"Put the friction where the risk actually appears, and nowhere else."
The Mental Model in Your Head
Helkyn's CoderLegion profile contains a line that perhaps summarizes his entire approach to AI:
"The best AI in your stack is still the mental model in your head."
What does that mean in practice?
AI tools give developers answers.
But an answer is only valuable if you can understand and judge it.
If you understand the architecture and structure of the software you're building, you can evaluate AI-generated code.
If you don't, you risk outsourcing the architecture of something you're responsible for to a process you cannot properly audit.
Helkyn has experienced this himself.
He once spent an entire weekend trying to fix an AI-generated application that had suddenly stopped working.
After several days of troubleshooting, he discovered that the root cause was an architectural decision the AI had made around credential storage in a Supabase database.
It wasn't simply a coding mistake.
It was an architectural decision he hadn't realized the AI had made.
That experience reinforced an important lesson:
Don't let AI make important architectural decisions without guidance.
His advice to developers who rely heavily on AI is practical:
- Understand the important parts of your application before using AI.
- Decide what you think the solution should look like.
- Ask the AI for its approach.
- Compare the two.
- Ask the AI to argue against its own solution.
- Judge the arguments yourself.
- When the AI is wrong, understand why it was wrong.
And perhaps most importantly:
Think of AI as a junior developer peer who knows nothing about your application.
That mindset changes how you review its work.
Helkyn has one final rule:
"Never merge code you can't explain line by line to another person."
Reading code and thinking it looks fine isn't the same as reviewing it.
If you can't explain it, you haven't really reviewed it.
You've just approved it.
25 Years Later, the Technology Keeps Changing
From Access and client-server applications to .NET, web platforms, RAG, AI agents, and AI-native software, Helkyn has watched the technology stack change repeatedly.
But his biggest lessons aren't really about any particular technology.
They're about judgment.
Technology makes building easier.
AI makes it dramatically faster.
But understanding what should be built, why it should be built, how it should behave in production, what could go wrong, and how it fits into the business remains deeply important.
The developers who thrive in this new environment may not be the ones who write the most code.
They may be the ones who understand the problem deeply enough to know:
what to build, what not to build, what to let AI handle, and what should never be delegated blindly.
About Helkyn Coello
View Helkyn Coello's CoderLegion Profile
Helkyn Coello is a technology leader and Chief AI Officer at AccountTECH with 25 years of experience building enterprise software.
His career has covered the transition from Access-era applications to .NET client-server systems, web platforms, and now AI-native software.
Today, his work focuses on enterprise AI adoption, RAG, agentic AI, AI governance, software architecture, and bringing AI into production systems.
He is currently exploring agentic AI patterns, orchestration, guardrails, deterministic software, and AI-powered knowledge graphs over complex enterprise data.
Follow Helkyn's work and join the conversation on CoderLegion.
Interviewed and edited by James Dayal, Editor at CoderLegion.
