Earlier quoted context omitted.
Do you think O'Reilly would still put an animal on the cover?
A mockingbird?
A bull. Bonus if the background is a china shop.
Technical, cognitive, and intent debt
91–100 of 103 posts
Re: Technical, cognitive, and intent debt
#92It's very nerve-racking for people who like to have a deep understanding of everything they ship. A modernization project that would take you 2 months now can be done in a week or less because you don't need to go deep into the business logic to replicate it and instead you can just focus on designing the boundaries and interfaces properly. Then like the article mentions, just create a good test harness to test parit…
> It's very nerve-racking for people who like to have a deep understanding of everything they ship.
A deep domain knowledge of your industry and your business (company/org) makes you very valuable in your team and your company. I've seen people survive layoffs and other cost-cutting cycles just because they possessed immense knowledge compared to those who did not.
Re: Technical, cognitive, and intent debt
#93Earlier quoted context omitted.
I agree with your sentiment here. However: > if anything, by most traditional forms of evaluating software quality, the projects I work on are better than what they were 5, 10 years ago, using the same metrics as back then. In this side sentence you're introducing so much vagueness. Can you share insights to get some validation on your claim? What metrics are you using and how is your code from 10, 5, 0 years perform…
My anecdotes for using LLMs to modernize legacy (20-year-old systems): - 40x speed improvement - Painless env setup - 20 Second deploy - 90+% test coverage - Ability to quickly refactor - Documentation (The original system that I wrote with one other programmer 20 years ago took 1.5+ years to write. Modern rewrite: 2 days)
> Modern rewrite: 2 days
How much time to verify and validate that large corpus of code that they generated? Not including back and forth to get rid of hallucinations and other mistakes.
Re: Technical, cognitive, and intent debt
#94Earlier quoted context omitted.
My anecdotes for using LLMs to modernize legacy (20-year-old systems): - 40x speed improvement - Painless env setup - 20 Second deploy - 90+% test coverage - Ability to quickly refactor - Documentation (The original system that I wrote with one other programmer 20 years ago took 1.5+ years to write. Modern rewrite: 2 days)
> Modern rewrite: 2 days How much time to verify and validate that large corpus of code that they generated? Not including back and forth to get rid of hallucinations and other mistakes.
Two days total. Using TDD, you can move really fast with AI.
Re: Technical, cognitive, and intent debt
#95Earlier quoted context omitted.
> Modern rewrite: 2 days How much time to verify and validate that large corpus of code that they generated? Not including back and forth to get rid of hallucinations and other mistakes.
Two days total. Using TDD, you can move really fast with AI.
How does the code look? I am curious if there is proper usage of abstractions, or is logic just kind of all over the place?
Some part of me feels like LLM generated code is great if one cares about the solution, but leaves a lot to be desired if one actually cares about code quality. Then again, maybe I am just bad as using LLMs -- I prefer the chat over lettings LLMs do the work for me.
Re: Technical, cognitive, and intent debt
#96Earlier quoted context omitted.
The anecdote the GP is providing there rings true for me too - although I'm not sure if I am going offer better detail. I'm a proponent of architectural styles like MVC, SOLID, hexagonal architecture, etc, and in pre-LLM workflows, "human laziness" often led to technical debt: a developer might lazily leak domain logic into a controller or skip writing an interface just to save time. The code I get the LLM to emit is…
I've recently had the interesting experience of working on a Clean Architecture project for the first time. Pre and post-LLM adoption. It has been... difficult. Services/modules organised by infrastructural layer rather than by feature. A mediator pattern abstracted away the handling of commands. Just in case one day you needed CreateFooCommand to be executed by a different handler, or something, I dunno. It was so h…
> Services/modules organised by infrastructural layer rather than by feature.
That is actually true to the original CA as far as I am aware. The "veritcal slices" style of development came after.
> with the cost of this crushing accidental complexity that made it hard for everyone to hold everything in their heads, not just for me but also for the smart guys on the team.
What? You don't like editing 50 files every time a new column is added to a DB table?
> And it felt like the entire tradeoff was for the purpose of stopping smoothbrains from adding the ORM to an API endpoint
There is nothing wrong with this, and I will die on this hill. The entire purpose of CA was for people to make money off book sales, lectures, and consulting. Notice how every single on of the people involved with promoting CA have absolutely nothing noteworthy to their names. In fact, you might be surprised who was one of the consultants on a major failure of a solution... *cough cough*
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
Re: Technical, cognitive, and intent debt
#97Earlier quoted context omitted.
> If you are thinking through deterministic code, you are thinking through the manipulation of bits in hardware. No I'm not. If I want the machine to evaluate 2+2, I don't know or care what bits in hardware it uses to do that (as long as it doesn't run out of memory), I just want the result to come back as 4.
When you press the 2 button, the plus button, the 2 button and the equals button, you are translating your question into bits and operations which are logically guaranteed to yield bits that represent your answer. When you think through what will happen as a result of deterministic code, you are also thinking through what the bits will do, albeit at a higher level of abstraction. When you ask an LLM to do something,…
> When you press the 2 button, the plus button, the 2 button and the equals button, you are translating your question into bits
I am not. 2 is 2, + is +, I don't care whether the machine chooses to represent them as ASCII or EBCDIC or semaphore flags.
> If you want your answer to 2+2 to always be 4, you shouldn’t use a non deterministic LLM.
Right. Determinism and locality are important. But bit-banging isn't (as long as the higher level abstractions are good).
Re: Technical, cognitive, and intent debt
#98Earlier quoted context omitted.
Two days total. Using TDD, you can move really fast with AI.
How does the code look? I am curious if there is proper usage of abstractions, or is logic just kind of all over the place? Some part of me feels like LLM generated code is great if one cares about the solution, but leaves a lot to be desired if one actually cares about code quality. Then again, maybe I am just bad as using LLMs -- I prefer the chat over lettings LLMs do the work for me.
It is pretty clean. It has two swappable backends. I spent a bit of time refactoring which was easy because I have tests.
Re: Technical, cognitive, and intent debt
#99It's very nerve-racking for people who like to have a deep understanding of everything they ship. A modernization project that would take you 2 months now can be done in a week or less because you don't need to go deep into the business logic to replicate it and instead you can just focus on designing the boundaries and interfaces properly. Then like the article mentions, just create a good test harness to test parit…
You clearly know what you are talking about but I didn't understand about your testing methods explanation at all.
Re: Technical, cognitive, and intent debt
#100Best thing I've read on hacker news in so long. I relate so hard. Simon Willison's stuff on cognitive debt and "your job is to ship code you have proven to work" have led me to work on a project about Intent-Driven Development, because prior intent always seemed to dim with each set of changes. Might put it together into a real protocol and post here on hacker news sometime.
I'm wondering if we're working on the same thing. If you haven't seen my posts I suggest to look through them. In short: 1. stacked-commits automation (cannot skip writing context/why/verify sections) 2. product specs (full ERD: https://excalidraw.com/#json=WT-oRUdyKBhAsDZJ3NwAR,WAbVgfO39... ) 3. linking specs to code via SCIP indexes, and commits to ACs, later you can attach anything you want
Wow, yeah. You call it “optimizing for understanding.” I’ve been thinking about a very similar problem as “optimizing for execution of intent.”
My version is roughly: if execution and verification are getting cheap, but taste, design, intent, and planning are still expensive, then the workflow should focus on how intent gets executed in each change and how it stays intact over time instead of slowly drifting.
I’m more hesitant to formalize all of that into heavy tooling, but there are clear parallels here. I wrote up more of what I mean here: https://russellromney.com/blog/intent-driven-development