DEV Community: Umitomo

Weekly Dev Log 2026-W15

Umitomo — Fri, 24 Jul 2026 07:28:11 +0000

🗓️ This Week

Summer has fully arrived in Japan, and people are enjoying the season in many ways, from local festivals to swimming pools🌊. Just like last week, work has stayed hot in more ways than one💦, but I have still been finding small pockets of time to move my projects forward little by little🐛. I want to keep growing at my own pace without rushing✨.
This week, I was able to make progress on the iOS app development for ToneDrill. Based on the top menu UI design I created in Figma last week, I implemented the screen in SwiftUI⛏️.
I asked Codex to implement it using the same workflow I used when building the first screen with the app’s main feature. This time as well, Codex helped me implement the SwiftUI screen closely based on the Figma UI design🦾.
However, some detailed adjustments still require human review and manual refinement. I will continue reviewing the implementation myself while learning more about the overall iOS app development flow and SwiftUI implementation.
Since Codex handles the overall implementation structure, I can move forward with iOS app development while saving a significant amount of time. This has made me feel the usefulness of AI even more clearly.
I was also able to complete one TryHackMe task for the first time in two weeks😂. The room I am currently working on also covers infrastructure used in AI applications, so there are many unfamiliar terms. Even so, I want to keep making progress little by little while researching them as I go🔍.

📱 iOS (SwiftUI)

Organized the structure of the top menu screen in Figma.
Created designs for both the main top menu and the submenu screen that opens when a menu button is selected.
Defined a “Coming Soon” state for features planned for future development and established a corresponding color palette.
Created the SVG icons used on the menu screens in Figma.
Added the new colors and icons from the design process to Assets.xcassets.
Organized Assets.xcassets into separate folders for colors and images.
Implemented the Top Menu and Practice Mode screens in SwiftUI.
Added reusable menu card styles and layout settings.
Connected the screens using NavigationStack and NavigationLink.
Added disabled “Coming Soon” cards for future features.
Documented the implementation and prepared an Xcode verification checklist.
Reviewed the Xcode result and found that the NavigationStack navigation bar pushed FretboardPracticeView downward, clipping the Answer and Next area.
Hid the Back button and navigation bar using .navigationBarBackButtonHidden(true) and .toolbar(.hidden, for: .navigationBar).
Added a custom Quit button that presents an alert before calling dismiss() to return to PracticeModeView.

🔐 Security (TryHackMe)

Worked on the AI System Reconnaissance room, part of the AI Security Learning Path on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Reviewed how to add new Color Sets and Image Sets to Assets.xcassets.
Visually distinguishing between enabled and disabled menu components helped clarify the intended result before implementing the screens in SwiftUI.
I was reminded that using Codex to edit and organize Figma designs through MCP is an efficient way to break down an existing UI concept into detailed, implementation-ready specifications.
Parent views should decide a card’s state, layout, and destination.
Reusable views can translate configuration values into visual styles.
MenuCardState is a display setting, not the same as SwiftUI’s @State.
Keeping navigation outside reusable UI components makes responsibilities clearer.
Figma designs should be adapted to responsive SwiftUI layouts instead of copied as fixed coordinates.
NavigationStack manages the screen hierarchy, while NavigationLink opens each destination.
GeometryReader lets a view calculate its layout from the space currently available to it.
Destination views are not placed inside the Top Menu’s GeometryReader; they receive their own layout space when presented by NavigationStack.
Adding NavigationStack can change the available layout height, even when the destination view itself is unchanged.
Navigation changes must be reviewed together with the destination screen’s existing size and safe-area assumptions.
A practice or game screen may need a protected exit flow instead of the standard Back button.
The destination view should control its own navigation-bar visibility when it requires a full-height layout.

🔐 TryHackMe Learning

AI System Reconnaissance

Task 3: Fingerprinting AI Services

I learned that finding an open port is only the first step. To understand what is actually running behind the port, I need to fingerprint the service.
I learned that standard Nmap service detection is not always enough for AI infrastructure because AI services can be mislabeled as generic HTTP services or unknown gRPC services.
I understood that AI service fingerprinting requires checking multiple clues, such as HTTP headers, JSON response structures, error messages, endpoint names, and gRPC behavior.
I learned that some AI frameworks reveal their identity through response headers. For example, TorchServe may return a Server: TorchServe header, while Triton can expose Triton-specific headers and telemetry information.
I learned that API responses can also reveal the framework. For example, OpenAI-compatible endpoints often return JSON containing fields such as "object": "model".
I understood that error messages can be useful for fingerprinting because AI frameworks often return detailed debugging information about tensor shapes, data types, or internal namespaces.
I learned that AI-related endpoints often use names such as /predict, /infer, /generate, /embeddings, /v1/models, and /v2/models, which are different from traditional REST endpoints like /users or /products.
I learned that some AI services expose gRPC in addition to HTTP, and normal HTTP scanners may miss these services because gRPC is a binary protocol.
I understood that grpcurl can be used to inspect gRPC services, and if gRPC reflection is enabled, it may reveal the available services and API schema.
I learned that fingerprinting does not always require exploitation. Even simple requests, harmless prompts, headers, and response formats can reveal what model or framework is running behind an endpoint.
Through the exercise, I learned how to move from “this port is open” to “this service is likely Triton, MLflow, Qdrant, or Jupyter” by checking service-specific responses.

🚀 Next Week

Continue developing the top menu screen for ToneDrill.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W14

Umitomo — Thu, 16 Jul 2026 08:02:49 +0000

🗓️ This Week

After several gloomy weeks of rain, summer suddenly arrived in Japan, and it lifted my mood❤️‍🔥! At the same time, work has been hot in more ways than one💦, so I have been trying to enjoy development efficiently with the limited time I have😎.
This week, I worked on designing the top menu screen for my iOS app using the new workflow I built last week🐠.
I also created rule files and a task management document for my portfolio website project so that I can apply the same Codex workflow I built for iOS development to my web development project🌈.
Setting everything up took some effort, but now I can use a similar workflow for both iOS and web development, which made me feel much more organized🦾.
I also tried Penpot to see whether it could replace some of the design work I currently do in Figma, as I was reconsidering my Figma subscription🤔.
I thought Penpot was a great tool, but I decided to treat the cost of Figma as a necessary expense for now and focus on developing efficiently while still enjoying the process🤗.
I have not worked on TryHackMe for more than two weeks, so next week I want to at least reconnect with it, even if I only review the content briefly🐛.

📱 iOS (SwiftUI)

Used Codex to create the top menu screen design for ToneDrill in Figma.
Used the workflow I built last week, where Codex first reads documents such as AGENTS.md and TaskIndex.md before starting the task.
Followed a similar process to the previous implementation: first, I asked Codex to generate multiple UI design ideas as images.
Chose the design I liked the most from those options and used it as the base direction.
Organized the information needed to implement the selected design in Figma as top-menu-figma-brief.md.
Organized the structure of the top menu screen in Figma based on the design created there.
Decided to include menu buttons for features I want to implement in the future on the top menu screen as well. I designed them so that it is clear they are currently unavailable.
Since this added a new “unavailable” state, I also organized the color rules for that state in the Figma design system.

🌐 Web Development

Last week, I created a new Codex workflow for ToneDrill, my personal iOS development project. This week, I introduced a similar workflow to My New Portfolio Website, a personal web development project, by creating an AGENTS.md file and a dedicated task management file.
To make the workflow easier to use, I reviewed both the immediate tasks and the medium- to long-term roadmap for My New Portfolio Website and organized them in the task management file.
I also updated my Notion setup so that Codex can read and write project records through the Notion MCP integration.

🖼️ Design Tool Exploration

Tried Penpot, an open-source design tool, to explore whether I can edit design data from Codex without using Figma’s Full Seat plan.
Checked how Penpot works as a possible alternative to Figma for managing UI design data.
Explored whether Penpot could fit into my AI-assisted design and development workflow.

