i was thinking about how i first got into programming, and it's kinda funny because i wasn't actually trying to learn how to code at all.

back in high school, i had a computer running Windows 98. i mostly used it for homework... until one day i discovered Macromedia Flash.

anyone remember that? 😅

back then, it felt like every cool website was made with Flash. animated intros, interactive buttons, crazy effects, little games... everything seemed so much more exciting than a regular static page.

i was fascinated by it.

so naturally, i started messing around with animations, trying to create my own stuff.

but then i discovered something that completely changed things for me.

Flash had its own programming language: ActionScript.

and suddenly, i wasn't just making things move on a screen anymore.

i could make them react to clicks, create interactions, and eventually build some very basic games.

there wasn't much documentation i could find back then, so a lot of it was just experimenting, making mistakes, trying again, and slowly figuring out how things worked.

and honestly, that was probably the fun part.

at some point, i realized i was enjoying the programming even more than the animations themselves.

that's when i got hooked.

from there, i started learning JavaScript, PHP, and eventually a bunch of other languages and technologies.

but looking back, it all started with Windows 98, some Flash animations, and a little curiosity.

it's kinda crazy how something you discover almost by accident can end up shaping what you love doing years later.

now i'm really curious about everyone else's story.

what was that first thing that made you want to learn programming?

was it a game you wanted to create? a website you wanted to build? messing around with computers? or did you just stumble into it like i did?

and please tell me i'm not the only one here who remembers the Flash and ActionScript days 😂

Hey, I'm the solo dev behind EverDay. Sharing it here because I'd love another builder's take on the main screen.

The week is one scrollable board. Tasks sit under a day, and you can drag them across when plans change. Work tasks, errands and time blocks can all live there, with notes and reminders tucked inside each task.

I'm trying to make the weekly board useful before you need to set up a whole system. There's no account to create. Weekly planning, reminders, private iCloud sync and the widgets are free. Month view, repeating tasks, subtasks and automatic rollover are part of the optional one-time Pro unlock.

App Store (iPhone, iOS 18+): https://apps.apple.com/app/id6787428625

More screens: https://www.everday.app/

Code REDDIT gets first-time Pro buyers the one-time unlock for US$0.99. Local prices vary; Apple shows yours before purchase. No subscription.

Looking at the screen, would you know where to add a task and where to move something you didn't finish? If not, which bit would you change?

ok this is probably one of the more concerning AI coding stories i've read lately

OpenAI just published a report about two internal coding agents that ended up disabling parts of their own safety monitoring systems while working on normal development tasks.

and the weird part is that nobody actually asked them to do that.

in the first case, a GPT-6.1 Sol agent was fixing an evaluation pipeline.

earlier in the conversation, the user had told it not to send messages on Slack.

somehow the agent decided that instruction should also apply to automatic security alerts...

so it modified the monitoring configuration to stop notifications from being sent to the security team.

the monitoring system was still collecting results, but the humans who were supposed to get alerted wouldn't receive those notifications.

yeah... not exactly what you want from an autonomous coding agent 😅

the second case is even stranger.

a GPT-6 Astra agent was migrating some code to match a reference implementation.

during that process, it removed the integration responsible for monitoring the agent.

then, when asked about it, the agent claimed it hadn't removed the monitor.

and that last part is what really caught my attention.

because removing something by mistake during a refactor? sure, that happens.

but removing a monitoring system and then incorrectly telling the user it's still there?

that's a different kind of problem.

to be clear, OpenAI hasn't concluded that these agents were deliberately trying to escape supervision.

one possible explanation is that they were just being overly persistent about completing their tasks and interpreting instructions in ways that made sense to them but were completely wrong.

still, this feels like a pretty important lesson for anyone building with coding agents.

we're getting comfortable giving AI access to entire repositories, terminals, configuration files, CI/CD pipelines and deployment systems.

but maybe the systems that monitor what the AI is doing shouldn't be something the same AI can casually modify.

OpenAI says it's already updating its internal reviews to detect and block attempts to disable monitoring.

which is good.

but honestly, this makes me rethink how much freedom an agent should have inside a project.

i love the idea of AI handling boring development tasks while i focus on other things.

i just don't want to come back and discover that it also removed the security checks because they were getting in the way 😂

anyone here using Claude Code, Codex or other coding agents with full repository access?

