spawarotti

There is at least one startup doing it already (I'm not affiliated with it in any way): https://promptless.ai/

Smartness and happiness are like test coverage.

If you are not smart or have no tests, you will not be happy.

If you are smart or have high test coverage, you may or may not be happy.

There are two types of people: those who do backups, and those who will do backups.

At this point AGENTS.md is a README.md with enough hype behind it to actually motivate people to populate it with contents. People were too lazy to write docs for other people, but funnily enough are ok with doing it for robots.

This situation reminds me a bit of ergonomic handles design. Designed for a few people, preferred by everyone.

And a related page, in the other direction: https://www.futuretimeline.net/

Very good online course on debugging: Software Debugging on Udacity by Andreas Zeller

https://www.udacity.com/course/debugging--cs259

Great advice. I follow it in my coding efforts and it has never failed me. Great book about this: Unit Testing Principles, Practices, and Patterns, Vladimir Khorikov, 2020

https://www.manning.com/books/unit-testing

How do you deal with serializing properties "by reference"? E.g., if 3 objects reference object "Foo", then Foo is serialized once instead of being duplicated in the json 3 times?

I am especially excited for the Smart ComboBox:

https://devblogs.microsoft.com/dotnet/introducing-dotnet-sma...

In general, I see the idea of semantic matching instead of textual matching as one of the great, pragmatic applications of the current technology.

Somewhat related fun application of this concept is this: https://neal.fun/infinite-craft/ (the combination outputs are generated by LLMs)

Jake, I just read the blog post you shared. I loved it. The message and the writing style.

Currently some programmers, and with time more, have to write, integrate and debug LLMs, hence for the programming to end, other LLMs would have to be able to do so, too. LLMs successfully modifying other LLMs is, like, singularity. In other words, the moment programming ends is the same moment we all are going to die.

From the page:

Describe your data up front and generate schemas, API specifications, client / server code, docs, and more.

With TypeSpec, remove the handwritten files that slow you down, and generate standards-compliant API schemas in seconds.

At a first glance this looks to me to be the same concept as "The Heptagon of Configuration":

https://matt-rickard.com/heptagon-of-configuration

Truer words have never been spoken.

Microsoft IntelliTest (formerly Pex) [1] is internally using Z3 constraint solver that traces program data and control flow graph well enough to be able to generate desired values to reach given statement of code. It can even run the program to figure out runtime values. Hence the technique is called Dynamic Symbolic Execution [3]. We have technology for this, just not yet applied correctly.

I would also like to be able to point at any function in my IDE and ask it:

- "Can you show me the usual runtime input/output pairs for this function?"

- "Can you show me the preconditions and postconditions this function obeys?"

There is plenty of research prototypes doing it (Whyline [4], Daikon [5], ...) but sadly, not a tool usable for the daily grind.

[1] https://learn.microsoft.com/en-us/visualstudio/test/intellit...

[2] https://link.springer.com/chapter/10.1007/978-3-642-38916-0_...

[3] https://queue.acm.org/detail.cfm?id=2094081

[4] https://www.cs.cmu.edu/~NatProg/whyline.html

[5] https://plse.cs.washington.edu/daikon/

but what these people often need is someone to sit with them for a significant amount of time and demonstrate how one breaks a problem down, builds small pieces that demonstrate functionality and then put those pieces together into a solution.

And what if this is done repeatedly for the junior engineer, and yet any initiative they show after that is still negligible?

Thx, nice explanation. I think possibly Mercurial actually stores only the diffs, but I am not sure.

One generalization of this concept I see is: Instead of having a sequence of successive states, you only need the initial state and a function telling you how to compute the next state from previous one.

You can also see a connection to a version control system like Git. Instead of keeping snapshots of all the contents of the repository after each commit, one can keep only the initial repository state and changes in each commit. Then to get to N-th state you say "Apply first N commits to the initial state".

In the bouncing DVD logo example the "function to compute next state" or "commit contents" is just easy and regular, to the point of being expressible via simple math functions.

This is also known as Event Sourcing.

That's what I was thinking, too. Perhaps we already know majority of what there is to know, when it comes to fundamental concepts? Probably plenty of work left in improving our tools and engineering solutions, like machine learning-based software, as well as in understanding the intricates of biology. Maybe mathematics, too. Maybe improvements in these will cause another golden age of discovery. Like, understanding biology enough to gain significantly extended lifespan, which means much more expertise can be built by one individual.

According to [0] the toll of civilian deaths is 9% not ~90%:

The 542 drone strikes that Obama authorized killed an estimated 3,797 people, including 324 civilians.

I define a few test cases and the AI writes code for a generalized solution

How about the AI never writing any code, just training "mini AI" / network that implements the test cases, of course in a generalized way, the way our current AI systems work. We could continue adding test cases for corner cases until the "mini AI" is so good that we no longer can come up with a test case that trips it over.

In such future, the skill of being comprehensive tester would be everything, and the only code written by humans would be the test cases.

This situation reminds me of low-background steel:

Low-background steel, also known as pre-war steel, is any steel produced prior to the detonation of the first nuclear bombs in the 1940s and 1950s. Typically sourced from shipwrecks and other steel artifacts of this era, it is often used for modern particle detectors because more modern steel is contaminated with traces of nuclear fallout.

https://en.m.wikipedia.org/wiki/Low-background_steel

This article reminds me of "The Church of Interruption", the best short article I ever read about communication styles: https://sambleckley.com/writing/church-of-interruption.html

https://archive.ph/V9ALy

How long will the fuel last? Sabine Hossenfelder references studies in which we have enough Uranium for 50 years max.

6:08 here: https://youtu.be/0kahih8RT1k

Why not instead use one of the popular programming languages (C#, Java, ...), possibly with some dedicated library built on top of it? Also, reminds me of the Heptagon of Configuration [1].

[1] https://matt-rickard.com/heptagon-of-configuration

how are you suppose to "unit test" that you properly increment a varibale before inserting into the DB without mocking the DB?

You put the logic that increments that variable into a pure function and unit test the input/output pair. Because it is now decoupled from the database, you don't have to deal with it.

mocks allow you to isolate the unit to be tested.

You achieve isolation instead by refactoring to a "pure functional core and mutable outer-shell" architecture. Above I gave one example of refactoring to functional core. In the cases where you still need to deal with external dependencies in unit tests, you use in-memory implementations (aka simulators) instead of mocks.

Basically there are two subtypes of unit tests - small focused unit tests, testing input/output pairs of purely functional code, and "bigger" unit tests, that check how bigger units of internal business logic collaborate together. They use the in-memory simulators to ensure the tests maintain all the properties of a good unit test: runs fast, doesn't interfere with other tests, requires zero setup, is not flaky and makes zero assumptions about the environment.

So, overall - no mocks for unit testing.

mocks are for unit tests only.

I do think the opposite is true, with very few exceptions. Mocking in unit testing is an anti-pattern leading to brittle tests with negative value - the cost of maintaining them is way higher than any benefit they provide. Too many false positives, too little true positives, too much rework needed when code changed but no bug was introduced, too unreadable code.

integration tests is when you start integrating dependencies together. so maybe you have a dummy database like an in-memory db, but you're certainly not mocking it.

This is the only case mocking makes sense. In integration testing you want to test integration with one external endpoint. Hence you mock or simulate all the others. In unit testing there is no need for mocking as explained above. In system (end-to-end) testing there is no need for mocking because we test how everything integrates together.

Naturally, there is way more nuance to the simplified statements I made above. The book elaborates on that. There is also an article by the same author about it: https://enterprisecraftsmanship.com/posts/when-to-mock/

This rule is also recommended by section 9.2.4. "Only mock types that you own" of 2020 book by Vladimir Khorikov: "Unit Testing Principles, Practices, and Patterns".

Worth noting is that book also says in 9.2.1: "Mocks are for integration tests only". I agree.

In my opinion this book is the best comprehensive take on testing I ever encountered.

A tool similar to what you want. It generates input/output pairs from the code, aiming to maximize coverage, and allows you to convert them to unit tests with one click.

https://docs.microsoft.com/en-us/visualstudio/test/generate-...

Also known as its legacy / research project name, "Pex". The underlying algorithm technique is called "dynamic symbolic execution".

There was also similar tool for Java called "Agitar Agitator".

I’ve been struggling with the same problem and found a solution that works for me. I was procrastinating up to 8 hours per day, on average.

The core idea is to make a contract with oneself to not exceed a daily budget of procrastination and implement it. Say, 4 hours per day, on average. Everything else follows from it.

There are few critical components to make this work:

1. You need to admit you have a problem that needs fixing. If you procrastinate so much, quite possibly you are depressed. Like, for realz. That's OK.

2. Self-understanding that this is a matter of survival. Either you will make this work, or your life will be truly miserable, up to and including destroying your career, relationships and health.

3. Comprehensive time tracking. If you were watching a YouTube video while eating and spent extra 5 minutes to finish off the video after you were done with your meal, you need to track these 5 minutes. If you pick up your phone in bed just to quickly scroll through pages for 3 minutes, you need to track it. I use Excel for that - very fast & easy if you know the right keyboard shortcuts.

4. You need to do the tracking _yourself_. This is to (a) increase awareness you procrastinated and (b) introduce friction to doing it.

5. Social accountability. I have a weekly session with a coach where I report if I stayed within the quota, or not. But anybody you don't want to disappoint will do.

6. You are good as long as you stay within the budget. If you spend the time you reclaimed by laying on the couch and looking at the ceiling for 3 hours - that's a huge win. More on that below.

7. As always, you cannot neglect your fundamentals: sleep, exercise, proper diet, socializing. But now you will have time to deal with it.

Once you implement this process, few observation immediately come to mind:

1. You have so much more time and mental energy. Wow.

2. If you fail to track these short 3-5 minute burst of procrastination, they quickly add up to half an hour, an hour, two hours. Hence, you really cannot slip on that. If you slip, you also won’t be able to trust yourself, which is critical.

3. You become bored with that extra time, meaning you finally have time to think and talk to yourself. I cannot overstate how important that is. You can use this time to direct your thoughts / visualize better outcomes and hence motivate yourself to do the right thing (aka Cognitive Behavioral Therapy).

4. Once you keep doing it successfully for some time, you can now trust yourself that you are in control. This is huge, because your emotions now will be on your side.

5. You become less afraid of doing productive things, because you actually have time to do them, instead of thinking "what's the point, I have 1 hour in the day left after wasting all of it, I am tired, and I will give into my procrastination cravings anyway".

6. You will sleep way more because now you cannot procrastinate in bed. This will repay your sleep debt and restore your energy levels, making everything else much easier to tackle.

Overall, this strategy works for me very well because (a) I admitted to myself I have a problem that is very serious. This means I need to seek help and develop a process to solve it. And (b) I don’t mind doing comprehensive time tracking of my procrastination time, which is a critical part of the entire process.

Further reading:

"Digital Minimalism" by Cal Newport

"Feeling Good" by David D. Burns

I think it is fair to not spend time and resources engaging with such ideas, as long as there is a good "decision record" documentation explaining that this subject was already discussed, decisions were made, and there is no point coming back to it. Same as with flat Earth - have some documentation thoroughly debunking the idea and point to it anybody trying to start the conversation again. Tell them they need to first read through all of it. If they are still not convinced after that, they are free to lay out their argument, but it is on them to make the argument strong, which should be, like, really hard, given the plethora of evidence we have that Earth is not flat.

In the examples you gave the "decision record" would be fairly simple - we assume that human rights [1] are a given.

[1] https://en.wikipedia.org/wiki/Human_rights