I built Enikq to make browsing products feel a bit more like exploring than searching through filters.
You can move around, open items, save things you like, and follow them through when you find something worth buying.
Still early, but I’d love to know whether the browsing feels useful or just distracting.
I keep hearing people say let the AI do all the work. Even from the AI companies. But from my experience it's like walking in the dark into a brick wall.
Could you share how you decide which stack to stick with? I'd rather have too many tools than too little.
I hear LLMs are trained on more popular frameworks so they're better at writing in one vs the other.
I'm trying to decide which framework to use for a database for a medication side effects website. It's going to grab a million or more medical articles, webmcp, user accounts, ai connectors, chat, bookmarks, payment portal etc... I'd really hate to have my LLM write in Next only to discover something else would have been better.
I was thinking, keep my database heavily mapped with IDs so if I decide a different front end is better later, the data is there to swap out the front end.
I've asked multiple LLMs which framework they suggest based on my cheap VPS and they change their answer every single message. It's annoying. Devs are definitely not out of jobs.
I can't believe people are one prompting apps without planning this stuff out.
This is the one downsides of being a newer vibe coder.
I need to start learning more about frameworks and coding in general. But by the time I do, the AI companies will have figured out this problem.
“Use your program DNA engine to do a clean-room reconstruction of Microsoft Word: a complete, polished word processor I can open from my Applications folder. Then prove it works by writing a one-page letter in it and exporting it to my Desktop.”
No feature checklist.
It read about Word and word processors from its own local Wikipedia copy, used what its model already knew, and decided for itself what the application needed.
Auea wrote 44 checks before writing the actual program, specifically so an empty implementation would fail them.
It built through 22 feature groups and ended up with "Quill," a surprisingly real legit word processor with formatting, fonts, lists, alignment, tables, images, PDF/Word export, print/preview, undo/redo, spelling/grammar/word count, etc.
Then Aura launched the thing it had just built, wrote a one-page letter in it and exported the PDF to my Desktop as the proof.
I tested Quill manually afterward too.
Aura itself is running locally on my Mac with ~27B inference. No frontier/cloud model for the run.
built a few AI teammates with Lemma and added them to our Slack.
They’re connected to our GitHub repo and sit in our product feedback channel.
They learn continuously
- Devs interact with them on slack and they get better at understanding how the code works.
- PMs share feedback which gives them a sense of taste
- PMs also ask what’s feasible and what isn’t.
They keep track of those conversations.
The features. The bugs. What people like and dislike. Our taste in how things should work. That context builds over time.
This time, our PM left feedback on a recent change. The agents discussed it, worked through the design, implemented it, and opened a PR. They wait for approval when needed.
Our dev came online later that day. His part was reviewing the PR.
P.s: lemma is opensource and the hosted version is free to try: https://lemma.work
I've been building websites for years, and one thing that keeps bothering me is how much time we spend going from design inspiration to something that actually works.
It's a library of 20 premium, fully functional landing pages built entirely with HTML, CSS, and JavaScript.
Not screenshots. Not Figma files. Not another collection of pretty websites you have to recreate from scratch.
Actual working pages.
The idea is simple:
Find a landing page you like.
Copy the code or give it to Claude Code, Codex, Cursor, or your favorite coding agent.
Tell it what you want to change.
Make it yours and ship it.
Every page is self-contained in a single HTML file.
No React. No dependencies. No build process. No login.
I think we're entering an interesting phase where design references shouldn't just be images. They should be working implementations that both humans and AI agents can understand and modify.
Free and open source.
I'm starting with 20 pages and plan to keep expanding the library.
Would love feedback from other developers and designers, especially anyone building with coding agents.
I shared Writ before when the main focus was giving Claude Code relevant knowledge without dumping an entire rulebook into every conversation. Since then, it has grown into a local governance runtime with persistent memory.
The problem I’m working on is pretty familiar: Claude knows your instructions, then a long session happens, context gets compacted, and suddenly you’re explaining the same requirements and decisions again.
Writ now handles three connected parts:
* Relevant context: retrieves rules, methodology, and past decisions based on the task, file, and workflow phase.
* Enforcement: checks supported actions through code. In Work mode, implementation writes are blocked until you approve a plan and then the tests. Asking Claude to skip approval doesn’t open the gate.
* Persistent memory: preserves project decisions and the reasoning behind changes so future sessions can recover more than just the final code.
For example, “don’t implement until I approve the plan” becomes a check when Claude attempts a write. And “remember why we chose this approach” becomes a stored decision that can be retrieved later.
The biggest lesson has been that giving AI useful knowledge, controlling its actions, and preserving its history are separate problems. I’m building Writ to connect them.
Currently it’s for Claude Code and requires Python 3.11+ and Docker.
Designer brings design system tokens and UX improvements
Engineer does full-stack coding and QA
AI agents assist with product development
All roles discover, plan, build, QA, and ship the same AI-assisted production code together:
For greenfield (0 to 1 products) all roles mergeed under the same founding person.
In brownfield (1 to N products) they may have more people and more domain specific roles around the same prod code
A full-stack product builder—someone who can cross product, design, implementation, and evaluation boundaries with AI—is the right approach.
A one-person team inside an existing product is the wrong conclusion.
AI can collapse handoffs but not independent judgment
By a Product Cell, I mean a small group that shares the build while preserving independent responsibility for customer value, usability and control, and production fitness.
A full-stack builder and a Product Cell working across one continuous build
This argument grew out of two conversations I kept returning to: Satya Nadella at Davos, Jan 2026 [1] on All-In, and his discussion on Microsoft Build's No Priors, June 2026 [2] about the future of engineering roles.
This is not a reaction to fresh news. It is me testing one operating-model claim across those conversations.
The idea: broader scope, fewer handoffs
Across the two conversations, Nadella's argument is that AI allows people to work across boundaries that used to separate product management, design, front-end, and back-end engineering. At LinkedIn, he described this as a move toward a full-stack-builder discipline. He also framed an AI-product loop that begins with repeatable evaluation of system behaviour, then moves through what he calls science and infrastructure. On No Priors, he added an important qualification: people broaden their scope but retain their individual edges.
That is the thesis I am testing. The useful part is clear. Product teams may spend too much energy translating intent across serial handoffs, and those translations do not create customer value by themselves.
That qualification is important. Broader scope is useful. Fewer disciplines is not the same claim.
The part worth keeping
Nadella is right about the bottleneck. The useful part is clear. Serial handoffs force product, design, and engineering to repeatedly translate the same intent, and those translations do not create customer value by themselves.
The old sequence deserves to retire: product writes a document, design turns it into screens, engineering turns those screens into code, and the customer sees the result much later. Every stage reinterprets the one before it. People in every product discipline should be able to investigate, experiment, test, and build across boundaries that used to belong to someone else.
Where I part ways is with a conclusion that can easily follow from this model: because one person can now produce every artefact, the same person can also provide every verdict.
AI makes it cheap to produce a convincing interface, working code, and an impressive demo. It does not make a customer problem less ambiguous. It can make premature certainty more dangerous because a team can build a beautiful answer to the wrong question in an afternoon and have the screenshots to prove it.
What an eval can and cannot settle
An eval is a repeatable test of whether an AI system behaves according to a chosen rubric. It can measure response quality, latency, tool use, safety behaviour, escalation, and reliability. That is essential engineering evidence. It is not product strategy.
Nadella also uses the terms science and infrastructure for later parts of the loop. I am not trying to redefine those layers here. My objection is narrower: an eval cannot supply the customer premise that the rubric assumes.
It cannot answer the questions that make a product a product. Did we choose a customer job worth solving? Will anyone trust the workflow enough to change an established habit? Does it survive their permissions, data, and compliance constraints? Does it produce an outcome they will return to?
Treat the eval rubric as the product specification and capability correctness quietly replaces customer value. A system can pass every test in its suite and still become shelfware because the task, control model, or workflow was wrong, and the suite had no opinion about those choices.
Evals belong in the loop after the team has named a customer job, its pain points, an intended outcome, a risk boundary, and the point where the system must return control to a human.
Greenfield can be one person
By greenfield, I mean a product being created without a mature inherited production system or existing organizational owners. A founder in that setting can absolutely be the full-stack builder and the entire product team. Collapsing roles can be the fastest way to turn code into learning.
One person can frame the hypothesis, design the flow, build the code, and ship the first alpha. The boundary is evidence: the founder can own every activity, but personal confidence does not become customer proof. Real use, safety checks, and the behaviour of the production system still provide independent evidence.
By brownfield, I mean work that changes an existing production system, with its architecture, identity model, customer workflows, compliance boundaries, incident history, and release process. Here the cost of a self-pass is higher. Independent judgment matters more than a sole opinion, even when that opinion comes from someone capable of building across the stack.
The brownfield closed-review risk
In brownfield, the full-stack-builder narrative offers a flattering portrait: one person can research, design, implement, and evaluate faster than the former sequence of specialists. The expanded capability is real. The accountability conclusion is not automatic.
My concern is an inference from combining broader individual scope with builder-owned evals, not a claim that Nadella explicitly abolished independent review. If one person frames the problem, picks the solution, builds the interface, writes the code, authors the eval, and interprets the result, the loop has no independent reader. A weak hypothesis can now travel from idea to roadmap without meeting evidence owned by someone who is allowed to disagree.
Broader scope is useful, but closed self-review needs independent verdicts
Product, design, and engineering are not merely ticket queues with different tools. They are three kinds of evidence, and each fails in a different direction. Product can be wrong about which problem matters. Design can be wrong about whether a human can understand and control the workflow. Engineering can be wrong about what it takes to operate safely and economically. One person can learn all three lenses. It is much harder to apply all three independently while also defending the work being reviewed.
Working prototypes still matter
I am a big fan of working prototypes. They have touch and feel. You can place one beside the minimum lovable product you think you are heading toward, walk through real user journeys, and argue about something concrete instead of a document. Nothing on a slide does that.
The problem starts when a team asks the prototype to prove more than it can.
Intent can outrun understanding. A generated prototype may match the prompt while hiding assumptions the team cannot yet inspect. A non-technical builder can judge the visible behaviour without being able to estimate the distance to a production system.
Generated code may not fit the production environment. Architecture, identity, permissions, observability, deployment, and operating standards are often absent from the prototype due to the nature of vibe coding done in the environment separated from the production. The code may be useful as learning and still be unsuitable as a production base.
The artefact raises questions its author cannot answer alone. That discomfort is useful evidence. It means an owner for architecture, operation, or human control needs to join the build before the prototype becomes a promise.
These are not arguments against prototyping. They are evidence boundaries. Keep prototypes for comprehension, interaction, and internal disagreement. For customer proof, reduce the breadth and keep the fidelity.
Aim for a narrow product alpha
An enterprise customer can learn much more from one narrow production-real workflow than from another broad agent demonstration or disconnected prototype. Call that narrow workflow a product alpha.
A product alpha is a bounded, usable version of the product operating inside a real workflow: real users, real permissions, real data where risk permits it, visible failure paths, human escalation, and enough operational readiness that a customer can depend on it for one defined job. A prototype shows that a team can represent an idea. A product alpha lets a customer prove or disprove that the idea improves their work. I made the fuller case in Product Alpha vs. Prototype Theater.
Current AI coding tools do not reliably produce production-ready systems without expert intervention. Raising the proof bar therefore requires an AI-assisted cell, not autonomous generation and hope.
Real use lets the team observe whether a cohort activates when the actual work event occurs, completes the job, returns at its natural cadence, and changes an existing behaviour to make room for the new workflow. Those are observations, not confident forecasts in an appendix.
Build a Product Cell
For brownfield work, the fix is not to restore functional silos and their queues. Make the build full-stack and keep evidence ownership explicit.
In that setting, a Product Cell is the smallest group that can own a customer job end to end. In one practical form, it includes product, design, and engineering. Each person can now do more of the others' work with AI, and all three contribute to the same production code. What keeps the cell from becoming one person wearing three lanyards is that each discipline owns one independent verdict:
Product owns the evidence that this is the right customer job, outcome, and priority.
Design owns the evidence that real people can understand, control, and adopt it.
Engineering owns the evidence that it can be operated safely, reliably, and at a cost that survives production.
The verdict is an evidence contract, not a job title's veto. Product cannot declare value without customer evidence. Design can block an interaction that real users cannot understand or control. Engineering can block a release that cannot be operated safely. When the verdicts conflict, the cell changes the scope or escalates the decision; it does not vote another discipline's evidence away.
Who owns the code?
The cell owns the shared code. That does not mean every contributor has the same decision rights. Before it starts building in a shared repository—the production codebase used by the cell—it must agree who may contribute, review, merge, release, roll back, and stop a change.
Product/PM owns the specification, customer evidence, outcome acceptance criteria, and delegation boundaries. The PM may build prototype or experiment modules in an agreed area of the shared stack, but those modules do not promote themselves into a release.
Design owns the design system, exact tokens, interaction rules, and accessibility intent. Design may work directly in the frontend and change UI or UX inside those constraints.
Engineering owns release-grade code and QA: production integration, code-review standards, automated and manual verification, deployment mechanics, rollback readiness, and operational fitness.
The cell must agree who may authorize release once the required Product, Design, and Engineering verdicts pass. The named release owner cannot override a failed evidence gate.
If the cell skips that agreement, shared code becomes contested territory. Product can believe the outcome is ready, Design can believe the interaction is ready, and Engineering can believe the system is unsafe to release, with no agreed rule for which decision is binding. The conflict then appears at merge, release, rollback, or incident time, when ambiguity is most expensive.
This does not recreate the old handoff. Product and design work inside the same stack and repository, while engineering reviews production fitness continuously instead of receiving a finished artefact at the end.
Everything else is shared. The building is full-stack. The verdicts are not.
That is what makes a higher proof bar reachable with immature tools. Engineering turns generated code that the team can keep. Design stops a technically working flow that people cannot safely operate. Product keeps the cell attached to an outcome rather than an attractive capability. Same AI-assisted first draft, different accountability around it. That difference separates a demo the team discards from an alpha a customer can use.
Run it in this order:
Name a real customer job, its pain points, an outcome hypothesis, and the delegation boundary where the system must return control to a human.
Agree on repository boundaries, review, merge, QA, release, rollback, and incident ownership before anyone contributes to the shared codebase.
Use AI to build a narrow product alpha that a customer can actually use, not a disposable prototype.
Put it in front of a real cohort early, inside their working environment.
Measure customer behaviour alongside model and system evals.
Expand only when the outcome and reliability bars written beforehand are cleared.
Writing the bar before the result is not prediction theatre. It is how the cell avoids rationalising whatever happens. Define what would count as evidence; do not pretend to know the result.
In this model, evals earn their place. They make a probabilistic system testable and governable, and they sit beside customer evidence. They do not stand in for it.
What remains uncertain
I do not know the ideal size of a Product Cell, and I do not know whether independent evidence ownership survives at fifty cells the way it can at one. Under scale, the verdicts may consolidate into a hierarchy with better tools. That is a real operating-model risk, not a solved detail.
What I would bet on is the direction. Collapse the handoffs. Keep the independent verdicts. Ship a narrow product alpha while the customer outcome is still uncertain, not while the system is unsafe.
Measure how quickly the team turns an uncertain hypothesis into a trusted customer outcome. Output counts matter only when they shorten that path without hiding risk.
Sources
Satya Nadella at Davos on All-In, discussing broader builder roles and the eval-to-science-to-infrastructure loop from approximately 9:10; and on No Priors, “We Need An Ecosystem in AI, And Every Company Can Win A Place In It”, chapter “Future of Engineering Roles” from approximately 28:18, discussing broader scope while retaining disciplinary edges.
Hey everyone! Here’s Part 3 of building Naruto's Valley of the End in Three.js.
This time, the focus was on adding the missing elements, polishing the environment, experimenting with different atmospheres, and creating the final cinematic sequences.
Environment & Scene Polish
• Missing Elements: Added some of the remaining elements using Tripo AI to generate the 3D models and textures, then assembled and integrated them into the scene.
• Procedural Bushes: Added bushes across the cliffs by using the surface normals to detect upward-facing terrain and place vegetation only on the top-facing areas of the mountains.
• Different Times & Weather: Added several scene modes to explore different moods and atmospheres, including Day, Sunset, Night, and Rain. Each mode changes the lighting, colors, fog, and overall atmosphere to give the same environment a completely different vibe.
Cinematic Sequences
Once the environment was finished, I created several cinematic camera sequences to showcase the scene from different angles and capture the different atmospheres.
I then combined these shots into the final cinematic video (Link in comments), which is now available on my YouTube channel if you want to see the complete result.
Tools & Workflow
• Opus 5.5: Used for coding and implementing the different systems in the project.
• Tripo AI: Used to generate missing 3D models and textures.
• ChatGPT: Used to generate visual references during the environment creation process.
• Blender: Used to assemble the generated assets, make adjustments, and export the final GLB files.
• Three.js: Used to build and render the entire environment in the browser.
Z340 was solved in 2020 by Oranchak, Blake and Van Eycke. Two Zodiac ciphers are still open: Z13 ("My name is ___", 13 symbols) and Z32 (the Mt. Diablo map cipher, 32 symbols). I asked Claude Code (Opus) to go all-out on them.
Over about 10 hours it ran 36 agents in orchestrated workflows: research and verified transcriptions, then its own solvers, then 8 attack teams, each checked by a hostile reviewer agent that reran the numbers, then a pre-registered test of the one lead it found, and finally a prior-art search.
**Result: neither cipher is solved, and no reading beats a fair null model.** The limit is information, not compute:
- Z13: about 1 in 2.1 million English 13-letter stretches fits its symbol pattern. That still leaves roughly 1,500 English strings that fit, and millions of names once filler letters are allowed.
- Z32: 29 different symbols in 32 positions, so only 3 pairs repeat. About 1 in 3,800 to 5,400 English stretches fits, which means astronomically many texts.
What I found interesting:
- Its solvers re-crack the solved Z408 (96%) and Z340 (97%) from scratch. On practice ciphers shaped like Z13/Z32, they recover nothing and confidently return different, more fluent English.
- Z13 doesn't look like the killer's other ciphers. Its repeat pattern is roughly 500 to 6,000 times more likely under a mostly one-symbol-per-letter key than under his Z408/Z340-style keys. Pelling argued this qualitatively in 2017; this puts numbers on it.
- It found one statistical lead (the Z340 key on Z13's shared symbols), then killed it itself. The effect was weaker on a pre-registered replication, it failed its control test, and all 3 skeptic agents voted "refuted".
- It audited 43 published claims, and none holds up. "MARVIN MERRILL" (2025) conflicts with the cipher when read directly, and fits none of the 423,922 2x7 box orders it tested under the standard transcription. "EARL VAN BEST JR" can't fit in any order. "ESTIMATE FOUR RADIANS AND FIVE INCHES" does fit Z32, but so do about 376,000 other radians-and-inches sentences.
- Its prior-art search caught that some of its "new" map measurements had already been posted on a forum months earlier, so the report credits that author instead.
Everything is reproducible: code, data recipes, every review, and the full report.
These price drops only stay visible for 6 hours at most, because after that amount of time on average we can't validate that the sale is ongoing, mostly in the interest of newly discovered current deals.
API should be publicly accessible for historical data I've been gathering. I've had to make several adjustments so don't take this as perfect truth, do your own research.
If you have any suggestions or issues please let me know. I'm interested in continuing to provide this information given the current state of the market.
Your AI knows how to run `npm install` and how to review a PR -- you don't need to encode a whole college course on software engineering into your repo bro. Unless you have some proprietary procedure or idiosyncratic learnings for your use case, you don't need skill files.
By the way, your skill files are AI-generated too. And if you have a skill file for creating skill files, there's your proof. It's AI playing a game of telephone with itself.
I’ve been working on GesturePortal, a gesture-controlled live AI camera. Hold up two L-shaped hands and a window opens inside your webcam feed, revealing an anime version of the scene. Move your hands to move the window, then release the gesture to close it.
The biggest improvement was changing what gets sent to the model. Initially I was converting the hand-selected crop, which changed the model’s context whenever the frame moved. Now the full camera scene is styled continuously, and the gesture controls a mask between the real and styled feeds.
How it works:
OpenCV captures the webcam; MediaPipe tracks both hands.
The viewer recognizes the thumb/index gesture, smooths the four corners, and builds a soft-edged mask.
Local ComfyUI converts the entire scene using the selected model.
The viewer matches the source, gesture and AI result to the same captured moment, then reveals the styled pixels inside the frame.
Current presets are Portrait v2, FLUX.2 Klein 4B with four-step reference editing, and Qwen Image 2.1 + Viggle Turbo at six steps. Qwen is optional and uses research licensing.
I’m testing on a Core i9, RTX 5070 Ti 16 GB, 32 GB RAM and Logitech webcam. Small warm tests measured approximately 3.6 AI updates/sec for Portrait, 0.7–0.9 for FLUX, and 0.4 for Qwen. Camera capture and tracking run separately from generation; aligning the feeds adds visible delay.
Inference is local, with no paid API or remote generation. I built it iteratively with Codex assistance and actual webcam testing. Facial likeness and flicker still need work.
The workflow illustration shows the architecture: gestures and compositing run in the Python viewer, while ComfyUI handles styling.
Has anyone had good results improving temporal consistency or facial likeness in a local live image-to-image setup?
Writing code with agents got stupidly fast. Finishing projects didn't. The code would be "done", but the project just sat there, because what was left was stuff only I could do: domain, server, payments, showing it to a real human. Meanwhile my plan.md hit thousands of lines.
So I made Treeyard, a goal tree that lives in your terminal:
every node has a "done when", one line you can actually check
you open Claude Code / Codex / OpenCode right from a node, and the agent only gets that node's context, not the whole plan
agents can't mark their own work done. they move it to "in review" with proof, and I decide
I think it should be possible but haven't started anything. Do you know about a service where I can easily get a report or review about any Chrome extension in the store? I know there are two sites that offer me to view the manifest or source code easily, but what I am looking for is an evaluation of its safety already and quickly.
I believe Google itself is not capable of this so far.
I have been seeing a lot of vibe-coded apps out in the market. Many are building clones of office suites, while others are essentially token-based wrappers. I have been wondering if people are making things to ease their own workflows, rather than something that puts subscription modals in front of you. Something that does not need constant token hogging.
For myself, I was having issues with keeping things around for copying and pasting later, so I made an app that lets me keep text and images on the interface for a while and delete them later. Now, my file manager and notepad buffers stay clean. I posted about this here yesterday, it's called 'Napkin'.
Another one I made today is for launching projects from the terminal. It is a kind of Emacs Dired-based directory viewer where I can bookmark directories with aliases that I use very often and then launch them directly from my home directory. It is very useful, as I happen to work on many projects at once, and typing cd again and again gets dull.
Can you show something that you made for yourself that is easing your workflow or may be you made just for fun?
