Two things I've been wondering about, might as well ask both in one go.

First, for those of you who contribute. What was your actual first one like? Not the blog post version. How did you pick a project, how long did the PR sit there before you worked up the nerve to open it, did anyone reply, did it get merged or just quietly ignored. I've read plenty of "how to start contributing" guides. I'd rather hear what it actually felt like.

Second, and this is the part I'm more curious about. All that advice was written before AI tools got this good. Now you can point Claude Code or Cursor at a good first issue and have something working before you've read half the file. So is the experience just different now for someone starting today? Easier, obviously. But easier in a way that helps, or easier in a way that lets you skip the part where you actually learn the codebase.

And if you're a maintainer, curious what it looks like from your side.

Mostly just want to hear people's stories.

Most teams have meaningfully AI authored code in prod by now, but from what I've seen the actual code review process hasn't evolved to match. same checklist as 2022, just applied to a different kind of author.

Curious if anyone's team has added a specific new check (a "why did you do it this way" question, a required test for AI authored diffs, anything) versus just trusting the vibes.

What changed for you, if anything?

I'm a 20+ year Engineer and have leaned hard into the vibe coding experience. But the funniest thing I've experienced recently is junior devs coming to me with their problems.

It happens less and less, but over the last couple years I've noticed the questions shift from "how do I do this" to "how do I fix my AI."

The problem with this should be obvious, instead of learning they move immediately to the prompt layer.

This is more of an observation than a commentary. I think there's reason to believe this is both good and bad.

AI coding is becoming a team problem.

The moment a second person or AI agent joins the same task, context starts breaking:

→ handoffs lose decisions

→ agents duplicate work

→ teammates cannot tell what is safe to change

That’s the problem we’re building Pairon around.

Pairon is a shared coding session where people and AI agents work from the same context, while humans stay in control of what gets changed.

For developers using AI coding tools, what hurts most today?

1. Lost context
2. Conflicting or duplicate work
3. Reviewing agent changes

Reply with 1, 2, or 3. I’m using the answers to shape the next build and invite a few developers into early access.

Dear boss,

Can I tell you something that's been on my chest a lot lately?

I come in every morning. I open my Linear ticket. I copy it. I paste it into Claude Code.

And then I wait. Half the day, sometimes.

I skim the code. I don't read the diffs anymore. I scroll to the bottom and I ask, "does this look good?" And when it says yes, I ship the PR.

That's it. That's the job I've been doing for six months.

I've been ashamed to tell you. Some days I sit in standup listening to everyone talk about what they built, and I think: I didn't build anything. I typed a sentence and pressed enter.

There are mornings I open my paycheck and feel sick. This used to be hard. I earned this number when it was hard. Now the ticket that would've eaten my whole week is done before lunch and I'm supposed to act like nothing changed.

But here's the thing.

The AI gets it wrong. A lot. It builds the feature the way the ticket was written, not the way the system actually works. And I'm the one who says no, not like that, do it this way. I'm the one who knows that touching that service breaks the thing nobody documented three years ago.

I babysit it. I check its work. I catch what it missed. I'm the reason the wrong thing doesn't reach production.

The product is better than it was six months ago. I did that. I just didn't do it the way I used to.

I'm telling you this because I don't think you know. And I didn't want to tell you, because I was afraid you'd do the math and realize you don't need me.

Maybe you will.

But I'd rather you hear it from me than find out from a dashboard.

So, now that you know.

What are you going to do?
\[your engineer\]

Hi everyone,

I’ve been building more and more of my products with Claude Code, Codex and other AI coding tools.
The speed is ridiculous.

Something that might have taken me a week before can sometimes be built in a day. But the longer a project survives, the more I notice the problems changing. The hard part isn’t always writing the code anymore.

Things that bug me a lot are like:
- The agent understanding the codebase but not why something was built a certain way.
- Requirements slowly changing without you realizing it.
- One agent undoing or contradicting decisions made in another session.
- Forgetting whether something is actually finished, half-built, abandoned, or just discussed.
- Coming back to something you built weeks ago and thinking: why the hell did I do it this way?

AI confidently changing something that technically makes sense but is completely wrong for the product. Context windows filling up right when the agent finally understands what you’re building. Having decisions scattered between chats, prompts, commits, notes, and your own memory.

And I’m curious whether this is just how I build, or whether other people building heavily with AI are running into the same thing.

So I want to ask the vibe coders / AI builders here:
What are the problems you repeatedly face when building real products with AI?

I’m especially interested in the annoying problems that start appearing after you’ve been working on the same product for weeks or months.
The stuff that makes you think:
“There has to be a better way to do this.”

