From Blank Page to Working ERP: Our AI Development Workflow
A behind-the-scenes look at how LuceneX builds custom software with AI agents, including what works, what doesn't, and why methodology still matters more than tools.
A behind-the-scenes look at how LuceneX builds custom software with AI agents, including what works, what doesn't, and why methodology still matters more than tools.
I haven't written a single line of code in about three years.
That statement usually gets a reaction. People expect the founder of a software development company to be deep in the codebase, debugging at midnight, arguing about tabs versus spaces. But my role has fundamentally changed. I've shifted from developer to engineer to something closer to an orchestra conductor, one who manages a team of AI agents instead of human developers.
This is the actual workflow we use at LuceneX to take projects from a blank page to working software. Not the theoretical version. The real one, with all its wins and rough edges.
It Still Starts With Questions
When a client comes to us saying they need a custom ERP system, that's a vague starting point. Before any AI gets involved, before any architecture decisions, I cut to the chase and dig deeper.
I ask clarifying questions and divide answers into functional and non-functional requirements. I look at the project from multiple perspectives: How will the client use this? How will their end users interact with it? What are the edge cases? How do we ensure the architecture is technically sound and maintainable long-term?
One thing I think about from day one that many developers skip: graceful degradation. Every system ages. I want ours to degrade gracefully over time instead of unexpectedly breaking apart, leaving everyone clueless about where to even start fixing things.
AI can assist in this planning phase (we experiment with it at LuceneX) but it takes real practice to get quality output from AI during requirements gathering. The human judgment, the client conversations, the experience of knowing which questions to ask: that's still essential.
Documentation as Source of Truth
We follow agile methodology strictly. Between planning and development, there's a design phase, roadmaps, and extensive documentation. This isn't bureaucracy for its own sake. It's insurance.
Unexpected things happen. Sometimes execution gets handed to different developers. Sometimes the person who planned a feature isn't the one building it. We create documents that serve as a universal source of truth, understandable by anyone, following best practices, with clear deliverables at each phase.
That last part matters enormously for what comes next.
The AI Team
Here's where things get interesting. When I reach the development phase, I don't code. I don't ask for architecture suggestions either because those decisions are already made during planning. That's the beauty of proper methodology. By the time development starts, there's a clear blueprint. No ambiguity about approach.
The actual coding is handled by predefined AI agents.
I have around twelve of them. Maybe that's overkill, but it dramatically boosts production speed and quality. Each agent has a specific role, defined permissions, selected tools it can access, and even a philosophy built into how it should operate within the codebase.
Think of it like the old days when you had an office full of teams. Team A creates the blueprint. Team B designs the prototype. Team C develops. Team D tests and ships. Each team has a specific, expected outcome.
My agents work the same way:
Planning Assistant helps transform a blank sheet into concrete requirements during client brainstorming sessions
Architect evaluates and selects the most compatible tech stack for each project's specific needs
Developer writes the actual code based on the established blueprints
Code Review Agent is my most important one. It goes through every line of code, ensuring stories meet requirements, checking for security issues, and evaluating tech debt
The agents have access to the tools they need: MCP servers, plugins, databases, testing frameworks. They hand work off to each other through deliverables, the same way agile phases work. After each phase, there's a concrete artifact that the next agent processes.
The Code Review Agent: Where Quality Lives
Since AI generates all the code, quality assurance becomes critical. My code review agent uses tools like Playwright for testing and Sentry for monitoring. When it finds issues, it categorizes them:
Critical means the story is not fully implemented or there are fundamental problems
High priority covers hardcoded variables and security concerns
Medium severity includes tech debt that's functional now but becomes a liability long-term
Low priority catches missing tests and inconsistent naming conventions
Here's what's important: this isn't fully automatic. The agent surfaces issues, prioritizes them, and proposes solutions. But I still put on a senior developer's hat, review the findings, evaluate risks, and make the final judgment call.
It's augmented decision-making, not replacement. The AI gives me a comprehensive summary of what's implemented, what works, what doesn't, and what might cause problems later. Then I decide what to do about it.
When fixes are needed, the agent pulls information from databases of best practices using tools like Context7, or searches for similar solutions across the web via Brave API. It's like having a research assistant who's already done the homework before I make a decision.
The Real Tradeoffs
People want to know about time savings, and the honest answer is nuanced.
Traditional development is often slower at building but faster at debugging. You wrote the code yourself. You understand it completely. When something breaks, you know where to look.
AI-driven development flips this. Getting from idea to product is often faster. But you spend significantly more time debugging code you didn't write.
Here's the critical insight: flagship AI models are generative models. Their job is to generate things. They're quick to assume and don't always follow direct instructions precisely. This creates real risks alongside the opportunities.
If you don't ensure your AI agent has clear, unpolluted context (if it's cluttered with irrelevant information) you'll find yourself in a rabbit hole of endless debugging. Fixing issue after issue instead of shipping product.
For comparison: my first project from scratch, years ago with traditional development, took roughly three months. I was younger, less experienced. Now, with AI-driven development, I build more complex projects in significantly shorter timelines.
But here's what I tell everyone: AI is a force multiplier. It amplifies what you already have.
If you're a good engineer who knows how to get from point A to point B, who can abstractly instruct an AI model, you'll get high-quality output with little friction. If you don't know how to provide the right context, how to see projects from multiple perspectives (client, stakeholder, architect, developer) you'll battle scope creep, tech debt, AI slop, and security issues constantly.
Where AI Still Fails
Every project is unique, which makes generalizing difficult. But some patterns emerge:
Context window degradation. Once an AI uses more than half its available context window, quality drops noticeably. Someone I worked with called AI "a genius with amnesia." My framing is slightly different: AI is like a builder with dementia. Sometimes he forgets he's a builder. Sometimes he forgets he has dementia. But all he knows is that he has to build, regardless of what.
Time estimates are unreliable. What takes an hour to develop, an AI agent might estimate at two weeks. Don't rely on AI for project timelines.
Abstract concepts remain challenging. Angles in image generation. Temporal reasoning. These are hard for current models to grasp consistently.
What's Surprised Me
When AI became mainstream for development, I saw a lot of badly implemented features. Hardcoded variables. Exposed API keys. It was a mess.
The improvement since then has been dramatic. Security and privacy handling is significantly better. The reasoning capabilities of current models are probably the biggest game changer in years. And the ability to use tools without polluting context (giving agents access to libraries, repositories, documentation) is like having a cheat sheet during an exam.
We're only at the beginning of how AI will influence development. There's a lot to learn, a lot to improve. But the fundamentals haven't changed: clear requirements, solid architecture, proper methodology, human judgment at critical decision points.
The AI just helps us move faster through the parts that used to be bottlenecks.
Ernests is the founder and CEO of LuceneX, a Latvian software development, AI, and cybersecurity company building custom solutions for European businesses. Reach out at [lucenex.lv](https://lucenex.lv) to discuss how AI-driven development might fit your next project.