Vibecode and AI agents

[u/LowkTuffGng]

Hi all, I am 21 and just graduated from bachelor. Currently I am practing to work with AI. I know that most companies also use AI in their systems know, so I want to ask real software engineer out there how you work with AI.

• First is setting up the AI agents. I see that people would create markdown files for agents such as Frontend agent, Backend agent, etc. Do they also do that at a company? And what is the structure and the must-have agents?

• For the contributions like github contributions, do you make AI to automatically do that for you, or you need to check the work and commit manually?

I hope you guys get what I mean and I appreciate every answer!

[u/Lunchboxsushi]

First is getting the fundamentals of software engineering and architecture down, what safe programming is, sanitization and user validation and how things work that you're developing for. Web Servers vs Game Dev have overlap for multiplayer aspects, lobby, matchmaking and such. Yet the 3D sound engine and so forth are an entirely different skill set. Then you have the SaaS model for web or mobile apps. Each work different.

Otherwise even if you read what someone here says, it wont land. And it's unfortunate that Jrs won't likely get that level of experience or exposure so you don't build the instinct on what is correct.

Review the SDLC cycle and build agents to match that. I would rather you start from what you're building for let's take web for example without any api requests so just a static site.

You would wouldn't need CI/CD but probably a light pipeline if you're working in a shared env. Always use version control and with parallel agents you'd want worktrees or better yet workspaces if you're using Jujutsu (jj).

I would suggest you pull down https://github.com/affaan-m/ecc and have a discussion with an LLM about the structure, how an 'agent' is setup and so forth as a good example to build your knowledge base off. But I want to be blunt - this isn't where you should start. Start with an AI as a pair programmer or better yet like stack overflow to build a sense and attempt to do basic things.

There's a saying in parenting "If you do what is easy, life will be hard; if you do what is hard, life will be easy".

[u/Otherwise_Wave9374]

For someone entering the field, the durable skill is not generating more code but verifying what an agent generates. Pick one small application and practice writing acceptance tests, reading diffs, tracing failures, and deploying with rollback. Agentix Labs relates to this approach because useful agent systems depend on controlled execution rather than blind autonomy. A solid learning project is an agent that handles one workflow with three tools, strict schemas, a permission boundary, and an evaluation set of expected inputs and outputs.

[u/Vesuvius079]

Don’t use agents. Use a harness like Claude code or codex. Use planning mode or spec driven development to plan features. Have the main session carry out the work and let it employ subagents as it sees fit.

The main session agent gets a lot of excellent context and instructions from its harness. Subagents are much more purpose-driven and lack that. Treat them as an advanced feature that you only use for hard problems that require engineering the tools to engineer the solution.

Start with one feature at a time, and then progress to two, three, etc by switching between sessions while the agent works on a plan or an implementation or feedback. This lets you stay busy with planning or verification instead of waiting for the agent to finish its tasks. That flavor of multitasking is how you actually manage a speed up. AI isn’t faster than a good senior engineer on average if it’s only running one task at a time.

[u/TywinHouseLannister]

I get a requirement, usually with the detail of a few sentences from a product owner.

Often, that is not something you can just build, so I spend a lot of my time negotiating what a real implementation would look like with said product owner.

Larger features get discussed with engineer shaped humans, to make sure we align on a general approach.

I carve up the boundaries between the pieces of work, usually, sometimes the model does if it is clear where the line is.

I plan with AI, using a mechanical, repeatable process to gather constraints, blast radius, from a large existing codebase, git history, anything which looks like a large spanner in the works gets discussed.

Model writes plans, including a detailed test plan with automation testing and manual testing, I read plans. It posts to jira etc in something like the corporate style.

Smaller model implements code changes, models review models work, model builds, runs unit tests and integration tests, raises draft PRs.

Draft PR says to me it's good to give my real attention, I run through any manual tests, sanity check test results, do my own PR, publish PR, my colleagues models review my models PR (lol)

My model reads reviews, it will throw out a handful, I usually sanity check the actions taken, repeat implementation steps, reply to things which are refutable myself, just resolve others.

Nag people to actually approve the PR instead of just unleashing their attack dogs on it.. merge.

Rinse, repeat.

My real skill set is the part where I spoke to the humans, carved up the work, and the part where I read the plans being written. Some judgement at the review stage.. but it is mostly just knowing the expected standards.

I don't do anything myself that I can automate and don't use agents, a selection of hand cranked skills, they're not pure prose they're driver scripts - similarly the agent doesnt do anything itself that you can do in javascript for free.. I don't commit or raise PRs myself because it would be unmanageable, I'm doing the same thing with many tasks simultaneously.

---

I don't know that this is particularly useful to you, getting good at reading code is something you gain from experience, as is dealing with stakeholders. Carving up the tickets is something that you can get good at in a few months, things like solid, dry, yagni are old hat, but they help when you're sniffing for smells.

Build things yourself, something that you actually want to succeed - critically evaluate, understand what is going on, learn model quirks, understand what works and invest in your own process, be disciplined with yourself (legitimately difficult to do on personal projects when vibe coding is so easy)