💡 Key Takeaways

📱 SwiftUI Learning

After reviewing and improving my workflow last week, I felt that Codex could work more smoothly because it had a better understanding of the task details and previous project context.
I asked Codex to create multiple design ideas, and I chose a simple layout.
I realized that when the UI structure is simple and does not rely on complex image editing or highly detailed visual parts, there is less gap between what I imagine and what the AI understands.
Based on this, I felt that an efficient approach is to first use AI to build an app with a simple overall structure and the main features I want to use, then work on detailed UI refinements later.
Since I am developing this app by myself alongside my full-time job, I realized that choosing what to focus on is very important🤔.
For now, I think it is better to prioritize finishing a simple working app, even if that means sacrificing advanced, complex, or visually impressive UI design at the beginning❤️‍🔥.

🌐 Web Development Learning

Setting up this kind of workflow takes some time at first, but having a consistent way of working across different projects has reduced both the mental effort and the stress involved in switching between them😉.
I had already been managing tasks for My New Portfolio Website in Notion, but aligning its task management structure with the one used for my iOS project made everything feel much more organized and easier to understand.
Although the workflow is still relatively simple, I now have a basic and repeatable structure for using Codex in my personal development projects. As a result, I have a much clearer idea of how and when I want to use Codex than I did before🧐.

🎨 What I Learned from Exploring Design Tools

💡 What I found

Learned that Codex can read from and write to Penpot design files by using Penpot’s MCP server.
I actually asked Codex to create a simple dashboard design in Penpot, then tested whether I could implement a web app based on that design. Through this, I confirmed that Codex can write design data to Penpot and that it is possible to implement a program based on a Penpot design.
I also tested what differences would appear if I asked Codex to recreate the ToneDrill UI design I am currently working on in Figma as a similar design in Penpot.
As a result, I found that it is possible to create a design in Penpot that is almost the same as the Figma design.

🖼️ Figma Design and Penpot Design

When I tested this workflow, the designs Codex actually created looked like this.

I was surprised that Penpot could recreate almost the same design🔥!

(Penpot Design)

(Figma Design)

🐛 What I will do next

Since I am already familiar with Figma, I still find it easier to use in terms of both workflow and usability. However, Penpot appears to support many of the core features I need, so it could be a good option for personal projects like mine.
I considered switching from Figma to Penpot for the next screen in the ToneDrill project. However, I have already established a basic workflow for creating designs and implementing them with Codex and Figma while working on the first screen.
Changing the workflow in the middle of the project could lead to unexpected issues and additional rework. Therefore, I decided to continue using Figma for the current ToneDrill project and focus on completing the app with the workflow I have already tested
Instead of introducing Penpot into ToneDrill immediately, I plan to create a separate small iOS project and use it to test a Penpot-based design and development workflow. I think it is more important to complete ToneDrill first and establish a reliable end-to-end workflow before experimenting with a different design tool.

🚀 Next Week

Continue developing the top menu screen for ToneDrill.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W13

Umitomo — Fri, 10 Jul 2026 21:08:52 +0000

🗓️ This Week

This week, I mainly focused on iOS development📱.
I also tested a small workflow using Codex: organizing ideas, creating a design file, and implementing a SwiftUI prototype. Through that process, I realized that Codex can be very helpful for making iOS development more efficient💡.
Until now, I had been using Codex in a rather ad hoc way, sending instructions only when I wanted it to handle a specific task😂.
This week, I started thinking about how to make that workflow more efficient, and how to make Codex act more like a development partner that understands the project in the same way I do🧐.
As I explored this, I realized that I needed to review my Codex settings, build better rule files for giving instructions to Codex, and rethink how I use Codex in my own workflow🛠️.
Working through all of this slightly changed the way I think about AI agents🤖.

📱 iOS (SwiftUI)

I organized the UI structure for ToneDrill mini in Figma.
I created a structured design page and a small Mini Design System in Figma.
I summarized colors, typography, buttons, fretboard parts, spacing, and radius rules.
I updated the implementation note so Codex could understand the design direction.
I asked Codex to implement the SwiftUI fretboard UI based on the Figma design and implementation note.
I changed the instruction so app colors would be managed as Color Sets in Assets.xcassets.
I reviewed the SwiftUI code for ToneDrill implemented by Codex.
I asked Codex questions to better understand the implementation.
I checked how the fretboard UI is drawn and updated in SwiftUI.

🆙 Updating my workflow

🤖 AI agent workflow

I worked on setting up a more structured workflow for using Codex in my development projects.
I created a global AGENTS.md file for Codex (~/.codex/AGENTS.md).
I created a project-level AGENTS.md file at the root of the repository (repo-root/AGENTS.md).
I separated the responsibilities of the global AGENTS.md file and the project-level AGENTS.md file.
I created docs/codex/TaskIndex.md as a task management document. In it, I organized both immediate tasks and mid- to long-term tasks, and defined a consistent format for writing them down.
To reduce the need to repeatedly explain the project background, past work, and current tasks every time I move to a new chat, I decided to build a workflow and create a mid- to long-term project memory in Notion for the work and lessons I develop with Codex.
I created a Notion page called AI Operating Manual so AI can summarize the project overview, what I learned, mistakes, improvements, fixes, and any rules that should be added to the project-level AGENTS.md. I connected it through Notion MCP so Codex can update it.
I organized this entire process as a workflow.
At the start of a chat, Codex should read the AI Operating Manual Notion page, then read AGENTS.md and TaskIndex.md, so it can start working with the same understanding as me. I registered this as a Skill so I can call it with a single phrase.
At the end of a work session, Codex should summarize what was done and organize what should be saved as mid- to long-term project memory in the AI Operating Manual Notion page. I registered this as another Skill so I can call it with a single phrase.
Finally, I registered a separate Skill that can write the summarized content to the AI Operating Manual Notion page. I separated this from the summary Skill so that I can review the content first and decide what should actually be saved as mid- to long-term project memory before running the write operation.

💡 Key Takeaways

📱 SwiftUI Learning

By asking Codex to implement the SwiftUI UI based on the Figma UI structure and the small design system page, I was able to get a UI that was very close to the design I created in Figma.
I learned that Codex sometimes adds many custom style definitions in the code, even in areas where SwiftUI’s default styling system would be enough. I need to decide more carefully which parts should rely on SwiftUI’s default styles and which parts should be customized.
Through this implementation, I learned that I need to separate the parts where I want to take advantage of SwiftUI’s built-in default styles from the parts where I want to apply my own custom design.
I also noticed that Codex tends to implement SwiftUI previews using older syntax. This helped me understand the difference between older preview code and the newer style I learned in the SwiftUI tutorials.
I also learned that if I want colors to be managed in Assets.xcassets, I need to explicitly tell Codex to do that.
I learned that I should add rules for Codex so that the same kind of issue does not happen in the next implementation.
I learned how SwiftUI draws horizontal and vertical lines using .frame(width:height:) and .position(x:y:).
I learned that .position(x:y:) places the center of a view.
I learned that a parent view’s @State change causes SwiftUI to recalculate the parent view’s body.
I learned that child views are updated when new values are passed from the parent view.
I learned that @ViewBuilder does not trigger UI updates by itself.
@ViewBuilder is used to write conditional view logic, such as showing or hiding a view depending on a condition.

🆙 Updating my workflow Learning

🤖 AI agent workflow

🐛 How My Workflow Changed

Previously, I had to explain in each prompt who I am, how I prefer to work, and what kind of reasoning I expect from Codex. For example, I often had to explain my background and say things like, “Because I think this way, please do not do that.” By organizing this information in advance, I no longer need to repeat those explanations every time, and the direction of Codex’s responses is now much closer to what I expect.
I can now start talking with Codex about the task I want to work on right away, without wasting time aligning the process. Before, when I felt that Codex was moving in a slightly different direction, I had to explain the project background, current progress, and what I wanted to do next in order to bring Codex back to the same understanding.
By formatting the workflow, I no longer feel unsure about what information I should give Codex when working on any project. I created a system that lets Codex reach a consistent level of understanding with a minimal prompt. Because I also defined a clear way to operate Codex in order to protect that system, I feel that I can work with it more confidently and without hesitation.

