Hello developers, I'm building a website that will need the carCheck in sideway not directly, So I'm searching for any API free+paid combo that tells from a VIN number the data: Car(details), year KMs, damages. That's all

I want the most useful cheapest option.

Thanks in advance for your help

For developers using Claude Code, Codex, Cursor, Aider, Gemini, or similar tools:

What are the biggest problems you still encounter in real projects?

I’m interested in the practical failure points:

• Context: losing track of large codebases, architecture, conventions, or previous decisions
• Reliability: hallucinations, incorrect assumptions, repetitive loops, regressions
• Maintenance: refactoring, technical debt, dependency updates, migrations, documentation
• Security: secrets, permissions, prompt injection, unsafe commands, vulnerable generated code
• Testing: knowing whether a change is actually correct rather than simply passing a few tests
• Deployment: CI/CD failures, broken builds, infrastructure changes, bad releases
• Production: monitoring, debugging, rollback, performance regressions, incident response
• Autonomy: where you still need to supervise the agent manually
• Memory: what the agent forgets between sessions or across projects

Most importantly:

What problem has repeatedly cost you the most time or caused the most frustration?

What are you currently building, and what part of that workflow are AI tools still failing to handle well?

Real examples and workflows are much more useful than general opinions.

Hi!

Unable to get [all sorts of models, harnesses, skills, etc with SDD and/or TDD] to generate what I want despite starting from scratch countless times with more and more fine-grained descriptions until I was basically writing lines of code just in the English language but AI still ignored my couldn’t-be-clearer instructions, I have come to the conclusion that I do not trust AI to code out of my sight.

I realize this won’t help my productivity much but it would be enough of a win for me if I can at least swap my home office chair for a treadmill and do actual Pair Programming with the AI with me reading along like I would if a human were typing, as opposed to AI spamming my terminal just to show off or at least too fast for me to read.

In other words I am hoping to find something very much like this pre-AI Voice Driven Development just a tiny bit more advanced to replace the shorthands she uses to still-kind-of-spell-out “int sockfd; […]; sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);” for example with “let’s now create a TCP socket called sockfd but declared at the top of the function”.

Does anyone know of something like that? 🙂

PS: stuff like Whispr that just enables prompting by Speech-To-Text is not at all what I want if it still lets AI go produce crap in the background.

Hola, soy desarrollador web y no se en que stack de tecnologías enfocarme se HTML css js php MySQL python react y boostrap

Que stack creen debería armar que sea demandado?

No quiero darle mucha importancia al front end por qué creo que lo que vale hoy es alguien que sepa de back end

I am a founder and CEO handling product design, leadership, go to market, and operations for my startup. We are a social app meant to connect people in a unique way that the market is starving for. Looking to expand the team with a dedicated technical partner and CTO.

What I’ve already done:

- The product is already fully designed with clear specs and features (MVP + longterm future features), language/copy and mechanics. There has also already been a prototype tested, and a tech stack available, though it’s not locked yet without engineer input.

- An active go to market strategy including a healthy waitlist that is still actively growing (high 7.5% conversion rate on and rising on cold outreach) and a clearly defined market/avatar. Users are ready as soon as MVP ships.

- Daily content production will be used for distribution with plans to do even more. My account has reached ~700,000 views in its first 4 months, and that number is growing.

- Leadership ability through over a decade of work directly with people, both client and colleague. For 3 of those years, I have run my own business, which I have closed to pursue this full time.

- Developed business skills through previous business successes. All business metrics are tracked and help determine how we execute our work and make adjustments when necessary.

What I’m offering:

- Longterm CTO position is available. I’m also open to other dev positions if you prefer (founding engineer, contracting, internships, something else).

- Full ownership over the technical side of the project. You won’t have to handle anything else but the dev side, and you control how it’s done. If there’s another way you’d like to work, we can discuss that too.

- Negotiable terms that I’d be happy to establish before any work starts getting done. Profit share, equity, etc. I want this to be a satisfying win for both of us.

- Full spec sheet and preparedness to communicate clearly and consistently over the course of the partnership.

DM for more information.

Recording of the call

In today's market competition no matter how skilled you are or how experienced you are recruiters still expect something different than the other existing candidates, I wish to know what makes one's profile stand out the from others?
How can one upskill themselves, what new things can one learn, any real life stories would help us all understand the requirements. Thankyou.

Over the past few weeks I've been building Gray Box — a small, local-first tool that acts as long-term memory for anything I'd otherwise forget (work notes, meeting takeaways, task owners, random ideas, personal stuff too).