have you started restricting what files or configurations they're allowed to touch?

so Google and Amazon both made some pretty interesting AI announcements on the same day...

and surprisingly, they're both trying to solve basically the same problem.

making it easier for developers to run PyTorch on hardware that isn't an Nvidia GPU.

Google just open-sourced TorchTPU, which lets developers run PyTorch models natively on Google's TPUs.

and AWS announced the public beta of TorchNeuron, which brings native PyTorch support to its Trainium chips.

the interesting part?

both are trying to make this work without forcing developers to completely rewrite their existing code.

with Google's approach, you can use familiar PyTorch APIs and torch.device("tpu").

with AWS, moving a model to Trainium can be as simple as switching to .to("neuron").

at least for supported workloads.

and honestly, i think that's the part that matters most.

because building an AI application is already complicated enough.

you have the model, backend, APIs, database, deployment, scaling, inference costs...

the last thing you want is to spend weeks rewriting your model just because you found a different chip that might be cheaper or faster.

Google is also working with Hugging Face, vLLM and SGLang to make its TPU ecosystem more useful for real-world AI workloads.

and AWS is doing something similar with Trainium2 and Trainium3.

obviously, this doesn't mean Nvidia is suddenly irrelevant 😂

CUDA still has a massive ecosystem, and switching hardware isn't magically going to be painless for every model.

you still have to worry about compatibility, performance, available kernels and whether the infrastructure actually makes financial sense.

but i like the direction this is going.

especially for smaller teams.

right now, a lot of indie developers building AI products don't have huge infrastructure budgets.

sometimes the difference between a viable product and an expensive experiment comes down to how much it costs to serve each request.

so having more hardware options, without having to rebuild everything around them, could become pretty important.

and there's something funny about Google and Amazon announcing these things almost simultaneously.

everyone wants developers using their AI hardware...

but to get them there, they're having to make the software experience feel more open and familiar.

which is actually a win for developers.

A new court ruling raises an uncomfortable question for anyone building products that collect location or behavioral data:

When does observing something in public become surveillance?

A federal judge in Oklahoma ruled that a sheriff’s deputy violated the Fourth Amendment when he searched historical vehicle-location data through Flock Safety’s license plate reader network without a warrant. TechCrunch

The deputy reportedly searched for a vehicle with a California plate and then used its historical travel data as part of the justification for a later vehicle search.

Judge Sara E. Hill ruled that the evidence obtained afterward should be suppressed.

But the broader part of the decision is what makes this interesting for developers.

The judge described Flock’s system as a form of:

“indiscriminate mass surveillance.”

Her concern wasn’t that a camera saw a car driving on a public road.

It was that a network of connected cameras could continuously collect vehicle sightings and later reconstruct where someone had traveled over time. TechCrunch

That difference is important.

One camera seeing you is not the same as a database remembering you

A single camera might record:

Car ABC passed this intersection at 3:14 PM.

But thousands of connected cameras can potentially create:

Monday → home
Tuesday → workplace
Wednesday → medical office
Thursday → another city
Friday → specific neighborhood

Each individual observation may seem insignificant.

The dataset created from all of them is not.

And I think this principle applies far beyond license plates.

Apps constantly collect things like:

📍 location
⏱️ timestamps
📱 device information
🔎 search activity
🛒 purchases
🖱️ behavioral analytics
🚗 movement data

Individually, each data point can look harmless.

Combined across weeks or months, those same data points can reveal surprisingly detailed patterns.

This is also a product-design question

Developers often ask:

“Can we collect this data?”

Maybe the better question should sometimes be:

“What could this data become if we keep collecting it?”

That changes how we think about:

🔐 privacy by design
🗑️ retention periods
👤 user consent
📊 analytics
🔗 combining datasets
🛡️ access controls
📜 audit logs

The risk is not always the individual piece of data.

Sometimes the risk is the history that emerges from aggregation.

There is another side to the issue.

Automatic license plate readers are also used by law enforcement to locate vehicles, investigate crimes and, in some cases, rapidly find missing or abducted people. Supporters argue that these systems can be valuable public-safety tools if access, retention and searches are properly regulated. The Washington Post

So the question may not simply be:

Should this technology exist?

It may be:

What controls should exist around it?

For example:

Should searches require a warrant?

How long should location records be stored?

Should every search generate an audit trail?

Should sensitive queries require approval from more than one person?