📝 What I Learned From This

I felt that in order to use an AI agent effectively, I need to clearly tell it who I am and what kinds of actions or workflows I prefer.
At the same time, I realized that this kind of workflow becomes possible when I clearly define what I will delegate to the AI agent and what I will handle myself. In my workflow, the AI agent should not immediately start working on a task. Instead, it should first propose a plan, and then I, as the human user, review and approve it before the task is executed.
This feels similar to the relationship between a manager and a team member. In other words, I felt that using an AI agent effectively depends on how well the human can act as a capable manager. I also realized that the skills used to manage work in real-world teams can be useful when working with AI agents.
For regular applications that are used simply as tools, the important skills are things like understanding the features and knowing how to use the application well.
I found it interesting that the skills needed for AI agents are different from the skills needed for ordinary tools. This difference feels like one of the unique characteristics of AI agents.

🚀 Next Week

Continue developing the top menu screen for ToneDrill.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W12

Umitomo — Fri, 03 Jul 2026 04:42:07 +0000

🗓️ This Week

I had less time to work on my personal projects this week😅, but I was still able to make some progress on both my iOS app and web development projects.
One reason I was able to keep moving forward was that I used ChatGPT and Codex to work more efficiently. This week reminded me how helpful AI can be for personal development projects🦾.
I continued refining the UI direction for ToneDrill mini, the minimum-feature iOS app I implemented in Xcode last week.
Last week, I was excited to build the basic functionality of a working minimum-feature app in Xcode. This week, I shifted my focus to creating a clearer UI image for the app🎯.
I was not sure how to approach the UI design at first, but after discussing it with AI, I decided on a direction. I would like to keep using this approach as a base going forward🐎.
For web development, I finished reviewing the implementation of the portfolio site that Codex created last week❤️‍🔥.
I gained a better understanding of shadcn/ui and realized how convenient it is for building consistent UI components.
I was not able to work on TryHackMe this week, so I would like to make time for it again next week🔥.

I also want to thank everyone who commented on my previous Weekly Dev Log 2026-W11✨

Reading the comments on my previous Weekly Dev Log made me feel that I would also like to try writing standalone articles that go deeper into what I learned.

I hope I can share my honest learning process and thoughts in different formats, not only through Weekly Dev Logs.

Also, thank you so much for leaving positive comments on my personal, honest Weekly Dev Logs!

I always appreciate your comments, so please feel free to leave one if you have any thoughts or feedback.

📱 iOS (SwiftUI)

I used Codex and Figma to create the UI design for the minimum version of ToneDrill mini.
I asked Codex to generate several UI design ideas, then chose the one I liked and organized it as a design file in Figma.
ToneDrill mini will have multiple screens in the future, but I focused on designing only one main interaction screen first.
I started organizing a Mini Design System based on that one screen so that future screens can have a consistent UI.
At first, I considered organizing the design rules in a text file like Design.md, but I decided to organize them visually in Figma instead.
I organized the basic color structure, including background colors, text colors, button colors, and typography rules.

🎸 ToneDrill mini UI Image

Here are two UI images of ToneDrill mini: the current UI before creating the Figma design, and the temporary UI direction I created this week using Codex and Figma🥰.

I am excited to start implementing the app based on this new UI image🔥

(Current ToneDrill mini UI screenshot)

(ToneDrill mini UI screenshot decided this week)

🌐 Web Development

Posted my weekly dev log on Dev.to 📝.
Reviewed the structure of the portfolio home page created with React Router v7.

🔐 Security (TryHackMe)

I was not able to work on TryHackMe this week. I would like to make time for it again next week!

💡 Key Takeaways

📱 SwiftUI Learning

I noticed that if I ask Codex to create UI designs each time without clear rules, the colors, spacing, and font sizes can easily become inconsistent.
I learned that it is better to create one base UI design first, then organize the frame structure and Mini Design System based on that design.
I also considered asking Codex to implement a SwiftUI prototype first and then adjusting it in Xcode, but I felt that organizing the UI visually in Figma first was easier for me to understand.
Having the UI structure and color roles visible in Figma made it easier to understand the design than organizing everything only in text.
I learned that a visual design reference also makes it easier to imagine what needs to be changed after implementing the UI in SwiftUI.
For a personal iOS app like this, I felt that it is better to start with a small set of design rules based on one screen, rather than trying to build a large design system from the beginning.

🌐 Web Development Learning

Learned that sticky top-0 keeps the sidebar content visible near the top of the screen while scrolling.
Reviewed how Tailwind CSS utility classes are used to control layout in the profile sidebar.
Learned that flex flex-wrap is useful for arranging small elements naturally and letting them wrap when space is limited.
Learned that flex is better for content-sized inline groups, while grid is better for structured row-and-column layouts.
Reviewed the shadcn/ui Button component and learned that asChild lets a child element, such as an <a> tag, receive the button styles while keeping its original HTML meaning.
Rearned that this makes it possible to create a link that looks like a button, while still using the correct semantic element for navigation.
Reviewed the official shadcn/ui Button documentation and learned how asChild, variant, and size help create consistent button UI patterns.
Learned that shadcn/ui helps create consistent UI while allowing predefined design variations through component props, and its documentation makes it easy to understand how each prop affects the result.

🚀 Next Week

Finish organizing the Mini Design System for ToneDrill mini in Figma.
Organize the UI adjustment points for the portfolio site implemented by Codex in Notion, then start making small UI refinements.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W11

Umitomo — Fri, 26 Jun 2026 21:04:23 +0000

🗓️ This Week

While reviewing the code for the minimum-feature iOS app that Codex implemented for ToneDrill, I started coming up with many ideas for small improvements💡.
When I first started building the iOS app, I thought it would be enough to recreate the web version I had casually built before. However, once the app started taking shape, I naturally began wanting to add more features and improve the design🌋. At the same time, this is my first time building an iOS app, so I often do not know the best way to move forward. Human curiosity and ambition are interesting 😅.
Because of that, I discussed my ideas with ChatGPT, separated them into short-term tasks and medium- to long-term ideas, and organized a realistic development plan in Notion🗃️.
For now, I decided to focus on completing the minimum-feature version implemented by Codex. I changed the app layout from the default portrait orientation to landscape orientation and organized several UI ideas🦾.
I reviewed the program that Codex implemented last week based on my Figma design.
I learned more about React Router v7 features and several CSS functions.
Worked on the AI System Reconnaissance room from the AI Security Learning Path on TryHackMe this week 🤖.

📱 iOS (SwiftUI)

Organized feature ideas I would like to add to ToneDrill in Notion and separated them into short-term tasks and medium- to long-term tasks.
Changed the app layout from the default portrait-oriented design to a landscape-oriented design.
Planned the next UI improvement for the app: replacing horizontal scrolling with left and right buttons to switch the visible fret range.
Explored a design direction for a SwiftUI-drawn guitar fretboard background before using a real image background.
Worked with ChatGPT to define the direction for a fretboard-style UI in SwiftUI, organized the required display elements, and prepared them as a specification for Codex.
Prepared a concrete Codex prompt for generating a Figma draft based on the design task document and reference image.

🌐 Web Development

Posted my weekly dev log on Dev.to 📝.
Reviewed the structure of the portfolio home page created with React Router v7.
Checked how root.tsx, routes.ts, and home.tsx work together to render the top page.
Studied how the loader function passes page data to the home component.
Looked through home-page-layout.tsx and checked how the main area and profile sidebar are arranged.
Reviewed app.css to understand the layout, responsive design, and light/dark color settings.
Looked up grid-template-columns, minmax(), clamp(), and @media using MDN and ChatGPT.