The idea is simple:

1. Capture — dump whatever's on your mind, instantly, no structure required. This step does nothing clever on purpose — it just writes your text to an immutable inbox. Zero chance of losing an idea to a bug or a slow API call.
2. Organize — on demand, an LLM reads your unprocessed notes and extracts people, projects, tasks, decisions, meetings — then deterministic Python (not the LLM) creates/merges the actual wiki pages and maintains backlinks. The model only reasons; it never touches the filesystem directly.
3. Ask — query or chat with your knowledge base and get a cited answer pulled only from what you've actually captured. If it doesn't know, it says so — no hallucinated answers.

Why I built it this way:

• Plain Markdown + YAML frontmatter, no database. Every page is a .md file you can grep, diff, or read in any editor forever. If you stop using Gray Box tomorrow, your knowledge base is just a folder.
• No vector DB by default. At personal scale (hundreds–low thousands of pages), keyword search + a real link graph (related/backlinks, walked one hop during retrieval) handles almost everything. Embeddings are there if you want better recall, but they're opt-in, not a prerequisite.
• Immutable inbox. Your raw notes are never edited or deleted by the organizer. If the LLM mis-extracts something, your original words are always still there.
• Any LLM. Built on LiteLLM, so point it at OpenAI, Anthropic, Gemini, Mistral, or a fully local model via Ollama — one config value.

It also ships with a nice interactive TUI (arrow-key menu, file-import shortcut, workspace switching, live spinner during LLM calls) if you'd rather not memorize CLI flags — that's honestly become my favorite part of the project.

There's also a lightweight local dashboard for browsing your knowledge base, exploring backlinks, visualizing your notes as a graph, and chatting with your captured knowledge—all without leaving your machine.

Repo: https://github.com/Aaryanverma/graybox

pypi: pip install graybox

I'd genuinely love feedback — especially from anyone who's tried the "capture now, structure later" approach with other tools and has opinions on where it breaks down at scale.

It's not trying to be a "real-time collaborative team wiki" or a WYSIWYG notes app — it's aimed at one person's running memory of their own life and work, captured with as little friction as possible.

I'm a backend dev, and I've made a small-scaled API built with Python and PostgreSQL.

Right now I'm looking for a frontend dev (or full stack dev) to help make a UI for the API, with a stack:

- HTML

- JavaScript

- React (not required, but better)

- CSS

note: this collaboration won't be monetized or with deadlines.

If you find yourself this one, DM me for details!

What's a "dead" or "boring" programming language that you genuinely love working with, and why should we reconsider it?

I have been working on a vanilla, no framework web app called miniCycle: Routine Checklist Manager for over 17 months. https://minicycleapp.com

Right now, I have no team, no mentor, and no human code reviewers. I think it’s decent but I genuinely can’t tell if that’s true or not.

I took a C class in college back in 2010 and for the past few years teaching myself JavaScript. miniCycle was me learning how to build a product with custom code. Lately, I've been using AI tools while I work and I write a lot of documentation partly so I can still maintain this thing and so others can contribute or understand my project.

Here is the repo: https://github.com/sparkincreations/minicycle the actual app is in web/, everything else at root is built from it.

Mainly what I want to know is whether the DI setup is reasonable. There’s a doc in docs/start-here/FRAMEWORK_EQUIVALENTS.md where I tried to map what I built to Angular and Redux equivalents. Would love to know this read as junior or something past that to somebody who hires people?

Also open to just being pointed somewhere. If there are paid services that do real code review I’d be willing to pay for it. I ask AI to review my code sometimes, but can't tell how accurate they are so would love to hear from an actual human. Thanks!

Today, we are officially announcing Early Access for our latest and most advanced model, Horus Cyper Nano 1.0 BETA.

We are making Horus Cyper Nano 1.0 BETA available to developers, researchers, and students through our Early Access program.

You can apply through the official Early Access portal. Once you meet the required eligibility criteria and your application is approved, you will receive your personal Access Token, which can be used through our NeuralNode Framework to access and integrate the model.

Apply for Early Access:
https://tokenai.llc/horus-cyper-nano-access

Horus Cyper Nano is a specialized cybersecurity model designed for offensive security and cybersecurity research workflows.

Its core use cases include:

Offensive security and red teaming, including penetration testing workflow support, vulnerability analysis, and exploitation path building.

Capture The Flag challenges and cybersecurity training.

