Hello everyone, It’s Lee again! I want to share something that’s been both humbling and eye-opening – my journey from complete technical ignorance to actually understanding how AI development works.
Full Story about me: I’m not a technical person. My background is business administration, seven years in tech but always on the business side, product management, strategy, operations. Before that? Zero tech experience.
But after months of experimenting with AI development tools, I’ve discovered something fascinating about two completely different approaches: context engineering and vibe coding. And honestly? As a non-technical person, these differences taught me more about software engineering than I learned in seven years of managing technical projects.
This is Part 1 where I’ll break down what these approaches actually are, how they work, and what I discovered as someone learning from scratch. In Part 2, I’ll dive into building my own framework and what this means for Vietnamese tech industry.
My Starting Point: A Business Guy Who Knew Nothing About Code
Let me be honest about where this journey started. 6 months ago, if you asked me about system architecture, API design, or database schemas, I would have given you blank stares. My technical vocabulary was limited to Product Manager buzzwords: “scalable,” “user experience,” “technical debt,” “UX flow” (which I used without really understanding).
My coding experience? Exactly zero lines written.
But I was curious. After seven years of working with engineers, I wanted to understand what actually happens behind the scenes. How do you choose frameworks? What makes code “good” or “bad”? Why do some features take days while others take weeks? Why some seems so hard but it was just a library update away and the feature is ready?
The catalyst was simple: I wanted to build my own apps. Not manage them, not specify them – actually build them, myself.
So I dove in after watching a vibe coding video demo from Tina Huang on Vibe Coding Fundamental in 33 minutes (it that 33 mins did change my perspective in my tech life), what I discovered about vibe coding vs context engineering completely changed how I understand software development.
Understanding the Two Approaches: What I Learned the Hard Way
Let me start with definitions, because the industry uses these terms loosely (and I learned these the hard way):
Vibe Coding: Direct AI interaction where you describe what you want and get immediate code output. Think GitHub Copilot’s autocomplete, ChatGPT code generation, or Cursor’s quick fixes. Fast, intuitive, but often lacks systematic structure. Think of it like improvisational blues – you get something that sounds good quickly, but it may not hold up under scrutiny. Btw, I play Blues so I know what I am talking about.
Context Engineering: Systematic approach using structured requirements, design documentation, and planned task execution. Tools like Kiro, or increasingly, updated versions of traditional tools that now include planning phases.
Here’s what I learned after months of painful trial and error: the fundamental difference isn’t speed vs quality – it’s systematic vs ad-hoc thinking.
Latest as of 9th Nov 25: GitHub Copilot has actually evolved significantly since I started the coding journey. When you start a new chat session now, there’s a planning section where the agent lists tasks and executes them systematically. This is context engineering! The difference is Copilot’s planning is more implicit, it does it for a first prompt in the session but then not do it for the following prompt, while tools like Kiro make the three documents process explicit and mandatory.
My First Disaster: Vibe Coding Reality Check
My first approach was what any non-technical person would do: ask ChatGPT to build things.
“Build me a tarot reading app.”
And it worked! Sort of. I got Python Flask code, some HTML, basic functionality. I copy-pasted everything, followed setup instructions, deployed on my Contabo server using Docker and had a working demo in about an hour.
I felt like a genius.
Then I tried to show it to friends. Vietnamese names broke the encoding. Mobile users couldn’t use it properly. The UI looked like it was built in 2017 (Crypto Old Style). And when I wanted to modify anything? I had no idea where to start. The Agents just ran in loops while the UI broke.
The Problem: I was generating code, not building systems. I had no understanding of:
- Why certain frameworks were chosen
- How different parts connected
- What would happen when real users used the app
- How to maintain or extend anything
I then built several “working” prototypes this way. Every single one ended up in my Pending folder within two weeks.
This is classic vibe coding – quick results that fall apart under real-world conditions.
How Kiro’s Engineering System Actually Works (Technical Deep Dive)
After working with Kiro from AWS for months, here’s what I discovered about its sophisticated approach:
The Orchestrator Phase: When you request an app, Kiro’s orchestrator agent (powered by Claude 4.0 at the time, they do have 4.5 now) creates three comprehensive documents. But here’s what’s brilliant, it’s teaching you engineering thinking at the same time.
Awesome thing is that, if you read the specs and feel like don’t like something, you can ask for revisions before any code is written. This is huge for non-technical people like me. Vibe Coding? and now what? Vibe Spec Revision? WHATTT
The Execution Phase: Here’s where it gets interesting. Each task execution opens a fresh agent session with a clean context window. The new agent:
- Reads the three spec documents
- Understands the specific task context
- Executes following established guidelines and steering documents
- Maintains consistency across the entire project
This agent orchestration approach solves the context window problem while maintaining systematic development practices.
My Learning Experience: What amazed me as a non-technical person was how this process taught me to think systematically. Instead of “build me X,” I learned to think:
- Who will use this and how? What is the goal of the app?
- What could go wrong?
- How do different parts need to connect?
- What happens when users try it on mobile devices?
- What about scalability and maintenance? Security measures?
- Ease of deployment and updates?
… The list goes on, I was not used to think this way before, now I have to but way more fun with Ai assisted.
Modern Copilot Evolution: GitHub Copilot now includes planning phases, but you need to manually provide the requirements, design docs, and task breakdown. When you do, execution quality matches Kiro. The difference is Kiro forces the structured approach, while Copilot makes it optional.
Personal Discovery: I can now take my requirements and design documents to Copilot and get excellent execution. The breakthrough wasn’t the tool or the Ai Model – it was learning systematic engineering thinking.
PlantUML Diagram:
The Learning Experiment: Building the Same App Both Ways
To really understand the difference, I built the same tarot app using both approaches:
Vibe Coding with Copilot (My Old Way, well it lasted for 2 weeks):
- Asked for the code directly.
- Got immediate results in 30 minutes
- Looked impressive in demo
- Completely broke with Vietnamese input (bug)
- Couldn’t handle mobile users (fail on responsive)
- Had no error handling or security
Don’t get it wrong, vibe coding is still useful for cases when you need a quick check and quick bug fixes; you don’t want to have 3 documents for that. I hate it when agents create so much documentation. I will write about my process to keep documentation clean and neat in another post.
Context Engineering with Kiro (My New Understanding):
- Spent 1 hours on documentation first, this time I have chance to read all the User Stories and Technical Design specs
- Design phase planned for mobile-first usage
- Task execution took 1-5 hours depending on complexity (and number of credit spent as well)
- Result: Actually worked for near production level
There might have a few sub-tasks in between depends on your pace and the outcome you expect but overall for simple, well not really for project that you have a defined scope in mind, it would be very fast from having the prompt send to Kiro until you have the actual product deployed.
| Comparison Aspect | Vibe Coding (Old Me) | Context Engineering (Learning) | What I Learned |
|---|---|---|---|
| Time to “Working” Demo | 30 minutes | 5 hours total | Upfront investment pays off |
| Frontend/Backend Integration | Broken API calls everywhere, Type and lint errors everywhere | Seamless integration | Design documents prevent disasters |
| Mobile Experience | Completely broken | Native-like responsive design | User experience requires systematic thinking |
| Production Readiness | Security, Crash, hard to deploy… | Handled edge cases gracefully | Requirements analysis matters |
| Code Understanding | Had no clue how it worked | Could read and modify confidently | Systematic approach teaches you |
The breakthrough moment: When I shared my Kiro-built tarot app with VGU classmates, it just worked. Vietnamese names, mobile devices, proper error handling, cultural context – everything I had struggled with before was solved through systematic planning.
Image Prompt: Vietnamese developer at 2 AM, surrounded by energy drink cans, laptop screen showing error messages, looking exhausted but determined, with a small Buddha statue on the desk for good luck. cartoon style
The Lucky Wheel Project: Learning Kiro’s Steering Documents
After the tarot app success, I wanted to test my new understanding. I built a lucky wheel app – input names, spin, eliminate participants until there’s a winner.
This time, I followed Kiro’s full workflow from the beginning. But I also discovered something powerful: Kiro’s steering documents.
From my business background, I understood process documentation. But Kiro’s steering documents are something different – they’re conventions and guidelines that define how the project should be built and maintained:
- Coding Conventions: Variable naming patterns, file organization standards, comment styles
- Quality Standards: Requirements for link checking, time tracking at task completion, testing coverage
- Project-Specific Guidelines: How to handle mobile-first design patterns, error handling approaches
- Development Awareness: Things every developer on the project needs to know, like integration patterns or cultural context requirements
As a non-technical person, this was a revelation. It’s like having a project style guide that ensures consistency across all development work, whether done by AI agents or human developers.
Update: As of 9th Nov 2025, we have something similar for Claude and Codex as they have the AGENTS.md agreement, it is kinda like the steering docs for me, but the approach is quite different
Personal Learning: The requirements document phase taught me to think through:
- Multiple user scenarios (office team building, classroom activities, family gatherings)
- Vietnamese name handling (proper Unicode, mixing formal/casual names)
- Mobile-first design (most Vietnamese users access apps via mobile)
- Social sharing expectations (results posted to Facebook groups, Zalo chats)
The Results: My lucky wheel app handled all these scenarios flawlessly. More importantly, I understood why each technical decision was made.
PlantUML Diagram:
My “Aha” Moment: Understanding Engineering vs Coding
The breakthrough came when I realized what Kiro was actually teaching me. This wasn’t just about building apps – it was about learning software engineering practices as a discipline.
Coming from a Product Management background, I thought I understood development. I could write user stories, I knew about sprints and standups, I could talk technical requirements with engineers. But Kiro showed me the difference between managing development and actually understanding engineering.
What I Learned About Requirements: Not just “what” the app should do, but “why” and “how” with clear acceptance criteria. The EARS format (Given/When/Then statements) helped me think through edge cases I would never have considered as a business person.
What I Learned About Design: This was revelation. Architecture design, UI/UX considerations, technical guidelines, coding standards, all before writing a single line of code. I learned about API contracts, database schemas, error handling strategies, and security considerations.
What I Learned About Task Breakdown: Breaking everything into granular, executable tasks taught me about dependencies, validation criteria, and the actual complexity hidden behind simple-sounding features.
The steering documents added another layer of institutional knowledge about how to maintain consistency and handle cross-cutting concerns like Vietnamese localization, mobile responsiveness, and integration patterns.
Personal Transformation: I went from asking “can you build this?” to understanding “here’s why we should build it this way.” That mindset shift changed everything.
The Numbers Don’t Lie: Engineering Process vs Vibe Coding
Let me be transparent about the data here. After building both apps using Kiro’s engineering process versus the vibe coding approach with Copilot, the metrics tell a clear story:
| Project Metric | Copilot (Vibe Coding) | Kiro (Context Engineering) | Impact |
|---|---|---|---|
| Lucky Wheel App | |||
| Documentation Time | 0 hours | 3 hours (requirements + design) | +300% planning |
| Initial Development Time | 30 mins | 2 hours (following task list) | 4 times more to produce outcome |
| Integration Issues | many major problems | 1 or 2 issues | Much less issues |
| Mobile Compatibility Score | 3/10 (barely usable) | 9/10 (native-like) | +200% mobile experience |
| Maintenance Time (Monthly) | 6+ hours debugging until usable | 30 minutes updates | -90% maintenance |
| Tarot Reading App | |||
| Error Rate (Production) | 1 in 3 sessions failed | 1 in 25 sessions had minor issues | -87% error rate |
| Code Maintainability | Impossible to modify | Easy to extend and update since the design doc is there we can have another Ai Agent to continue | 100% improvement |
With Kiro, the 3 hours spent on documentation eliminated 15+ hours of debugging, refactoring, and fixing production issues. The engineering approach frontloaded the complexity, while vibe coding backloaded it as technical debt down the way.
What Kiro Actually Taught Me About Software Engineering
Here’s what I wish someone had explained about the difference between coding and engineering before I started this journey:
Engineering Is About Systems Thinking, Not Just Code
The biggest revelation was understanding that software engineering is fundamentally about building systems that work reliably in complex, real-world conditions. Kiro’s three-document approach forced me to think systematically about:
Requirements Analysis: Not just “what should it do” but “what could go wrong, who will use it, and how will we know if it’s working properly?” The EARS format helped me think through scenarios I would never have considered.
Architecture Design: Understanding how different components communicate, where data lives, how errors propagate, and how to handle edge cases gracefully. This isn’t just technical – it’s about predicting how users will actually interact with your system.
Task Decomposition: Breaking complex features into granular, validatable tasks that can be executed independently. This taught me about dependencies, testing strategies, and incremental delivery.
Context Engineering Requires Systems Thinking
Kiro helped me build systems that understand:
UI/UX Expectations: My target users expect dark mode (Tarot app) support (especially for late-night mobile usage), specific color psychology (red for luck, avoid certain color combinations), and visual hierarchy that matches local app conventions like Zalo or Shopee.
User Behavior Patterns: My target users are mobile-first, expect social sharing functionality, often use apps in group settings, and have specific expectations about privacy and data handling.
Technical Environment: Internet infrastructure requires optimized CSS loading, efficient image compression for slower connections, and performance considerations for older Android devices that many users still rely on.
Steering Documents Create Institutional Knowledge
Perhaps the most sophisticated aspect of Kiro’s approach is how steering documents codify engineering knowledge. These aren’t automated rules – they’re documented conventions that ensure consistency and provide guidance for handling cross-cutting concerns.
For example, the steering documents specify how Vietnamese input validation should be handled throughout the project, ensuring consistent Unicode handling patterns. They define mobile responsiveness standards that every developer (or AI agent) should follow when adding features for Vietnamese users.
This is institutional knowledge – the kind of engineering wisdom that usually takes years to develop and is often lost when team members leave. Steering documents capture this knowledge in a format that can be referenced and followed consistently.
PlantUML Diagram:
The Reality Check: Honest Assessment After Three Months
Let me be direct about both the advantages and limitations of this approach:
What Actually Works Well:
- Predictable Development: Following the three-document process eliminates most surprises during implementation
- Vietnamese User Success: Apps built this way just work for Vietnamese users without retrofitting
- Maintainable Code: Clear architecture and guidelines make updates straightforward
- Learning Acceleration: The structured approach taught me engineering concepts I wouldn’t have discovered through vibe coding
- Production Readiness: Apps handle edge cases, errors, and real-world usage patterns gracefully
The Honest Limitations:
- Upfront Time Investment: The documentation phase requires 2-3x more planning time
- Learning Curve: Understanding how to write good requirements and design documents takes practice
- Over-Engineering Risk: It’s tempting to add unnecessary complexity during the design phase
- Small Project Overhead: The full process might be overkill for simple utilities or experiments
What I’m Still Learning:
- Scaling to Team Projects: Most of my experience is solo development with AI agents
- Enterprise Integration: How this approach works with existing enterprise development processes
- Performance Optimization: Understanding when optimization is actually needed versus premature optimization
- Technology Choice: Learning when to use specific frameworks, databases, or architectures
The key insight: Kiro didn’t make me a senior engineer overnight. It gave me a systematic approach to learning engineering while building real applications that work for real users.
Hype Chart
Practical Advice for Vietnamese Makers Getting Started
Based on my experience transitioning from vibe coding to engineering process, here’s what actually helps:
Start With Small Projects, But Use Full Process
Don’t try to build the next Grab or Shopee on your first engineering project. But do use Kiro’s complete three-document approach even for simple apps. The patterns you learn on small projects transfer directly to larger ones.
Embrace the Documentation Phase
This was my biggest mental shift. The requirements and design documents aren’t bureaucracy – they’re thinking tools. They help you discover problems while they’re still cheap to fix.
Test Early and Often
Don’t wait until the end to test with the users. Include Vietnamese names, mobile devices, and real-world usage scenarios from your first prototype. The steering documents make it much easier to accommodate this feedback.
Learn to Question Your Assumptions
The EARS format (Given/When/Then) forces you to be explicit about assumptions. Document things like “I assume users will primarily access this on mobile” or “I assume Vietnamese users will want to share results on social media.” Then test these assumptions.
Understand the Engineering vs Coding Distinction
Kiro taught me that engineering is about building systems that work reliably under various conditions. Coding is just the implementation step. The requirements analysis, architecture design, and systematic task breakdown are equally important parts of the engineering process.
The Tools and Process: Beyond Just Kiro
While Kiro introduced me to context engineering process, I’ve developed a broader toolkit as I’ve gotten more comfortable with the approach:
For Requirements and Design:
- Kiro Orchestrator: For structured requirements gathering and system design
- Figma: For UI/UX mockups that inform the design document
- Docmost: For organizing requirements documents and tracking assumptions
- EARS Format Templates: Given/When/Then statements for clear acceptance criteria
For Implementation:
- Kiro Task Executor: For structured development following the task list
- GitHub Copilot: For code completion, but guided by clear design specifications
- Local Testing Environment: Chrome MCP for testing, multiple device sizes, network simulation
For User Context Validation:
- Real User Testing: Friends, family, VGU classmates as beta testers
- Chrome MCP Testing: Using browser automation to test UI responsiveness and cross-platform compatibility
- Mobile-First Design: Testing on actual mobile devices and various network conditions
- Cultural Review Process: Checking assumptions about user behavior and local expectations
- Multi-Device Testing: Ensuring consistent experience across different screen sizes and input methods
| Engineering Phase | Kiro’s Role | Other Tools | User Focus |
|---|---|---|---|
| Requirements | Structured questioning | EARS format templates | Cultural context analysis |
| Design | Architecture guidance | Figma mockups | Local UI/UX patterns |
| Implementation | Task execution | Code completion tools | Cross-platform testing, Chrome MCP |
| Validation | Quality checks | User testing | Real user feedback |
The key insight: Kiro provides the context engineering process framework, but successful app development requires additional context and comprehensive testing throughout the workflow, which me as the solo builder needs to cover.
Professional Assessment: Is the Context Engineering Approach Worth It?
After three months of comparing these approaches on real projects, here’s my professional assessment:
Time Investment Analysis
Upfront vs Backend Time Distribution:
- Vibe Coding: 20% planning, 30% coding, 50% debugging/fixing
- Engineering Process: 40% planning/design, 30% coding, 30% testing/refinement
The total time investment ends up being roughly equivalent, but the engineering approach frontloads the intellectual work when changes are cheap to make, while vibe coding backloads the complexity when changes are expensive.
Quality and Maintainability
The context engineering approach produces significantly higher quality results:
- Fewer Production Issues: Systematic requirements analysis catches edge cases early
- Better User Experience: Design documents ensure consistent UI/UX patterns
- Maintainable Codebase: Clear architecture and guidelines make updates predictable
Learning and Skill Development
The most significant benefit has been educational. Kiro’s structured approach taught me:
- Systems Thinking: Understanding how components interact and dependencies propagate
- Requirements Engineering: Writing clear specifications and acceptance criteria
- Architecture Design: Making informed decisions about technical structure
- Process Discipline: Following systematic approaches even when they feel slow
With the addition of steering documents and systematic approach make it much easier to handle these considerations consistently across all features.
The Future: Ten More Weekend Projects (And What I’m Curious About)
So here’s where I’m at now – I’ve got these two working apps, I understand the basics of context engineering, and I’m genuinely curious about scaling this approach.
I’m planning ten more small weekend projects over the next few months:
- A Auto-backup script for my blogs
- A wifi retry script for unstable connections for my Raspberry Pi
- A AI Prompt library manager – I will write an article about this later
- A Note taking app that give task suggestions based on context
- A B2B2C HR app for VGU class demo in Data Analytics – Article can be found here:
- A wordpress python app that convert .md to WordPress post via REST API
- A language learning app for my german learning journey
- A few more fun utilities for personal uses
The goal isn’t to become the next tech unicorn. It’s to really understand how context engineering scales across different types of problems and different Vietnamese cultural contexts.
What I’m Still Learning: The Honest Gaps
Let me be transparent about the limitations of my experience and what I’m still figuring out:
Enterprise and Team Collaboration
My experience is primarily solo development with AI agents. I’m still learning how Kiro’s engineering approach scales when working with teams of developers, designers, and stakeholders. Questions I’m exploring:
- How do multiple team members collaborate on requirements and design documents?
- How does the steering document system work when different team members have different coding styles?
- What happens when business requirements change mid-project in a team environment?
Performance and Scale
I understand the engineering principles, but I’m still learning about:
- Performance optimization strategies and when they’re actually needed
- Database design for applications serving thousands of Vietnamese users
- Caching strategies for Vietnamese content and mobile-first usage patterns
- Infrastructure decisions for Vietnamese market conditions
Technology Selection and Architecture
I can follow Kiro’s guidance on architecture decisions, but I’m developing my own judgment about:
- When to choose specific frameworks, databases, or cloud platforms
- How to evaluate trade-offs between different technical approaches
- Understanding long-term maintenance implications of architectural decisions
- Making informed decisions about third-party integrations and dependencies
Professional Development Context
I haven’t yet applied this approach in my professional Product Manager role. I’m curious about:
- How engineering process knowledge changes my effectiveness as a PM
- Whether the systematic approach improves communication with development teams
- How to advocate for proper engineering process in organizations that default to vibe coding
- Balancing time-to-market pressures with engineering discipline
The key insight: Kiro taught me engineering fundamentals and gave me a systematic approach to learning. But developing professional-level engineering judgment requires continued practice and exposure to diverse, complex projects.
GIF Idea: Vietnamese developer shrugging with a slight smile, holding coffee, with text overlay showing question marks. Caption: “Vẫn đang học hỏi nhiều thứ” (Still learning many things), cartoon style
The Community Question: Vietnamese Engineering Development
Here’s what I’m most curious about, how are other Vietnamese makers and developers approaching AI-assisted development?
From my Product Management and BA background, I know Vietnamese tech teams often face pressure to deliver quickly. The startup environment here tends to favor rapid prototyping and iteration. But after experiencing both approaches, I wonder if we’re creating unnecessary technical debt by defaulting to vibe coding.
Questions for the Vietnamese Tech Community:
For Developers: Are you using AI development tools like Copilot, Cursor, or similar platforms? How do you balance speed with code quality? Have you experimented with more structured approaches?
For Product Managers: How do you work with developers using AI tools? Do you see quality differences between quick AI-generated code and more systematically developed features?
For Startup Founders: What’s your experience with technical debt from rapid development? How do you decide when to invest in proper engineering process versus moving fast?
For Vietnamese Users: What’s your experience with locally-developed apps versus international apps? Do you notice differences in how well they handle Vietnamese language and cultural context?
I suspect many Vietnamese developers are going through similar learning curves with AI development tools. The question is whether we’re learning systematic engineering practices or just getting faster at generating code that works temporarily.
Broader Industry Perspective:
The Vietnamese tech industry is at an interesting inflection point. We have talented developers, growing international investment, and increasing focus on building for global markets. But are we developing engineering practices that will scale with that ambition?
Kiro taught me that there’s a difference between building code and building systems. As Vietnamese tech companies grow and compete internationally, engineering discipline becomes increasingly important for long-term success.
What This Means: Engineering Discipline in the AI Era
After three months of comparing these approaches on real projects, here’s my assessment as someone who learned engineering from scratch:
Context engineering isn’t about choosing slow over fast – it’s about choosing systematic over chaotic. Both approaches require similar total time investment, but engineering process frontloads the intellectual complexity when changes are cheap to make.
The learning benefit is substantial. Kiro’s systematic approach taught me software engineering fundamentals that I wouldn’t have developed through seven years of managing technical projects or trial-and-error coding.
However, this isn’t a universal recommendation. For rapid prototyping, one-time demos, or experimental features, vibe coding might be perfectly appropriate. The key is making a conscious choice based on the project’s actual requirements.
Most importantly: engineering discipline becomes more valuable, not less valuable, in an era of AI-assisted development. AI tools make it easier to generate code, but they don’t automatically make that code maintainable, scalable, or culturally appropriate. Systematic engineering process provides the framework for using AI tools effectively.
Looking Forward to Part 2: In the next part, I’ll share how I developed my own framework from these learnings, what it means for non-technical people in Vietnamese tech industry, and the specific processes I now use to build applications that work for Vietnamese users. We’ll also dive into the broader implications for Vietnamese startups and the business-technical skills gap.
The journey from business person to builder is just beginning…
Image Prompt: Vietnamese business professional confidently presenting to mixed audience of business and technical people, displaying both business strategy and technical architecture on screen, bridging two worlds successfully, cartoon style
Tags: #BusinessToTech #AIAssistedLearning #ContextEngineering #VietnameseTech #ProductManagement #EngineeringEducation #SystematicLearning
TL;DR for Busy People
Main Experience: Spent 3 months comparing vibe coding (Copilot/quick AI prompts) vs engineering process (Kiro’s systematic approach) through building Vietnamese apps. Used Copilpot Edu, Kiro AWS, ChatGPT Codex models.
Key Discovery: Same Claude 4 model, completely different results. Copilot generates code quickly but creates integration disasters. Kiro’s three-document approach (requirements + design + tasks) creates reliable, maintainable systems.
Critical Insight: Engineering isn’t about slow vs fast – it’s about frontloading complexity when changes are cheap versus backloading it when changes are expensive. Total time investment is similar, but quality outcomes are dramatically different.
Vietnamese Context: Engineering process makes cultural localization systematic rather than retrofitted. Apps built with proper requirements handle Vietnamese language, mobile-first usage, and cultural expectations from day one.
Professional Learning: Understanding systematic engineering process improved both my development skills and my effectiveness as a Product Manager. Learned requirements analysis, architecture design, and task decomposition.
What Actually Works:
- Kiro’s three-document workflow (requirements, design, tasks)
- EARS format specifications (Given/When/Then statements)
- Steering documents for cross-cutting concerns
- Context integration from requirements phase
- Systematic validation and testing processes
What I’m Still Learning:
- Team collaboration with engineering processes
- Performance optimization for larger scale
- Technology selection and architecture decisions
- Integration into professional development environments
Bottom Line: Engineering discipline becomes more valuable, not less valuable, with AI development tools. Systematic process provides framework for using AI effectively rather than just generating code quickly.
Vietnamese Tech Industry Opportunity: Learn engineering fundamentals alongside AI tools rather than viewing them as alternatives – this combination could be significant competitive advantage for international scaling.
Next Action: Share your experience with AI development tools and Vietnamese user context. How are you balancing speed with systematic quality?
Cảm ơn bạn đã đọc! Looking forward to hearing about your development experiences. 🚀
