[HN Gopher] Beyond agentic coding
___________________________________________________________________
Beyond agentic coding
Author : RebelPotato
Score : 232 points
Date : 2026-02-08 01:55 UTC (21 hours ago)
(HTM) web link (haskellforall.com)
(TXT) w3m dump (haskellforall.com)
| Insanity wrote:
| Post had nothing to do with Haskell so the title is a bit
| misleading. But rest of article is good, and I actually think
| that Agentic/AI coding will probably evolve in this way.
|
| The current tools are the infancy of AI assisted coding. It's
| like the MS-DOS era. Over time maybe the backpropagating from
| "your comfort language" to "target language" could become
| commonplace.
| ipnon wrote:
| Programming languages are most interesting area in CS for the
| next 10 years. AI need criteria for correctness that can't be
| faked so the boundary between proof verification and programs
| will become fuzzier and fuzzier. The runtimes also need support
| for massively parallel development in a way that is totally
| unnecessary for humans.
| josephcsible wrote:
| > Post had nothing to do with Haskell so the title is a bit
| misleading.
|
| To be fair, that's not part of the article's title, but rather
| the title of the website that the article was posted to.
| Insanity wrote:
| I know, but that's not typically how you see titles posted
| here. I'm just disappointed as I enjoy writing Haskell. :)
| yoyohello13 wrote:
| I was excited to see a non-AI article on this site for once. Oh
| well.
|
| It was a good article though
| lordgrenville wrote:
| Agreed. This website seems to prepend the blog name to each
| page's document.title
|
| Would suggest that one of the mods remove it
| shevy-java wrote:
| Is the article good? I found it of a surprisingly poor quality.
| Is my assessment incorrect? Basically it is an article that
| tries to convince people of how relevant AI is nowadays. I
| don't really see it like that at all and none of the
| "arguments" I found convincing.
| nakedneuron wrote:
| Agree. Gist of the FA is about "calm technology". Title should
| reflect it better.
|
| Also agree on everything author mentions. I can't attest to all
| examples but I know what a UI is.
|
| Author mentions center of focus of attention. We should hear
| more often about the periphery of our attention field. Its
| bandwidth so to speak is a magnitude lower compared to the
| center but it's still there and can guide some decisions quite
| unintrusively to flow.
|
| (Major) eye movements are a detriment to attention, which
| itself should be treated like a commodity (in case of a UI
| thousands use, moreso like a borrowed commodity).
| OutOfHere wrote:
| Agentic coding doesn't make any sense for a job interview. To do
| it well requires a detailed specification prompt which can't
| reliably be written in an interview. It ideally also requires
| iterating upon the prompt to refine it before execution. You get
| out of it what you put into it.
| charcircuit wrote:
| >which can't reliably be written in an interview
|
| Why not? It sounds like a skill issue to me.
|
| >It ideally also requires iterating upon the prompt to refine
| it before execution.
|
| I don't understand. It's not like you would need to one shot
| it.
| OutOfHere wrote:
| It's a time issue. Interviews hardly offer much time as it
| is. To ask for something that benefits from multiple
| iterations is probably not going to fit in the available
| time.
| simonw wrote:
| How about bug fixing? Give someone a repo with a tricky bug,
| ask them to figure it out with the help of their coding agent
| of choice.
| OutOfHere wrote:
| It doesn't have to be a "tricky" bug. A straightforward bug
| will do. If it's too tricky, the logic could be better off
| being rewritten.
| zarzavat wrote:
| In the UK the driving test requires a portion of driving using
| a satnav, the idea being that drivers _are_ going to use
| satnavs so it 's important to test that they know how how to
| use them safely.
|
| The same goes for using Claude in a programming interview. If
| the environment of interview is not representative of how
| people actually work then the interview needs to be changed.
| shash wrote:
| In the Before Times we used to do programming interviews with
| "you can use Google and stack overflow" for precisely this
| reason. We weren't testing for encyclopaedic knowledge - we
| were testing to see if the candidate could solve a problem.
|
| But the hard part is designing the problem so that it
| exercises skill.
| adhamsalama wrote:
| We don't solve LeetCode for a living yet it is asked in
| interviews anyway, so nah, we don't have to use AI in
| interviews.
| EdNutting wrote:
| You've just written the exact reason LeeteCode is widely
| mocked as an interview technique. They are not
| representative of most real world software, and engineers
| that train to solve them give a false impression of their
| ability to solve most other problems.
|
| I've interviewed hundreds of engineers for software and
| hardware roles. A good coding test is based on self-
| contained problems that the team actually encountered while
| developing our product. Boil the problem down to its core,
| create a realistic setup that reflects the information the
| team had when they encountered the challenge, and then ask
| the candidate to think it through. It doesn't matter if
| they only write notes or pseudo code, and it doesn't matter
| if they reach the wrong conclusion. What it's testing for
| is the thought process. The fact the candidate has to ask
| the interviewer questions as though the interviewer is
| effectively the IDE, is great! The interviewer experiences
| the engineer's thought process first-hand. And the
| interviewer can nudge the candidate in the correct
| direction by communicating answers that aren't just typical
| IDE error messages.
|
| To validate these kinds of questions in advance, I'd often
| run them on existing team members that hadn't already been
| exposed to the real challenge the problem was based on.
| bitwize wrote:
| Leetcode's utility is not in showing you can solve real-
| world problems. It's used as a baseline to estimate how
| smart you are. Every shop prides itself on hiring smart
| people, and some only want the best of the best--your MIT
| and Stanford grads, etc. A smarter engineering workforce
| can not only solve the problems you have, they're better
| positioned to spot and avoid problems you haven't
| anticipated yet. Anyways, IQ testing as a condition of
| employment can open you up to legal liability, as IQ
| tests are horribly racist. Leetcode is a way around that.
| tptacek wrote:
| Without commenting on the racial biases of IQ tests (we
| probably directionally agree), the idea that IQ tests in
| employment are legally risky is an Internet myth. The
| companies that offer employment-screening general
| cognitive tests have logo crawls of giant companies that
| use them.
|
| They're not unusual because they're legally risky;
| they're unusual because they don't work well.
| XenophileJKO wrote:
| As someone that agenticly codes A LOT. Detailed specs are not
| required, but certainly one way to use the systems.
|
| If you are going to do a big build out of something, spec up
| front at least to have a clear idea of the application
| architectural boundaries.
|
| If you are adding features to a mature code base, then the
| general order of the day is: First have the Ai scout all the
| code related to the thing you are changing. Then have it give
| you a summary of its general plan of action. Then fire it off
| and review the results (or watch it, less needed now though).
|
| For smaller edits or even significant features, I often just
| give it very short instructions of a few sentences, if I have
| done my job well the code is fairly opinionated and the models
| pick up the patterns well and I don't really have to give much
| guidance. I'll usually just ask for a few touchups like
| introdusing some fluent api nicities.
|
| That being said, I do tend to make a few surgical requests of
| the AI when I review the PR, usually around abraction seams.
|
| (For my play projects I don't even look at the code any more
| unless I hit a wall, and I haven't really hit a wall since Opus
| 4.5, though I do have a material physics simulator that Opus
| 4.5 wrote that runs REALLY slow that I should muck around in,
| but I'm thinking of seeing if Opus 4.6 can move it to the GPU
| by itself first.)
|
| So if I were doing an interview with an interview question. I
| would probably do a "let's break down what we know", "what can
| we apply to this", "ok. let's start with x" and then iterate
| quickly and look at the code to validate as needed.
| OutOfHere wrote:
| There is a real danger here during an interview of unfairly
| imposing one's style on others. I think it's great to share
| one's approach, but making it the only approach can lead to
| stagnation and lose out on picking ideas from alternatives.
| wazHFsRy wrote:
| I have the same feeling recently that we should focus more on
| using AI to enable us, to empower us to do the important things.
| Not take away but enhance, boring , clear boilerplate yes, design
| decisions no. And making reviewing easier is a perfect example of
| enhancing our workflow. Not reviewing for us, but supporting us.
|
| I am recently using this tiny[1] skill to generate an order on
| how to review a PR and it has been very helpful to me.
|
| https://www.dev-log.me/pr_review_navigator_for_claude/
| andai wrote:
| I wonder if the problem of idle time / waiting / breaking flow is
| a function of the slowness. That would be simple to test, because
| there are super fast 1000 tok/s providers now.
|
| (Waiting for Cerebras coding plan to stop being sold out ;)
|
| I've used them for smaller tasks (making small edits), and the
| "realtime" aspect of it does provide a qualitative difference. It
| stops being async and becomes interactive.
|
| A sufficient shift in quantity produces a phase shift in quality.
|
| --
|
| That said, the main issue I find with agentic is my mental model
| getting desynchronized. No matter how fast the models get, it
| takes a fixed amount of time for me to catch up and understand
| what they've done.
|
| The most enjoyable way I've found of staying synced is to stay in
| the driver's seat, and to command many small rapid edits
| manually. (i.e. I have my own homebrew "agent" that's just a loop
| of, I prompt it, it proposes edits, I accept or edit, repeat.)
|
| So then the "synchronization" of the mental state is happening
| continuously, because there is no opportunity for
| desynchronization. Because you are the one driving. I call that
| approach semi-auto, or Power Coding (akin to Power Armor, which
| is wielded manually but greatly enhances speed and strength).
| dybber wrote:
| You still have to synchronize with your code reviewers and
| teammates, so how well you work together in a team becomes a
| limiting factor at some point then I guess.
| tuhgdetzhh wrote:
| Yes, and that constraint shows up surprisingly early.
|
| Even if you eliminate model latency and keep yourself fully
| in sync via a tight human-in-the-loop workflow, the shared
| mental model of the team still advances at human speed. Code
| review, design discussion, and trust-building are all
| bandwidth-limited in ways that do not benefit much from
| faster generation.
|
| There is also an asymmetry: local flow can be optimized
| aggressively, but collaboration introduces checkpoints.
| Reviewers need time to reconstruct intent, not just verify
| correctness. If the rate of change exceeds the team's ability
| to form that understanding, friction increases: longer
| reviews, more rework, or a tendency to rubber-stamp changes.
|
| This suggests a practical ceiling where individual "power
| coding" outpaces team coherence. Past that point, gains need
| to come from improving shared artifacts rather than raw
| output: clearer commit structure, smaller diffs, stronger
| invariants, better automated tests, and more explicit design
| notes. In other words, the limiting factor shifts from
| generation speed to synchronization quality across humans.
| EdNutting wrote:
| This thread seems to have re-identified Amdahl's law in the
| context of software development workflow.
|
| Agentic coding is only speeding up or parallelising a small
| part of the workflow - the rest is still sequential and
| human-driven.
| cyanydeez wrote:
| And its abstracted as
|
| Mythical Man Month -> Mythical Agent Swarm
| james_marks wrote:
| This is 100% the new bottleneck. We're going to see a lot
| agentic QA, E:E testing, etc soon for this reason.
| zozbot234 wrote:
| You can ask the agent to reverse engineer its own design
| and provide a design document that can inform the code
| review discussion. Plus, hopefully human code review would
| only occur after several rounds of the agent refactoring
| its own one-shot slop into something that's up to near-
| human standards of surveyability and maintainability.
| andai wrote:
| I've mostly done solo work, or very small teams with clear
| separation of concerns. But this reads as less of a case
| against power coding, and more of a case against teams!
| hibikir wrote:
| I've seen this happen over and over again well before LLMs,
| when teams are sufficiently "code focused" that they don't
| care much at all about their teammates. The kind that would
| throw a giant architectural changes over a weekend. You
| then get to either freeze a person for days, or end up with
| codebases nobody remembers, because the bigger
| architectural changes are secret.
|
| With a good modern setup, everyone can be that
| "productive", and the only thing that keeps a project
| coherent is if the original design holds, therefore making
| rearchitecture a very rare event. It will also push us to
| have smaller teams in general, just because the idea of
| anyone managing a project with, say, 8 developers writing a
| codebase at full speed seems impossible, just like it was
| when we added enough high performance, talented people to a
| project. It's just harder to keep coherence.
|
| You can see this risk mentioned in The Mythical Man Month
| already. The idea of "The Surgery Team", where in practice
| you only have a couple of people truly owning a codebase,
| and most of the work we used to hand juniors just being
| done via AI. It'd be quite funny if the way we have to
| change our team organization moves towards old
| recommendations.
| rubenflamshep wrote:
| > That said, the main issue I find with agentic is my mental
| model getting desynchronized. No matter how fast the models
| get, it takes a fixed amount of time for me to catch up and
| understand what they've done.
|
| This is why I'm so skeptical of anyone running 6+ Claude
| sessions at a time. I've gotten to 5 but really that was across
| 3 sessions with 2 standing by just to commit stuff. And even
| with just 3 sessions I constantly lost where I was and wasted
| time re-orienting myself, doing work in the wrong session, etc.
|
| >The most enjoyable way I've found of staying synced is to stay
| in the driver's seat, and to command many small rapid edits
| manually.
|
| Same, there's a fantastic flow state/momentum I can get in a
| single session just knocking off features. I don't mind
| switching between two sessions in this state but the experience
| is better when it's two different projects vs two different
| features on the same project. The complete context switch lets
| be re-orient more easily
| resize2996 wrote:
| Warning: I was in two different project experimenting with
| similar forms of db access at the same time. don't do that.
| sourabhrakhya wrote:
| same
| port11 wrote:
| Waiting on AI is its own category, so I'm not entirely sure
| what 'idle time' means. Of course we could just go and read
| that study...
| roughly wrote:
| The "Calm technology" thing always annoys me, because it skips
| every economic, social, and psychological reason for the current
| state of affairs and presents itself as some kind of wondrous
| discovery, as opposed to "the way things were before we invented
| the MBA." A willing blindness to predators doesn't provide a
| particularly useful toolkit.
| pringk02 wrote:
| I would be interested to hear you elaborate on this more. I
| feel like I almost get what you are saying but am not confident
| I actually understand.
| roughly wrote:
| Yeah, so - the whole Calm Technology((tm)) feels like someone
| looked at the dopamine casino of modern tech and said "well,
| this is all wrong" - which, yes - and then proceeded to try
| to treat it like a design problem, which it is emphatically
| _not_. Not only are the people who made the dopamine casino
| aware of what makes "calm technology"((tm)), they're experts
| in it, because the entire design process of most modern tech
| is explicitly designed _not_ to be "calm," because the
| _entire economic incentive structure_ is pushing dopamine
| casinos. People aren 't building "uncalm" technology by
| mistake, they're building it because the modern tech business
| structure and environment rewards addictive software.
|
| If the "Calm Tech"((tm)) people/institute/whatever actually
| wanted to move the needle, they'd be lobbying for
| regulations, building tools for consumers to fight back, or
| trying to do anything at all that actually shifts the
| underlying institutional and incentive structures. As it
| sits, they're the equivalent of a recess monitor suggesting
| maybe the bully would be happier if he shared the toys with
| the other kids - and frankly, given the degree of branding
| around the whole thing, it all starts to smell more like
| "influencer" than "genuine attempt to improve technology."
| eigenblake wrote:
| I have been considering what it would be like to give each
| function name a specific color and a color for each variable's
| type followed by a color derived from the hash of the symbol name
| and keywords would each be their specific type. And essentially
| printing a matrix of this, essentially transforming your code
| into a printable matrix "low-lod" or "mipmap" form. This could be
| implemented like the VSCode minimap but I the right move here is
| to implement it as a hook that can modify the output of your
| agent. That way you can look at the structure of the code without
| reading the names in particular.
| nakedneuron wrote:
| Great idea. As a "visual type" this would be so much more
| intuitive to decipher. I prefer TUIs over GUI exactly because
| they're simpler and work hard to focus on the essential. This
| is low hanging fruit to enhance TUIs.
| kstenerud wrote:
| What I've found is that most people who dislike the chat
| interface aren't using it in a way that leverages its strengths.
|
| Up until recently, LLMs just plain sucked. You'd set them on a
| task and then spend hours hand-holding them to output something
| almost correct.
|
| Nowadays you can have a conversation with the chatbot, hash out a
| design, rubber duck and discuss what-ifs until you have a solid
| idea of the thing you're building, codified in a way an agent
| could understand, and now you have a PLAN.
|
| From there, it's a matter of setting the agent in motion and
| checking from time to time to make sure it's not getting stuck on
| something under-specified.
|
| That said, I've found that this kind of workflow works a lot
| better with claude than with gemini.
| tossandthrow wrote:
| I whole heartedly prefer chat interfaces over inline ai
| suggestions.
|
| I find the inline stuff so incredibly annoying because they move
| around the text I am looking at.
| coffeefirst wrote:
| Same! It feels like being shouted at nonstop by an overeager
| teacher's pet who's wrong 60% of the time.
|
| I do appreciate in-IDE functionality that can search the
| codebase etc etc, but I want to hit a button when I need it.
| benob wrote:
| I really like the "file lens" example:
|
| > "Focus on..." would allow the user to specify what they're
| interested in changing and present only files and lines of code
| related to their specified interest.
|
| > "Edit as..." would allow the user to edit the file or selected
| code as if it were a different programming language or file
| format.
| AIorNot wrote:
| "Facet-based project navigation You could browse a project by a
| tree of semantic facets. For example, if you were editing the
| Haskell implementation of Dhall the tree viewer might look like
| this prototype I hacked up2"
|
| ^ This is a genius idea - someone add this to claude
| plaguuuuuu wrote:
| At work we use Clean Architecture which is _incredibly_ hard to
| browse, even though I 've been there for 6+ months now and know
| where everything is, I have to use so much working memory to
| gather together the files for a feature slice (endpoint,
| command, command handler, etc).
|
| I've thought for a while of building this exact thing as a
| vscode extension because of how utterly shit it is :D
|
| I really want the source code!
| Gabriel439 wrote:
| Author here: the source code is linked in the post but it can
| be easy to miss: https://github.com/Gabriella439/facet-
| navigator
|
| It's very rough, but I plan on cleaning it up soon (the
| cluster labeler still needs a lot of work) and writing
| another post about it soon
| matheus-rr wrote:
| The "junior dev" analogy is the one I keep coming back to, but
| the part people miss is the review surface area problem.
|
| When a human junior writes code, they leave breadcrumbs of their
| thinking -- commit messages, PR descriptions, comments explaining
| why they chose approach A over B. You can reconstruct their
| reasoning from the artifact trail.
|
| Agents don't do this naturally. You get a diff with no context
| for why it went that direction. So the reviewer has to reverse-
| engineer the thinking from the code alone, which is actually
| harder than reviewing human code because there are no "tells" --
| no familiar coding style, no consistent patterns that hint at the
| developer's mental model.
|
| The semi-auto approach mentioned upthread works precisely because
| it solves this: you were there for every decision, so there's
| nothing to reconstruct. The productivity loss from staying in the
| loop is offset by the time you save not having to audit opaque
| changes after the fact.
| wazHFsRy wrote:
| Also with your real junior dev you build trust over time. With
| the agent I start over at a low trust level again and again so
| far.
| shevy-java wrote:
| > I believe there is a lot of untapped potential in AI-assisted
| coding tools
|
| Yikes.
|
| By the way, the whole website is strange. Just the name alone
| "haskell for all".
|
| Many years ago when I tried to learn Haskell (and wrote some
| haskell code that worked but it was sooooo much harder when
| compared to ruby or python), one of the few things that appeared
| early on, aside from the monad barrier, was that many haskell
| people said that Haskell is deliberately not for everyone. Back
| then this was when IRC was still en vogue, so I "heard" that via
| various discussions on #haskell.
|
| I did not fully understand this part, because ... why would you
| write a language that only a few big brain people could use? I
| found that elitistic and snobbish, even arrogant.
|
| Only at a later time did I understand one part of the meaning.
| The "we don't want you here" also means "we don't want YOU to
| change haskell into some other new meta-variant". I understood
| this much better when some guys wanted to have ruby embrace
| types. Then I understood that people not only want to change a
| language but also want to ruin it; whether on purpose or because
| they prefer something else (such as their brain embraced types-
| only code bases) is a separate discussion. I still find the
| haskell attitude very elitistic but I at the least understand
| that they don't want everyone to use - and change - Haskell.
|
| > For example, someone who was new to Haskell could edit a
| Haskell file "as Python" and then after finishing their edits the
| AI attempts to back-propagate their changes to Haskell.
|
| I like the general idea behind "write in any language, have it
| work in EVERY language". But the whole AI movement seems more
| about trying to dumb down people really or make them lazy, in
| many ways. I have seen people use it to great effect, so I am not
| at all saying AI has no use cases. What I am however had noticing
| is that it made many normal folks super-lazy. They type on their
| smartphone, solution comes out, task finished, move on. That's
| not necessarily only bad, but it comes with trade-offs. My
| approach is much slower, but it is systematic and I am in full
| control of what is documented how and where.
|
| > This is obviously not a comprehensive list of ideas, but I
| wrote this to encourage people to think of more innovative ways
| to incorporate AI into people's workflows
|
| Oh he has achieved this in a different way. Now I have another
| reason to not want AI in my "workflows". The whole website also
| seems super-strange to me. Has he used AI to write the whole
| content and layout? It's hard to say because I don't know how it
| used to be in the past, but the paragraphs and the content seem
| so strange. I suspect he used AI to generate the layout too; and
| some of the content as well. We are losing "interaction" with
| real humans here too (ok ok, there is not a lot of interaction
| with regards to a static website, but if a blog is written by AI,
| then that is not really any possibility for interaction with a
| human - you could not even distinguish WHO wrote the content or
| made the decisions such as which style to choose and so forth; it
| looks very fake to me or, at the least, in part. I typically
| don't see this with other blogs.).
| Gabriel439 wrote:
| Author here: my pronouns are she/her
|
| I did not use AI to generate my blog's content nor layout.
|
| Also, the reason my blog is named "Haskell for all" is because
| I originally created my blog a long time ago to try to make
| Haskell more accessible to people and counter the elitist
| tendencies.
| zeendo wrote:
| Her blog has lots of quality content that's been featured on HN
| several times - well before AI writing became a thing. Not that
| you should necessarily know that but just strong evidence that
| your intuitions here are way off on so many levels.
|
| Your entire take is super strange and presumptive.
| wazHFsRy wrote:
| On the flip side, this finally reads again like something that
| is written by a human for a human, so I'm very glad to get this
| kind of content.
| cess11 wrote:
| "I allow interview candidates to use agentic coding tools and
| candidates who do so consistently performed worse"
|
| I have a similar impression. It seems to me that people get
| something that kind of works and then their interest runs out and
| they're left with a shallow understanding of the result and how
| it might be achieved. This seems detrimental to learning, which
| tends to happen when one is struggling.
|
| "I strongly believe that chat is the least interesting interface
| to LLMs"
|
| This is also something I agree with. When I work with databases,
| the best part is not sitting with an immediate client writing raw
| queries by hand.
| WilcoKruijer wrote:
| > You could take an editor session, a diff, or a pull request and
| automatically split it into a series of more focused commits that
| are easier for people to review. This is one of the cases where
| the AI can reduce human review labor
|
| I feel this should be a bigger focus than it is. All the AI code
| review start up are mostly doing "hands off" code review. It's
| just an agent reviewing everything.
|
| Why not have an agent create a perfect "review plan" for human
| consumption? Split the review up in parts that can be
| individually (or independently) reviewed and then fixed by the
| coding agent. Have a proper ordering in files (GitHub shows files
| in a commit alphabetically, which is suboptimal), and hide boring
| details like function implementations that can be easily unit
| tested.
| jasonjmcghee wrote:
| Yes please. There are many use cases where failure modes are
| similar to not using AI at all, which is useful.
|
| Many very low risk applications of AI can add up to high payoff
| without high risk.
| telotortium wrote:
| Unfortunately GitHub doesn't let you easily review commits in a
| PR. You can easily selectively review files, but comments are
| assumed to apply to the most recent HEAD of the PR branch. This
| is probably why review agents don't natively use that workflow.
| It would probably not be hard to instruct the released versions
| of Opus or Codex to do this, however, particularly if you can
| generate a PR plan, either via human or model.
| SatvikBeri wrote:
| I do this. For example, the other day I made a commit where I
| renamed some fields of a struct and removed others, then I
| realized it would be easier to review if those were two
| separate commits. But it was hard to split them out
| mechanically, so I asked Claude to do it, creating two new
| commits whose end result must match the old one and must both
| past tests. It works quite well.
| wazHFsRy wrote:
| > Why not have an agent create a perfect "review plan" for
| human consumption? Split the review up in parts that can be
| individually (or independently) reviewed and then fixed by the
| coding agent. Have a proper ordering in files (GitHub shows
| files in a commit alphabetically, which is suboptimal), and
| hide boring details like function implementations that can be
| easily unit tested.
|
| Yes exactly! I have been using this to create a comment on the
| PR, showing suggested review order and a diagram of how changes
| relate to each other. And even this super simple addition has
| been very helpful for code review so far!
|
| (more on this: https://www.dev-
| log.me/pr_review_navigator_for_claude/)
| jonfw wrote:
| "I have a PR from <feature-branch> into main. Please break it
| into chunks and dispatch a background agent to review each
| chunk for <review-criteria>, and then go through the chunks one
| at a time with me, pausing between each for my feedback"
| zmj wrote:
| I like this thought. Scaling review is definitely a bottleneck
| (for those of us who are still reading the code), and spending
| some tokens to make it easier seems worthwhile.
| kloud wrote:
| Exactly this, existing code review tools became insufficient
| with the increase of volume of code, I would like to see more
| innovation here.
|
| One idea that comes to mind to make review easier would be to
| re-create commits following Kent Beck's SB Changes concept -
| splitting structure changes (tidying/refactoring) and behavior
| changes (features). The structure changes could then be quickly
| skimmed (especially with good coverage) and it should save
| focus for review of the behavior changes.
|
| The challenge is that it is not the same as just committing the
| hunks in different order. But maybe a skill with basic agent
| loop could work with capabilities of models nowadays.
| WilcoKruijer wrote:
| I experimented with a command for atomic commits a while ago.
| It explicitly instructed the agent to review the diff and
| group related changes to produce a commit history where every
| HEAD state would work correctly. I tried to get it to use
| `git add -p`, but it never seemed to follow those
| instructions. Might be time for another go at this with a
| skill.
| CuriouslyC wrote:
| I've been talking about having AI add comments to PRs to draw
| attention to things that should be given special attention
| since last May. I think most code review tools don't do this
| because A/B testing has shown people engage less/churn more
| with noisier review output.
| camgunz wrote:
| The only way AI companies can recover their capex is to replace
| workers. That's why their interfaces are only facially built for
| the workers they're replacing (engineers, finance, etc) and why
| this is a non-starter: it totally undermines the business model.
| agnishom wrote:
| This is an amazing article. The HN title should be edited a bit.
| "Calm Technology - Beyond Agentic Coding"
| nakedneuron wrote:
| Hard agree.
| brightstep wrote:
| > A tool is not meant to be the object of our attention; rather
| the tool should reveal the true object of our attention (the
| thing the tool acts upon), rather than obscuring it
|
| I think this is true of AI agents. What is the object of our
| engineering attention? Applications, features, defect resolution.
| Not code.
| Gabriel439 wrote:
| Author here: yeah, this is a good point and something I think
| about even outside the context of agentic coding.
|
| I've also tinkered with this idea myself in the context of
| prompt engineering with my Grace Browser project
| (https://trygrace.dev/), which converts code to an equivalent
| dynamic web form live within your browser.
|
| I do think it's useful to remember that code is not the end
| goal and is itself just another mediated interface to the
| actual goal: the product your building. However, I think even
| if you cut code out of the picture the chat interface is still
| not necessarily the right interface for building a product. A
| great example of how to build a non-chat interface to product
| building (predating the AI boom) is Bret Victor's Inventing on
| Principle talk (https://www.youtube.com/watch?v=PUv66718DII)
| and there might be ways we can refresh the ideas in that talk
| for the AI era (although I still don't have any specific
| thoughts along those lines yet).
| brightstep wrote:
| Totally agree about the chat interface. I like to say it's
| "infinitely powerful and infinitely confusing." A dangerous
| combination. And, arguing with myself, I think it's fair to
| say the code is AN object of our attention, if not THE
| object. A common metaphor being applied to agentic coding is
| the invention of power tools. If AI is the drill, and the
| goal is a house, then the code is the framing.
| Narciss wrote:
| I did a bit of digging into why you think agentic coding is "not
| there yet", and I think you are bashing a tool you have very
| little experience with and are using a bit wrongly.
|
| Nothing wrong with that, except that as opposed to any other tool
| that is out there, agentic coding is approached by smart senior
| engineers that would otherwise spend time reading documentation
| and understanding a new package/tool/framework before giving
| conclusions around it with "I spun up Claude code and it's not
| working". Dunno why the same level of diligence isn't applied to
| agentic coding as well.
|
| First question that I always have to such engineers is "what
| model have you tried?" And it always ends up being the non-SOTA
| models for tasks that are not simple. Have you tried Claude Opus?
|
| Second question: have you tried plan mode?
|
| And then I politely ask them to read some documentation on using
| these tools, because the simplicity of the chat interface is
| deceptive.
| zazibar wrote:
| A "you're holding it wrong" with the implication that the
| author is a bad engineer as the cherry on top. Brilliant stuff.
| Narciss wrote:
| Definitely didn't want to imply that the author is a bad
| engineer, quite the contrary he seems like a very good one.
| Apologies if it came across that way.
|
| Just that many brilliant engineers as themselves test agentic
| tools without the same level of thorough understanding that
| they give to other software engineering tools that they test
| out.
| mjburgess wrote:
| VibeTFM
| Narciss wrote:
| hmm didn't get the pun...Time to turn to chatGPT :))
| jmull wrote:
| It doesn't look like you addressed issues raised in the
| article. E.g., see the "my experiences interviewing candidates"
| section where we can see this isn't just a problem of the
| author's (just one example in one section of an article that
| covers various things).
|
| I always wonder what the purpose of posting these generic,
| superficial defenses of a certain form of LLM-based coding is?
| Narciss wrote:
| That was a different matter altogether. I agree though that I
| didn't touch on that.
|
| My experience is different in that case, but it certainly
| depends on the type of technical challenge, the programming
| language, etc.
|
| Candidates that perform better or worse exist with and
| without agentic coding tools. I've had positive and negative
| experience on both fronts, so I'd attribute the OP's
| experience to the N=1 problem, and perhaps to the model's
| jagged intelligence.
|
| I work mostly in Typescript, and it's well known that models
| are particulary well versed in it. I know that other
| programming languages are less supported because the training
| data for them is lower, in which case models could be worse
| with them across the board (or some SOTA models could be
| better than others)
| resize2996 wrote:
| find the reflections in the rushing river
| deanc wrote:
| All the problems highlighted with agentic coding are problems you
| face when working as a team of humans. Apply the same principles:
|
| - Break down big problems into smaller ones
|
| - Create extensive plan + documentation (context)
|
| - Make sure some parts of the plan if possible can be done
| simultaneously and not create too many dependencies.
|
| - Define success criteria (tests?)
|
| Then just unleash the agents. The more you put in, the more you
| get out.
| danielvaughn wrote:
| Generally agree with the idea of calm technology, but I feel like
| inlay hints are a bad example. They actively give me anxiety
| because it makes the code feel harder to read, it takes my
| attention away from the code, and it feels more awkward to edit
| the text because you have these virtual characters getting in the
| way and having to re-render as you type, causing a shift in your
| cursor position. It's not at all calming for me, lol.
| clarity_hacker wrote:
| The review ordering problem is less about AI generation and more
| about graph traversal. Every diff already encodes a dependency
| graph (imports, function calls, type references), and optimal
| review order is just a topological sort weighted by cognitive
| load. GitHub's alphabetical ordering is zero-information when we
| have the full call graph. The hard part isn't producing the
| ordering -- it's efficiently extracting and maintaining the
| dependency graph as code changes.
| totaa wrote:
| any extensions / third-party tools to visualise this?
___________________________________________________________________
(page generated 2026-02-08 23:01 UTC)