Daiju HoshinoDaiju’s DeskGet in touch

Do You Have the Vibe?

A growing record of the tools I build for recurring problems at work, the constraints that shape them, and what the process teaches me about judgment.

A LinkedIn series with one permanent companion page 4 project stories published New work will be added after each post appears

Read Post 5 · The Observation PuzzleStart with Post 2 · The Scantron Story

【 The series 】

02

The Scantron Story

A tool disappears mid-semester, the data cannot leave the building, and the minimum trustworthy version turns out to be enough.

Read the storyPublished
03

What the Reader Became

Reading the marks was the easy part. The report was still being finished by hand in a spreadsheet.

Read the storyPublished
04

The Submission Chase

Three files per section, a form that does not record the section, and a tool built to stop rather than guess.

Read the storyPublished
05

The Observation Puzzle

Sixteen colleagues, 2,627,625 ways to group them, and one pair no arrangement can fix.

Read the storyPublished
+

The series will continue

Future entries will appear here after their LinkedIn posts are published.

Growing gradually

【 Published work 】

The series is still beginning. These are the four project stories I have published so far. Each one follows the same path from friction, through a constraint, to a tool I could test and use.

OMR 100 Reader

The outcome · A local tool that reads answer sheets, flags uncertain marks for review, and exports the data needed for individual student feedback.

The friction

Near the end of the semester I asked our IT department to keep the exam-scoring software running through finals. They declined, having found it was no longer supported. The first move was to ask. After that was refused, I still needed digital answer data to give students individualized exam reports, so I decided to build it.

The constraint

Student responses could not be uploaded to an outside service, which ruled out the convenient answers and GenAI alike. And reliable was not the whole requirement. I needed something I could audit myself, so that nothing went out as a grade until I had checked it. All I actually had to obtain was the digital answer data. That decided the shape of the tool before a single feature did.

What I built

An optical mark reader for a custom 100-question sheet, running entirely in the browser with Python compiled to run there rather than on anyone’s server. It registers each page from its four corners, adapts its threshold to the scan, and catches multiple marks. Before any grade goes out it flags blanks, double marks, and low-confidence reads, so a person reviews the doubtful ones first. A guided roster step at the front means every sheet arrives already carrying a name, and captured page images stay in the session rather than being stored.

What it taught me

I did not need a perfect replacement. I needed a local, testable, good enough one.

What it looks like · the working screens
Roster firstDownload a template, fill it in, upload it. Every sheet then arrives already carrying a name, an email and a student ID, so no names are typed in afterward.
The scan panelDrop in the stack, say how many questions to score, and let the first detected sheet stand in as the answer key. The page ledger confirms no sheet went missing.
Twenty-five pages, twelve secondsA score for every student, the review flags raised, and a crop of the handwritten name beside each row.
The auditEvery detected mark boxed in red, all four corner marks registered, and each answer editable. Nothing is exported until a person ticks Identity verified.
Percentage correct, point-biserial, pointsAll 100 items with how many got each one right and how well each item separated the class. Points allocated equally in one click, then the raw student data out as CSV.
The last step happens outside the app

Thanks to the CSV this app generates, I was able to build an individualized student report in Excel. One page per student, built from the export rather than typed in by hand, so every student gets back not just a score but the question-by-question picture of where they actually stand.

One page per studentEvery question with the student’s own answer beside the correct one, plus the chapter, the cognitive level and the learning objective it belongs to. The panel down the right marks in red where that student is weak.
Their own trajectoryThe same student across five unit exams, set against three earlier cohorts, and their scores by cognitive level over the same run.

From reading marks to reading the exam

The outcome · Individual reports now come directly from the reader, bringing scoring, item analysis, and student progress into one workflow.

The friction

The reader solved the scoring. It did not solve the reporting. I was still exporting a CSV, opening an Excel template I had built, updating several parts of it by hand, checking the result, and only then printing something a student could learn from. It worked. It also meant the job was spread across two tools and a stack of manual steps every single time I gave an exam.

What I built

The report moved inside. The same app that reads the marks now assembles the individualized report, so the path from a scanned answer sheet to the page a student holds never leaves one file. Each report carries the student’s answer against the key for all one hundred questions, the chapter, cognitive level and learning objective behind each one, and their standing by all three of those against the class. Twenty-four students, ninety-six pages, one click, padded so a two-sided run starts each student on a fresh sheet.

What it taught me

An emergency replacement, left alone long enough, turns into the thing you actually wanted.

The harder part

