Vibe coding solo is easy. But once 2 people or multiple AI agents work on the same app, things get messy fast.
Who builds what? How do you share context, avoid overwriting each other, and review changes without reading all the code?
Do you split work by feature, page, branch, or agent?
What’s your biggest pain when collaborating with other vibe coders?
At what point do we think generating code using AI will no longer be about spitting out human readable languages?
And instead, let’s say for web, Chrome will no longer work with HTML, JS and CSS - but a new language used by AI agents?
If code no longer needs to read by humans, does the compiler need to exist anymore? Or is there an efficient language to be created?
In a way I suppose it’s like image data in a JPEG, could web sites be the same?
All of us slightly technical, millennial biz users are all using AI to dynamically build software and edit that software over and over….and run that software over and over.
I’m sure a software engineer is sitting somewhere like “yeah, that’s why you need be specific with what you want and force compliance….so you can use Claude to build your custom software once - then you use _____ (I don’t know powershell? Jupiter notebook? Pycharm) to just manually invoke the software yourself.
I’m getting the sense that I’m not only paying Albert Einstein rates to creat the theory of relativity every time but that I’m also paying Albert Einstein rates to have old Albert run his theory over and over when a caffeinated grad student would’ve done just fine.
Has this crossed anyone else’s mind? Or am I just missing something completely obvious that would be known if I wasn’t the Business/Finance guy who happens to be kind of dangerous with Claude coding?
Of the 14 gigabytes our self-hosted @Langfuse stack was storing on disk, only 1.6 gigabytes was actual observation data. The rest was the tool logging its own internal queries about itself.
Memory told the same story. The full stack needs about 7.6 GB of RAM to run, and ClickHouse, its own time-series database, eats 5.6 GB of that before storing a single event of ours.
We chose self-hosting to cut cost and keep control of the data. What we got instead was a monitoring tool that needs its own monitoring, sized for its own overhead rather than for the product it's watching.
If you're weighing Langfuse for self-hosting, check what share of its footprint is genuinely your data versus the tool watching itself work. Ours was about 12 percent
I’ve been copy/paste building a ML system with ChatGPT Plus that analyzes a rather challenging data stream. And after working for a few months on building databases sets for comparisons and creating new analyzer scripts. I’ve found that I don’t have time to type a single character as I’m often going through thousands of lines of code daily that never gets used more than once. And I’ve found that even if I had the inclination to “vet the code”. It would take too long because once the path forward has been agreed, then it’s simply a matter of copying and pasting as efficiently as possible while catching any errors that occasionally occur and grasping the gist of progress through comments that ChatGPT provides. This creates momentum that fuels progress. The point is that I’m regularly throwing away enough original code used for testing and retrieving code structure comprehension for editing that it would be impossible for humans to keep up, and therefore, my project would never have been attempted without AI writing all of the code and humans just steering the bus.
Hey folks 👋
We just open sourced TrueForge, our vendor-neutral agent harness for building general-purpose agents.
It handles the runtime pieces that get painful quickly : context management, tool/MCP execution, subagents, sandboxing, approvals, persistent state, and more.
We also benchmarked the harness itself. With the same Opus 4.8 model, TrueForge delivered a similar solve rate at ~30% lower cost than Claude Managed Agents. Switching to an open model pushed that to ~75% lower cost on the same benchmark.
Would love feedback from people building agents.
⭐ Star the repo: https://github.com/truefoundry/trueforge
📖 Read the launch article: https://x.com/truefoundry/status/2090081376330715176
If you are an experienced dev, I have a question for you. How are you using AI. Do you think it's a superpower or it's just another bubble that will burst and we will back to pre AI era soon with a lot of slop to clear?
One habit that can seriously improve your software development skills is learning to understand error messages instead of immediately copying them into AI.
Most errors already give you valuable clues:
→ What broke
→ Where it broke
→ What the program expected
→ Sometimes even why it broke
And there’s another benefit: the better you understand the error, the better you can prompt AI.
Instead of saying “fix this error”, you can explain what you think is happening, what you’ve already tried, and what behaviour you expected.
That gives AI much better context and usually leads to more accurate solutions.
Use AI to speed up debugging—not to replace the skill of debugging.
Do you usually read the error first, or send it straight to AI? 👀
CTOs, engineering managers, and staff engineers are rushing to deploy autonomous AI agents across their businesses – either through their own volition or because of the clamor of demand from rank-and-file workers. However, they should think twice, a new study shows.
Enterprise large language model (LLM) agents are likely leaking company secrets, and throwing more compute at the problem is only making it worse, the study finds.
In part, that’s because of the AI’s ability to retrieve and synthesize vast amounts of internal data, from Slack messages to board transcripts, to automate tasks. By gathering that information, they also create issues with contextual integrity.
When retrieving dense corporate data, these agents routinely fail to disentangle essential task data from sensitive, contextually inappropriate information. Higher task completion rates often directly correlate with increased privacy violations.
Read the full story: https://leaddev.com/ai/frontier-ai-models-haemorrhage-sensitive-data
And yes of course I did that to find if the feature we were adding made sense.
Let me explain. I run an API platform full of micro capabilities for all sorts of stuff like conversions, file manipulations and more. So I wanted to see how much "ai ready" they are. Since anyone can build them with Claude, I was like "yeah but is it worth it"?
Answer: no it's not - and I am glad cause this proves that there are many ways of building something, some are cheap (AI) and some are cheaper (AI + APIs).
So -
+ building from 0 consumed 20k tokens
+ Calling the Apyhub API for the same task consumed 5k tokens consistently, even when I played with the file sizes.
Thats a significant cost efficiency for someone who cares about token optimisation. I am not even counting here the efficiencies you get from maintaining the application.
So if you are building with AI you are super welcome to check out catalog of ready made APIs at Apyhub.
Also, if you have built sth cool , we are also looking for more to add. Currently sitting somewhere around 450+ services.
I work at an AI startup, and I directly report to the CTO. He's very technical and uses AI heavily for development. Sometimes he can build an entire feature over a weekend that would probably take a human engineer weeks.
Recently, during a team discussion, he said something that honestly shocked me:
Why should we care so much about clean code, naming, avoiding duplication, etc. when AI is going to read, modify and maintain the code anyway?
His approach is basically: if the feature works, ship it. If something breaks, tell the AI what's wrong and let it fix it.
I understand his point. AI is getting ridiculously good at understanding and modifying large codebases, and the speed difference is huge.
But I'm personally the opposite. I care a lot about code quality, naming, structure, maintainability, linters, formatting, developer experience, etc. Even when I use AI to write code, I spend a lot of time cleaning it up.
So I'm genuinely curious:
Has AI changed how much you care about code quality?
Do you think clean, maintainable code is becoming less important because AI can understand and fix messy code?
Or do you think we're going to regret this approach once the codebase becomes large enough?
Would love to hear how other developers are thinking about this.
Pulled up an AI code review from a few weeks back that had approved a PR touching retry logic near a payment flow. At the time it read as thorough, numbered comments, a couple of suggestions, a clean summary at the end. Went back afterward and checked it against five specific questions instead of just trusting the tone.
Did it establish what was actually at risk? No. Nothing in the review distinguished the retry logic from a comment on variable naming, both got roughly equal attention. The model wasn't told this touched a payment path, so it had no way to weigh it differently.
Did it check a specific failure mode? No. The comment was "should probably check for duplicates," which sounds like a finding but is actually a hedge. Nothing tested whether the retry would double-charge under a duplicate request with the same idempotency key.
Was severity justified? No. The duplicate-check comment sat at the same visual weight as a docstring suggestion. Nothing forced a distinction between "this could cause an incident" and "this is a nitpick."
Did it state its own scope? No. Silent about whether it had visibility into the caller, or the idempotency key generation happening elsewhere. Silence read as "nothing else to worry about," which is a much stronger claim than "I didn't check that part."
Was there a confidence check on its own findings? No second pass existed. A confidently wrong suggestion and a confidently correct one look identical in tone, the only way to actually tell them apart is asking what would prove it wrong and then checking.
Four out of five, on a review that read as completely fine at the time. Re-ran it with risk context supplied up front, a specific failure scenario framed explicitly, severity tags required with justification, and a stated scope, and the duplicate-charge risk became the one clearly flagged blocking issue instead of one line sitting level with a naming suggestion.
The uncomfortable part wasn't that the AI missed something. It answered confidently either way, whether it had actually checked or not, and confidence was the only signal I had to go on until I started asking these five questions deliberately instead of trusting the shape of the output.
Wrote the full breakdown of the five questions with the before/after comparison here: https://medium.com/@nagatomopedro05/five-questions-your-code-review-should-always-answer-66be919bb200
Worth running your own last "looks good" AI review through the same five questions. Curious how many people find theirs holding up better than mine did.
A dev I was talking to last week put it like this: the build took 2 days with AI, the debugging took 10. He didn't say it as a complaint — more like it's just the shape of the work now.
What I can't work out is whether that's the same debugging we've always done, just more of it, or whether it's a different activity wearing the same name.
So, concretely — think of the last time you shipped something substantially AI-generated and it took much longer than expected to get working.
And the one I'm most curious about: did it feel different from debugging code you'd written yourself? If yes, what specifically was different. If it felt exactly the same and the ratio thing is overblown, I'd genuinely rather hear that — I'm trying to find out if this is real, not collect agreement.
I’ve built around 7–8 projects with AI so far: small websites, tools, a couple of games, etc. I’m currently working on something more complex: a cross-platform game, multiplayer rooms, servers, more moving parts. As the projects get bigger, I’m starting to feel overwhelmed by the sheer number of AI coding workflows and tools people recommend.
Every week I see posts about things like:
Some examples of the kind of posts I’m talking about:
https://x.com/goan999999/status/2088920272812564546
https://x.com/Av1dlive/status/2088998246849118583
https://x.com/mattpocockuk/status/2075218406266036236
https://x.com/lornasuriano/status/2088742742499205219
https://x.com/29meat_ai/status/2088395759129673856
https://x.com/bil0090/status/2088351963951890635
https://x.com/vatsy99/status/2088346475185283390
https://x.com/dillon_mulroy/status/2087537790061850984
https://x.com/DavidOndrej1/status/2087862257279459422
https://x.com/josesilesdata/status/2087993121153991016
And this project in particular:
https://github.com/DannyMac180/sol-advisor
My problem is that I can’t tell anymore what’s genuinely useful, what’s situational, and what’s mostly Twitter hype.
I’m a very organized person. I document things heavily. Currently A lot things in this project got done by doing .md files defining things so agents have a clear source of truth. I don’t like blindly telling an agent “go build this” and hoping for the best.
I also assume the right workflow depends on the size of the task. Adding a button probably doesn’t need specs + five agents + an orchestrator. Redesigning an entire visual identity or changing a major system probably does need much more structure.
I’m curious what people who are actually using these tools seriously are doing today:
And especially: how do you keep the workflow organized and token-efficient without sacrificing quality or constantly rebuilding your setup every time a new AI coding tool appears?
When I started learning, everyone around me had ChatGPT open in the next tab. Every bug, every "how do I center this thing," straight into the chat. And honestly it annoyed me. I had this stubborn idea in my head that if I could only write code with AI holding my hand, then I hadn't really learned anything, I'd just learned to ask.
So I did something kind of dumb looking back. I banned myself from AI for my whole first year. No ChatGPT, no Copilot, nothing. Just docs, Stack Overflow, and Google at 1am.
Some bugs took me like 10 hours. Not exaggerating. There was this one TypeScript error I chased across an entire weekend and it turned out to be something so small I don't even want to say what it was. AI would've caught it in four seconds.
And here's the part I can't really explain to people: that year kind of sucked and I'd still do it again.
Not because suffering makes you a better person or whatever. But being lost in my own code for 10 hours forced me to actually get how the pieces fit. I learned to actually read a stack trace instead of just copying it somewhere and waiting. Learned to guess what was probably broken before I started changing stuff. That stuck in a way I don't think it would've if something just handed me the answer every time.
I use AI a ton now btw. Not anti-AI at all, that's not what this is. Tests, boilerplate, responsive css, translations, all the boring stuff, I just hand it over. It's great at that. But I can usually feel when its answer is off, and I think that's only because of that dumb year building up some sense of what "right" looks like.
The thing that kinda worries me is people starting out now where the AI writes everything from day one. Their credits run out and the work just... stops. Not because there's nothing to do but because doing it without AI was never actually a skill they built up.
I'm not saying refuse AI like I did. That was probably overkill honestly. But maybe give the bug an honest 20 min yourself before pasting it in. Just to keep the muscle.
Anyway. Curious if anyone else did something like this or if I just wasted a year being stubborn about it. How do you all balance using AI vs actually learning the thing?
It’s been something of a mantra for a while now: use a frontier model for planning, then delegate the implementation to low-cost models, and finally verify the implementation using the frontier model (and then ask the cheap one to do the corrections)
I’m not saying it isn’t the best approach, but speaking from my own experience… I have my doubts.
Let’s say GPT-Sol Medium (or Terra High) are my planner models, and something like DeepSeek V4 Flash or Gemini 3.7 Flash handles the implementations. What I’ve noticed with this workflow is that the number of correction rounds resulting from the review is often enormous, no matter how clear the plan is. In this scenario, I end up burning ‘expensive’ tokens on planning and the review rounds, whilst also burning cheap tokens (which also add to the cost) through constant implementation and correction, which ultimately amounts to a waste of time and money.
So now I’m trying a different approach: once the planning agent has defined the plan, why change it? That agent already has the context to implement it in a single shot and, if anything, I have the implementation reviewed by a couple of low-cost agents. I know it sounds counterintuitive, and I don’t have any large-scale data to back up this approach either, but my feeling is that it works better for me.
I’ve been building production software with AI coding agents doing most of the implementation work — not toy projects, things that reached real users. The failure mode that kept showing up wasn’t “the AI writes bad code.” It was drift: things that started clean got quietly worse over weeks, because nothing was checking. Here are the specific patterns that actually fixed it, not vague advice.
Small habit change that had a bigger effect than expected. Before asking for a fix or a feature addition, started asking the model to first explain what a piece of code was actually doing, in its own words, no changes, just a plain description of the current behavior.
Expected this to be a formality, mostly useful for onboarding someone else onto unfamiliar code. Turned out to be useful on my own code, code I'd written and thought I understood completely. The model's explanation occasionally didn't match what I thought the function did, and in a couple of cases, the model was right and I was wrong about my own logic. One function I'd assumed handled a specific edge case actually didn't, the explanation described behavior that only looked correct because the edge case in question had just never come up yet.
What's interesting is why this works better than just re-reading the code myself. Explaining requires committing to one specific interpretation instead of holding a vague, flexible sense of "yeah, this looks about right" in your head. A model forced to state plainly what a function does can't hedge the way a quick visual skim lets you hedge. Either its stated interpretation matches your intent or it doesn't, and the mismatch is obvious immediately instead of staying buried in an assumption you never examined closely.
Doesn't replace actual testing, obviously, an explanation being wrong doesn't guarantee the code is broken and an explanation being right doesn't guarantee it isn't. But it's turned into a cheap first-pass check I run before touching anything, especially on code I wrote a while ago and am about to modify without having fully reloaded the context in my head first.
Anyone else use "explain this before I ask you to change it" as a deliberate step, or is jumping straight to the fix/feature request the more common workflow? Curious if this is specific to older or unfamiliar code, or if people find it useful even on stuff they wrote last week.