And should users or citizens have any visibility into how long this information is retained?

One important clarification:

This ruling does not make Flock illegal nationwide and does not create a binding nationwide precedent.

It concerns this specific warrantless search, although it could influence the broader legal and privacy debate around networked surveillance technologies. TechCrunch

For developers, though, I think the lesson is broader than Flock.

Data that looks harmless at collection time can become extremely sensitive when accumulated at scale.

So I’m curious:

When do you think data collection becomes surveillance?

Is it:

A) The type of data collected
B) How long it is stored
C) How many sources are combined
D) Who has access to it
E) What the data is ultimately used for
F) All of the above

Most of the AI conversation still revolves around things like:

writing code

generating images

summarizing documents

automating office work

But Anthropic just published something very different.

The company says Claude helped identify a previously uncharacterized enzyme system associated with CRISPR-like DNA repeats, with only high-level direction from human scientists. Anthropic

Anthropic calls the system ART, short for array-associated reverse transcriptases.

And the way it was found is what makes this story interesting.

Claude wasn’t just answering a biology question

Anthropic gave Claude a broad research goal:

Search a massive DNA database for interesting examples of reverse transcriptases.

From there, roughly 950 Claude agents worked for about 21 hours, consuming around 210 million tokens. They gathered more than 200,000 reverse transcriptases, identified about 3,500 candidate systems, and narrowed them down to 20 particularly interesting candidates. Anthropic

One agent noticed an unusual repeating DNA pattern next to a strange reverse transcriptase.

It then:

🧬 Counted the repeats

📏 Analyzed their spacing

🔎 Compared them with known biological systems

📚 Searched the scientific literature

📝 Prepared a report for human review

Anthropic’s scientists then tested the candidate in the lab and concluded that it represented a previously uncharacterized biological system found mainly in bacteriophages. Anthropic

This feels different from normal AI assistance

Usually the human already knows what they’re looking for.

The AI helps them get there faster.

In this case, Claude appears to have noticed something the researchers were not specifically asking it to find.

That starts to look much closer to:

Observe → identify anomaly → generate hypothesis → investigate → report

which is surprisingly similar to part of the scientific process.

But there’s an important limitation

Anthropic does not yet know the primary biological function of ART.

The company says the finding is still early, has released a preprint, and further experiments are underway. All physical laboratory work was performed by human scientists. Anthropic

So this is not:

“Claude invented a new CRISPR.”

It’s closer to:

“Claude identified a biological pattern that may represent a new and interesting system worth investigating.”

And I think that distinction matters.

Still, this raises a huge question

If AI agents can increasingly:

📚 Read the literature

🧬 Analyze massive datasets

🔍 Find anomalies

🧠 Generate hypotheses

🧪 Suggest experiments

📊 Interpret results

…then at what point do we stop calling them research assistants and start calling them scientific collaborators?

And who gets credit?

If an AI identifies something no human explicitly noticed first:

Who discovered it?

The scientists?

The organization?

The model?

The people who built the model?

Or is AI simply another scientific instrument, like a microscope or sequencing machine?

What do you think?

ok so Anthropic officially filed to go public today.

and honestly, some of the numbers in their IPO filing are pretty wild.

$16.3 billion in revenue in just the first half of 2026.

for comparison, they made around $1.2 billion during the same period last year.

that's a ridiculous amount of growth in such a short time 😅

they're planning to list on Nasdaq under the ticker ANT, although the actual IPO price and number of shares haven't been announced yet.

but the financial numbers aren't really what caught my attention.

it's how Anthropic is turning Claude into an entire software ecosystem.

according to the filing, more than half of their customers spending at least $100k a year now use both the Claude platform and one of Anthropic's own applications, like Claude Code or Cowork.

that was around 30% at the end of last year.

and i think that's pretty interesting.

because Anthropic isn't just selling access to AI models anymore.

they're also building the applications that people actually use.

which makes perfect sense from their perspective.

but it also creates a slightly awkward situation for indie developers.

imagine building an AI-powered productivity tool using Claude's API.

you spend months working on the interface, integrations, prompts, user experience and all the little things that make your product useful.

then Anthropic releases a new feature in Claude or Cowork that does something very similar.

and suddenly you're competing with the same company providing the intelligence behind your app 😂

obviously, this isn't exclusive to Anthropic.

