Loci

So you want to code with AI

Properties2
descriptionSoftware engineers can be very opinionated about their tools, patterns, and philosophies. Let’s react to some of the most controversial opinions from elite d...
tagsclippings

18 min read

So you want to code (with AI)

Very interesting perspectives for anyone aspiring to be a developer. But don’t just read these, put them in practice.
a word of warning about AI

Key Takeaways from main video

  • OOP: Valid but often overblown; favor modules and plain objects in JS for tree-shaking.
  • Passion: You don’t necessarily need to code in your spare time to be a “10x developer.”
  • Efficiency: “Lazy” (clever) programmers are often the best because they seek the smartest path. But they still need to be able to focus.
  • Skills: Googling is a primary professional skill.
  • Education: CS degrees provide a foundation and fast-track internships, but are not strictly necessary for success.
  • Testing: Quality > Quantity. Avoid “coverage for the sake of coverage.”
  • Communication: The customer isn’t always right; developers must communicate technical debt and bad ideas.
  • Code: Prioritize readability; explain why something exists in comments, not what it does.

Extra learning Resources

General Engineering & Architecture

Specialized Topics

AI-Assisted Coding

NextJS: fast server side rendering, plus they just pushed an update.
TailwindCSS: https://en.andros.dev/blog/af3ee191/why-i-dont-recommend-tailwind-css/ got some issues but overall for AI I think those are fine.

There is something I should warn you about. https://www.ssp.sh/brain/ai-making-you-exhausted/, https://www.youtube.com/watch?v=GEkoGCFpY8c

What makes an engineer great (or anyone in general) is the ability to focus deeply on the right task, without getting distracted. telegram boss

https://bun.com/blog/bun-in-rust

Great courses: https://anthropic.skilljar.com/
Great guides: ai coding

Best local AI right now: https://www.intelligentliving.co/qwen-3-8-27b-open-model-rivals-gpt-5-6

AI Coding Skill Reference

---
name: writing-code
description: Use for any code work — writing, adding, refactoring, fixing, reviewing, or documenting code. Routes to the right process skill for each phase, sets the documentation standard, defines when a change is actually done, and governs subagent and context spending.
when_to_use: implement, add a feature, fix a bug, refactor, write tests, build, debug, review a diff, write docs or a README, set up a new project, "why is this failing", "make it work"
---
 
# Code work
 
Read `references/documentation.md` before writing any documentation, README, or
docstring. Do not write docs from memory — the four-quadrant rules are specific.
 
## The loop
 
Per feature, in order. Each phase has a skill that owns it — use it, don't
improvise the phase from memory.
 
| Phase | Owner | Skip when |
|---|---|---|
| 1. Should this exist? | `batman-new` (new project/feature) | Bug fix, or scope already settled |
| 2. Understand the ask | `brainstorming`, or `requirements-clarity` if requirements are the fuzzy part | Intent is unambiguous and small |
| 3. Read the real flow | `Explore` subagent (wide search) or codegraph tools | Already have the context |
| 4. Plan | `writing-plans`; plan mode for anything multi-file | Single obvious edit |
| 5. Pick the smallest rung | `ponytail` ladder — always active | Never |
| 6. Test-first | `test-driven-development` | Trivial one-liner, or `ponytail`'s single runnable check is enough |
| 7. Implement one slice | — | Never: one slice at a time, each ending verifiable |
| 8. Verify with evidence | `verification-before-completion` | Never |
| 9. Document | `references/documentation.md` | Nothing user-facing or non-obvious changed |
| 10. Commit | `commit-work` / `caveman-commit` | Never; small commits, don't push unless asked |
 
Debugging enters at `systematic-debugging`, not at phase 1.
 
**Fix root causes.** A report names a symptom. Before editing, find every caller
of the function you're about to touch; one guard in the shared function beats a
guard in each caller and leaves no sibling still broken.
 
## Ask, or default
 
These pull in opposite directions, so the tiebreak is explicit:
 
- **Different readings produce materially different work** → ask, before writing.
  Architecture, data model, scope boundaries, anything hard to reverse.
- **A sensible default exists** → take it, name it in one line, keep going. Never
  stall on a choice you can default and flag.
