RJ OSORIO / DESIGN, MEDIA & ENGINEERING
I’m RJ. I design and build custom software for small businesses. If your day involves working around an app, copying between tools, or keeping the whole process in your head, we have somewhere useful to start.
A website, a native app, or the connections behind them. Built to fit the job.
Book a conversation with me Understand the machinery ↗HOW I WORK
My way into software is through media and design: what someone sees, hears, touches, and expects to happen next. I follow that through to the code, the data, and the connections that make it work.
Think of a forward-deployed engineer at the scale of your business. I work alongside you, make the thing, and stay close enough to notice where it falls short.
The handoff matters too. I want you to feel capable using what we build, explaining it to your team, and imagining what you could make next.
Bring a piece of your working day ↗FIELD NOTES
Five retrospective notes, with interface studies you can try. Written now to explain what the work taught me.
BEHIND THE WORK
A few thoughts on the work you do, and what we might build around it.
You remembered a detail. You asked the question that made the job go smoothly. You noticed something before it became their problem.
Over time, those small choices become the reason people come back.
A business begins to carry the character of the person behind it.
The steps you repeat. The mistakes you've learned to avoid. The moment you know a customer needs a conversation.
Then come the notes, the messages, the forms, and the work of keeping one tool in step with another.
You've found a way to make it work. It may still be asking a lot of you.
I'd like to see how that work happens. What do you check? What do you copy? Where do you stop and use your judgment?
We might begin with an application that brings a request and its context together, ready for you to review.
First we agree what good looks like. Then we try it on real examples, including the awkward ones.
Your customer might begin on the web. You might pick up the request on your Mac, then make a decision from your iPhone.
Those experiences can share the information they need. An application, an automation, or a connection to a tool you already use can each have a part.
We choose the pieces around how you actually work.
A regular customer asks for something outside your usual terms. That exception carries context a standard form may never have considered.
A useful tool can bring that request to you with the relevant details. We decide which situations follow a routine and which deserve a conversation.
Make the unusual case easy to notice, before it becomes a problem.
WORKING ALONGSIDE YOU
I'm RJ. I build applications and automation around the people who use them. As your forward-deployed engineer, I'd work alongside you: understand the problem, build the pieces, and help get them working in your day.
You can start with a problem you've been putting up with, or an idea you haven't had the time to pursue.
Book a conversation with me ↗ Explore Clouseau, CoreScribe, Alloy Bot & Daydream ↗PERCEPTION
MY PERSPECTIVE
Why this subscription? Why this workaround? Why does a simple task need so many steps?
A company being established doesn't tell you whether its next product belongs in your business. Neither does an influencer telling you to hurry.
I think a tool should be able to answer a simpler question: what does it help you do, and what does it ask of you in return?
Your time, your money, and your attention deserve an explanation.
Building these projects made the technology less abstract for me. A surprising result became something I could reproduce, inspect, and work on.
It also made the limits clearer. A convincing demonstration is one moment; handling an unfamiliar input, recovering from a failure, and working on a phone take further care.
Understanding grows by trying something specific and noticing what happens.
Let’s look inside AI together ↗A keyboard asks you to learn its combinations. A mouse asks for movement and precision. Every interface takes some share of your attention.
Sometimes speaking is easier. Sometimes touch is. Sometimes the familiar tool is exactly right. I want to understand the person and the task before choosing.
The work is the reason for the interface.
Some jobs need a model to interpret language or images. Others need a reliable rule, a calculation, or a well-designed form.
I want to choose each part for the job it actually does. Adding AI to a working routine is only worthwhile if the whole experience gets better. Sometimes the useful change is removing a step.
A straightforward solution is a good outcome.
A PLACE TO BEGIN
A task that takes too many steps. A tool you keep working around. An idea you've never had the chance to try. We can start there.
Let's talk about it ↗See where these questions have taken me ↗LET'S TALK
You don't need a technical brief. Tell me about the work, the part that gets in the way, or the thing you wish you could make.
“I enter this twice.” “Nobody knows where this lives.” “I have an idea, but I don't know how to make it.”
You can tell me in your own words. My first job is to understand what you're trying to do and why it matters to you.
You don't need to learn a new vocabulary to begin.
Where does the work arrive? What do you check? What do you know that isn't written down?
I'd work alongside you to understand the ordinary steps and the exceptions. Then we'd choose a useful starting point and agree what that first version needs to do.
Your experience helps decide what we build.
I'll build a version you can try against the work we discussed. We'll look at what feels natural, what gets in the way, and where it should stop and ask you.
We will try normal days and awkward ones: missing information, an interrupted connection, a correction after the work has started. Those examples help define the next change.
A first version gives us something concrete to improve.
We'll walk through how it works, what you can change, and what still needs care. We'll make ownership, access, and ongoing costs clear.
I want you to feel comfortable using what we've built—and more able to imagine what you could do next.
A useful system should leave you with more room to do your work.
YOUR FORWARD-DEPLOYED ENGINEER
I'd like to understand your business and see where I can be useful. A few sentences are enough to start.
We'll arrange a time by email.
Start with one job. These prompts turn your description into a short brief you can edit.
Nothing is sent or saved to a server.
Your email app opens a draft. You choose when to send it.
AI, IN PLAIN LANGUAGE
If AI can do so much, why does asking it to do your work sometimes lead nowhere? There are a few different things inside that promise. Let’s take them apart, with things you can actually try.
A LITTLE EXPERIMENT
Give our imaginary bakery a request. Add a connection, then permission. Notice what actually changes.
“Could you book 12 lunch boxes for tomorrow?”
It can draft, explain, or suggest a plan. This setup has no diary connection, so it cannot check tomorrow’s space.
These are authored replies and real rules running in this page, with fictional records. No AI service is called. In a real app, the model can misread a request; the application needs checks around its proposals.
A model can be useful before it can act. An application can do useful work once the right information, tools, and boundaries are in place.
Start with the model, or go straight to your question.
01 / THE MODEL
AI is a broad name for different kinds of systems. Here we’re exploring learned models, especially the language models behind chat apps. Start with one adjustable number, then follow the idea into words.
You already know the first step: open an app and type a question. Let’s lift the lid and see what sits underneath the chat window.
The model is the part trained on examples to do a job, such as generating text or recognizing patterns. The app wraps it in an interface and may connect it to files or tools. Those connections determine what it can reach. A model’s ability to explain a task and an application’s ability to carry it out are separate parts of the system.
You can start with one ordinary task. Ask what the app can access, try the result, and keep your own judgment involved.
Try lifting the lid.
Imagine estimating how long it takes to pack an order. This tiny model multiplies the number of items by a single adjustable number: minutes per item.
That number is a weight. Move it, then fit it to our made-up examples. Afterward, open the test order and add gift wrapping. The model only knows the item count; it has no input for that extra work. Training adjusts parameters like this to reduce prediction error across examples. A language model has many more, working together across layers. Individual weights are not neatly labeled facts or beliefs.
Using a trained model is called inference. An ordinary reply does not, by itself, retrain its weights.
Here, time = items × weight, with the starting offset fixed at zero. “Fit” calculates the least-squares weight from the three examples. A perfect fit to these simple examples does not promise accuracy on real orders. Google’s explanation of weights and linear regression ↗
Text is split into pieces called tokens. A piece can be a word, part of a word, punctuation, or whitespace. A tokenizer gives each piece a numerical ID.
Try the sentence about a microbakery. Notice how one word becomes several pieces. Different tokenizers can split the same text differently.
Tokens help determine how much text fits in the model’s working context, and can be a unit of usage or cost.
The model maps token IDs into learned lists of numbers called embeddings. An ID is a lookup label; a larger ID doesn’t mean a more important word. These examples were generated with OpenAI’s cl100k_base encoding. tiktoken ↗ · How tokenizers differ ↗
A reply takes shape a piece at a time. The model uses the conversation so far to work out possible next pieces, then a selection rule picks one. Watch how each choice changes what follows.
These pieces are called tokens. In this illustration, you make the choice yourself. The scores are made up to show the idea; no real bakery hours are being checked.
A convincing continuation can still be wrong. Confidence in the wording is not evidence that a claim is true.
An application can fetch information or run tools and supply the results as additional context. That can help, but the result still needs checking. The text-generation loop is one part of an AI application, not a description of every kind of AI. Language-generation strategies ↗
Change “big” to “small.” The words around “it” change how we interpret the sentence. Words need their surroundings.
Many language models use a design called a transformer. Its attention mechanism lets information from different parts of the input interact. Several layers build on those relationships. This helps the surrounding words matter.
Useful context matters. Tell a tool what the task is, what information it needs, and what a good result should contain.
The highlight illustrates context; it is not a trace from a real model. Attention uses learned calculations to mix information across token positions. An attention weight alone is not a complete explanation of a decision. Google Research’s introduction to the transformer ↗
An image can be represented as a grid of color values. Digitized sound can be represented by measurements of a signal over time. Tap the picture, then switch to the sound.
Models transform numerical inputs into representations they can work with. Some image systems use patches; some audio systems use time-frequency representations. The exact path depends on the model.
“It accepts a photo” is only a starting point. Ask what kind of images it handles, what it returns, and how you can check it.
This is a real 4 × 4 RGB grid and a made-up series of 12 sound samples. They illustrate digital representation, not a running vision or speech model. Image processing ↗ · Audio representations ↗
A chat subscription usually offers a ready-made application with access to a set of capabilities. An API lets software request model services. Running a model on your device is another arrangement, with its own requirements.
Compare the three. The useful questions are about the whole package: which capabilities, how much usage, what access to your information, and what happens when you reach a limit.
Pay for a useful result and a clear agreement. A model name on its own doesn’t tell you what you’re getting.
Check the provider’s current terms before buying. For example, ChatGPT subscriptions and OpenAI API usage have separate billing; paying for one does not include the other. OpenAI’s billing explanation ↗
AI is changing what a person or a small business can make. It also leaves room for confusing promises. You can be curious and deliberate at the same time.
Pick a question in the illustration. Bring it to a product demo, a subscription decision, or a conversation about your own application.
You don’t have to know everything. Name the work, supply the context, check the outcome, and keep the ability to correct it.
Try all four questions.
Read “we bake…” and a few words might come to mind. We can start with something simple: count which words follow “bake” in a small collection of sentences.
Two neighboring words make a bigram. Add another cake example and watch the balance change. Here, each estimate is a pair’s count divided by the total for that starting word.
The examples influence the prediction. They don’t guarantee what happens outside those examples.
This word-bigram model only looks one word back. Modern language models use much richer context and learned parameters. A bigram is also different from the pair-merging procedure used by some tokenizers. Jurafsky & Martin on n-gram models ↗
“Do we have any oat milk?” A model can write a reply, but checking your actual stock needs a connection to your records. Walk through how that connection works.
A tool call is a structured request to use a capability the application offers. The app checks the request and access, the tool does the lookup, and the model can use the returned information in its reply.
You can decide which records an application can read and which actions need your review. Try turning stock access off.
The example request could look like this:
{"name": "check_stock",
"arguments": {"item": "oat milk"}}The request itself does not execute anything. Application code handles execution and passes back a result or an error. OpenAI’s guide to function calling ↗
Imagine finding your invoice PDFs every week. A short set of instructions can do the same little routine each time. Try it with the made-up files here.
A Bash script is a text file of commands that Bash, a command interpreter, can run. An AI can help write those instructions. The computer running Bash carries them out.
You can ask for a routine in your own words. Have it explained and tested on copies before using it on your business files.
This example lists PDFs in a folder called invoices. It does not move or change them.
find ./invoices -maxdepth 1 \
-type f -name '*.pdf' -printA script can be called through an application’s shell tool. What it can do depends on its commands and that environment’s access. This page only simulates the routine. The GNU Bash manual ↗
Tell the app that your bakery closes at four today. It can include that note in the conversation. Start a new conversation and see whether the note is still available.
The model’s learned weights and the information supplied for this request are different things. An application may also save notes and bring them back later. Try allowing that in this little example.
Ask where a tool gets a fact: training, the current conversation, a saved note, or a connected source. Each has different limits.
Prompting normally uses existing model parameters. Saving a note in an app and retrieving it later changes what is supplied to the model. Fine-tuning is a separate process that updates model parameters.
Provider retention and training policies are another question, governed by the service and its settings. Google’s explanation of prompting and tuning ↗
Predicting the next piece sounds small. The machinery doing it is not: learned representations pass through layers that combine context and transform information.
A transformer is a model architecture. Attention helps combine information from different token positions. Other learned operations transform those representations, layer after layer, before the model produces scores for possible next pieces.
During training, many examples adjust the parameters. This can produce useful abilities across writing, code, and other tasks. Applying those abilities to a new request is not the same as looking up a verified answer.
The next-token mechanism explains how text is produced. It does not, on its own, tell you how capable or reliable a model is on your particular work.
In a common decoder-style transformer, token and position information enters a stack of blocks. Causal self-attention mixes information from available positions; a feed-forward network transforms each position’s representation. Residual connections and normalization help the stack operate.
The final representation is mapped to vocabulary scores, and a decoding rule selects the next token. Architectures vary. The original transformer paper ↗ · Google Research’s illustrated introduction ↗
A bakery assistant reads a refund request and proposes an amount. Should every refund wait for the owner? Set a small rule and try three cases.
The model proposes. The application compares that proposal with the order record and your limit. A routine match can qualify for automation; a mismatch or missing record needs attention. Those checks are ordinary software rules.
Delegation is a design choice. Decide what may happen automatically, what needs review, and what evidence you want to see afterward.
An amount match does not prove a refund is justified. A production system also needs identity and eligibility checks, protection against duplicate payments, a record of actions, and a way to handle exceptions. Test it on representative cases before allowing real transactions.
A model can make useful recommendations and perform well on some bounded tasks. That does not establish reliability for a different task, or give it authority to act in your business.
A LITTLE LESS MYSTERY. A LITTLE MORE SAY.
This is how I like to work: make the moving parts understandable, try something useful, and leave you with more confidence in your own decisions.
Talk it through with RJ ↗Explore the projects ↗An experience like this can be part of your own website or application, too.