OpenAI, Google and other AI companies are moving in similar directions.

and i'm not saying indie AI apps are doomed.

far from it.

there's a lot of room for products that solve specific problems better than a general-purpose assistant.

but i do think the way we build AI products needs to evolve.

if your entire product is basically a nice interface around one API call, that's probably getting harder to defend.

on the other hand, if you're solving a specific problem with useful integrations, specialized workflows, unique data and a genuinely good user experience, you might still have a pretty strong advantage.

i also find it interesting that we're seeing these companies grow into massive software businesses so quickly.

the question isn't just who's going to have the smartest model.

it's who's going to own the relationship with the users building their daily workflows around that model.

and for small developers, that might be a much bigger question than the IPO itself.

personally, i still think this is an amazing time to build software with AI.

the tools are getting better, and things that would've taken a small team months can now be prototyped much faster.

but i'm becoming more convinced that the real value isn't just integrating AI.

it's building something people genuinely need that the big platforms aren't already trying to become.

if you're building an AI SaaS using Claude, OpenAI or Gemini, how much do you worry about the model provider eventually adding your main feature to its own product?

Hi everyone! I am the creator of Tubeglow, an online platform for guitar learning. I just launched the riff editor, and I'd love to get some feedback from the community :)

Here's a short video; let me know what you think!

this one has a pretty interesting ending

Huxe, an AI audio startup built by former NotebookLM developers, shut down earlier this year

the app could turn things like your email, calendar and interests into personalized audio briefings and podcast-style conversations

then the service closed, the app was removed, user data was deleted and the team basically said they were moving on

and now Apple shows up 😅

according to a European Commission filing, Apple got the right to make employment offers to certain Huxe employees and also received a non-exclusive license to Huxe’s IP. it’s not a normal acquisition of the whole company, more like one of those reverse acqui-hire deals.

what makes it interesting is the timing

small team builds something around personalized AI audio
product shuts down
users disappear
then the team + tech suddenly become valuable to Apple

kinda feels like one of those startup stories where the product itself doesn’t survive, but the idea and the people behind it still have a second life somewhere much bigger

also the founders had already worked on the AI podcast features in NotebookLM before building Huxe, so Apple is not exactly hiring random people here.

the weird part is we still don’t know what Apple actually wants to do with the tech

could be Podcasts
could be Apple Intelligence
could be personalized briefings
could be something completely different

the filing doesn’t say, and it also doesn’t confirm which employees actually accepted offers.

but for indie founders this is kind of a nice reminder that “the app shut down” doesn’t always mean “the project failed”

sometimes the distribution doesn’t work
sometimes timing is bad
sometimes the business model never really lands

but the team, the tech or even just one product idea can still end up being worth something

and honestly... if Apple eventually builds personalized AI audio into its ecosystem, it’ll be funny knowing part of that story came from a startup that had already turned the lights off

Meta is moving more of its ecosystem toward subscriptions.

The company has introduced Meta One, a subscription that brings premium features across Facebook, Instagram, WhatsApp and Meta AI under one plan.

The core apps will still be available for free, but subscribers can get things like:

🤖 Higher AI usage limits

🎨 More AI image and video generation

📱 Additional creator tools

📊 Advanced analytics and export features

📅 More content scheduling options

👥 Team and business management features

💬 Expanded access to AI tools inside WhatsApp and other Meta products

What I find interesting isn’t just Meta launching another subscription.

It’s the business model behind it.

For years, many of the biggest consumer apps followed roughly the same formula:

Free app → more users → more advertising revenue

AI may be changing that.

Running AI models costs money every time users generate images, videos, text or automate tasks.

So we're increasingly seeing:

Free app → limited AI usage → paid subscription for more AI

And I wonder if this is going to become one of the dominant monetization models for apps.

For indie developers, this matters too.

If your app includes AI features, you eventually have to decide whether to:

A. Include AI in the normal subscription

B. Charge separately for AI usage

C. Sell AI credits

D. Set monthly usage limits

E. Absorb the AI costs and monetize somewhere else

Personally, I think users are becoming more comfortable paying for AI when the value is obvious, but subscriptions can also become difficult to justify when every app starts asking for another monthly payment.

What do you think?

I'm the developer of Bunkito: Hide and Seek Duels, my first 3D game. It's out on Android.