- **Uncertain about a fact** → verify it with a command, a doc, or a search.
  Never silently assume, never hand the lookup back to the user.
 
Batch the questions. Ask at the point the answer is needed, not up front, and do
everything that doesn't depend on the answer first.
 
## Subagents
 
A subagent starts cold and re-derives context — it is the expensive path, not the
cheap one. Spawn one only when **the reading is large and the answer is small**.
 
- Good: "find every place we build the auth header" (`Explore`), sweeping an
  unfamiliar tree, a long research read.
- Bad: work you already have the context for, anything needing conversation
  history, or a task whose output is as large as its input.
- Delegate with a **specific question and a stated output shape**, not a topic.
  A vague prompt returns a vague summary and the reading has to be redone.
- Read-only fan-out → `Explore`. Design → `Plan`. Both skip CLAUDE.md to stay
  small, so restate any constraint they must respect in the prompt itself.
- Never delegate the final verification. Confirm that yourself.
 
Three custom agents exist for the recurring cases, each with a fixed output
shape so the answer comes back small:
 
| Agent | Use for | Returns |
|---|---|---|
| `code-explorer` | locating symbols and callers in an unfamiliar tree | a `path:line` table, haiku, read-only |
| `code-reviewer` | a diff that's written but not yet trusted | `path:line — defect → fix`, preloads this skill, cannot edit |
| `test-runner` | running the suite, lint, or typecheck | `PASS`/`FAIL (n)` plus verbatim failures only |
 
Prefer these over `Explore` for code work — they load CLAUDE.md and
`rules/code.md`, so the constraints don't need restating.
 
## Definition of done
 
Not done until all of these are true:
 
1. The stated ask is complete — not the easy part of it. Anything left out is
   named explicitly, with the reason.
2. Tests written and **run**, with output seen. "Should pass" is not passing.
3. Lint and typecheck clean.
4. Non-trivial logic leaves one runnable check behind — an `assert`-based
   `demo()`/`__main__`, or one small `test_*.py`.
5. Docs updated in the same change, in the right quadrant.
6. Diff read start to finish. No unrelated edits, no drive-by reformatting.
7. Claims match reality: if tests fail, say so with the output; if a step was
   skipped, say that.
 
Never report success from expectation. Evidence before assertion.
 
## Context
 
Quality degrades past ~100k. Treat context as the scarce resource it is.
 
- One session per feature. `/compact` between chunks, fresh session on a pivot.
- Read the part of the file you need, not the whole file.
- Prefer the `LSP` tool and codegraph over grep-and-guess — real symbol data,
  fewer wrong turns, less reading. `code-explorer` for wide location sweeps.
- If `.codegraph/` exists in the project, read `~/.claude/codegraph.md` for the
  tool table and use those lookups instead of scanning files.
 
## Reach for the real tool
 
Do not describe, approximate, or reimplement a capability that already exists:
 
- **Library or framework specifics, any version question** → Context7. Even when
  the answer feels known; training data lags.
- **UI actually works?** → Playwright. Drive it like a user; read the console.
  Don't eyeball the code and declare it working.
- **Facts, current events, unfamiliar tooling** → Perplexity (`perplexity_search`
  for URLs/facts, `perplexity_research` for depth).
- **Over-engineering suspected** → `/ponytail-review` on the diff,
  `/ponytail-audit` on the repo.
- **Diff written but not yet trusted** → `code-reviewer`. Tests, lint, typecheck
  → `test-runner`. Neither can edit, so the report comes back honest.
- **Security is designed in, not bolted on.** For each feature answer: who may do
  this, what inputs exist, what can be abused, what data is sensitive. Then still
  do the final pass on critical flows.
 
## Security floor
 
Never simplify away: validation at trust boundaries, error handling that prevents
data loss, authz checks, secrets hygiene (never in prompts, never in the repo),
accessibility basics. `ponytail` shortens solutions, never these.

Transcript

Controversial Opinions

0:00 · object-oriented programming is absolutely the worst thing that’s ever happened to the field of software engineering [Music] in today’s video we’ll look at some of the most controversial programming opinions coming from highly experienced developers on stack overflow which is known for its kind friendly and not toxic at all community i’ll give you my initial reaction based on my 10 years of

