jon allie

221

Jonny Langefeld@jonnylangefeld·2h

The parts a human owns has to become larger areas of responsibility than before. It can’t be anymore what we used to put in a ticket to be one PR. It’s faster to write the prompt for that than writing the ticket. Merge conflicts however I found pretty easy to resolve via the agent.

English

0

1

316

jon allie@jonallie·2d

Half-formed shower thought: we need a better version control paradigm for AI assisted coding. The agent speedup feels great on greenfield/solo projects, but when you start collaborating with other devs, things can fall apart. Either you all exchange huge PRs (abandoning code review, and dealing with gnarly merge conflicts), or stick to a traditional flow with reasonably sized changes, in which case you spend a lot of time waiting for changes to land. Old style version control systems had the notion of files being "checked out" by a user. This was painful, but was a pretty good signal that someone was making changes to a set of files that might affect what you wanted to do. Obviously that had huge downsides, but I wonder if that "signal" doesn't still have value. In theory you could get something like this from git, with automatic / frequent push and pulls. You'd have to deal with the messy commit history, but...maybe the existing "functional chunk commits" strategy is an anachronism

English

78

47

1K

484.4K

jon allie@jonallie·2h

Since I got unexpectedly popular, I've gotten a few replies that are variations on "I want to code, not write essays" In a lot of ways I'm very sympathetic to this argument. I was (relatively) late to programming, but fell in love with it, and took a lot of pride in being good at it. As my career progressed, my day-to-day work changed. It turns out, when projects get large, you need a lot of people moving in the same direction to make them work, and although I continued to make time for writing code myself, a large fraction of my time shifted to writing docs, doing code reviews, and offering advice. It turns out, I was already programming in English, although I admit that it didn't always feel as satisfying as doing it the old-fashioned way. I'm not the first person to observe that agentic coding is very exciting for people who are/were in the same boat. Those same skills can be applied more directly to the computer, and although you are still "programming in English", it _feels_ the same way that programming always did. I also want to be clear that I don't subscribe to the "outcome maximalist" view that the program itself is unimportant, and that all that matters is how fast you can produce some barely working thing to push into the market. Correctness, efficiency, and security still matter. This remains true whether your "compiler" reads Rust source code or English. It's interesting to consider that "programming" or "coding" used to refer to the physical keying of code into the computer, and was considered distinct from the design of the system itself. Although this is an anachronism today, it does capture the essential point that typing and engineering are separable things. I first learned to program in perl, and then moved to python. These days I write most of my code in Go or Zig. All of these have different features that let me express logic in a different way. Writing code in python isn't "fake" because I don't have to think (explicitly) about every memory allocation, and I don't think "programming in English " has to be fake either

English

2

21

2K

jon allie@jonallie·7h

These days, 99% of my "work" coding is agent assisted, but outside of work, I still do a lot of programming by hand. For this, I follow nearly the opposite of my agentic coding advice: I pick languages and problems I'm not familiar with, and type everything into vim. (Most recently, implementing 9P in Zig) Partly, I do this because I enjoy the process of programming, just like I enjoy tabletop games, but partly I do it for the same reason that I lift weights...doing hard things builds strength that I can apply to other areas. As I hinted in my post about getting started with agents, just because the agent is typing, doesn't mean that I'm not deeply involved. Instead, I find that I get the most return with agents when I can apply the knowledge I've acquired over years of "regular" coding and systems design. Being able to leverage agents if I want to "get things done", and reserving my personal programming time to learn is, in many ways, incredibly freeing

English

4

3

58

4.2K

jon allie@jonallie·11h

@btwphones I don't know, but I strongly suspect that agents are subject to the same quadratic growth in communication overhead that plagues large human organizations

English

0

6

1.5K

Ben Stephens@btwphones·11h

@jonallie Is part of the answer to have an org chart for your agents, an org chart for their agents and then define how the two org charts interact around PRs? Ie is the problem that we aren’t breaking down work across enough agents clearly enough?

English

0

2

2K

jon allie@jonallie·13h

@_belioff Not in parallel, but something I probably should have included is that I try to keep sessions "short", and generally restart the agent after each logical chunk in order to benefit from a fresh context window

English

1

12

1.5K

Belioff@_belioff·13h

@jonallie Great read. What happens between step 4 and 5 - do you create a separate agent for each task?

English

0

1.8K

jon allie@jonallie·13h

For engineers that are struggling to use (or see the value in) agent assisted coding, give this a try: 1. Pick a domain and language that you know really well. You should be confident that you could implement a good version of whatever you want to build, given enough time. 2. Write a design document (with the same care that you would for a team of humans). Include things like tech choices and invariants. 3. Ignore people talking about one-shot prompting, agent swarms, etc, and start by telling the agent to read your doc and confirm its understanding. 4. Ask the agent to make an implementation plan, decompose the plan into work items and record them (I use a local issue tracker.. separate post) 5. Read every diff. Correct and critique the agent's work as if you were mentoring a junior developer. For senior engineers, this isn't that much different than what you probably do anyway, except that the agent is always available, faster at typing, and happy to do painful refactors without complaint.