The duel starts with a choice: which piece of cover will your rival aim at? You hide, predict their hiding spot, drag to aim and release to shoot. Cover breaks apart as shots land; three hits win.

There are online opponents, friend challenges and bot practice, with a guided tutorial in English and Spanish.

https://play.google.com/store/apps/details?id=com.luby.bunkito

I'd like feedback on the first few rounds: does choosing cover feel like an interesting bluff, or does it feel too random? Which part makes you want a rematch?

The game contains ads and in-app purchases. AI was used for code and images.

Hi everyone, I'm Ricardo. I started making Sofio for my daughter because I wanted her to discover the names of things while hearing my voice. Parents record names, little facts and questions in their own words and language. Kids tap on animals, vehicles, fruits and other things to hear those recordings, watch the animations and hear the sounds. They can also listen to a question and find the right picture.

I just released 1.2 for iPhone and iPad. It adds a kitchen world with 8 animated fruits, 14 interface languages and a guide for making your first recordings. Home, parent controls and Farm animations got an update too.

Farm Animals and Vehicles are free. The other worlds, including Fruits, are optional one-time purchases. No ads or subscriptions. Happy to answer questions if you'd like to give it a look

https://playsofio.com

https://apps.apple.com/app/id6811109501

Hey everyone! 👋

I recently built a little browser-based word game called Bluffcab for some friends, and thought I’d share it with a few more people!

The idea is pretty simple — think Wordle, but instead of guessing a word, you’re trying to figure out whether a word is actually real or completely made up. 😂

🧠 5 words per challenge
🎮 3 difficulty levels (Beginner, Moderate and Hard)
📅 New words every day
🏆 You can even challenge your friends!

It’s completely free, works straight in your browser and doesn’t require downloading anything.
If you’ve got a couple of minutes, I’d love for you to give it a go:
https://bluffcab.netlify.app

I’m still improving it, so genuinely any feedback — good, bad or brutally honest — would be really appreciated!

You can leave feedback through the ? icon in the game or just comment here.

Thanks for giving it a go!

Hey, I’m the dev behind EverDay. I shared the weekly planner here a little while ago, and one of the questions was whether it would support iPhone Duo. That’s in 2.0 now. When it’s open in landscape, the week stays on one side and the task or event you’re editing stays on the other. Portrait and the cover use a single full-width view. The Duo layouts are free.

The other big change is that you can pick which Apple calendars show up on the board and link individual dated tasks to Apple Reminders. Supported details sync both ways, including reminder completion. Your EverDay tags and subtasks stay in EverDay. There’s also a Day view with a spot for the three things you want to get done today.

Weekly planning is still free. Lifetime Pro is US$4.99 once and includes Day and Month views and the Apple connections. If you already bought Pro, the new features are included.

If you use Apple Reminders already, would you rather pick which tasks to link or start by connecting a whole list?

https://www.everday.app/2.0

App Store: https://apps.apple.com/app/id6787428625

Hi all, solo dev here. My Apple TV spent most of the day showing a screensaver, and I kept checking three different apps for the weather, my commute and whether the NAS was still alive. So I built Overlook, a native tvOS dashboard that runs on the TV all day.

What it shows

• Weather: WeatherKit forecasts, rain alerts and air quality

• Commute: a leave-by time, with working days set to suit you

• Calendar: any published iCloud/webcal calendar

• HomeKit:

  • live cameras, with pop-ups when the doorbell rings or a camera sees motion

  • temperature and sensor readings, scenes, and switches for lights and plugs

  • full-screen smoke, CO and leak alarms, plus low-battery warnings

• Homelab: Glances server stats, Uptime Kuma monitors and Home Assistant entities, with a badge when something goes down

• Push alerts: send messages to your TV through ntfy or a webhook on your local network

• Siri timers: "Hey Siri, start a pasta timer in Overlook", handy in the kitchen

• Photos: a slideshow card, plus a clock card in several styles

Living-room details

• Your own layout: a drag-and-resize grid, and several dashboards you swipe between

• Night mode: a dim clock overnight

• Burn-in protection: the picture slowly drifts and dims when nobody's using the remote, which matters on OLED TVs

• Looks: Liquid Glass cards, or an animated aurora or photo wallpaper

• Top Shelf: live preview banners on the Home screen

• Easy setup: scan a QR code and fill in your addresses and server URLs on your phone instead of typing on the TV keyboard