🔐 Security (TryHackMe)

Worked on the AI System Reconnaissance room, part of the AI Security Learning Path on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Learned how to configure an iOS app to support landscape orientation.
Learned how to adjust the UI layout so it fits neatly on the screen in landscape mode.
Learned that a SwiftUI-drawn fretboard background is a safer first step than placing buttons directly on top of a real guitar image.
Learned that building the fretboard UI with separate background and button layers will make it easier to replace the background with an image later.
Learned that Codex should first explain its planned Figma structure before actually creating or modifying the design.
Learned that giving Codex a task document, a reference image, and clear constraints helps reduce unexpected changes.

🌐 Web Development Learning

Learned that root.tsx provides the base HTML layout, and child routes are rendered through <Outlet />.
Learned that loader prepares data before the page component is rendered.
Learned that home-page-layout.tsx mainly controls the page structure, while app.css controls most of the visual design.
Learned how CSS Grid is used to create a two-column layout with a flexible main area and a fixed-width sidebar.
Learned that grid-template-columns defines the width rules for each grid column.
Learned that minmax() sets the minimum and maximum size of a grid column.
Learned that clamp() lets a value change flexibly within a minimum and maximum range.
Learned that @media rules can be used for different CSS conditions. In this project, they are used to change the layout based on the screen width.
Learned how media queries change the layout from three-column cards to two columns, and then to one column on smaller screens.
Learned how CSS variables are used to manage colors for light mode, dark mode, and portfolio-specific design tokens.

🔐 TryHackMe Learning

AI System Reconnaissance

Task 2: The AI Infrastructure Stack

I learned that AI infrastructure is not just a single AI model or server, but a collection of specialized services that support the whole machine learning lifecycle.
I understood that AI systems often expose unfamiliar ports and APIs, so traditional network scanning alone may miss important AI-related services.
I learned that services such as model serving endpoints, experiment tracking tools, vector databases, model registries, Jupyter notebooks, MinIO, and Prometheus can all become important reconnaissance targets.
Although there were many new terms and I could not fully understand every single one, I was able to understand the main purpose of this task: building a mental map of AI infrastructure components and their common ports.
Through the exercise, I learned how to compare AI-specific ports with traditional service ports and identify which hosts are likely running AI infrastructure.

🚀 Next Week

Design the UI structure for the minimum-feature version of ToneDrill in Figma.
Finish reviewing the program that Codex implemented last week based on my Figma design and deepen my understanding of how the code works.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W10

Umitomo — Thu, 18 Jun 2026 06:39:33 +0000

🗓️ This Week

While organizing ideas for my first iOS app, I remembered an old web app idea called ToneDrill, which I had casually built before to help practice note names on a guitar fretboard🎸. I decided to try turning it into an iOS app🛠️.
I clarified the purpose of ToneDrill, its minimum requirements, and its core features, then organized them in Notion📝.
I was curious to see how well Codex could implement an iOS app from those minimum requirements, so I gave it a try right away💡.
I reviewed the SwiftUI code generated by Codex and worked through the app logic to understand how it was implemented🔍. For now, I was able to create a working app, which felt like a meaningful step forward🚶.
I created the top page UI design for my portfolio website in Figma🎨. I focused on keeping the structure simple and implementation-friendly, and designed the UI with reusable components for each major part.
Based on what I learned from my previous failed attempt, I tried again to see how well Codex could implement a prototype from the Figma UI design (You can read about my previous attempt that didn’t go so well here😅.)
Worked on the AI Threat Modelling room from the AI Security Learning Path on TryHackMe this week🤖.

📱 iOS (SwiftUI)

Revisited an old web app idea called ToneDrill, which I had previously built casually as a guitar note-training app, and considered turning it into an iOS app.
Organized the app idea in Notion, including its purpose, target use case, minimum requirements, and core features.
Decided to aim for an MVP-level version first, instead of trying to build a fully featured app from the beginning.
Wrote down simple requirements and tested how accurately Codex could implement the initial version of the app.
Reviewed the iOS app implementation generated by Codex and examined the code in detail to understand how the logic worked.

🌐 Web Development

Posted my weekly dev log on Dev.to📝
Completed the top page UI design for my portfolio website in Figma.
Tried using Codex again to generate a prototype app based on the Figma UI design.

🔐 Security (TryHackMe)

Worked on the AI Threat Modelling room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

🦄 What I learned by starting with a small app and minimum features

I started building the app with the mindset of creating small, steady progress instead of trying to build a large app right away.
Starting small made it much easier to take the first step mentally and actually begin building the app.
Even though the app is small, I realized that the knowledge I gained from tutorials alone was not enough to fully understand the implementation details.
I had to review and research the code step by step to understand how each part worked.
This made me realize that if I started with a much larger app, it would take a lot more time to understand the implementation while building it.
I also learned that I should define more clearly when and how I use Codex during development.
For now, my plan is to keep using AI actively until I can complete one working app, then evaluate where AI is most helpful and where I need to review the code more carefully myself.

🌐 Web Development Learning

❤️‍🔥 What I learned from retrying prototype generation with Figma MCP and Codex

Learned that I should first ask Codex to review the design system in the Figma UI design, then have it create rule files such as app.css and FIGMA_DESIGN_SYSTEM.md based on those design rules.
Learned that designing a Figma UI with implementation in mind is important when asking Codex to generate a prototype.
Instead of only creating a visual mockup, I structured the UI with clear frames, reusable components, and layout rules.
I also documented the design system in rule files so Codex could better understand the intended structure, spacing, colors, and component styles.
As a result, Codex was able to generate a prototype that closely matched the Figma design🔥.

🔐 TryHackMe Learning

AI Threat Modelling

Task 6: OWASP LLM Top 10 — Mapping Risks to Components

I learned that the OWASP LLM Top 10 helps map LLM-specific risks to the components where they occur.
OWASP LLM Top 10 is useful not only as a checklist, but also as an assessment tool for reviewing LLM architecture.
I learned that the LLM inference endpoint has the highest risk concentration, including prompt injection, sensitive information disclosure, excessive agency, system prompt leakage, misinformation, and unbounded consumption.
Vector databases and RAG pipelines require special attention because they can introduce indirect prompt injection, embedding weaknesses, and misinformation from stale or incorrect sources.

🚀 Next Week

Review the issues and improvements needed in the minimum-feature app generated by Codex, then start making code changes.
Ask Codex to help explore UI design ideas for the ToneDrill app and decide on the overall UI direction.
Review and understand the implementation details of the portfolio website prototype generated by Codex.
Continue posting small articles on Dev.to.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W09

Umitomo — Fri, 12 Jun 2026 00:10:44 +0000

🗓️ This Week

Completed the SwiftUI app development tutorial and tested the app I built on a real iPhone🦾
Learned the overall flow of building an iOS app with SwiftUI.
Organized my app ideas in Notion because I want to start building a real app next week🤔 I also realized that starting with a small app is important at this stage💡
Worked on the UI design for my portfolio site using the official shadcn/ui Figma template. I want to finish one design direction next week and then move on to implementation.
Worked on the AI Threat Modelling room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Completed the SwiftUI app development tutorial.
Learned how to run an app on a real iPhone by connecting it to my computer, without joining the Apple Developer Program yet.

🌐 Web Development

Posted my weekly dev log on Dev.to📝
Worked on my portfolio site UI design using the official shadcn/ui Figma template.

🔐 Security (TryHackMe)

Worked on the AI Threat Modelling room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

🔬 What I learned from testing an app on a real iPhone

I need to connect my iPhone, choose it as the run destination, and configure Signing & Capabilities before running the app.
A unique Bundle Identifier is needed to identify the app.
Xcode uses my personal Apple Account to sign the app for testing on my iPhone.
I need to enable Developer Mode and trust the developer profile on the iPhone before launching the app.
Preview data and real app data are handled differently in SwiftUI/SwiftData.
In previews, sampleContainer is used, so includeSampleMoments is passed as true.
The diary entries I create on the real iPhone are saved in the app’s local storage on the device.
The data is not automatically saved to my Apple Account or iCloud.