English

26

36

396

30K

jon allie@jonallie·14h

I actually hope that people do read and meaningfully review the important code (for now, at least). I don't think that the increase in merge conflict is purely the result of agents changing the core code more quickly...part of the problem is also that they make it possible to do things that humans weren't doing before..adding tons of new test cases, updating docs and user guides, updating make files, etc (and the other part might be that they fear merge conflicts less than humans do) I generally review every diff my agent generates to the "core code" in my projects (although I admit I don't look closely at the diffs for things like debugging dashboards or test cases), and try to do the same for other people's agent-assisted PRs during code review. To be honest, I'm not sure that humans were always doing a good job at code review either :) Your point about "letting the team see the changes" is partly what I was getting at...if everyone on the team is using an agent-assisted flow, the agents need to be aware of what's changing too

English

0

24

4.5K

Patrick Smith@royalicing·20h

@jonallie The point of GitHub pull requests was the reading experience letting the team see what was being changed. If standards drop where no one cares about the code, or if the code moves so fast you can’t really read it entirely, then PRs are unnecessary friction. Just merge to main.

English

0

36

8.4K

jon allie@jonallie·14h

@yenkel @rony358 At some point, it feels like I'm going to need one of those franchise-style trailers for movies with a lot of sequels :)

English

2

39

yenkel@yenkel·14h

@rony358 @jonallie 🙌

GIF

QME

0

2

148

yenkel@yenkel·1d

finally convinced one of the best engineers I know to start posting more on X he’s an amazing engineer and communicator. has built dist sys at Google, Snowflake and Auth0 I’ve learned a lot from him; now you can too. go give @jonallie a follow

jon allie@jonallie

Half-formed shower thought: we need a better version control paradigm for AI assisted coding. The agent speedup feels great on greenfield/solo projects, but when you start collaborating with other devs, things can fall apart. Either you all exchange huge PRs (abandoning code review, and dealing with gnarly merge conflicts), or stick to a traditional flow with reasonably sized changes, in which case you spend a lot of time waiting for changes to land. Old style version control systems had the notion of files being "checked out" by a user. This was painful, but was a pretty good signal that someone was making changes to a set of files that might affect what you wanted to do. Obviously that had huge downsides, but I wonder if that "signal" doesn't still have value. In theory you could get something like this from git, with automatic / frequent push and pulls. You'd have to deal with the messy commit history, but...maybe the existing "functional chunk commits" strategy is an anachronism

English

17

23

1.2K

444.2K

jon allie@jonallie·14h

@johnlambe You might be on to something here, because I've also been wondering why this workflow fails so quickly with agents, when there are plenty of examples of large numbers of humans collaborating on huge codebases.

English

1

38

8.7K

John Lambe 🇮🇪🇵🇹🇪🇺🌍@johnlambe·19h

@jonallie The Jirafication of software development is partly the cause where many developers work only on a task and are not aware of the overall context of all planned changes. Need to move back to developers having responsibility for a whole major functional area of a complex system.

English

5

0

112

12.8K

jon allie@jonallie·15h

@pxue I'm not sure I agree that merge conflicts don't require human-in-the-loop, because the task isn't solely to make the conflict markers go away, or for the result to compile, but to end up with some union of the conflicting changes that aligns with the long term project goal.

English

0

11

402

Paul Xue@pxue·15h

Here’s a hot take: start pushing merge conflicts to the repo. Let a conflict solver agent deal with it. Human focus on the creative part, who cares about merge conflicts. I’ve implemented this internally and it’s night and day difference in reducing cognitive load.

jon allie@jonallie

Half-formed shower thought: we need a better version control paradigm for AI assisted coding. The agent speedup feels great on greenfield/solo projects, but when you start collaborating with other devs, things can fall apart. Either you all exchange huge PRs (abandoning code review, and dealing with gnarly merge conflicts), or stick to a traditional flow with reasonably sized changes, in which case you spend a lot of time waiting for changes to land. Old style version control systems had the notion of files being "checked out" by a user. This was painful, but was a pretty good signal that someone was making changes to a set of files that might affect what you wanted to do. Obviously that had huge downsides, but I wonder if that "signal" doesn't still have value. In theory you could get something like this from git, with automatic / frequent push and pulls. You'd have to deal with the messy commit history, but...maybe the existing "functional chunk commits" strategy is an anachronism

English

0

7

1.1K

jon allie@jonallie·22h

@yenkel @dirceu @dirceu yooooooo :wave:

English

2

47

yenkel@yenkel·23h

@dirceu @jonallie pure alpha and cigars

English

0

1

595

jon allie@jonallie·23h

Following on from this, I suspect that if/when we solve memory, it will be something that can effectively convert past experiences into "system 1"-like processes, and so it might share more with code generation than something like RAG. As a human, many of the useful things I've learned have become system 1 tasks...I drive, type, and find my way home without thinking about it consciously, and still they have a very low "error rate" and are highly repeatable. On the other hand, most current solutions for agent memory seem either slow and unreliable, or fast but not automatic (and typically feel more like the model is taking an open book test for a class it didn't sign up for)