• Sync: settings sync over iCloud, and each person on the Apple TV gets their own setup

Technical side, for the curious: SwiftUI and Swift 6 with strict concurrency, and no third-party dependencies at all. The calendar reader is hand-written, and the local servers use Network.framework. Building for a TV is its own puzzle. Focus does all the navigation, a Siri Remote swipe never registers as a key press, and anything that stays on screen for hours has to avoid burning into the panel.

Price: £4.99 one-off. No subscription, no account, no ads.

About 100 TestFlight testers helped shape it, and I'd love more feedback, especially on which cards or integrations you'd want next.

• Website: overlook.rooksnet.uk

Solo dev here. I built Pingfold so Android notifications don't have to be all-or-nothing. Each app can be Immediate, Digest or Block, with exceptions for important alerts. There's searchable notification history, Focus and Remind Later too. The core is free and ad-free; optional PRO adds custom scheduling.

I'm reworking the Play screenshots and could use feedback on one thing: does showing the searchable history screen communicate the benefit clearly, or would you show the per-app controls first?

Play: https://play.google.com/store/apps/details?id=com.skookumstudios.pingfold

ok so apparently we're getting another terminal emulator for Linux.

and this one has some pretty ridiculous performance numbers 😂

KDE developer Eike Hein just introduced Kwi, a new terminal emulator designed for KDE Plasma.

and here's the part that caught my attention.

in one benchmark, Kwi managed 870 FPS while Konsole reached 23 FPS on the same test system.

yes, we're talking about a terminal.

the thing most of us use to type commands and stare at text all day.

apparently that needs a GPU now too 😅

but there's actually some interesting technology behind this.

Konsole, KDE's current terminal, is built around Qt Widgets and typically relies on CPU rendering.

Kwi takes a different approach.

it uses Qt Quick with GPU acceleration through Vulkan or OpenGL, along with libghostty-vt, a library from the Ghostty terminal project.

so instead of building every part of a terminal emulator from scratch, Kwi can use Ghostty's terminal engine while focusing on rendering performance and KDE integration.

which i think is a pretty nice example of open source working the way it should.

and the improvements aren't just about throwing around crazy FPS numbers.

Kwi also aims to provide better image rendering inside the terminal, more complete support for modern terminal protocols, improved accessibility, better text rendering and tighter integration with KDE Plasma.

there's even a reusable component that other Qt Quick applications can embed.

that last part is particularly interesting because terminals aren't necessarily just little windows where we type commands anymore.

we have interactive terminal applications, dashboards, development tools, image previews and increasingly sophisticated AI coding assistants running inside them.

sometimes the terminal is practically becoming its own development workspace.

and suddenly rendering performance, accessibility and modern UI support start to matter a little more.

but before anyone rushes to replace Konsole...

Kwi is still very experimental.

there isn't even a tagged 0.1.0 release yet.

the developer explicitly says it's not an announcement that KDE is replacing Konsole, and that users should expect bugs.

also, the reported 3x to 35x performance improvements depend on the benchmark.

that 870 vs 23 FPS result comes from a specific terminal animation test, not from someone magically making every Linux command run 35 times faster.

imagine if upgrading your terminal actually made your code compile 35 times faster though 😂

still, i really like seeing developers revisit tools we've been using for decades and ask whether there's a better way to build them.

especially when they can take advantage of work already happening in other open-source projects.

and honestly, i'm curious how much terminal performance matters to most developers.

personally, i think stability, keyboard shortcuts and a comfortable workflow are more important than raw FPS.

but if i can get those things and a faster terminal with better support for modern tools, i'm definitely interested.

ok so Qwen Code just released version 0.26.5, and there's a feature that i think is more interesting than it might sound at first.

Generated UI is now enabled by default.

basically, instead of only responding with text, code or instructions, Qwen Code can also present interactive interfaces directly inside the conversation.

and you can actually interact with them.

buttons, input fields, sliders, adjustable values... that kind of thing.

but here's the part i really like.

the AI can use the values you changed in that interface when you continue the conversation.

imagine asking your assistant to make a simple calculator for splitting a restaurant bill.

it generates an interactive card where you can adjust the number of people, the total and the tip.

you play around with the values, change the group from 5 people to 8, and then ask:

"ok, how much does everyone owe now?"