🦄 What I learned from organizing ideas for my first iOS app

As a beginner developer, I should not try to build a large, market-ready app from the beginning.
Large apps usually include many hidden complexities, such as data management, user experience design, error handling, security, performance, and long-term maintenance.
Since I have a full-time job, my development time is limited, so starting too big would make it harder to keep making steady progress.
Starting with a small app helps me focus on one or two core ideas and understand each part more deeply.
Building something small first also makes it easier to finish, test, and improve the app step by step.
I realized that the goal at this stage is not to compete with polished apps on the market, but to build practical experience by completing small projects.
This approach should help me stay motivated while gradually improving my skills in real app development.

🌐 Web Development Learning

Learned more about how to create UI designs in Figma and how to design screens using components.
Practiced building a consistent portfolio site design based on a design system instead of creating each part separately.

🔐 TryHackMe Learning

AI Threat Modelling

Task2 AI-Specific Assets and Attack Surfaces

AI systems add new assets such as training data, model weights, embedding vectors, system prompts, feature stores, and model registries.
I learned that poisoned training data can corrupt a model’s behaviour at the source.
I learned that model weights are especially valuable because they define what the model has learned.
If model weights are stolen, an attacker may obtain a functional copy of the AI system.
I learned that system prompts can reveal the model’s behaviour, constraints, business logic, and security guardrails.
Embedding vectors are important in systems such as RAG pipelines, recommendation engines, and fraud detection systems.
Manipulating embeddings can change what information the model sees at query time.
Feature stores are important because they provide preprocessed data used as real-time model inputs.
Tampering with feature stores can affect model decisions without changing the model itself.
A compromised model registry can allow an attacker to replace a legitimate model with a backdoored one.
AI threat modelling needs to consider not only traditional application risks, but also AI-specific assets, behaviours, and failure modes.

Task3 Data Supply Chain and STRIDE's Gaps

I learned that AI systems have a data supply chain in addition to a traditional software supply chain.
Each stage of the AI data supply chain can become a point of compromise.
Data poisoning can start from data collection, labelling, or other early pipeline stages.
If poisoned data reaches training, the damage can become embedded in the model’s weights.
A compromised model registry can allow attackers to replace a validated model with a backdoored one.
A backdoored model may look normal until it receives specific trigger inputs in production.
LLM-based systems can introduce additional injection points through retrieval pipelines during inference.
AI threats such as data poisoning, adversarial manipulation, tool misuse, and model theft do not always fit neatly into traditional STRIDE categories.
The key takeaway is that AI threat modelling must cover the full data supply chain and AI-specific failure modes.

Task4 Adapting STRIDE for AI Systems

I learned that STRIDE does not need to be replaced, but it needs to be adapted for AI systems.
In AI systems, familiar STRIDE categories can appear in new forms, such as data source impersonation, data poisoning, model extraction, and inference cost exploitation.
AI decisions are harder to audit because the model version, input features, prompts, and retrieved context may not be fully recorded.
Tool-enabled AI systems can make privilege risks broader, because a jailbroken model may misuse databases, email systems, or other connected tools.
The key takeaway is that STRIDE is still a useful starting point, but some AI risks require additional AI-specific frameworks such as MITRE ATLAS.

Task5 MITRE ATLAS: The AI Threat Technique Catalogue

I learned that MITRE ATLAS is an AI-focused knowledge base for adversary tactics and techniques against AI and ML systems.
ATLAS complements STRIDE by adding AI-specific technical detail, documented techniques, mitigations, and real-world case studies.
I learned key ATLAS techniques such as Data Poisoning, Model Extraction, Evade ML Model, LLM Prompt Injection, and Backdoor ML Model.
ATLAS helps turn broad STRIDE findings into specific, actionable threat findings with technique IDs and defensive guidance.
Real-world cases such as ShadowRay and Morris II show that AI threats are not only theoretical, but can affect real AI infrastructure and RAG-based systems.

🚀 Next Week

Start building a small iOS app based on the app ideas I organized this week.
Finish one portfolio site UI design in Figma and start implementing it in code.
Continue posting small articles on Dev.to.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

Weekly Dev Log 2026-W08

Umitomo — Thu, 04 Jun 2026 02:13:06 +0000

🗓️ This Week

Completed one section of the SwiftUI tutorial 🦾 Since I want to continue through the tutorial until I can build the app for testing and run it on an actual iPhone, I’ll focus on that from next week.
I also wrote another standalone article this week. It was about my experience experimenting with Codex and Figma MCP to see how much UI design work I could delegate to AI📝 If you're interested, feel free to check it out 👇

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

Umitomo
Umitomo

Umitomo

Follow

Jun 2

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

#beginners #devjournal #ai #figma

4 reactions
5 comments

6 min read
I’ll continue working steadily on my portfolio site design by combining AI-generated UI ideas with the official shadcn/ui Figma design template.
Completed LLM Security room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed "Reproduce a bug with unit tests"

🌐 Web Development

Posted my weekly dev log on Dev.to and a standalone article about my experience using Codex × Figma MCP 📝
Started learning UI design in Figma using community resources

🔐 Security (TryHackMe)

Completed LLM Security room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Reproduce a bug with unit tests

Learned that a streak should only increase when a moment exists on the next consecutive day.
Understood that multiple moments on the same day should not increase the streak more than once.
Learned how continue skips duplicate days while keeping the current streak.
Realized that break stops the calculation as soon as a gap in the streak is found.
Learned that fixing one bug can accidentally introduce new bugs in other scenarios.
Learned how to implement parameterized unit tests by preparing multiple input patterns and expected values.
Used @Test(arguments:) to run the same test logic with different test data.
Used #expect to compare the actual result with the expected value for each case.

🌐 Web Development Learning

While experimenting with automating UI design using Codex × Figma MCP, I learned that clearly defining design system rules first and then building the UI from small components is important for reducing the gap between the original Figma design and the implementation generated from its design data.

🔐 TryHackMe Learning

LLM Security

Threat Categories

Data-Based Threats

Training data extraction
Membership inference
Prompt leakage

Model-Based Threats

Model extraction
Model inversion

System-Based Threats

Prompt injection
Context Overflow
Memory Poisoning

User-Based Threats

LLM-powered social engineering
Trust exploitation

LLM Security Threat Cheat Sheet

Type	Threat	Target / Attack Surface	Input	Output
Data-Based	Training Data Extraction	Training dataset (confidentiality)	Crafted prompts designed to trigger memorised content	Verbatim or near verbatim training data (text, PII, secrets)
Data-Based	Membership Inference	Training dataset membership (privacy metadata)	Known candidate data sample already possessed by the attacker	Yes/no (or probability) decision indicating whether the sample was used in training
Data-Based	Prompt Leakage / System Prompt Exposure (LLM07:2025)	System prompt / developer instructions	Prompts asking the model to reveal or reflect on its instructions	Partial or full disclosure of hidden system or developer prompts
Model-Based	Weight Extraction (Model Stealing)	Model parameters (intellectual property)	Large volumes of carefully chosen API queries	A surrogate or distilled model replicating the original model's behaviour
Model-Based	Model Inversion	Model's internal representations	Unknown or partially known data, or model embeddings/outputs	New training data or attributes reconstructed from the model
System-Based	Context Window Poisoning (Prompt Injection)	LLM context window (instruction hierarchy)	Attacker controlled text embedded in input or retrieved content	Altered behaviour, policy bypass, unintended actions
System-Based	Context Overflow / Unbounded Consumption (LLM10:2025)	Context window size and system resources	Excessively large prompts or documents	Truncated safeguards, degraded responses, or denial of service
System-Based	Stateful Conversation Manipulation (Memory Poisoning)	Persistent conversation memory	Malicious statements intended to be stored as long term context	Persistent misinformation or corrupted future responses
User-Based	LLM-Powered Social Engineering	Human cognition and decision-making	Contextual or personal information used to craft persuasive output	Manipulated users (phishing success, fraud, coerced actions)
User-Based	Trust Exploitation / Misinformation (LLM09:2025)	User trust and judgment	Confident but incorrect or maliciously framed prompts	Users accepting false, unsafe, or harmful information