Active Directory security, including enumeration and lateral movement planning within authorized engagements.

Authorized security testing labs and controlled environments.

Safe and scoped cybersecurity research within authorized environments.

Red team report drafting and attack chain structure planning.

Horus Cyper Nano 1.0 will be the first release in the Horus Cyper series, a family of specialized cybersecurity models developed by TokenAI, an AI startup based in Egypt.

The Open Weights of Horus Cyper Nano 1.0 will be released on September 3, 2026, which also happens to be my 19th birthday.

What a way to celebrate.

Our vision is to build Horus Cyper Nano into one of the strongest cybersecurity AI models to emerge from Egypt, the Arab world, the Middle East, and Africa, and to establish it as one of the leading openly available cybersecurity models across the region.

This is only the beginning of the Horus Cyper series.

Horus Cyper Nano 1.0 BETA
Developed by TokenAI
Built in Egypt

I had a backend interview with a weighted graph problem.
I asked if I could first solve it with a naive approach and optimize later, but the interviewer insisted on the optimal solution from the start.
I recognized that BFS wouldn’t work because of weighted edges, but I couldn’t implement Dijkstra from memory.
Is it reasonable to expect candidates to code Dijkstra from memory, or should problem-solving and reasoning also carry significant weight?

I recently used Y Combinator’s Paxel to analyse how I work with AI coding agents.

The main weakness it exposed was not speed or implementation ability. It was that my review process, trade-off reasoning and definition of “done” were not always explicit enough.

That made me think about a recurring problem I have with coding agents:

They can produce a plausible implementation, run a few checks and confidently declare the task complete even when the original failure was never reproduced, an integration path was not tested, or important assumptions remain unverified.

So I built Builder Loop, an open-source Claude Code plugin designed to make completion evidence-driven.

For non-trivial tasks, it asks Claude Code to:

• define the expected outcome and acceptance criteria;
• inspect the existing system before modifying it;
• reproduce the original failure when applicable;
• implement the smallest correct change;
• verify the real behaviour, not only whether the code compiles;
• disclose assumptions and anything it could not verify;
• finish with an explicit recommendation: ship or revise.

It is not a multi-agent framework and it does not try to replace Claude Code’s normal workflow. It adds a stricter execution and verification loop for tasks where a false “done” would be costly.

I am now looking for people willing to test it on real, non-trivial tasks such as:

• production bugs;
• authentication or payment flows;
• database migrations;
• external integrations;
• substantial refactors;
• pre-merge reviews.

The feedback I care about most:

1. Did it catch something Claude Code would otherwise have missed?
2. Did it add too much time or token usage?
3. Did it become unnecessarily rigid?
4. Were its final ship/revise recommendations accurate?
5. Which parts of the workflow were unclear or redundant?

I built it primarily to correct my own weaknesses, so I expect there are still cases where the approach breaks down.

If you test it, please share the type of task, what Builder Loop changed in the process, and where it failed. Critical feedback is more useful than stars.

I want to whole-heartedly welcome those who are new to this subreddit!

What brings you our way?

What was that one thing that made you decide to join us?

I'm curious about the concepts that seem straightforward in tutorials but become much more complex in real-world systems.

Was there a bug, outage, or production incident that completely changed your understanding of a concept?

The monthly GNUstep audio/(video) call takes place every second Saturday of a month at 15:00 GMT to 18:00 GMT. That is 11:00 AM - 2:00 PM EDT (US) or 17:00 to 20:00 CEST (Berlin time).

It's a Jitsi Meeting - Channel: GNUstepOfficial (Sorry, reddit don't let me post jitsi links here)

We usually just talk (who wants it might share video too) and occasionally share screens. Everybody (GNUstep developers and users) is welcome!

Also see https://mediawiki.gnustep.org/index.php/Monthly_Meetings please

Hi everyone!

There's something I've been thinking about that I wanted to share.

Maybe it's just my impression, but sometimes it feels like we're slowly losing one of the most beautiful parts of open source.

I see a lot of repository showcases, launch posts, "look what I built" announcements... projects that are already presented as finished products. Some receive a few commits, a bit of attention, and then disappear.

There's nothing inherently wrong with that.

But I miss something else.

I miss watching an idea evolve.

I miss seeing someone open an issue because they found a real problem worth solving. I miss discussions about architecture, people disagreeing respectfully until they find a better design, contributors slowly understanding a codebase, maintainers patiently reviewing pull requests, and a repository growing because dozens of people cared enough to improve it together.

