AI slop in my Advisory Guide?

The entire frontend of Advisory Guide is vibe-coded.

I'm a stubborn backend engineer. Give me a latency problem and I want to know where the time went. Ask me to choose the spacing around a button and suddenly I have other priorities. Frontend work spent a long time on my list of things I would become interested in eventually.

AI gave me a way into that work. I could describe an interface, try it, and ask for changes while learning what made the result usable. Waiting for a spontaneous interest in CSS had produced very little CSS.

I say this openly because "vibe-coded" has become an awkward label to attach to something you care about. It can sound like an admission that you skipped the work. Sometimes people do skip it. The label alone tells you very little about which decisions the builder understood or how carefully they checked the result.

There is a real distinction behind the argument. Andrej Karpathy's original description involved accepting generated changes without reading them and letting the code exceed his understanding (Karpathy). Simon Willison separates that practice from AI-assisted programming with review, testing, and comprehension (Willison). I'm using the broader everyday meaning here: building through instructions to AI and repeated revision. Within that broad usage, experience still matters enormously.

The pressure to conceal AI use deserves attention, too. In Microsoft and LinkedIn's 2024 workplace report, 66 percent of surveyed leaders said they would avoid hiring someone without AI skills. Among workplace AI users, 52 percent were reluctant to admit using it for their most important tasks. These were reported attitudes, but they capture an uncomfortable tension: learn the tools, then worry about admitting you used them (Microsoft and LinkedIn).

In four experiments published in 2025, Jessica Reif and her colleagues found that people described as using AI could receive lower ratings for competence and diligence. The response varied with the task and the evaluator's own AI use (Reif et al.). That makes the anxiety understandable. It also gives employers something concrete to examine in their own evaluation practices.

Employers can choose a more open approach. Shopify has publicly described both an expectation of AI use and a culture of sharing what employees learn from experimentation (Beauchamp). Clear rules about confidential data and hiring assessments are reasonable. Making people guess whether permitted AI use will quietly count against them is exhausting.

I want to be able to discuss the work plainly: where AI helped, what I changed, and what I learned. That conversation gets much more useful once we distinguish the different levels of building hidden inside the same label.

I think of four levels, based on how much of the result someone can explain and take responsibility for. They are a practical way to discuss the work, and a person can occupy different levels in different parts of a project. My backend experience travels only so far when the question becomes whether a screen works well with keyboard navigation.

The first level is the experimenter. You describe an idea, get a working screen, and discover whether the idea makes sense. An answering-service operator might prototype a better way to organize client instructions. Their knowledge of the job gives the experiment value immediately. At this stage, the builder may depend on the assistant for every change and have little ability to diagnose a failure. That is a useful starting point for learning. It is also a reason to keep the experiment away from sensitive data and consequential live operations.

The second level is the guided builder. You begin reading the generated code, following how data moves, and checking changes against examples you understand. When something breaks, you can narrow down where it happened. AI becomes a tutor as well as a code generator. The danger is accepting a convincing explanation without checking it. Asking the assistant why a function works helps; changing an input and predicting the result gives you a way to test your understanding. A small tool with a clear boundary can teach a great deal here.

At the third level, the engineer owns the behavior of the system. That includes awkward conditions the original prompt omitted: interrupted requests, stale data, permissions, and changes that break an older feature. GitHub's own guidance warns that generated code can look valid while being incorrect or insecure, and calls for review and testing (GitHub). The engineer has to evaluate the proposed test, too. An assistant can faithfully write a test for the wrong requirement. A green result then makes the mistake easier to trust.

The fourth level involves coordinating work across a larger system. You can delegate pieces to several agents, establish boundaries between them, and verify that their changes work together. This requires judgment about what to delegate and what needs closer human investigation. Two individually sensible changes can conflict when combined. More agents create more work to reconcile. The work includes tracing a change through the whole path, from the request sent by one component to the answer displayed by another.

These levels also explain how an experienced programmer can benefit. I already have ways to investigate slow requests and reason about failure. AI lets me bring those habits into frontend work while learning the unfamiliar parts. It cannot supply taste or accessibility knowledge simply because I know how to operate the assistant. When the work exceeds my understanding, seeking a specialist is part of owning the result. Being experienced includes recognizing where your experience stops.

Consider a hypothetical support dashboard. In the demonstration, a short customer name fits neatly beside a button. During a real call, a longer name covers the control. Then a request fails, and the previous answer remains visible. The agent has to decide whether it belongs to the question they just asked while the customer waits. A pleasant screenshot revealed almost nothing about those problems. Understanding the failure means tracing how the request and the displayed answer relate, deciding what the agent should see, and checking that behavior after the next change.

That is where the word "slop" becomes useful to me. Merriam-Webster describes digital slop in terms of low-quality AI content produced in quantity ("Slop"). In software, I associate it with work that transfers unfinished thinking to the user. Generic copy leaves them guessing what a control does. A confident success message conceals a failed operation. The builder had a way to produce an answer quickly and stopped before asking whether it was a good answer to this person's problem.

Visual sameness can make that impression worse. A layout that could advertise any product suggests that nobody considered this particular one very closely. Still, colors and rounded cards cannot establish how software was made. Handwritten code can produce a careless interface. Generated code can be revised with considerable attention. The important details are often mundane: understandable labels, readable text, useful errors, and a task someone can finish without guessing. Those details make care visible.

In Advisory Guide, the user loads their material, presses Suggest during a live conversation, and decides what to say from the guidance. Their attention is already divided. They need to recognize which material is active and whether a request is still running. Reading an answer should fit into the conversation. These are the questions I need to answer about the frontend. They connect the interface to the backend work I discuss in Conversation Engineering, and they give me something more useful to improve than a screenshot's first impression.

The same judgment has to survive the next release. Suppose a new feature changes how prepared material is selected. Existing users still need their familiar workflow to behave predictably. Someone must work out which assumptions changed, check the affected behavior, and decide how to recover if the release causes trouble. AI can help with each step. A useful record explains why a decision was made and which behavior must remain intact, so the next person can evaluate a change without reconstructing the entire prompting session. Maintaining that continuity is part of becoming a better builder.

Hiring should examine this kind of judgment directly. Ask a candidate to explain a change, investigate a failure, or adapt their work when a requirement changes. Agree in advance on which tools are allowed. A beginner who can produce an attractive prototype may be a promising junior hire with supervision. Giving that person sole responsibility for a production system requires capabilities the prototype has yet to demonstrate. Experienced candidates should be able to show those capabilities even when AI wrote substantial portions of their code.

Vibe coding is open to everyone. Beginners deserve room to experiment, and experienced people should be able to discuss their tools without embarrassment. The useful progression is learning enough to make better decisions, catch more of your own mistakes, and maintain what other people rely on. AI helped me enter work I had kept avoiding. I still prefer the backend. The button, including the space around it, is my responsibility anyway.