Key Takeaways

LLMs introduce a unique attack surface distinct from traditional ML systems, driven by natural language interaction, context handling, and emergent behaviour.
Data-based threats exploit how LLMs learn from and memorise training data, enabling attacks such as training data extraction, membership inference, and system prompt leakage.
Model-based threats target the model itself, including model extraction (theft of model behaviour or weights) and model inversion (reconstructing sensitive training data).
System-based threats arise from how LLMs process all inputs as a single context, enabling prompt injection, context window overflow, and memory poisoning.
User-based threats leverage LLMs as force multipliers for social engineering, increasing the effectiveness of phishing, scams, and trust exploitation.

🚀 Next Week

Work through the "Preparation for Distribution" section of the SwiftUI tutorial.
Continue posting small articles on Dev.to.
Explore Figma MCP and experiment with generating UI design ideas using AI.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

I Thought Figma MCP Could Recreate Any Design. I Was Wrong.

Umitomo — Tue, 02 Jun 2026 00:30:16 +0000

Introduction

Since I started publishing articles on Dev.to, I've been working on a personal project to transform my old blog website—which is no longer actively maintained—into a portfolio site♻️

As part of that project, I recently started learning Figma and UI design🎨 When I discovered Figma MCP, I imagined a future where generative AI could automatically create polished, modern, and visually appealing designs for me with minimal effort😎

Unfortunately, reality turned out to be quite different.

This article is a reflection on that experience and a reminder to my future self about what I learned along the way📝

TL;DR

I wanted to design a portfolio website in Figma, but quickly realized that UI design was more difficult than I expected.
I wondered whether using Codex and Figma MCP would allow me to outsource the design process to AI, so I decided to try it.
I couldn't magically generate the polished design I had imagined while also maintaining a well-structured Figma file with globally managed variants and reusable components.
I learned that defining design rules first and building components step by step helped produce results that were much closer to my original vision.
Even then, the process was not dramatically easier than expected, so I eventually decided to keep things simple and build my portfolio around the design principles already provided by shadcn/ui.

What I Tried with Figma MCP🎨

While planning the UI design for my portfolio website, I initially created simple wireframe-like layouts in Figma to explore the overall page structure and component placement before working on detailed designs.

At first, I wanted to keep things simple.

However, as I continued working on the project, I found myself wanting something more polished, more modern, and ultimately more impressive.

The problem was that I have very little confidence in my design skills. I'm an in-house IT engineer, not a professional developer or designer, so I often struggle to judge what makes a design truly good.

That led me to a simple idea:

What if I could let AI handle the design work for me?

While researching possible solutions, I discovered that Codex could interact with Figma through Figma MCP. By connecting the two, Codex could actually edit Figma files and create designs based on my instructions.

That sounded promising.

So I decided to give it a try.

Doesn't Everyone Dream at First?🎰

Before using it for my real portfolio project, I wanted to answer a few questions:

Can Codex really create designs directly in Figma?
Can it generate polished and visually appealing layouts?
How accurately can it turn a Figma design into a real web page?

Since it was also my first time using Codex, I decided to run a quick experiment.

My test process looked like this:

Install the Codex application.
Set up the Figma integration so Codex could write design data to Figma.
Create a blank Figma design file.
Create a local test project.
Send a simple prompt to Codex and verify whether it could generate a design inside Figma.
Ask Codex to build a web page from the generated design and evaluate how closely the implementation matched the design.

There are already plenty of great articles from DEV Community members explaining the setup process in detail, so I won't cover it here😂

The prompt I used was surprisingly simple:

Create a stylish portfolio website design.

(Screenshot of the generated Figma design)

(Screenshot of the web page generated from the Figma design)

And honestly?

The results were far better than I expected😮

The generated design looked great.

The generated web page closely matched the design.

For a moment, it genuinely felt like magic.

Reality Hits🪄

Encouraged by the results of my initial experiment, I decided to use the same approach for my actual portfolio project.

This time, I asked Codex to create a Figma design based on a homepage concept image generated by ChatGPT.

However, the results were very different from what I had expected.

At first glance, the generated design looked somewhat reasonable. But once I looked more closely, it lacked consistency. Component sizes, spacing, and layout rules all felt disconnected from one another.

It seemed as though the AI had focused only on the overall "polished feeling" of the image while missing the underlying structure that made the design work.

As a result, the entire page ended up feeling cluttered and disorganized.

To be honest, my only reaction was:

"Wait... how did it end up like this?"

Because my earlier experiment had produced surprisingly good results, I had assumed the same thing would happen with my real project.

Reality turned out to be much less forgiving.

It was at this point that I finally realized I had misunderstood something important.

The Problem Wasn't AI🔎

My first thought was:

"Maybe AI just isn't smart enough yet."

But the more I worked on the problem, the more I realized that the issue was somewhere else.

I had only provided the AI with a finished design image.

What I had not provided were the rules behind that design.

For example:

A color palette
Typography rules
Spacing guidelines
Component variants
A layout grid

None of those things had been defined.

A human designer might be able to infer some of those details from an image.

However, an AI generating designs through Figma MCP needs more than just a visual reference. It has to translate that image into actual components, layouts, and reusable design patterns.

In other words, I was essentially saying:

"Make it look like this image."

without having any design system in place.

Looking back, it's no surprise that the results were disappointing.

Starting Over with Small Steps🚶‍♂️

So I changed my approach.

Instead of generating an entire page from the start, I decided to build the foundation first.

I began by creating a design specification file and defining things such as:

Colors
Typography
Spacing
Border radius values
Shadows

Next, I created small reusable components, including:

Buttons
Cards
Tags
Navigation elements

I then defined variants such as:

Primary
Secondary
Outline

Only after those pieces were in place did I move on to creating the page design itself.

The results were dramatically better.

The design was no longer chaotic, and the overall structure felt much more consistent.

Communication with the AI also became smoother, and providing feedback or requesting changes became significantly easier.

It Still Wasn't Magic👻

There was, however, one thing that surprised me.

The design was definitely better.

But the feeling I had during my first experiment—

"Wow, this is the future!"

—was gone.

In the end, I still needed to:

Organize design tokens
Design components
Define variants
Think through layouts

AI hadn't eliminated those tasks.

Instead, I realized something different:

The better your design system is, the more effectively you can use AI.

That felt much closer to reality.

What I Ended Up Doing🤖

Eventually, I decided to base my portfolio design on shadcn/ui, which had been my original plan from the beginning.

The reason was simple.

A lot of work had already gone into defining:

Component architecture
Variant patterns
Design consistency

and those decisions had been validated by a large community of developers.

To be clear, I still think Figma MCP and Codex are incredibly interesting technologies.

Using them made it obvious that the gap between design and implementation is getting smaller.

But the biggest lesson I learned was this:

AI is not a replacement for a design system.

AI can be an excellent assistant.

However, it is not a magical tool that can automatically generate a complete and well-structured design from a vague idea alone.

At least, not in the way I was hoping to use it.

What I Learned✨

This experience taught me three important lessons:

Think about your design system before asking AI to generate pages.
Design components before designing entire pages.
Good results require clear rules and constraints.

AI can create designs.

But it cannot magically create a design system for you.

Although the experience was a little frustrating, it ultimately helped me understand the importance of design systems far better than before.

Weekly Dev Log 2026-W07

Umitomo — Fri, 29 May 2026 00:18:11 +0000