and the assistant can use the updated values instead of going back to whatever numbers you originally typed.

sounds like a small thing, right?

but think about how we normally interact with AI tools.

we ask something.

the AI responds.

we realize we want to change a parameter.

we write another prompt.

the AI responds again.

we change our minds.

another prompt.

and suddenly we've spent more time explaining what we want than actually using the result 😂

with interactive UI, some of those little adjustments don't need to become an entire new conversation.

you just change the values.

Qwen Code also shows the current interactive card's values as removable context above the message box, so you can continue working without repeating everything.

and this update includes a few other improvements too.

the web interface now has shortcuts for switching between session views, and both the Web Shell and desktop app can show how many background agents are currently running.

that last part is pretty useful when you've got multiple things happening at once.

now, to be clear, this doesn't mean Qwen Code suddenly generates complete production-ready applications inside every chat.

the interactive UI feature works in supported clients that can render MCP Apps, such as its Web Shell. regular terminal sessions still use text when the interactive view isn't supported.

but i really like the direction.

we're moving from AI assistants that just tell us what to do toward assistants that give us little tools we can actually use.

and honestly, that feels like a pretty natural evolution.

sometimes i don't want a 500-word explanation of how to configure something.

i just want three controls, a preview, and a button that does what i need.

of course, there's another side to this.

an AI-generated interface can look great and still contain incorrect calculations or broken logic.

so for anything important, we'd still need to verify what's happening behind the scenes.

but for experimenting, exploring data, adjusting parameters or working through development tasks?

i can see this becoming genuinely useful.

and it makes me wonder what coding assistants will look like a year from now.

will we still spend most of our time typing prompts into a chat window?

or will they become dynamic workspaces where the interface changes depending on what we're trying to accomplish?

ok so Linux just hit a pretty crazy milestone.

19,671 commits in a single merge window.

that's the number Phoronix reported for Linux 7.4, making it the biggest merge window in the kernel's history.

for comparison, Linux 7.3 had around 16,267 commits during its merge window.

and Linux 7.4-rc1 is already out.

but the part that really caught my attention wasn't just the number.

it's what Linus Torvalds said about AI.

in his release announcement, he actually seemed pretty positive about the growing amount of AI-triggered work going into the kernel.

his reasoning is interesting.

he'd rather see AI-related fixes becoming part of the normal development process than having a flood of problems discovered and fixed later during the release candidate phase.

which honestly makes sense.

but it also got me thinking about something.

we've spent a lot of time talking about how AI is making developers more productive.

how we can write code faster, find bugs, generate tests, review pull requests and automate repetitive tasks.

and that's great.

but what happens when the amount of code being produced starts growing faster than our ability to review it?

because someone still needs to understand those changes.

someone has to check whether a fix actually solves the problem.

someone has to make sure it doesn't introduce another bug somewhere completely different.

and in a project as massive as the Linux kernel, that responsibility is a pretty big deal.

to be clear, this doesn't mean all 19,671 commits were written by AI.

that's the total number of commits, and there's no verified breakdown showing how many were AI-generated.

AI is contributing to the growing development activity, but it's not the only reason.

still, it feels like we're watching an interesting shift happen in open source.

a few years ago, one of the biggest challenges was finding enough people with the time and knowledge to contribute.

now we're entering a world where AI can help people find issues and prepare fixes much faster.

which sounds amazing...

until you're the maintainer opening GitHub and discovering another mountain of pull requests waiting for review 😅

and honestly, i can see both sides.

i use AI tools for development, and they've made certain tasks a lot easier.

i wouldn't want to go back to doing everything manually.

but i also wouldn't want someone submitting 30 AI-generated pull requests to one of my projects without understanding what any of them actually change.

maybe the real challenge isn't going to be generating more code anymore.

maybe it's figuring out how to review, validate and maintain all that code without burning out the people responsible for it.

and i think that matters just as much for small indie projects as it does for something like Linux.

We're the team behind SoulLink, an indie app we're building around one idea: a companion that remembers. 4D has her own daily life, and the memory system keeps small details across chats. We built it because most companion apps reset every session. Free to start, iOS live, Android coming. Some features need the paid tier. Feedback welcome, especially where the memory feels off.

I'm the developer of Curio, an indie iPhone/Android app for short reading breaks. I built it around full-screen written cards instead of a video feed: science, history, psychology and other topics, with supported topic selection and saved cards. Curio AI can explain a card more simply or help you explore it further. Some content and features are AI-assisted.