Getting here was not tidy. Versions broke things that had been working. Ideas that looked trivial turned out not to be. The work was less about writing the feature than about noticing, each time, which part of my own process I had never actually written down.

What it looks like · the report, generated in the app
One student, one page, straight out of the appEvery question with the student’s own answer beside the key, the chapter and learning objective behind it, their standing by category, where they rank in the section, and notes on the questions the class found hardest.
Where this exam sits in their yearThe student’s own line across three exams, set against this term’s class average and three earlier terms, then the same trajectory broken out by cognitive level. This is what the historical averages in the library are for.
Eleven assessments, two termsThe library holds every quiz and exam for a course across terms, so a student report can place this exam beside the ones that came before it.
Averages, options, one buttonThe library keeps the historical class averages that put a student’s score in the context of earlier semesters, and the checkbox row decides what appears on their report. One button then prints every student’s copy.

Grade Submission Checker

The outcome · Three required files per section, matched to the right section by the file name alone, with every uncertain case handed back to me instead of guessed.

The friction

Every term ends with three required files from every instructor, for every section they taught. Collecting them was never the hard part. Faculty submit through a form and everything lands in one place. Knowing who is still outstanding was the hard part. It meant opening the shared folder, filtering by a faculty name, finding a file, then clicking it to confirm which section it actually was, and starting again with the next name. I built an Excel workbook to cut the clicking down. It helped, and it had to be reformatted at the start of every term, so the workaround became its own small chore.

The constraint

The form does not record which section a file belongs to. The only clue is the file name, and file names are written by people, so the same submission arrives as Alvarez_BIOL_1406_86002_CAN.pdf one term and Alvarez-BIOL-1406-86002-CAN.pdf the next. There is a second trap underneath that one. Section numbers are not unique across the college, so a biology section and a humanities section can carry the same five digits. Matching on the number alone is safe only when the submitter is already on my roster.

What I built

The app takes the roster on one side and the form’s recording sheet on the other, then works through the file names. It reads the five digit section number, corroborates it against the course number in the same name, keeps the most recent version when a section is sent twice, and ignores everything before a date I set so last term’s rows never count toward this one. What comes out is the list I used to assemble by hand. Every instructor, every section still open, and which of the three files each one is missing, ready to copy straight into a reminder email.

What it taught me

The useful move was making it decide less, and making it say out loud where it stopped.

The harder part

Deciding when to offer nothing at all. When two of an instructor’s sections are equally close to the number in the file name, the app suggests neither. Two sections one digit apart are the easiest thing to mix up and the worst thing to get wrong, so a blank is safer than a confident answer. Everything it cannot place arrives with its reason written beside it, which is the part that actually saves the time.

What it looks like · a demonstration term, with invented faculty and sections
Three it would not guessOne instructor typed 86344 where the roster says 86334. One used a colleague’s section number. One sent three files carrying two different sections. The app names the reason in each case and suggests a section for the first two. The third is left blank, because two candidates were equally close.
Who still owes whatSorted so the longest outstanding list sits at the top, with the exact files missing from each section spelled out. This is the list that used to mean a folder, a filter and a great deal of clicking.
Every section, file by fileGreen where a file arrived, red where it has not, carrying the file name the instructor actually used. The notes column holds the resubmissions, the naming slips, and the matches the app wants me to check rather than trust.

Teaching Squares Scheduler

The outcome · Four instructors per Square, grouped so that each pair can actually attend the other’s class, with the one pair it cannot solve named on screen instead of quietly hidden.

The friction

Teaching Squares asks four instructors from four disciplines to visit each other’s classes across a semester. Nobody is evaluated, and the value is in watching someone teach a subject you do not teach. The obstacle is that all four of them are teaching. A colleague’s most interesting class meets at the hour you are standing in front of your own, and the only way to find out is to lay the schedules side by side. For a cohort of eight that is tedious. For a cohort of sixteen it stops being something a person should be doing at all.

The constraint

Observation is a two-way relationship, so a Square of four holds twelve separate questions. Whether A can visit B is a different question from whether B can visit A. Sixteen people divide into four Squares 2,627,625 ways, and a grouping that looks balanced on paper can still contain one person nobody in the Square is free to visit. Of those 2,627,625 arrangements, exactly 16 leave twenty-three of the twenty-four pairs workable in both directions. Nothing reaches twenty-four. A random arrangement averages under sixteen workable pairs.

What I built

