Introduction: The Promise of AI Development
Artificial intelligence is changing the way software is developed.
Today, a person can describe an application in natural language and ask an AI system to generate its interface, implement features, debug errors, and write automated tests.
Tools such as ChatGPT, Claude Code, and AI-powered development environments have made software creation more accessible than ever.
But there is a significant difference between generating code and delivering reliable software.
During the development of MAKAN Translate, an open-source multilingual translation application, I encountered this difference repeatedly.
I experimented with several AI coding tools, investigated different machine learning models, and spent considerable time testing features that initially appeared to work.
The project taught me an important lesson:
The most important skill in AI-assisted software development is not writing the perfect prompt. It is understanding a problem well enough to divide it into manageable tasks, evaluate possible solutions, and verify the results.
This article examines that lesson through practical experience and established software engineering principles.
1. The Illusion of the Perfect Prompt
One of the most common ideas surrounding AI development is that better prompts automatically produce better applications.
Prompt quality certainly matters.
Clear instructions help AI systems understand requirements, expected behavior, technical constraints, and desired output.
However, a detailed prompt cannot guarantee that the resulting software will be correct.
Consider the following request:
"Build a complete application that translates subtitles, documents, websites, audio, and video using local AI models."
An advanced AI system might generate an attractive interface and a substantial amount of code.
But the request contains numerous independent engineering problems.
Each feature requires different technologies, dependencies, and verification methods.
Subtitle translation must preserve timestamps and text structure.
Document translation must extract and reconstruct content.
Website translation must interact safely with dynamically changing pages.
Speech translation requires recognition and language processing.
Offline model execution introduces hardware and compatibility requirements.
These are not simply different interface screens. They are separate engineering systems.
A better prompt can describe these requirements more clearly, but it cannot remove their underlying complexity.
A prompt is an instruction. It is not a substitute for architecture, implementation, or verification.
2. Why Software Decomposition Matters
Software engineering has long used decomposition to manage complexity.
The principle is straightforward: divide a difficult problem into smaller problems that can be understood, implemented, and tested separately.
This becomes particularly useful when working with AI coding assistants.
Instead of requesting a complete translation application, development can begin with a sequence of smaller objectives:
- Create a functional text input and output interface.
- Integrate one translation engine.
- Implement language selection.
- Handle translation errors and unavailable services.
- Add subtitle parsing and timestamp preservation.
- Introduce additional translation engines.
- Add document processing as a separate component.
- Integrate browser functionality after the underlying translation workflow is stable.
Each component can have explicit acceptance criteria.
For example, a subtitle translation feature should not merely produce translated text.
It should preserve subtitle identifiers, maintain valid timestamp formatting, keep segments in the correct order, and report unsuccessful translations rather than silently omitting them.
By dividing the application into manageable parts, developers make failures easier to identify.
This does not guarantee that bugs disappear. It reduces the number of interacting components that must be investigated when something goes wrong.
The objective is not simply to write smaller prompts.
The objective is to create smaller, verifiable units of engineering work.
3. Feasibility Research Should Come Before Coding
Another lesson from developing MAKAN Translate was the importance of understanding technological limits before implementing a feature.
Modern AI tools are often willing to generate code for ambitious ideas.
But technical feasibility depends on more than the ability to produce source files.
When investigating an offline translation model, developers need to consider several questions.
- Does the model support the required languages?
- Is it appropriate for translation, or is it primarily designed for general text generation?
- Can it run on the target hardware?
- What are its memory and storage requirements?
- Does the license permit the intended use?
- Can it be integrated into the selected application architecture?
During my project, finding usable models with satisfactory Persian support required extensive research and experimentation.
I investigated multilingual translation models, general-purpose language models, and speech recognition systems.
Some models were promising but difficult to integrate. Others required resources or configurations that were unsuitable for my intended users.
I also experimented with game translation, where the challenges extended beyond machine translation into proprietary asset formats, engine-specific tooling, compatibility, and ongoing maintenance.
These experiences demonstrated that AI-generated code cannot eliminate fundamental hardware, data, licensing, or interoperability constraints.
Before committing to a complex feature, a small proof of concept can answer a more important question than a large implementation:
Is the underlying approach practical under the project's actual constraints?
4. Why Working Code Is Not the Same as Reliable Software
One of the most frustrating patterns in AI-assisted development occurs when a tool reports that a feature is complete, but real-world testing reveals unexpected behavior.
An AI assistant may produce code that compiles, launches, and passes several automated checks.
Nevertheless, users may encounter problems that the tests do not cover.
A translation application offers useful examples.
A function can return a translation without preserving the meaning of the original sentence.
A subtitle processor can generate a valid file while damaging its timestamps.
A browser extension can work on a demonstration website but fail on dynamically updated pages.
A document translator can process extracted text while losing the structure of the original document.
Software correctness therefore has multiple dimensions.
Functional correctness concerns whether the program performs the intended operations.
Integration correctness concerns whether components work together.
Output quality concerns whether the result satisfies the user's actual needs.
Reliability concerns whether those properties remain consistent across inputs and environments.
These dimensions require different forms of testing.
For AI-driven applications, simply checking that a model returned a response is rarely enough.
5. The Regression Problem: Fixing One Bug and Creating Three More
During MAKAN Translate's development, I repeatedly encountered regression bugs.
A regression occurs when a modification breaks functionality that previously worked.
AI coding assistants can generate fixes quickly, but their changes may affect shared components, configuration, state management, or interfaces used elsewhere in the application.
For example, modifying language-selection logic may repair one translation workflow while accidentally breaking another.
In my experience, some fixes appeared successful initially but introduced additional problems that became visible only through manual testing.
This created a difficult cycle:
- A bug was discovered.
- The AI proposed a correction.
- The application was modified.
- The original bug appeared resolved.
- Another feature stopped working.
- More investigation and testing became necessary.
The problem becomes increasingly demanding as an application grows.
This is why incremental changes and regression testing are valuable.
Before modifying a shared component, developers should identify the behaviors that must remain unchanged.
After a modification, they should test both the corrected feature and the existing functionality that depends on it.
The principle applies regardless of whether the code was written by a human or generated by AI.
A successful fix is not merely one that removes the reported error. It must also preserve the behavior that was already correct.
6. Automated Testing Cannot Replace Human Judgment
Automated testing is essential for many types of software verification.
It can validate file formats, check functions, detect exceptions, confirm API responses, and identify regressions.
However, the effectiveness of an automated test depends on the assumptions and conditions encoded within it.
AI-generated tests can be particularly misleading when they reproduce the same misunderstandings as the implementation.
Suppose an AI assistant incorrectly interprets a requirement.
It may generate code based on that interpretation and then create tests that confirm the incorrect behavior.
All tests can pass while the application still fails to meet the actual user requirement.
This does not mean automated testing is ineffective.
It means that tests must be evaluated independently of the code they verify.
Human judgment is especially important for subjective or context-dependent outputs, including machine translation.
A sentence may be grammatically correct while mistranslating a technical concept.
A subtitle may preserve its formatting while changing a speaker's intended meaning.
A PDF may contain translated words but remain difficult to read because of layout reconstruction errors.
During development, I increasingly relied on direct testing with real inputs.
This was time-consuming, particularly as an independent developer, but it exposed problems that automated checks did not reliably detect.
The practical lesson is to combine automated tests with representative real-world scenarios and independent human evaluation.
Neither approach should be treated as a complete replacement for the other.
7. Using Multiple AI Tools as an Engineering Workflow
Different AI systems can demonstrate different strengths in research, planning, coding, and debugging.
During my experiments, I eventually adopted a workflow in which tools performed different responsibilities.
I used AI research assistants to investigate models, technologies, and alternative approaches.
Another AI system helped review implementation decisions and debug problems.
A coding assistant performed much of the implementation.
I remained responsible for selecting objectives, testing behavior, and deciding whether the results were acceptable.
This approach was more effective for my project than repeatedly asking one system to complete the entire application.
However, this experience should not be interpreted as evidence that a multi-AI workflow is universally superior.
A controlled study would be required to compare such approaches fairly.
The useful principle is separation of responsibilities.
Planning, implementation, and verification are different activities.
Assigning them explicitly can make the development process more understandable, even when a single AI system performs more than one role.
The critical requirement is maintaining an independent mechanism for deciding whether the software actually meets its objectives.
8. The Hidden Economics of Free AI Applications
A further challenge emerged from my decision to make MAKAN Translate free.
Free source code does not necessarily mean free computation.
A locally executed model may avoid recurring inference fees but requires compatible hardware.
A cloud API may provide powerful capabilities without demanding local computing resources, but its usage limits and pricing can become significant.
Model licensing, development tools, hosting, and application distribution introduce additional considerations.
These constraints influence architecture.
An application designed around a commercial API has different operating characteristics from an offline-first application.
Neither approach is automatically superior.
The correct choice depends on the intended users, available resources, privacy requirements, supported languages, and acceptable operating costs.
For independent developers, researching these constraints before implementation can prevent considerable wasted effort.
Technical feasibility and economic sustainability are both engineering requirements.
9. A Practical Framework for Building Software with AI
Based on my experience, I recommend treating AI-assisted development as a continuous cycle rather than a single instruction.
Stage 1: Define the problem
Start with the user and the task.
What problem are you trying to solve?
Why are existing solutions insufficient?
What would count as a useful result?
Avoid beginning with a long feature list before understanding the core problem.
Stage 2: Research the constraints
Investigate the required technologies, libraries, models, hardware, licensing conditions, and costs.
Identify assumptions that must be tested.
For uncertain features, build a small proof of concept before committing to a larger architecture.
Stage 3: Design a minimal architecture
Separate the application into components with clear responsibilities.
Define how those components communicate.
Identify shared state, dependencies, and error-handling requirements.
Avoid unnecessary complexity when simpler solutions satisfy the requirements.
Stage 4: Implement one feature
Give the AI a limited, explicit task.
Describe the expected behavior, relevant constraints, and acceptance criteria.
Prefer incremental modifications over broad changes to unrelated components.
Stage 5: Verify independently
Run automated checks where appropriate.
Perform manual tests with representative inputs.
Compare actual behavior with the original requirements.
For AI-generated outputs, evaluate quality as well as technical execution.
Stage 6: Preserve working behavior
Before adding another feature, confirm that the existing functionality remains stable.
Document known limitations.
Record failures that should become regression tests.
Stage 7: Expand progressively
Only introduce additional complexity when the current components are sufficiently reliable.
Revisit architecture when new requirements justify it.
Recognize that abandoning or postponing a feature can be a valid engineering decision.
This framework is a practical recommendation informed by experience and established engineering ideas. It has not yet been validated through controlled experimental research.
That distinction matters.
A useful development method should remain open to evaluation and improvement.
10. What This Means for the Future of AI-Assisted Development
As AI coding systems improve, they may become capable of handling larger development tasks with less human intervention.
That progress is likely to change how software is designed, implemented, and maintained.
However, increasing model capability does not automatically eliminate questions of correctness, reliability, resource constraints, or user expectations.
Even highly capable systems need clear objectives and meaningful evaluation.
My experience building MAKAN Translate suggests that the developer's role may increasingly involve defining problems, selecting technical approaches, supervising implementation, and verifying outcomes.
This is not necessarily less demanding work.
It is a different distribution of responsibilities.
For independent developers, the opportunity is significant.
AI can make experimentation faster, reduce barriers to implementing unfamiliar technologies, and support continuous learning.
But speed should not be confused with engineering quality.
The true value emerges when faster implementation is combined with disciplined decision-making and verification.
Conclusion: The Most Important Skill Is Knowing How to Divide the Work
I began experimenting with AI-assisted development because I wanted to build useful software.
I discovered that modern AI tools could help me accomplish tasks that would otherwise have required considerably more time and independent study.
I also discovered their limitations.
An attractive interface did not necessarily mean the application worked.
A confident coding response did not guarantee correctness.
A successful automated test did not always prove that a feature met its real-world requirements.
And a powerful AI model was not necessarily practical for a free application.
The biggest improvement in my development process came when I stopped treating AI as a system that should complete an entire project from one instruction.
Instead, I began researching the problem, identifying constraints, dividing the application into smaller components, implementing them incrementally, and checking the results.
My experience does not prove that this method is optimal for every developer or project.
But it reinforced a principle that software engineering has recognized for decades:
Complex systems become more manageable when their problems are broken into smaller, understandable, and verifiable parts.
AI changes how quickly those parts can be implemented.
It does not remove the need to understand how they fit together.
The future of AI-assisted software engineering is not simply about writing better prompts. It is about building better processes for humans and AI to solve problems together.
About the Author
Makan is the founder of MAKAN LAB, an independent software development project focused on practical applications, open-source tools, and AI-assisted engineering.
His projects include MAKAN Translate and Epsilon Download Manager.
This article draws on his experience developing software with AI coding assistants and researching local and cloud-based language models.
Project: https://makanlab.tech/translate/
GitHub: https://github.com/makan20042002/translator
MAKAN LAB: https://makanlab.tech/
Research Context and Further Reading
These references provide background for the engineering principles discussed in this article.
- Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623
- Lewis, J., & Fowler, M. (2014). Microservices: A Definition of This New Architectural Term. MartinFowler.com. https://martinfowler.com/articles/microservices.html
- NIST. AI Risk Management Framework (AI RMF 1.0). https://doi.org/10.6028/NIST.AI.100-1
- Google. Rules of Machine Learning: Best Practices for ML Engineering. https://developers.google.com/machine-learning/guides/rules-of-ml
- Meta AI. No Language Left Behind. https://ai.meta.com/research/no-language-left-behind/
Methodology note: This is an independent practitioner article, not a controlled research study. Its observations are based on personal development experiences and should not be interpreted as experimentally established comparisons between AI development tools.
Writing disclosure: The article was developed with AI writing assistance using the author's reported experiences, technical observations, and editorial direction.