- Background -
1. Why not, since I'm idle anyway?
1) What's a senior unemployed person to do when idle? I returned to my hometown to help out my parents who are working in the midsummer heat.
2. A pretty-on-the-outside, hollow-on-the-inside IT career
1) Even so, I'd been making a living for over 10 years in the IT industry, calling it 'blockchain' or 'AI'..
- Reality check 01: Seeing that the situation of the work my family is actually doing back in my hometown is not very different from the 2G era, I had a reality check.
- Reality check 02: Even after witnessing the gap in reality check 01, 'I'm a planner.. but what can I actually do on my own?' - that's how it looked.
2) Despite that..
- Based on my amateur experience known as 'living-coding'..
let's try to do something with that-everywhere AI - that's the thought that came to me.
- Overview -
|
1. Recognizing the problem
1) The price of the same product differs by purchasing source and selling destination.
- Like memorizing phone numbers in the past, you commit them to memory; if you can't remember, you look up the invoice; if that doesn't work, you handle it 'later.'
2) Manual inspection, calculation, and writing of transaction statements
- Calculation errors occur during the process of inspecting on site and writing the transaction statement.
- There's a lot of inconvenience around storing transaction statements and reading them.
- Product names written on transaction statements are written under different names by the store and the distributor (each with their own abbreviations).
2. Motivation for getting involved in solving the problem
1) Reality check
- Like elderly people walking around with smartphones asking for directions... no, intuitively grasping that 'technology and reality are this far apart!!'/
- It's not someone else's problem; even if it isn't a grand SaaS, I felt the introduction of even appropriate technology was needed.
2) Trying to make a real, hands-on AI application case
- 'I hear LLMs are that good?!'
- YouTube was just starting to be plastered with praise for Claude Artifacts
- And on top of that, in a recent metropolitan-area ICT online course, while developing a blockchain application, I'd received a tremendous amount of help! from AI..
Let's apply this here. Starting with a half-belief: 'When you think about it, isn't it likely that LLMs have learned more about the more universal web development than about the relatively niche blockchain?'
3. Setting the MVP scope to solve the problem
1) Memory belongs to the smartphone, not to a person
- Set up an environment where you don't have to remember the cost, margin, and distribution price of countless products
2) Calculation belongs to the smartphone, not to a person
- Set up an environment where transaction statements are not handwritten
3) Statement management belongs to the smartphone, not to a person
- Set up an environment where the issued transaction statement is convenient for the consumer and supplier to read and store
4. Constraints
1) Offline-based usage environment
2) Develop within 2-3 days, omg
- Deliverables -
- LLM: Claude-3.5-Sonnet-200k, o1-mini
- IDE: VSCode
0. Data collection, preprocessing
1) .csv, by hand
2) Writing a per-purchased-product price table (cost, margin, distribution price)
1. Building the product database
|
1) Add a .csv or Excel file upload feature
2) Add a feature to crawl product images that match each product
3) Add a feature to edit individual product images or change the product name and re-crawl
4) Add a feature to save the result (adding thumbnail image, URL, and source fields to the original file)
5) Improve reusability of the generated file
- Add a feature so that when you add new product names to an already saved .csv and upload it again, products that already have image information are skipped and only new ones are crawled.
2. Building the transaction-statement generator (mobile web)
|
1) Load the product database
2) Add product search and thumbnail-preview features
3) Add a manual-entry feature (for products not in the database)
4) Add the transaction-statement issue feature (auto calculation)
5) When generating a transaction statement, add a return feature
6) Add an edit feature (real-time total update)
7) Add image and .csv download features
- Lessons learned -
1. A keenly felt understanding of MVP.
- I really got to think about the absolute minimum features, both as the maker and the user
- At first I drew up an ERD, designed the database structure, did it with SQLite, then set up MySQL, Firebase, and finally just settled on a .csv file
- For data analysis, I tried to unify all programs and the GUI in Python and built it with the Flat framework, then ended up settling on React
- I built a barcode reader using the smartphone camera, and finally settled on just typing it into the .csv by hand
- ..and so on; while iterating between development and use, I think I pivoted four times in total
2. As expected, there is no such thing as prompt engineering.
- It's a marketing term. It's just one of the 'standardizations of experience' that those who make a living from content use to package and explain it as content.
- Just as a person's tone of voice and the temperature of their conversation does not come from 'oratory or rhetoric,' prompting becomes naturally settled as you use various AIs. Even leaving aside the recent characteristic case of the o1 LLM model, both the diversity of the models themselves and the context of each conversation differ. I've come to think that this is not so different from how a single person's attitude reacts differently depending on the situation and conditions.
- So instead of spending time reading famous influencers' prompt-engineering cheat sheets, it's better to actually try out even one model yourself. Don't try to learn it as a habit (the way some students do prep-learning ahead of others in high school) - just experience it directly.
3. Thinking about appropriate technology.
- Not something grand - I thought about what kinds of things anyone could use independently right now without separate, specialized learning or installation.
- DT (Digital Transformation) does not lie in a convenient solution (or system). It depends on changing the work patterns familiar to existing native (analog) tasks. So gradual updates are needed. For reference, just collecting things from the vendors as files - rather than as paper statements - took over a month (there's still a lot we haven't received. So I had to manually process more than 300 product names, units, and unit prices)
- It might be a stretch to call this 'DT,' but just by skipping the process of writing and calculating by hand, there was a huge benefit.
- (Of course, this hands-on round? was at the MVP level within a very, very narrow scope.. ha)
- Epilogue
1. The programs I built this time are
- two pieces: a 'thumbnail scraping tool' to be run on a PC and a 'transaction-statement generation web application' that runs in a mobile web browser.
- The thumbnail scraping tool used Python and a Python framework called FLAT, while the transaction-statement generation web application was implemented based on vanilla JS.
2. And this whole process
- was, perhaps, more like a contracted job than a collaboration with AI. (Thank you, LLM? And also sorry?)
- If a process like this were to be advanced further and adopted into formal school education like the technology classes of the past - and were operated for just 2-3 years - the role of an IT-agency SMB would, in effect, no longer seem meaningful.
3. The unemployed must always be most careful of dying from overwork...
4. Hmm, hmm - this is fun;; should I delay finding a new job by just a pinch and improve this further?