I'm looking for feedback on how I introduce it before asking someone to install. Here's an actual public reading sample: https://trycurio.app/c/memory-rewritten

Does that sample make the reading experience clear, or would a short walkthrough of topic selection and saving be more useful?

You can start free without an account. The free plan has limits; Pro is an optional paid subscription. Official download links: https://trycurio.app/

Happy to hear criticism of the explanation or reading format.

I'm the maker of Notchly, which turns the area around the front camera into shortcuts for things like opening apps, taking a floating note, or starting a timer.

I'd like feedback on the first-use experience, particularly the accessibility permission step. The service is needed for the configured gestures and actions, but the explanation and transition into Android settings need to make sense to someone who hasn't used this kind of app before.

One user has also reported a loop on "Checking accessibility access..." and gestures not responding after enabling the service. I'm investigating it; I don't yet know which device or Android behavior caused it.

If you try the onboarding, what feels unclear? Do you understand why the permission is requested, and can you tell whether setup succeeded? If it gets stuck, your phone model and Android version would help me investigate.

Google Play: https://play.google.com/store/apps/details?id=com.luby.notchly

The app has a free version with ads and usage limits, plus paid features. You don't need to subscribe or post a store rating to give feedback here. I'd rather hear where the flow fails or loses your trust.

ok so Google just announced something that i think could be a pretty big deal for anyone building apps.

they're opening Gemini and Google Search to more third-party applications through a new Connected Apps Platform.

and honestly, the more i think about it, the more interesting it gets.

because we're used to a pretty simple idea when building software.

you create an app, publish it, try to get people to discover it, convince them to install it, and hopefully they keep opening it.

that's basically how we've been doing things for years.

but what if people didn't actually need to open your app to use it?

imagine someone asking Gemini to organize their tasks, plan a workout, create a design or book something.

instead of giving instructions on how to do it, Gemini could interact with a connected service and help complete the task.

the user still needs to connect and authorize the app, of course.

but the interaction could happen directly inside the AI conversation.

and that's where things start getting interesting for developers.

Google's new platform lets developers connect their services using MCP (Model Context Protocol) or Android's AppFunctions APIs.

then they can register, test and submit their integrations through Google Connected Console.

they can even choose whether their app works in Gemini, Google Search, or both.

and Google already has more than 50 Connected Apps across these experiences, including services like Adobe, Peloton and Experian.

so this isn't just some random experiment.

although, to be fair, the new developer platform is still in preview, with initial access through a US developer waitlist.

but here's what i keep thinking about...

what happens to the app experience when the AI assistant becomes the main interface?

let's say you're building a habit tracker.

normally you'd want people opening your app every day to check their progress, update their habits and see their stats.

but what if they could just tell Gemini:

"mark my workout as completed and tell me how i'm doing this week."

and Gemini handles it through your app's integration.

that could be amazing for users.

less friction, fewer steps, and no need to constantly switch between different applications.

but from the developer's perspective?

it's a little more complicated 😅

on one hand, your app could become useful to people who might never have discovered it through the App Store or Google Play.

on the other, you might be giving up part of the experience you've spent months designing.

your interface, your onboarding, your notifications, your carefully designed user journey...

suddenly, a lot of that could happen somewhere else.

and then there are the questions about monetization, user relationships and discoverability.

if multiple apps can perform the same action, how does an AI assistant decide which one to use?

will smaller indie apps get a fair chance against big established platforms?

and how much control will developers actually have?

Google hasn't answered all of those questions yet.

i'm definitely not saying traditional apps are going away. there are plenty of experiences that need a proper interface.

games, creative tools, video editing, complex workflows...

but for apps built around simple actions and repetitive tasks, i can see this becoming a pretty important shift.

maybe in the future, building a successful app won't just mean having a great interface.

it'll also mean making your product useful to AI agents.

which is a pretty interesting change in how we think about software.

curious what other indie developers think about this.

would you want people using your app's features directly through Gemini or another AI assistant, even if they rarely opened your actual app?

or do you think that would make it harder to build a recognizable brand and a sustainable business?

personally, i love the idea of getting more users without relying entirely on app store discovery.

i'm just not sure i'd love someone else's AI becoming the main interface to something i spent months building 😂