jon allie@jonallie

Personal rule of thumb: don't use an LLM for something that a deterministic program can do. I get it, LLMs are exciting, but they don't mean that software ceases to exist. They are fantastic at dealing with human language and ambiguity, but are terrible (by design and for good reason) at repeatability. To borrow terminology from the book Thinking Fast and Slow, LLMs are "system 2"...slower, more "expensive" (for LLMs, both in time and dollars), but flexible and creative. Traditional programs are "system 1" ..fast and cheap, but inflexible and dumb. Instead of trying to put an LLM in the "hot loop" of your program, it's usually worth asking an agent to write a deterministic program to do the thing you need done. Since code is "cheap", this deterministic tool can do exactly what you want it to, and doesn't consume tokens on every execution. (This applies to agents too..I find myself regularly yelling at Claude to stop repeatedly generating the same 30 lines of python to inspect a file, and instead telling it to generate a 3-line shell script wrapper around jq that it can check in and call repeatedly)

English

1

52

18.2K

jon allie@jonallie·1d

@yenkel @vidhyarang Any time :)

English

1

32

yenkel@yenkel·1d

@vidhyarang @jonallie in your case you can ping him on slack 😛

English

0

1

851

Vidhya@vidhyarang·1d

@yenkel @jonallie @jonallie in my timeline is a gift. Looking forward to learning from him all over again.❤️

English

0

1

1K

jon allie@jonallie·1d

Personal rule of thumb: don't use an LLM for something that a deterministic program can do. I get it, LLMs are exciting, but they don't mean that software ceases to exist. They are fantastic at dealing with human language and ambiguity, but are terrible (by design and for good reason) at repeatability. To borrow terminology from the book Thinking Fast and Slow, LLMs are "system 2"...slower, more "expensive" (for LLMs, both in time and dollars), but flexible and creative. Traditional programs are "system 1" ..fast and cheap, but inflexible and dumb. Instead of trying to put an LLM in the "hot loop" of your program, it's usually worth asking an agent to write a deterministic program to do the thing you need done. Since code is "cheap", this deterministic tool can do exactly what you want it to, and doesn't consume tokens on every execution. (This applies to agents too..I find myself regularly yelling at Claude to stop repeatedly generating the same 30 lines of python to inspect a file, and instead telling it to generate a 3-line shell script wrapper around jq that it can check in and call repeatedly)

English

81

111

1.1K

87.2K

jon allie@jonallie·1d

@yenkel I _wondered_ why I suddenly got more popular 😅

English

0

14

3K

jon allie@jonallie·1d

@GeoffreyHuntley Yep :) the great thing about the internet is that you only have to publicly wish for something in order to find out that it already exists. Thanks for the pointer , I will experiment

English

4

351

geoff@GeoffreyHuntley·1d

@jonallie that’s roughly perhaps what you are thinking re session logs perhaps :) see github.com/ghuntley/loom/… for treasure

English

0

8

553

jon allie@jonallie·1d

@GeoffreyHuntley Indeed. A nice side effect of this would be the ability to revert both the code and the context to the same point in time. (I'm playing a bunch of old doom mods at the moment, so the analogy that comes to mind is "save scumming" for LLMs).

English

0

3

106

geoff@GeoffreyHuntley·1d

@jonallie what we really need is “prompt governance” as in SBOM but for agent history. at the end of each state machine turn of an agent it does a commit of working directory with the prompt history/prompt used to generate the unit of work so far and the thinking traces.

English

4

0

6

535

jon allie@jonallie·1d

That sounds promising! I could imagine several interesting things to try (near-realtime RSS-style feed of commits/changes from agents, using session logs as "commit messages", dedicated "change coordinator" agents, etc), but I suspect that people who are closer to the problem than I am will likely have better ideas.

English

0

21

10.3K

geoff@GeoffreyHuntley·1d

@jonallie concur. ps. the folks behind JJ are cooking 🧑‍🍳 (not sure if public yet but watch this space!)

English

0

42

13.1K

jon allie@jonallie·2d

Obviously unwise for complex or security critical code, but maybe a (partial) counterbalance to more frequent supply chain attacks

English

3

3.1K

jon allie@jonallie·2d

One thing I have noticed (and like) about agent coding is that it removes some of the temptation to use third-party libraries for trivial problems. If I don't actually have to do the typing, and the implementation is short and obvious, having the LLM write it from scratch is an easy call. Agents mean "death to left-pad"

English