It imports the college’s own schedule export, so nobody retypes a week. The import applies the rules that make a schedule readable. A cross-listed section appears once rather than twice. A dual credit high school section counts as teaching time that cannot be visited. A meeting with an incomplete time is reported rather than guessed at. Then it tests every ordered pair. A class is visitable for a given observer only when that observer is free for the whole class plus a transition buffer, so a fifteen minute walk across campus does not turn into a late arrival. Each Square that comes out of the search gets a weekly calendar image, color coded by person, with rooms, times and the possible observation weekdays printed underneath.

What it taught me

A search that reports what it could not solve is worth more than one that returns a tidy answer.

The harder part

Deciding what the app is allowed to settle on its own. The facilitator unchecks labs, clinicals and studios by hand, because judging what is worth observing belongs to a person, and an unchecked class still counts as busy time for the instructor who teaches it. In the run below, one direction out of forty-eight has no complete class visit. Nadine teaches calculus at the exact hour Dean teaches his only visitable class, because his studio section was withheld from observation. No arrangement of this cohort fixes it, and moving either of them breaks something else. The app names the pair and leaves the choice open. Every option it produces is a weekly possibility rather than an appointment, since exams and presentations stay with the instructor and the visit itself is confirmed by email.

What it looks like · a demonstration cohort, with invented faculty and sections
What the search returnedTwenty-three of the twenty-four pairs work in both directions, which is the ceiling for this cohort. The amber alert names the pair it could not solve, and each line below gives the exact weekdays a visit is possible in each direction.
What the cohort seesOne image per Square, color coded by person, carrying rooms, times and the possible observation weekdays. The pairing with no listed day appears here too, in red, rather than being left out of the picture.
The judgment stepLabs, clinicals and studios are unchecked by hand, because deciding what is worth observing is a person’s call. An unchecked class still counts as busy time for the instructor who teaches it, which is what keeps the arithmetic honest.

This page will grow with the series. I will add the next project only after its LinkedIn post is published, so the page remains a record of work readers can actually explore.

【 Where the tools come from 】

Every tool on this page started the same way. Something at work went wrong often enough that I stopped noticing it, and then one day I noticed it again. There should be an app for this. Most people have that thought and let it go.

Vibe coding means building software by describing what you want in ordinary language, testing what comes back, and improving it through feedback. The loop still runs through a person. It does not remove human judgment. It moves it, from typing syntax to defining the problem, checking the output, and deciding whether the result is trustworthy enough to hand to someone else.

I teach biology, and the loop I ask students to run is the same one. Isolate the confusion. Resist asking for the answer. Explain what you now understand. Try again. When I sit down to build a tool I am on the other side of that desk, running the same loop, and it works for the same reason. Progress belongs to whoever can say clearly what they are stuck on.

Two things keep this honest. The work has to be something I can explain in words, because no tool can follow a rule I cannot state. And the data has to stay where it belongs, which is why every tool below runs in the browser on the machine in front of me and uploads nothing.

There is a third thing I did not expect. Once you start building, the building itself creates work, and some of the tools on this page exist only because another one needed them first.

Build tools.
Protect judgment.
Improve systems.

【 The five questions before building an app 】

Before I build anything, I answer these five about the task. Most of the time the honest answer is that it does not need an app, and that is a useful result too. It is loaded with my own case below. Clear it and try one of yours.

00 The task
Showing Daiju's example

Your recommended action will appear here, based on your answers.

【 One more important thing to consider 】

Most people assume the opportunity to use AI is a function of how good AI gets. It is not. In this model, the opportunity appears where what you know about AI reaches into the part of your own work you can actually put into words, and that second part is usually much smaller than the work itself. Drag both sliders and watch which one moves the number.

EVERYTHING I DO

The percentages describe overlap in this diagram. They illustrate the idea; they do not measure your productivity or predict outcomes.

27
10
What each shape means
  • Everything I do
  • What I can clearly explain in words
  • My knowledge about AI, never a tidy shape
  • Hard to explain, hard to replace
  • The opportunity
The opportunity
0% of everything I do

Hard to explain
99% of everything I do

Being able to explain a task can make it easier to delegate or automate. Trust, context, and responsibility still matter. The hatched area is a reminder of the judgment that can be difficult to put into words.

This page will grow as new posts are published. If one of these problems looks like yours, the tools themselves matter less than the habit that produced them, which is noticing the friction you have already stopped noticing.

None of this replaces real software development, and none of it removes the need for someone to check the work. What it gives back is time, and the chance to spend it on the part of the job that actually needs a person.

Build tools.
Protect judgment.
Improve systems.