🗓️ This Week

Completed two more sections of the SwiftUI tutorial 🦾 As I continue working through the tutorial, I can feel my understanding of SwiftUI fundamentals becoming more solid🔥
It was my first time posting a standalone article about reverse engineering📝 If you're interested, feel free to check it out 👇

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

Umitomo
Umitomo

Umitomo

Follow

May 26

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

#beginners #reversing #security #python

6 reactions
Add Comment

5 min read
I started creating UI designs for my future portfolio website in Figma. I was able to roughly sketch out the overall structure of the site, but I also realized how difficult it is to create modern and stylish UI designs. (It really made me realize I don’t have much design sense yet 😂💦)
While struggling with the design process, I came across several articles about Figma MCP. That made me interested in exploring how generative AI could help with UI design ideas, so I decided to start researching Figma MCP further.
Completed Securing AI Systems room from the AI Security Learning Path on TryHackMe this week🤖

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed "Create an Algorithm for Badges" and "Add inclusive features"

🌐 Web Development

Posted my weekly dev log on Dev.to and a standalone article about my first attempt at reverse engineering 📝
Created rough portfolio website UI layouts in Figma
Used shadcn/ui component library design templates in Figma
Started learning UI design in Figma using community resources

🔐 Security (TryHackMe)

Completed Securing AI Systems room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Add inclusive features

Learned that SwiftUI automatically adapts UI elements for Light and Dark Mode by default.
Learned how to preview and compare Light and Dark Mode layouts in the Xcode canvas.
Understood that system-provided semantic styles help SwiftUI automatically adjust UI appearance.
Learned that SwiftUI uses view modifiers to customize ScrollView behavior.
Understood that .scrollBounceBehavior(.basedOnSize) only enables bouncing when the content is larger than the visible area.
Learned that .defaultScrollAnchor(.center, for: .alignment) centers smaller content inside a ScrollView.
Learned that the dynamicTypeSize modifier can be applied to any SwiftUI view.
Learned how AttributedString(localized:) supports localization-aware text in SwiftUI.
Understood that (inflect: true) automatically changes words like “Day” and “Days” based on the number value.
Learned that SwiftUI can apply different font styles to specific parts of an AttributedString.
Realized that Apple provides built-in grammar inflection support for more natural localized UI text.

🌐 Web Development Learning

Reviewed several useful functions in Figma
Learned the importance of focusing on the overall page layout before designing detailed UI components

🔐 TryHackMe Learning

Securing AI Systems

Task 2 Anatomy of an AI System

Traditional apps use deterministic logic, while AI systems rely on probabilistic model inference.
AI systems accept free-form natural language, making input validation much harder.
Prompt Construction combines the system prompt, user input, and retrieved context before sending data to the LLM.
RAG allows LLMs to retrieve external knowledge from a vector store or other data sources.
A vector store contains embedded representations of internal documentation for retrieval-augmented generation (RAG)
Trust boundaries are points where data moves between different security contexts.
Major trust boundaries include user-to-system, system-to-LLM, LLM-to-tools, and system-to-user.
LLM-to-tools is especially sensitive because model output can trigger real actions.
Tool layers may execute database queries, API calls, or file operations on behalf of the LLM.
Security controls are needed at every boundary to reduce prompt injection and data leakage risks.

Task3 The AI Attack Surface

Studied the OWASP LLM Top 10 and how major risks affect AI-integrated systems.
Learned that MITRE ATLAS documents adversary tactics and exploitation techniques for AI systems.
Studied how the NIST AI RMF approaches AI security from a governance and risk management perspective.
Learned the difference between OWASP (vulnerabilities), ATLAS (attack techniques), and NIST AI RMF (risk governance).

Task4 System-Level Threats

Studied how LLM10 Unbounded Consumption can cause resource exhaustion and extreme cost increases through excessive requests.
Learned that system prompts may leak internal rules, tool information, and architecture details if exposed.(LLM07).
Understood that LLM output must never be trusted as safe input for downstream systems.(LLM05)
Learned that Excessive Agency occurs when AI systems are given unnecessary permissions, tools, or autonomy.(LLM06)
Learned that users may unintentionally leak sensitive information when using AI systems.(LLM02)
Studied how the OWASP LLM risks relate to the CIA triad across confidentiality, integrity, and availability.

Task 5 Secure Design Patterns

Learned that security controls are most effective when applied during the design stage of AI systems.
Learned that layered controls reduce the risk of end-to-end attack success.
Understood the importance of least privilege for AI tools, API tokens, and database access.
Learned that write operations should require human approval before execution.
Studied how input and output validation reduce prompt injection and downstream injection risks.
Learned that MLSecOps integrates security throughout the AI and machine learning lifecycle.

🚀 Next Week

Complete the badge algorithm in the SwiftUI tutorial.
Continue posting small articles on Dev.to.
Explore Figma MCP and experiment with generating UI design ideas using AI.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.

A Curious Journey Into Reverse Engineering an AI-Generated Python .exe

Umitomo — Tue, 26 May 2026 05:02:08 +0000

Introduction

I usually post weekly learning and development updates on Dev.to📝

This time, however, I decided to write a standalone article about something a little different — my first attempt at reverse engineering🦾

What started as simple curiosity quickly turned into an exciting journey of uncovering how a modern AI-generated Python application was actually structured internally🔎

TL;DR

Reverse engineered a PyInstaller-based Python .exe
Reconstructed a surprisingly large portion of the application's architecture from the packaged .exe
Analyzed .pyc files using tools like strings, pycdc, and pycdas
Learned how React/Vite frontend assets can be bundled into a standalone executable
Realized how difficult production frontend bundles are to understand without the original source code
Thought deeply about maintainability in the age of AI-generated applications

What I Reverse Engineered

As someone who works in IT administration and internal tooling, I often become curious about how applications are actually built under the hood.

This time, a coworker showed me a PDF-processing desktop application that had been created with the help of generative AI.

The overall architecture had already been explained to me verbally beforehand.
However, that led me to a simple but exciting question:

How much of an application's internal structure can actually be reconstructed just by reverse engineering the final .exe file?

That curiosity became the starting point of this exploration.

The application itself was a harmless internal utility designed for local use, and this investigation was performed purely within an authorized and educational context.

Rather than trying to analyze malware or bypass protections, I wanted to understand:

What information remains inside packaged executables
How modern Python applications are bundled
Whether frontend/backend structures could still be inferred after packaging
How much architectural detail could realistically be reconstructed from compiled artifacts alone

What made the process especially exciting was slowly piecing together the architecture from small clues hidden inside the executable.

Reverse Engineering Environment Setup

Since I was using Kali Linux on WSL for this experiment, I first prepared a small reverse engineering workspace.

Creating a Python Virtual Environment

mkdir -p ~/reverse
cd ~/reverse

python3 -m venv venv
source venv/bin/activate

At first, the virtual environment failed because python3-venv was missing:

sudo apt install python3.13-venv

After that, I recreated the environment successfully.

Installing Basic Analysis Tools

I installed a few basic tools for inspecting the executable and analyzing Python bytecode.

pip install pyinstaller

I also installed binutils so I could use strings:

sudo apt install binutils

Building `pycdc`

To inspect .pyc files more deeply, I built pycdc from source:

sudo apt install -y cmake g++ git

mkdir -p ~/reverse/tools
cd ~/reverse/tools

git clone https://github.com/zrax/pycdc.git

cd pycdc
mkdir build
cd build

cmake ..
make -j4

This generated:

pycdc
pycdas

which I later used to inspect Python bytecode files.

Extracting the PyInstaller Executable

After confirming the executable was likely packaged with PyInstaller, I used pyinstxtractor to extract its contents:

git clone https://github.com/extremecoders-re/pyinstxtractor.git

Then:

cd ~/reverse/pdf_exe

python ~/reverse/pyinstxtractor/pyinstxtractor.py PDF.exe

