Live and recent posts from across the Fediverse tagged #ππ²ππ²πΉπΌπ½πΊπ²π»π, aggregated by home.social.
AI Turned a Three-Hour Update Into Ten Minutes. Now What?
AI turned a three-hour project update into ten minutes. π
That's a huge improvement.
But look at what happens next. That's where the rest of the time goes.
If the draft waits for approval, gets checked by two people, and comes back because nobody agreed on the source data, those ten minutes can quietly turn into two days.
The task got faster. The workflow didn't.
That's why AI workflow automation needs to focus on the entire process, not just individual tasks.
4 Ways to Optimize Your AI Workflows
Here's where I'd start.
1. Establish a Single Source of Truth
Agree on where the numbers come from before anything is written.
When teams rely on conflicting spreadsheets, outdated reports, or disconnected systems, AI can't magically resolve every inconsistency.
Reliable project reporting starts with reliable data.
2. Define Human and AI Responsibilities
Let AI handle what it does well. Keep a person accountable for the decision.
AI can help draft updates, summarize information, and identify potential issues. People still need to validate critical outputs and take responsibility for decisions affecting budgets, schedules, and project outcomes.
Clear ownership prevents automation from becoming another layer of confusion.
3. Make Reviews Faster and Easier
Review shouldn't mean starting the work all over again.
Show the source behind each number, the assumptions behind each forecast, and clearly flag anything that needs attention.
When reviewers can quickly understand where information came from and what requires their judgment, they can focus on meaningful decisions instead of repetitive verification.
4. Eliminate Unnecessary Steps
Automation shouldn't simply make an inefficient process run faster.
Look at the existing workflow. Which approvals still serve a purpose? Which checks protect quality? Which steps exist only because the process has always worked that way?
Keep the steps that add value. Retire the ones that don't.
The goal isn't to automate every step. It's to build a better process.
Human Oversight Is Part of Good Automation
At FridayReport.ai, real people supervise the workflow.
Good supervision is focused: quick to check, easy to approve, and clear about who owns what.
That's an important distinction. Human oversight shouldn't recreate the administrative burden that AI was introduced to reduce.
Instead, it should make the process more reliable while allowing people to spend less time on routine work.
Measure the Entire Workflow, Not Just the Task
If you're bringing AI into your team, start with one workflow.
Follow it from the first input to the final decision.
Measure:
Then improve the process and measure it again.
A faster first draft is useful. A faster, more reliable workflow is better.
Where the Real Productivity Gains Happen
Use AI enthusiastically. Give people clear ownership. Redesign the work around what's now possible.
Don't stop when a task becomes faster. Look at everything that happens before and after it.
That's where the real hours come back.
Which step in your workflow would you retire first?#ai #automation #productivity #software #coding #development #engineering #inclusive #community
AI Turned a Three-Hour Update Into Ten Minutes. Now What?
https://noailist.org is heading toward 350 projects and 10,000 visitors. 5 more projects to reach 350! https://noailist.org
#NoAI #AntiAI #WithoutAI #NoSlop #NoLLM #NoGenai #games #software #development #gamedevelopment #books #authors #reading #writing #blogs #websites #nonprofit
1/ Install Visual Studio Code
2/ Install Python and get the path where python is installed
C:\Users\XXXXX\Python\pythoncore-3.15-64\python.exe
python --version
python path
3/ go to aistudio.google.com and use 300$ free credit. Create API Key
4/ Check the doumentation for api-key usage according to the requirement. In my case I am using Python. So, I refer the python code
5/ Create a workspace folder on your desktop and open using VS Code editor. Then open the terminal in the path using view --> Open terminal
6/ Create environment in the path for python using below command
python -m venv myEnv
7/ Activate virtual environment
cd .\myEnv\Scripts
.\Activate.ps1
if security error occur then
Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
once activated, it shows (yourenv) in greencolor
8/ From the command prompt go to the directory where Pythoncode is writted, same place install flask
pip install Flask
pip list --> will show if installed or not
pip install google-generativeai
9/ Now in the workspace folder create one more folder called templates
10/ In the templates folder create Welcome.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Venkatesh AI Chatbot</title>
<!-- Bootstrap CSS -->
<link href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css" rel="stylesheet">
<style>
body {
background-color: #f4f6f9;
}
.chat-container {
max-width: 900px;
margin: 30px auto;
}
.chat-header {
background: #8e95a0;
color: white;
padding: 15px;
border-radius: 10px 10px 0 0;
font-size: 24px;
font-weight: bold;
text-align: center;
}
.chat-window {
height: 500px;
overflow-y: auto;
background: white;
border: 1px solid #dee2e6;
padding: 15px;
}
.message {
margin-bottom: 12px;
padding: 10px 15px;
border-radius: 10px;
max-width: 80%;
word-wrap: break-word;
clear: both;
}
.user-message {
background-color: #d1e7dd;
float: right;
}
.bot-message {
background-color: #e9ecef;
float: left;
}
.input-section {
border: 1px solid #dee2e6;
border-top: none;
padding: 15px;
background: white;
border-radius: 0 0 10px 10px;
}
textarea {
resize: none;
}
.typing {
font-style: italic;
color: gray;
}
</style>
</head>
<body>
<div class="container chat-container">
<!-- Header -->
<div class="chat-header">
Venkatesh AI Chatbot
</div>
<!-- Chat Window -->
<div id="chatWindow" class="chat-window">
<div class="message bot-message">
Hello! How can I help you today?
</div>
<div style="clear:both;"></div>
</div>
<!-- Input Area -->
<div class="input-section">
<div class="row">
<div class="col-md-10">
<textarea
id="userInput"
class="form-control"
rows="3"
placeholder="Type your message here..."></textarea>
</div>
<div class="col-md-2 d-grid">
<button id="sendBtn" class="btn btn-primary">
Send
</button>
</div>
</div>
</div>
</div>
<!-- JQuery -->
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
<!-- Bootstrap JS -->
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.bundle.min.js"></script>
<script>
function appendMessage(message, type)
{
let cssClass = (type === "user")
? "user-message"
: "bot-message";
$("#chatWindow").append(`
<div class="message ${cssClass}">
${message}
</div>
<div style="clear:both;"></div>
`);
scrollToBottom();
}
function scrollToBottom()
{
$("#chatWindow").scrollTop(
$("#chatWindow")[0].scrollHeight
);
}
$("#sendBtn").on("click", function ()
{
sendMessage();
});
$("#userInput").on("keypress", function(e)
{
if(e.which === 13 && !e.shiftKey)
{
e.preventDefault();
sendMessage();
}
});
function sendMessage()
{
let userText = $("#userInput").val().trim();
if(userText === "")
return;
// Append User Message
appendMessage(userText, "user");
// Clear input
$("#userInput").val("");
// Show typing indicator
let typingId = "typing_" + Date.now();
$("#chatWindow").append(`
<div id="${typingId}" class="message bot-message typing">
AI is typing...
</div>
<div style="clear:both;"></div>
`);
scrollToBottom();
// AJAX POST Call
$.ajax({
//url: "http://127.0.0.1:5000/chat",
url: "/chat",
type: "POST",
contentType: "application/json",
data: JSON.stringify({
message: userText
}),
success: function(response)
{
$("#" + typingId).remove();
appendMessage(
response.response || "No response received",
"bot"
);
},
error: function(xhr)
{
$("#" + typingId).remove();
console.log(xhr.responseText);
appendMessage(
"Error: " + xhr.responseText,
"bot"
);
}
});
}
</script>
</body>
</html>
11/ In the workspace folder create Welcome.py
from flask import Flask, render_template, request, jsonify
import google.generativeai as genai
import os
# Replace with your actual Gemini API key
GOOGLE_API_KEY = "your_APIKe"
genai.configure(api_key=GOOGLE_API_KEY)
#for m in genai.list_models():
# print(m.name)
#model = genai.GenerativeModel("gemini-1.5-flash")
model = genai.GenerativeModel("gemini-3.5-flash-lite")
chat = model.start_chat(history=[])
app = Flask(__name__)
@app.route('/')
def index():
return render_template('Welcome.html')
@app.route('/chat', methods=['POST'])
def chat_response():
user_input = request.json.get('message')
if not user_input:
return jsonify({"error": "No message provided"}), 400
try:
response_raw = chat.send_message(user_input)
#print(response raw)
print("RAW:", response_raw)
response = response_raw.text
print("TEXT:", response)
return jsonify({"response": response})
except Exception as e:
print(f"Error: {e}")
return jsonify({"error": str(e)}), 500
if __name__ == '__main__':
app.run(debug=True)
12/ Dubug the output and open the chatbot in Chrome and test
All the best!!!!!!!!!!!!!!!!!!!!!!!!#ai #webdev #programming #javascript #software #coding #development #engineering #inclusive #community
Google AI Chatbot
AI-assisted development has changed the way many of us write software.
Today, a developer can use tools like ChatGPT, Claude, Cursor, Copilot, or autonomous coding agents to generate features, refactor code, debug issues, and even design parts of an application architecture.
The productivity gains are real.
But there is another side of this shift that I think deserves more attention:
We are producing code faster than we are producing understanding.
And over time, that can become a serious engineering problem.
The New Problem: Comprehension Debt
Traditional technical debt is familiar.
We make a fast implementation today, knowing that we may need to improve it later.
But AI-assisted development introduces something slightly different.
I think of it as comprehension debt.
This happens when a project evolves faster than the developer or team can fully understand the reasoning behind it.
For example, imagine this workflow:
βWhy was this implemented this way?β
At that moment, Git may tell you what changed.
But it may not tell you:
That context may exist somewhere inside chat history, issue trackers, notes, commits, or personal memory.
And that is exactly where things become difficult.
Our Development History Is Becoming Fragmented
Modern development already uses many tools.
A typical project might include:
Each tool contains a piece of the story.
But the complete development story is often missing.
A commit may say:
Fix payment flow
An issue may say:
Checkout occasionally fails.
An AI conversation may contain the real explanation:
The original implementation created a race condition when two asynchronous requests completed in a different order.
That reasoning is often more valuable than the commit message itself.
Yet months later, it may be extremely difficult to recover.
Git Tracks Code-Not Always Reasoning
Git is one of the most important tools in software engineering.
But Git was primarily designed to track changes in source code.
It answers questions like:
But increasingly, developers also need answers to questions like:
These questions become especially important when AI generates a significant portion of the code.
AI Agents Make This Problem Bigger
The more autonomous coding agents become, the more important development context becomes.
Imagine an agent that can:
All of that might happen during one interaction.
The amount of code produced can be enormous compared with traditional manual development.
But if we only preserve the final code, we lose the reasoning process that produced it.
That becomes dangerous when:
Development History May Become a First-Class Engineering Asset
I believe one important evolution in developer tooling will be the preservation of development reasoning, not just source code.
Imagine a project where you could see:
Requirement
β
Initial idea
β
AI discussion
β
First implementation
β
Problem discovered
β
Alternative considered
β
Architecture decision
β
Final fix
β
Lesson learned
That is much more useful than looking at isolated commits.
It creates something closer to institutional memory for software.
This Is Why Tools Like HindSite Are Interesting
I recently came across an early-stage project called HindSite that is exploring this problem.
The concept is interesting because it focuses on reconstructing the development journey from different traces such as:
Instead of only asking:
βWhat code changed?β
the idea is to help answer:
βWhat actually happened while we were building this?β
The workflow is centered around capturing development activity, reconstructing the timeline, reviewing important moments, reflecting on decisions, and eventually exporting useful knowledge.
It is still an early-stage concept, but I think the underlying problem is important regardless of which product ultimately solves it.
Why This Matters for Teams
This kind of development memory could be useful in several situations.
Developer onboarding
A new developer could understand not only the current architecture but also the decisions that created it.
Project handoffs
Freelancers and contractors could leave behind a much clearer explanation of what they built.
Debugging
Engineers could understand the sequence of decisions that introduced a difficult problem.
Architecture reviews
Teams could revisit old technical decisions with the original context still available.
AI oversight
Developers could better understand how much of a system was influenced by an AI agent and why certain recommendations were accepted.
Retrospectives
Instead of relying on memory, teams could analyze actual development events:
The Future Developer May Need Two Histories
For years, software teams have preserved one major history:
the history of the code.
In an AI-assisted world, we may also need:
the history of the reasoning.
The first tells us:
Here is what changed.
The second tells us:
Here is why it changed.
And increasingly, both may be necessary to maintain complex software responsibly.
A Question for Developers
As AI becomes more involved in your development workflow, how are you preserving the reasoning behind your code?
Do you rely on:
I am curious how other developers are dealing with this.
Because AI is making us faster.
The next challenge may be making sure we still understand what we are building.#ai #productivity #softwareengineering #software #coding #development #engineering #inclusive #community
AI Is Helping Us Build Faster-But Are We Still Understanding What We Build?πβπ¨
I keep my drafts as Markdown files with a short front matter block at the top. It holds the title, a one-line description that ends up as the meta description, and a few tags. When a piece is ready, the static site generator or the blogging platform reads those fields and builds the page from them.
The trouble is that front matter is the part I look at least. I spend hours on the body and about ten seconds on the block above it. So the mistakes pile up there: a title that grew while I was editing and is now far too long for a search result, a description I meant to write later, a tags line I left empty.
None of this is hard to fix. It's just easy to miss. So I wrote a short script that reads every draft in a folder and tells me what's missing or too long.
What it checks
I kept the rules deliberately small:
--- lines.title, description and tags are present and not empty.The two length limits are rough guides, not official numbers. Search engines cut titles and snippets by display width, not by a fixed character count, so treat them as a "probably too long" warning. Change them to whatever your platform or site uses.
A draft that passes looks like this:
---
title: How I name my draft files
description: A simple naming pattern that keeps a folder of drafts easy to search.
tags: [writing, workflow]
---
Body text starts here.
The script
It uses only the standard library, so there's nothing to install.
#!/usr/bin/env python3
"""Flag Markdown drafts with missing or overlong front matter fields."""
import sys
from pathlib import Path
REQUIRED = ["title", "description", "tags"]
MAX_TITLE = 60
MAX_DESCRIPTION = 155
def read_front_matter(text):
lines = text.splitlines()
if not lines or lines[0].strip() != "---":
return None
fields = {}
for line in lines[1:]:
if line.strip() == "---":
return fields
if ":" in line:
key, value = line.split(":", 1)
fields[key.strip()] = value.strip().strip('"').strip("'")
return None # no closing ---
def check(path):
problems =
[] fields = read_front_matter(path.read_text(encoding="utf-8"))
if fields is None:
return ["no front matter block"]
for key in REQUIRED:
if not fields.get(key):
problems.append(f"missing {key}")
title = fields.get("title", "")
if len(title) > MAX_TITLE:
problems.append(f"title is {len(title)} characters (max {MAX_TITLE})")
description = fields.get("description", "")
if len(description) > MAX_DESCRIPTION:
problems.append(
f"description is {len(description)} characters (max {MAX_DESCRIPTION})"
)
return problems
def main():
folder = Path(sys.argv[1] if len(sys.argv) > 1 else ".")
found = 0
for path in sorted(folder.rglob("*.md")):
for problem in check(path):
print(f"{path}: {problem}")
found += 1
sys.exit(1 if found else 0)
if __name__ == "__main__":
main()
read_front_matter returns None when there's no opening --- or no closing one, and a dictionary of fields otherwise. check turns that into a list of plain-language problems. main walks the folder recursively with rglob, prints one line per problem, and exits with status 1 if anything was found.
Running it
Save it as check_front_matter.py and point it at your drafts folder:
python3 check_front_matter.py drafts
With one good file, one file with a long title and no description, and one file without front matter, the output looks like this:
drafts/long-title.md: missing description
drafts/long-title.md: title is 83 characters (max 60)
drafts/no-front-matter.md: no front matter block
Each line starts with the file path, so in most editors' terminals you can click straight through to the file. When everything passes, it prints nothing and exits with 0.
Making it hard to forget
If your drafts live in a git repository, the exit code means you can run the check before every commit. Put this in .git/hooks/pre-commit and make it executable with chmod +x .git/hooks/pre-commit:
#!/bin/sh
python3 check_front_matter.py drafts
If the script finds a problem, git stops the commit and shows the list. When I really do want to commit a half-finished draft, git commit --no-verify skips the hook for that one commit.
I don't always want that level of strictness. On some projects I just run the script by hand before I move a file into the "ready" pile, and that's enough.
What it doesn't do
This is not a real YAML parser. It reads simple key: value lines, one per field. If you write tags as a block list:
tags:
- writing
- workflow
the script sees an empty tags: line and reports it as missing. If that's how you write front matter, either switch to the inline [writing, workflow] style or install PyYAML and use yaml.safe_load on the block instead of the loop.
It also can't tell whether a description is any good. It only knows that one exists and isn't too long. Writing a description that makes someone want to read the piece is still my job. The script just makes sure I don't publish without one.
That's the part I like about small checks like this. They take the boring, forgettable items off my mind, so the attention I have left goes to the writing itself.#python #markdown #writing #productivity #software #coding #development #engineering #inclusive #community
A small Python check for front matter in a folder of Markdown drafts
We just shipped our first Kotlin Multiplatform module in a real app. It's small β models, validation, and a bit of networking β but it's in production.
What I'd tell someone starting:
expect/actual everywhereThe biggest win was validation: one implementation, same behavior on both platforms, one place to fix bugs.
The biggest surprise was build times. They're noticeable, and they add up in CI.
Next step is sharing some state-management logic. I'm being cautious about that one β UI-adjacent code is where shared modules get messy.#kotlin #mobile #multiplatform #software #coding #development #engineering #inclusive #community
KMP on a real app: the first shared module
For years the main reason to add an FAQ section was the dropdown it could earn in Google results. That reason has gone. The page itself still matters, though, because AI assistants and AI search features pull short, direct answers from pages, and a well-built FAQ is one of the easiest things on a site for them to lift.
This post covers what changed at Google, what still makes an FAQ worth writing, and the HTML pattern we use so each answer stands on its own.
Disclosure: Appie.run publishes this post. The AI FAQ Generator and Website FAQ Generator mentioned below are our free tools. Everything else here works with any CMS and no tool at all.
What Google changed (as read on 26 Oct 2026)
From Google's Search Central updates and Search Console Help:
FAQPage markup can stay on your pages and causes no harm.llms.txt file isn't needed for Google Search.So: no more SERP dropdown, no penalty for leftover markup, and no special file required. What's left is the content.
Why an FAQ is still worth writing
Nobody outside the AI companies can tell you exactly how each assistant picks its sources, and we won't pretend to. What you can control is whether your answer is easy to find, easy to extract and correct when pulled out of context. A question-and-answer block does all three if you write it properly:
Those same properties help a human who lands on the page from a support link, so the work isn't wasted whichever way the traffic arrives.
Step 1: Collect real questions
Don't invent questions in a meeting. Pull them from places where customers already asked:
Group duplicates, then keep the 8 to 15 that come up most or block a purchase.
Step 2: Write answers that survive being quoted alone
A quick test for each answer: paste it into a blank doc with only the question above it. Does it still make sense?
Weak:
Yes, as mentioned above, it does, depending on your plan.
Better:
Yes. Team plans include SSO via SAML. The Starter plan does not.
Rules we follow:
Step 3: Use plain, semantic HTML
You don't need a plugin. Headings for questions and paragraphs for answers are enough, and they render the same for every crawler:
<section id="faq" aria-labelledby="faq-title">
<h2 id="faq-title">Frequently asked questions</h2>
<h3 id="faq-sso">Does the Starter plan include SSO?</h3>
<p>No. SSO via SAML is included on Team plans only. The Starter plan
uses email and password sign-in. <a href="/pricing">Compare plans</a>.</p>
<h3 id="faq-cancel">Can I cancel at any time?</h3>
<p>Yes. You can cancel from the Billing page, and your plan stays active
until the end of the current billing period.</p>
</section>
If you prefer collapsible answers, <details>/<summary> keeps the text in the HTML:
<details>
<summary>Can I cancel at any time?</summary>
<p>Yes. You can cancel from the Billing page, and your plan stays active
until the end of the current billing period.</p>
</details>
Avoid loading answers only via JavaScript after a click. If the text isn't in the served HTML, some crawlers will never see it.
Give each question an id so you can link straight to it from support replies and docs.
Step 4: Keep or add FAQPage markup (optional)
Google no longer shows FAQ rich results, and it says leftover markup does no harm. Other consumers of schema.org data may still read it, so if it's already there, keep it in sync with the visible text. If you add it, mirror the on-page wording exactly:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Can I cancel at any time?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. You can cancel from the Billing page, and your plan stays active until the end of the current billing period."
}
}
]
}
</script>
The risk with markup is drift: someone updates the visible answer and forgets the JSON. If your FAQ comes from a CMS field, generate both from the same source.
Step 5: Put the FAQ where the question is asked
One giant /faq page is fine as an index, but the most useful placement is next to the thing in question: pricing questions on the pricing page, setup questions in the docs. A short block of 4 to 6 questions per page tends to stay accurate because the owner of that page sees it.
Step 6: Review it on a schedule
Add a "last reviewed" date and put a recurring reminder on someone's calendar. Every price, limit and integration claim in the FAQ should be checked against the product at least each quarter.
Getting a first draft faster
If you have the source material but not the time, two of our free browser tools can produce a draft for you to edit (both run a captcha check first):
Treat the output as a draft. Check every answer against Step 2's rules before it goes live.
Checklist
Google sources: Search Central blog and Search Console Help pages on FAQ rich results and structured data, read 26 Oct 2026.
RG, Founder, Appie.run#seo #html #webdev #ai #software #coding #development #engineering #inclusive #community
How to Write a Website FAQ That AI Answers Can Quote (Now That Google's FAQ Rich Results Are Gone)
Half an hour of PUBG is enough to turn my Redmi into what feels like a different phone, so I stopped trusting my memory and started writing numbers down instead.
The routine is boring on purpose. The phone sits on a shelf for twenty minutes in a 26Β°C room. Case comes off, brightness locks at 50%, charging cable stays out, airplane mode goes on. After that I open the game and play the same Erangel route every single time β same landing spot, same rotation, same two firefights. Anything variable ruins the comparison, and a random hot drop will do exactly that.
Every 30 seconds I read three things. Battery temperature and the thermal status come from an adb command I keep in a plain text file, so I don't fumble with flags mid-match. I type it, glance at the output, go back to playing. Frame pacing I pull twice β at the five-minute mark and at the end β from the latency dump of the game's surface layer. I also hit the back panel with a cheap IR thermometer from 2 cm away, right above the camera bump, where the SoC actually sits.
The dump is what changed my mind. My frame counter happily reports 60 while the latency numbers say a fifth of frames missed their deadline. That gap is the whole reason I keep logging.#android #mobile #performance #software #coding #development #engineering #inclusive #community
My Fifteen-Minute Temperature and Frame-Rate Log on a Mid-Range Android
What I Built
π―οΈ Ghost Journal AI: The Hollow β Where AI Meets the Supernatural
What if a haunted diary could create its own mysteries, hide secrets in evidence, and answer your questions while trying not to reveal the truth?
I built Ghost Journal AI: The Hollow, an AI-powered supernatural mystery investigation game. Players enter a fictional scenario, and the AI creates a mystery with three suspects, evidence clues, hidden motives, and a chilling story.
Players can investigate the suspects, examine the evidence, question a haunted diary, and finally accuse the culprit to reveal the solution.
The application also saves completed investigations in a local journal, so each case becomes part of the player's history.
I interpreted "Ghost in the Machine" as a story in which an AI feels almost supernatural: a voice inside a machine that knows the secrets of a mystery and guides you through the darkness.
Demo
The application currently runs locally on my laptop using Streamlit and Ollama.
Demo: I am preparing a video demonstration of the application.
The demo will show mystery generation, suspect investigation, evidence review, interaction with the haunted diary, and the final accusation.
Code
GitHub repository: Ghost Journal AI: The Hollow
The project is built with Python and Streamlit, uses Ollama for local AI inference, and stores investigation history in SQLite.
Replace the example GitHub URL above with your actual public repository link before publishing.
How I Built It
I built the application using open-source tools and a locally running open-weight language model.
My technology stack includes:
Python β application logic and investigation flow.
Streamlit β the interactive web interface.
Ollama β running the AI model locally.
Llama 3.1 8B β generating mystery stories and powering the haunted diary chatbot.
SQLite β storing investigation history locally.
Requests β communicating with Ollama's local API.
When a player enters a scenario, the application asks the model to generate a structured mystery containing a title, opening scene, three suspects, evidence clues, a diary entry, a culprit, a solution, a twist, and an epilogue.
The player can then question the haunted diary. After the player submits an accusation, the application reveals the culprit and solution and saves the result in the investigation journal.
I tested the main workflow, including case generation, suspect and evidence display, diary responses, accusations, and journal history.
Why Does Open Innovation Matter?
Open innovation made it possible for me to experiment with an AI-powered storytelling experience without building the entire project around a paid, hosted AI API.
By using Ollama and an open-weight model locally, the core AI experience can run on my own machine. After the model has been downloaded, the application can generate stories without requiring a continuous connection to a remote AI service.
This approach also gives me flexibility. I can experiment with different models, adjust prompts, and improve the mystery-generation process without depending entirely on one provider's hosted API.
It also comes with trade-offs: local models require sufficient hardware resources, and AI-generated mysteries can still contain inconsistencies. Improving the logical connection between evidence and solutions is one of my next development goals.
For me, open innovation means being able to learn, experiment, and build something creative with tools that I can run and adapt myself.
My Agent Session
I developed and tested the application locally.
I do not have a DevRelay session link to share at this time.
The Spirit of It
The idea behind The Hollow is simple: what if the machine isn't just answering you, but telling you a story it doesn't want you to finish?
The haunted diary is the heart of the experience. It responds to questions, hints at hidden truths, and keeps the atmosphere alive while the player searches for the culprit.
I wanted to combine the creativity of AI storytelling with the feeling of investigating an old supernatural mystery, where every clue matters and every character might be hiding something.
The project is also an experiment in making local AI feel more personal, interactive, and a little unsettling.
Sometimes the scariest thing isn't a ghost in an old house. It's a voice inside a machine that knows more than it should. π―οΈ
My project explores open-weight AI and local inference through an interactive storytelling application.
Built with curiosity, open-source tools, and a haunted diary that refuses to stay silent.
hacktoberfest #hf26challenge #devchallenge #opensource #AI #Python #Streamlit #Ollama
#hf26challenge #devchallenge #godot #software #coding #development #engineering #inclusive #community
Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine
I added Goose and Amp to a tool that runs several coding agents. The most useful thing I learned wasn't about the protocol. It was the defaults.
Goose's default mode approves tool calls automatically. If you start it through a wrapper that doesn't set a mode, it runs commands without asking anyone. So I set the mode per process instead of relying on whatever is in the user's Goose config. Default, accept-edits and auto all use Goose's approval mode, so tool calls ask. Only the permission mode literally called bypass picks automatic approval, and none of it touches the user's own Goose configuration.
The second surprise was Goose's chat-only mode. It disables all tools, reads included. A plan mode you'd expect to still read your files doesn't, so mapping 'plan' to it means the agent can only talk.
Amp went the other way. Its streaming output has no documented way to answer an approval from outside, so approvals stay in its own terminal. Its plan and don't-ask modes reject every tool, reads included, and only bypass asks for automatic approval.
What I do with any new agent CLI now: before wiring up anything else, run it once in an empty directory and see what it does with a tool call by default. Two agents gave me two very different answers, and neither was in the first page of the docs.
Which of your agent CLIs would run a command without asking, if you started it the way you usually do? I'm building Styx, where this came from.#agents #ai #cli #tooling #software #coding #development #engineering #inclusive #community
Your coding agent CLI may approve its own tool calls by default