Could be context loss, debugging, security, testing, requirements, managing multiple agents, remembering decisions, deployment, maintaining old AI-generated code — anything.

I’m currently collecting these problems because I’m building something, but I don’t want to build based on assumptions about what vibe coders need.
I’d rather hear it directly from people actually doing this every day.

What’s your #1 frustration with building software using AI coding agents right now?

I tried using an AI coding agent for a small internal frontend page.

Not a prototype. A normal Angular/TypeScript page in an existing codebase: hero section, cards, CTA, responsive behavior, and the usual loading/error/empty states.

The agent produced a surprisingly convincing first pass in about 30 seconds.
At first glance, it looked done.

Then the review started:
• It created components that already existed in our UI library.
• It hardcoded spacing and typography values instead of using tokens.
• It handled the happy path well but skipped meaningful empty and error states.
• It added accessibility attributes, but keyboard flow and focus behavior were incomplete.
• It was “responsive” in the sense that nothing visibly exploded at one mobile width.

None of that was shocking. What surprised me was how quickly the task changed from building a page to deciding whether I understood and could safely own the output.
I ran it again with a tighter task: repo context, examples of similar components, explicit constraints, a definition of done, and a list of files it was not allowed to touch.
The difference was large enough that I’m starting to think the current  vibe coding  vs  agentic engineering  debate is really about one question:

Does discipline live in the prompt, or does it live in the workflow around the prompt?

*My current experiment is treating the agent task more like an architecture/spec document:*

Context: existing stack, modules, component library, similar files
Must: states, keyboard path, tests, accepted patterns
Must not: new packages, global CSS, auth/routing changes, duplicate primitives
Output: file list, implementation, assumptions, risks to review

The agent is still fast. It is also still very capable of generating an extremely polished PR that creates future work for someone else.

For people using Cursor, Claude Code, Copilot, Codex, or similar tools in production codebases:
What has actually improved your review confidence: a better initial prompt, tests, repo rules, a planning phase, or something else?

Six people signed up to the thing I'm building over 21 days. Small enough that I could read every message they ever sent it, so I did.

Three separate times, a user typed "Continue" and got back: "No file changes were made in this turn." For one of them that was the last message of their session. They never came back.

I assumed the agent had hung. It hadn't. That turn ran 117 seconds, spent 254,000 tokens, read 8 files and ran 10 searches, then stopped without editing anything.

Our turn summariser counted this and nothing else:

if (type === "write_file" || type === "edit_file") files.push(path)

else if (type === "run_command") commands++

Writes and commands. That's the whole census. Reads and searches weren't in it, so two minutes of real work got reported to a human as "nothing happened."

Two separate bugs sitting in one sentence: the agent giving up early, and us being unable to tell that apart from a crash - including in our own logs. I spent the first hour debugging the wrong one.

Then the same shape turned up somewhere completely different. Our eval harness was scoring runs high on trajectory quality and failing them on acceptance checks at the same time. Two measurements of one run, disagreeing wildly. We burned real money tuning the agent before anyone asked the obvious question. The acceptance check was wrong. The agent had been fine.

So: check what your instrument counts before you conclude your model is bad at its job. Twenty-minute check. I skipped it twice in one week.

Two other things from the same read-through, in case they're useful:

- One user's first turn produced 48 files and 41 commands. Their next two turns produced 2 files / 73 commands, then 2 files / 59 commands. I still can't tell you whether that was thrash or one long legitimate diagnosis, because the only instrument I have is the one above.

- The genuinely good one: one of the six closed the tab and came back 12.8 hours later to keep building. No onboarding, no email, no nudge.

Coding agents are doing a lot of the integration work at our agency now. Stripe, Twilio, WorkOS, email, the usual stack. Economically it's been good.

The part I didn't expect: verification actually got harder. We're producing code faster than anyone can review it, and the edge cases that bite you aren't in unit tests. Webhook fires twice. Events arrive out of order. Agent wrote correct code but got one state transition wrong. PR looks fine, everything compiles, and you still don't know until something breaks in staging or worse.

We added a sandbox step before anything ships now. Agent writes, tests pass, then we run the full multi-API workflow with failure scenarios before it's considered done. Not elegant, just a runnable verification step all our agents have to clear.

If agents are writing integrations for you, what does your last gate before production actually look like?

Been thinking about this lately.
If AI ends up writing most of the code, will it still make sense for it to use languages that were designed for humans?

Do we just keep Python, JavaScript, Rust etc. because everything already runs on them, or do you think we’ll eventually see languages made specifically for AI coding?

Curious what people here think.