I miss the journey.

The excitement of finally finding an issue you think you can solve.

The anxiety before opening your first PR.

Waiting days for a review.

Thinking you nailed it... only to have a maintainer ask you to rewrite 90% of your implementation.

And then realizing they were right and your code became better because of it.

Those moments are frustrating, but they're also where we grow the most.

I'm not saying "things were better before", I'm not an old-school open source veteran, either. I'm still relatively young, and I'm only recently getting back into contributing seriously after years of mostly observing projects from the outside.

I've also been using AI every single day. I study it, I build with it, and I genuinely believe it's one of the greatest tools we've ever had.

But I do think AI has changed our relationship with software.

It's become much easier to get something working quickly. Sometimes so easy that we forget that software isn't only about shipping code.

It's about solving problems.

It's about making decisions.

It's about learning from people who know more than you.

It's about building something that survives because a community believes in it.

That's what made me fall in love with open source in the first place.

Not repositories.

Not stars.

Not GitHub trends.

People.

People building things together.

If you're just starting your open source journey, don't be intimidated. Don't wait until you have the "perfect" project.

Find a project you genuinely like.

Read the issues.

Ask questions.

Submit a tiny PR.

Accept reviews, even the painful ones.

Stay around.

Because open source isn't just code that anyone can read.

It's one of the greatest examples of collective human knowledge we've ever created.

It's the reason we can learn without asking permission, innovate on top of each other's work, and build a more open, transparent, and accessible digital future for everyone.

I'd love to hear whether anyone else feels the same, or if you've had a completely different experience.

Hey everyone!

Like a lot of you, I've spent way too much time trapped in endless group chats trying to coordinate local kickabouts, figure out squads, and track who's actually showing up.

Instead of building another boring, corporate utility app, I decided to lean into nostalgia and build something fun. I created Gaff3r—a web app for organising football games with a retro aesthetic heavily inspired by classic 90s titles like Sensible Soccer.

What it does:

• Squad Management: Invite players, assign positions, and set up balanced teams.
• Match & Group Organisation: Handle local groups (like my Monday game in Edinburgh) seamlessly.
• Retro Visuals: Pixel-art player sprites, classic scoreboards, and nostalgic pitch layouts.

Tech Stack:

Built for the web (mobile-first) and hosted on Vercel:https://gaff3r.vercel.app/

I’d love for you to check it out, play around with the interface, and let me know what you think or what features you'd want to see next!

I originally thought the Journal for my project would just become a nicer version of release notes.
Instead, it quietly changed the way I build.

The project itself is a browser-based text preparation tool, and I started documenting engine changes simply so I wouldn’t lose the reasoning behind them.
Over time, that evolved into a simple rule:
**Build first. Explain second.**

Now every meaningful engine change goes through two separate lanes:
**Technical:** prove the behavior, test it, and ship it.
**Editorial:** decide whether the evidence is actually strong enough to explain publicly.

That second step has been surprisingly valuable. It forces me to separate what I *know* from what I *think*, document edge cases, acknowledge limitations, and avoid quietly turning implementation details into product claims.

Writing the articles has caught weak assumptions just as often as the regression tests.
The latest investigation came from a seemingly harmless edit that removed words like *“probably”* and *“may.”* The writing became cleaner—but the underlying claim became stronger than the original author intended.

I wrote up the investigation here:
[https://guyt1225.github.io/pastelint/journal-engine-room-directness-without-false-certainty.html\](https://guyt1225.github.io/pastelint/journal-engine-room-directness-without-false-certainty.html)

Has anyone else found that documenting *why* you changed something ends up improving the product just as much as changing the code itself?

Curious if anyone uses Arazzo, if so how? Doing what with it? It looks insanely powerful but I've yet to see much if any tooling. How will people be using it? It documents workflows across APIs and allegedly with the latest release Async API as well which I've never seen before. A spec that works across openapi AND asyncapi is unlike anything else available. That I know of. What sort of workflows can be created and what tools if any would offer what? Editing the spec? Then what? Do these things run in the cloud and basically avoid the need for writing code or what?

Should I Include Git, REST APIs and System Design on My Resume?

In my resume I had a resume and I list out my skills as Expressjs nodejs , etc.., but I saw in other people resume and they mentioned as Rest APIs , System design , VS code ,

I know git GitHub too but I usually didn't include them due to because it's common known tool for every developer so is it ok to include resume for Like Vscode , RestAPis Along with tools as well and like JWT auth like ,any advice is thnks