HN user

nimonian

316 karma
Posts1
Comments109
View on HN

The article presents hypothesis as fact with insufficient science. I have no problem discussing speculation, but if the author wants to promote their claims to any more than that I would want to see more journalism.

This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think."

I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data structures and ideas; less and less in lines of code.

And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide.

The idea is the hard part, and it's the right place to focus your effort.

Online chess is taken seriously as an e-sport, especially at the top levels, and is played for cash prizes. Imagine if the best cs:go or competitive programmers were found to be cheating. They would be ostracized.

Very close to this at my company. We have docs each of which having its description in the yaml. An MCP tool lists the doc sections, a full section with its descriptions, or the entire contents of a doc. A kind of progressive disclosure. Works really well. We even write "skills" this way so they can be used in all our chat environments.

Fable is really good at front end (Opus 4.8 is decent too) but it really needs a verification loop - it can't always infer the output from the code alone. Give it Playwright to check its work, and it'll generally do a good job. Also if you're using a framework, add to your CLAUDE.md to always rtfm before making changes!

I do quite a lot of what this post describes in a reasonably large project. Here's what works for me:

- write gherkin features for new features; update them for enhancements; don't touch them for refactors. Label your PRs with these nouns.

- use pre-push hooks for type checks, linting, unit tests, and other quick, scriptable validations.

- make a viteperess subsite in your repo, have the agents maintain it - document important principles, architecture, etc.

- make a cli command which lists all pages along with the yaml frontmatter description so agents can choose what to read without blowing up the context window.

- use ddd and monorepo - write your logic in headless layers, and compose layers into apps. agents navigate layers very successfully.

- use zod (or your language equivalent) and contract-first API development; this is my favourite bit tbh, I use orpc

- make a single skill called "code" which describes the lifecycle: open a worktree, setup .env to guarantee no conflict with other agents (choose unused ports etc - docker is good here), write or update feature file (this is where you negotiate the spec), implement, validate (e.g. using playwright mcp), pre-push checks, push and wait for review, tear down and fast forward main

- testcontainers is great for ensuring multiple agents can run tests that don't conflict

Seriously I only have one skill that's it. Everything else is in the docs. I'm feeling very productive like this, in a "making good software" sense not a LoC sense.

Ghostty with Claude Code. That's pretty much it.

For each new feature, I open a worktree, spar with Claude to work up a gherkin spec with @todo on each story. Each agent pushes commits to a WIP PR in GitHub where I review and leave comments or questions. Once the spec is done we mainly interact on the PR. @todo becomes @wip and @done as the agent progresses. I really like gherkin for agentic engineering, it's very clarifying.

I have about 2-4 agents running at a time. Large test suite, linters and formatters enforced on push.

If you think of it as being an accumulator function it can feel a bit more natural - the _definition_ of this accumulator is that, F(x) is the area from 0 to x

The fact that the derivative of this accumulator function is equal to the original function, this is the fundamental theorem of calculus, and I violently agree with you that this part is shockingly, unexpectedly beautiful

I'm with you on this (I think). Digitising my org is much easier if I can assume my colleagues' agents will be acting on their behalf. Even if I can't convince most humans to cooperate with solutions, I can usually trust their agents to do so. MCP hides the wiring somewhat, which I enjoy.

I am building _exactly_ this for my org for the past month, using Nuxt Content.

A "draft" is a row in a database with live preview. Users can click a button to make a checkpoint (git commit, by GitHub API, but they don't know that). When they click "publish", the PR for their draft is merged.

Writers in my team can use a nice Tiptap editor with custom components. I get the change management of git.

The API for reading content and editing drafts is also exposed over MCP meaning AI can collaborate in the authoring process from anywhere that can connect to MCP.

Loving it so far.

I still believe looking up the answer in the back of the book is completely fine. It creates a moment of tension. It invites you to justify in your own head that the answer is right before checking. The cognitive dissonance when you see your answer is wrong and really have to challenge yourself, or ask your neighbour, to see why - is all really valuable.

I just don't think "instant feedback" is as important as we think in mathematics education, and might even rob us of moments to practice mathematical behaviours like justifying, communicating and accommodating. Slow feedback does have benefits.

I am a tech enthusiast to put it mildly. I also taught maths in schools from roughly 2010 to 2020 so saw the iPad/app revolution in my classrooms. Anecdotally, I think it made my lessons and my students worse. Books, paper and each other are the best tools (in my very personal opinion).

Sorry for the late reply. When I was studying my A Level physics me and my teacher read Angels and Demons at the same time. It is a silly story really but just scratched that sci-fi bit of my brain in the right way at the right time. It is pulp fiction but sometimes that's just what you want.

I consider this a form of performance art. To really expose the absurdity of the system, you can't just point at the cracks; you need to actually stick your fingers in.

I completely agree. This is a good list, but a poor prompt.

Also, I sometimes find a sort of Streisand effect: when you tell the LLM to avoid something is starts doing it more. Like, if you say "don't use delve" it contains the words "use delve" which, amongst a larger context, seems to get picked up.

I have more success telling the LLM to write in the style of a particular author I like. It seems to activate different linguistic patterns and feel less generic.

Then, I make an "editor agent" comb through, looking for tropes and rewording them. Their sole focus is eliminating the tropes, which seems to work better.

This seems crazy to me. I am a PM and I am busier than ever. People are waking up to the idea that code is cheap and things can change faster now, so deciding _what_ to make and prioritise in the deluge of ideas coming to prod is becoming completely essential.

One thing LLMs don't have is taste. That's on me.

I've been on hn for years and I see this kind of sentiment raised all the time. It is not my understanding of the guidelines.

Politics and ideology are not off topic, provided the subject matter is of interest, or "gratifying", to colleagues in the tech/start-up space.

What's important is that we don't use rhetoric, bad faith or argumentation to force our views on others. But expressing our opinions about how policy affects technology and vice versa has always been welcome, in my observation.

So, what do you think about the US government's decision, and why?

Layoffs at Block 5 months ago

40%

More to your point, to get from 6,000 back up to 10,000 requires a 67% increase in productivity on the remaining 6,000!