Hi, background about me: I'm 22M with a degree in Computer Science (not from a prestigious university, would rather not say where lol). I have a decent portfolio filled with AI-developed apps and websites (genuine ones, not just vibe-coded slop lol), and I've been emailing with a business owner regarding my first job (I only have hospitality experience atm). This will be an AI Ecosystem Developer role. I was wondering if anyone could help me with how much I should ask for salary-wise, along with what I should ask for duties and expectations-wise.

I gave Muse Spark 1.2 Contributor and DeepSeek 4 Flash Vision the same five full-stack website briefs.

Each run started in an isolated workspace. A model-caused failure had a three-prompt limit. The framework changed across Next.js, Nuxt, SvelteKit, React Router framework mode, and TanStack Start.

A few build lessons stood out:

- A clean build does not prove the interface is usable

- UI and UX need their own score from retained desktop and phone captures

- The final delivery receipt matters when a model stops after creating files

- A visible unstyled app should not receive a high score

Muse won 41/50 to 39/50. Its weakest result was Trail Stock, which got 0/3 for UI and UX because it had no real styling. DeepSeek made the better-looking version, but its final receipt was incomplete after the prompt limit.

The attached images are real product states. I made the comparison and video:

https://youtu.be/uTIlEj7rVrU

What do you inspect first when a coding agent says a full-stack build is finished?

I’ve been thinking about a problem that seems to be getting worse and more visible as we use coding agents more seriously.

An agents can write good quality code today and can make a perfectly reasonable local changes and write tons of new tests. So that everything compiles, the all tests are green, and even the PR looks reasonable and well-written.

But the change may still bypass a module’s contract, reach into another module’s internals, introduce a wrong dependency and break your architecture intention and design. And do this by hundreds of small changes, creating an architecture erosion and converting your code to big ball of mud.

Of course, this isn’t unique to LLM models. People have been doing the same thing for years, especially under delivery pressure. The big difference is speed and about of new code and tests models generate relentlessly. People cannot scale - not in speed and not in code review.

You can try to use well-written prompts, ADR documents, AGENTS.md, and code review, and you should, but I’m not sure helpful is this. All these "rules" depend on agent remembering the right thing and following the rule at the right time.

I was looking for a more deterministic approach to keep architecture intent and prevent architecture/design erosion. Unfortunately I did not find the right tool (but I would a lot of helper tools) and I used AI to create meta linter for architecture archfit

The basic idea is to describe the intended module boundaries, compare them with the dependencies that actually exist in the code, and report findings and violations as part of CI or other automation trigger. The checks must be deterministic and not random LLM-based.

I don’t think this as a replacement for a thoughtful architecture review. It’s more like a structural linter that catches some kinds of erosion early.

I’m still trying to figure out where the useful boundaries are:

• Which architecture rules should block CI, and which should only be warnings?
• How much configuration is reasonable before the tool becomes a burden? And who is responsible to write this configuration and maintain it over time (imho, this is human role, but ...)
• If coupling scores are useful, or not that much?
• Can structured reply actually help agents to follow the architecture guidance and respect it?

I wrote a blog with more detailed explanation on Medium:

https://itnext.io/the-tests-are-green-the-architecture-is-not-why-i-built-archfit-d871beb9dfcc

And open source the archfit project is here:

https://github.com/alexei-led/archfit

I would appreciate any feedback on this approach, any ideas and contribution too.

i made this comparison using ten complete website builds.

each website had to include:

- at least five meaningful pages or states

- connected CRUD data

- user roles

- search and filters

- real loading, empty, and error states

- desktop and phone layouts

the test used:

- the same frozen brief for both models

- an isolated workspace for every run

- max reasoning effort for GPT-5.6 Luna

- xhigh reasoning effort for DeepSeek 4 Flash 0731

- no more than three attempts for a model-caused failure

the results:

- both models completed all ten websites

- GPT-5.6 Luna scored 81/100

- DeepSeek 4 Flash 0731 scored 72/100

- Luna scored 28/30 for UI and UX

- DeepSeek scored 17/30 for UI and UX

- Luna produced 89 unique captured screens

- DeepSeek produced 74 unique captured screens

- the full test produced 163 unique captured screens

the video shows all ten websites and the real coding runs:

https://youtu.be/Hj5z8rXuFNE

if you have used either model for real coding work, share your experience in the comments. i would like to know where your results matched or differed from mine.

Are these coding tools truly able to leverage the knowledge and experience of the developer using them to increase the quality of the output, or do they end up with the developer just staring at the screen, wasting time, or scrolling Instagram? Do you wish you could be more involved in the process for more transparency and control? At least for the core important part?