This generated a directory like:

PDF.exe_extracted/

Inside the extracted directory, I was finally able to inspect files such as:

app.pyc
pdf_stamp_processor.pyc
pdf-stamp-frontend/dist

This was the point where the application's overall structure started becoming much clearer.

How I Reverse Engineered It

Step 1 — Running `strings`

I first started with:

strings PDF.exe

Very quickly, I noticed Python-related strings:

python313.dll
pyi-python-flag
...

This strongly suggested that the application had been packaged using PyInstaller.

Step 2 — Inspecting the PyInstaller Archive

Next, I used:

pyi-archive_viewer PDF.exe

This helped confirm that the executable had been packaged using PyInstaller and allowed me to inspect the internal archive structure.

Step 3 — Analyzing `.pyc` Files

I then used:

pycdc
pycdas

to inspect the extracted Python bytecode files.

However, when running pycdc, I noticed that some parts of the bytecode could not be fully reconstructed.

In many cases, the output stopped after displaying messages like:

Unsupported opcode: CALL_KW (247)
from fastapi import FastAPI, File, UploadFile, Form, HTTPException
...
# WARNING: Decompyle incomplete

Instead of fully recovering the original source code, I had to combine multiple fragmented clues together:

Partial pycdc output
pycdas disassembly output
Extracted strings
Module names
API route names
Library imports

I also used generative AI to help interpret and organize those fragmented technical details while reconstructing the application's architecture.

Even with incomplete reconstruction, I was still able to identify:

FastAPI routes
PDF processing logic
OpenCV-based blank-space detection
PyMuPDF page rendering
Automatic browser launching
Local API endpoints such as:

/api/scan
/api/stamp_and_merge
/api/shutdown

Step 4 — Investigating the Frontend

The frontend bundle was much harder to understand.

The built JavaScript looked like this:

var e=Object.create,t=Object.defineProperty,...

At first, it felt almost impossible to read.

The extracted JavaScript was difficult to understand, and I could not initially tell what kind of frontend structure had originally existed before packaging.

By combining:

The extracted dist/ directory structure
The bundled JavaScript files
API communication behavior observed in the browser developer tools
And explanations generated through conversations with AI

I gradually started to understand how the frontend had likely been packaged and bundled, and that the application was probably using a modern frontend workflow similar to React/Vite.

At the same time, I also realized that the original frontend source structure itself was no longer included inside the executable.

Reconstructing the Architecture

By combining clues from strings, embedded .pyc files, frontend assets, and API routes, I was eventually able to reconstruct a rough picture of the application's architecture:

PDF.exe
    ↓
Launch FastAPI server
    ↓
Open browser automatically
    ↓
Serve React frontend
    ↓
React sends API requests
    ↓
Python processes PDFs locally

The application was not rendering a desktop GUI directly.

Instead:

FastAPI served static frontend files
React rendered the UI inside the browser
Python handled backend processing

What fascinated me most was not simply discovering the architecture itself, but realizing how much of it could still be reconstructed purely from packaged artifacts.

What I Learned

Reverse Engineering Can Reveal More Than I Expected

Before starting this experiment, I assumed that most of an application's architecture would disappear once everything had been packaged into a standalone .exe.

However, I was surprised by how many clues still remained inside the executable:

Python runtime artifacts
PyInstaller structures
Embedded .pyc files
Frontend build outputs
API routes
Localhost references
Technology-specific strings

By connecting those small clues together step by step, I was able to reconstruct a surprisingly large portion of the application's overall architecture.

That process itself was one of the most exciting parts of the experience.

“Working Software” and “Understandable Software” Are Different Things

This experience also made me think deeply about AI-generated applications and software maintainability.

Generative AI can absolutely help create working applications quickly.
However, once only compiled artifacts remain, reconstructing the original design and development intent becomes much harder.

Even after reverse engineering the executable, I still could not fully reconstruct the original frontend source code or understand every implementation detail.

That limitation itself became an important lesson for me.

It reminded me that understanding software architecture and preserving maintainable source structures are just as important as making software work.

Especially in the age of AI-assisted development.

Final Thoughts

This reverse engineering journey was honestly a lot of fun.

What made the experience especially enjoyable was gradually reconstructing the application's architecture from small technical clues hidden inside the executable.

At the same time, the experience gave me a deeper appreciation for software architecture, maintainability, and the importance of preserving understandable source code alongside AI-generated applications.

Weekly Dev Log 2026-W06

Umitomo — Thu, 21 May 2026 01:25:54 +0000

🗓️ This Week

Made a little more progress in the SwiftUI tutorial🦾
Started the journey of building my future portfolio site✈️ First, I created the project files and set up a repository on GitHub. I also started reserching React Router v7 by reading its documentation. I'm moving forward little by little🔥
Completed the ContAInment room from the AI Security Learning Path on TryHackMe this week🤖

💡 Thoughts on the ContAInment Room

This room was a hands-on investigation exercise set in a scenario where a company had suffered a security breach, resulting in important data being encrypted and used for blackmail. The goal was to investigate the compromised environment and discover the hidden flags🔎

I felt that this room built nicely on the concepts I learned in the previous AI Forensics room. One thing I especially enjoyed was solving the investigation by using a dedicated AI assistant available inside the victim environment🤖

As I worked through the challenge, I had to think carefully about what looked suspicious and follow clues step by step while actively using Linux commands. It also turned out to be a great review of Linux operations and practical investigation workflows🔥

📱 iOS (SwiftUI)

Worked through the SwiftUI tutorial and completed Sections 7 and 8: "Create an Algorithm for Badges"

🌐 Web Development

Posted my weekly dev log on Dev.to 📝
Created a new React Router v7 project for my future portfolio site.

🔐 Security (TryHackMe)

Completed the ContAInment room (part of the AI Security Learning Path) on TryHackMe.

💡 Key Takeaways

📱 SwiftUI Learning

Section 8: Calculate and Show Streaks

Learned how to calculate a daily streak by comparing saved dates with the current day.
Understood how reversing the array helps process moments from newest to oldest.
Learned how map and compactMap can transform Moment objects into simple day offsets like [0, 1, 2].
Understood how Calendar.dateComponents calculates date differences in calendar-based units.
Learned that multiple moments on the same day should count as a single streak day.
Realized that the streak variable represents the next expected day offset during the calculation.
Learned that comparing daysAgo == streak is a simple way to detect consecutive days.
Understood why using the end of the current day makes streak calculations more stable and predictable.
Learned that @ViewBuilder is used to build conditional or multiple-view UI structures, while Group is mainly used to organize existing views or share modifiers without affecting layout.
Understood that VStack creates all child views immediately, whereas LazyVStack generates views only when they become visible on screen.
Realized that LazyVStack is more suitable for scrollable, data-driven UIs with many or heavy views because it improves memory efficiency and performance.

🌐 Web Development Learning

React Router v7 Framework Mode is similar to Remix, so my Remix experience will still be useful.
root.tsx, routes.ts, and route files work together to render each page.

🔐 TryHackMe Learning

ContAInment

Identified useful indicators from attacker notes and used them to recover encrypted files.
Practiced DFIR-style investigation by following clues across logs, archives, and extracted data.
Used AI-assisted forensic tools to analyze encoded flag candidates and identify the correct flag.
Improved my understanding of how AI systems themselves can become targets in modern cyberattacks.

🚀 Next Week

Complete the badge algorithm in the SwiftUI tutorial.
Continue posting small articles on Dev.to and start creating Web UI designs in Figma.
Continue working on the AI Security Learning Path.

🌈 Goals for This Year

📱 iOS (SwiftUI)

Build a solid foundation in SwiftUI and create at least one iOS app.

🌐 Web Development

Continue posting learning logs on Dev.to and eventually turn them into a portfolio site using React Router v7.

🔐 Security (TryHackMe)

Continue learning cybersecurity on TryHackMe.