0:26 · experience primarily in web development but in full disclosure i only have about 5 000 rep on stack overflow so my opinion doesn’t really matter very much if you’re new here like and subscribe then leave your most controversial opinion and i’ll choose the best one to win a free t-shirt of your choice and i just released a whole bunch of new merch designs so check those out to support the channel and keep this content coming alright so let’s get back to that initial opinion that basically says object-oriented programming is horrible developers have been hating on oop a lot in recent years and even the legendary

Object-Oriented Programming

0:54 · edgar dykstra is quoted saying object-oriented programs are offered as alternatives to correct ones the idea behind oop has been around since the 1960s and allows developers to encapsulate data and logic inside of objects you start with a class which is like a blueprint that can then create multiple object instances these classes

1:14 · can inherit behaviors from each other forming a hierarchy of abstractions in addition there are a bunch of design patterns to go along with it like singleton factory dependency injection and so on all these features and design patterns sound sophisticated and sometimes they trick you into thinking you’re making productivity gains when there’s likely a much simpler way to get the job done a common complaint is that object-oriented languages require a lot

1:37 · more boilerplate than something that’s more functional in nature and applications end up having a bunch of mutable state that’s difficult to test refactor and just reason about personally i do think these criticisms are valid but a bit overblown in javascript i rarely implement my own classes and basically never use inheritance instead i create modules that export functions and plain objects

1:58 · that makes the code tree shakeable so that dead code can be eliminated when it’s bundled together you also don’t have to worry about things like constructors getters and setters that this keyword which in many cases just add unnecessary complexity but that being said i do come across cases where a class is a really nice way to encapsulate something and they do work really well in frameworks like angular or nest that have put a lot of thought into how to work with classes in a predictable way and there’s also other tools out there that i really like that are fundamentally object oriented like flutter or the unity framework when done

2:27 · properly object-oriented programming can be very nice and intuitive but it may not always be the best solution so it’s good to keep an open mind about procedural or functional approaches as well programmers who don’t code in their spare time for fun will never become as good as those that do the idea here is that if you’re not passionate enough about coding to do it in your spare time

Love to Code

2:45 · you’re never going to reach your full potential now i actually disagree with this opinion even though i’m the type of person that writes code in my free time i think the reality is that many people treat programming as a job and there’s absolutely nothing wrong with that there are some super talented programmers out there that can get stuff done with a fraction of the effort that other programmers might need 10x developers are real and it’s not because they’re programming in their free time they’re just built different than the rest of us like ellen iverson and his prime didn’t even have to practice and he was still better than pretty much everybody else we talking about the game we talking about practice man being a

3:17 · programmer is not just about writing code it’s also about communication being a good team player vision creativity and a bunch of other soft skills which brings me to the next opinion lazy programmers are the best programmers or another way to translate it is work smarter not harder i agree with this one 100 but i think a better word for lazy

Lazy Programmers

3:35 · might be something like clever working hard is good and all but sometimes it can blind you to a better solution like have you ever been stuck debugging something for hours then you take a 10 minute break and come back and solve it right away that’s a phenomenon experienced by all developers and has happened to me many times instead of working hard be lazy about things take a

3:53 · break and come back and look at it with a fresh set of eyes in addition when you suspect you’re doing something inefficiently it might be valuable to devote a few hours to learning a new skill maybe you need to write a function that checks for an odd number and currently you have an if else statement to infinity you might actually save some time by taking a few minutes to learn how the modulus operator works but in some cases learning might even be a waste of time the next opinion is that

Google

4:15 · googling it is okay one time my doctor told me that googling stuff online doesn’t make me a doctor that didn’t make a whole lot of sense to me because my most important skill as a developer is being able to google things a better opinion i found on the same thread goes like this it’s fine if you don’t know but you’re fired if you can’t even google it i agree with this opinion because the daily work of most developers is about problem solving for the business as opposed to more theoretical algorithm implementations that you face on an interview google is not the solution to everything but knowing how to use it efficiently is definitely a skill that any experienced

4:46 · developer should have on a related note another controversial opinion is that a degree in computer science does make you a more well-rounded programmer this is controversial because many influencers out there today say that you don’t need a degree to be successful as a programmer you don’t need college learning learn stuff okay

CS Degree

5:03 · everything is available basically for free you can learn anything you want for free and many big companies have dropped their degree requirements for developers altogether personally i don’t have a computer science degree everything i’ve learned has been self-taught or learned on the job and i’ve met many other developers making big salaries without a degree so you definitely don’t need a degree to break into the industry but that being said if i could go back in time i would probably pursue a computer

5:27 · science degree it can definitely fast track you by getting you internships at big companies and i do think that foundation of knowledge would likely make you a better programmer but on the other hand is it really worth 4 years of your time and a hundred thousand dollars in student debt college definitely isn’t a path for everybody and one of my favorite things about the tech industry is that you can be successful without a degree which is a good segue into the next opinion there’s an awful lot of bad

Bad Teachers

5:49 · teaching out there whether you have a degree or not you’ll eventually find yourself on youtube trying to learn from one of the many different teachers out there as a teacher myself and a supporter of my fellow youtubers i unfortunately agree with this statement in fact plenty of people out there absolutely hate my teaching style

6:06 · i get mean comments on almost every video saying the content sucks and that it’s too fast and so on what it really boils down to is that different people have different preferences when it comes to teaching style ironically the biggest turn off for me is when a teacher has a highly opinionated take on something there are people out there who preach dogma like there’s only one right way to do something that’s almost never the case and my mind is always being blown with new ways to get things done all the time the only thing i really know is that i know nothing speaking of dogma people have really strong opinions about unit testing a controversial one is that

Unit Testing

6:37 · unit tests don’t need to be written up front and sometimes not at all unit testing can be very valuable and there’s even empirical evidence to support that but also in my experience it can be a completely useless waste of time especially in projects where the requirements aren’t very well defined and likely to change as the project evolves because if you try to write your test up front then requirements change you not only need to refactor your code but also your tests in addition most developers don’t really like writing tests in the first place so when you put a requirement out like 95 code coverage

7:07 · you get a bunch of pointless tests just for the sake of testing and horrible code to go along with it i think quality is a lot more important than quantity when it comes to testing or if you have the resources use a dedicated quality assurance person or team to validate the code before it goes out another opinion that’s kind of related to testing is that the customer is not always right when building a new piece of software you generally start with some requirements from a customer project

The Customer

7:30 · manager or some other kind of stakeholder and it’s not like a blueprint for constructing a building these requirements are very likely to change multiple times throughout the project for non-technical people software development seems like black magic and it’s very important for you the developer to communicate when you recognize something as a bad idea or something that’s going to take a ton of time to refactor when i first started doing freelance work i took the approach that the customer was always right and ended up working many hours for free just to make the customer happy and i really only blame myself because it’s my fault for not being a good enough communicator but in some cases you may

8:01 · end up with a very difficult client and for that reason i generally recommend people do their billing on an hourly rate as opposed to a lump sum for an entire project because it’s more transparent and allows for a clean break if things go really south what a divorce divorce i knew we had something in common yeah sign these and with that

Comments

8:19 · we’ve reached the final opinion most comments in code are in fact a pernicious form of code duplication or on a related note readability is the most important aspect of your code for the most part i agree with these opinions i think writing code that is simple and self-describing is the ultimate goal we should strive for the reality though is that even if you write perfectly readable code i might be able to tell what it’s doing but not why it’s there in the first place comments that explain why something exists tend to be the most valuable another big question here is should you write code that is optimized for readability or performance

8:50 · in javascript i can write a for each loop which is nice and readable but it doesn’t perform nearly as well as a traditional for loop when faced with a situation like that i start by writing the most readable code and if performance does in fact become a problem then i may optimize it in the future but ninety percent of the time it’s too insignificant to even matter i’m going to go ahead and wrap things up there don’t forget to hit the like button and make sure to leave your own controversial opinion in the comments below thanks for watching and i will see you in the next one

Graph View

Recent Notes

Backlinks