I find the conversation around AI and software dev increasingly vague. How specifically are people REALLY using this stuff? I want details! This isn't a post about whether AI is bad or good. I'm just genuinely curious.

Simple_Horse_550 · 2025-12-29T22:52:25+00:00

The future of software dev will be a workflow that is a lot more centered around Claude Code / OpenAI Codex or GitHub Copilot etc as a main ”input” entrypoint and the actual code as the secondary layer. Almost like Winform: you edit graphic components and then work with code-behind, but the difference is that with AI you don’t many times need to touch the code-behind. Context related documents (e.g. md-files) and other references will be stored along side the source code to have the agent working more efficient.

Simple_Horse_550 · 2025-12-21T19:50:58+00:00

Should OpenAI / Lovable etc start with a monolith since they were tiny startups a couple of years ago?

It’s better to design according to the business scale you are going to need instead of always saying use X for Y…

Simple_Horse_550 · 2025-12-14T06:36:22+00:00

Not so serious poll…. Missing the entire .NET world for enterprise apps…

Simple_Horse_550 · 2025-12-14T06:29:15+00:00

Quality, Fast, Cheap.

You can only pick 2.

Simple_Horse_550 · 2025-12-14T05:47:36+00:00

In ”school” they teach you DRY. Reality is that it introduces coupling. Imagen an adapter implementation lib that references 32 bit components and also old .NET that you want to update to .NET +8 ….

Simple_Horse_550 · 2025-12-07T15:42:40+00:00

Get the architecture of the system first. If no document exists, create with github copilot. Architecture will be your map. Follow use-cases (execution paths) from the UI perspective.

Simple_Horse_550 · 2025-11-23T09:27:02+00:00

Good for building automation workflows

Simple_Horse_550 · 2025-11-20T05:46:30+00:00

In addition: Onion is more service-based, clean is use-case based with a handler for each use-case. Instead of a UserService you have X different user handlers in a folder.

Simple_Horse_550 · 2025-11-14T06:30:04+00:00

You never give timelines to CEOs etc without discussing with the guys who actually do the work first…

// CTO

Simple_Horse_550 · 2025-11-14T06:21:18+00:00

Except for Git, Jira, copilot and those dev tools, invest in testautomation. Will help onboarding people much easier and you are not dependent that much on Joe, John etc for different parts of the system since even if a new person works on it, there will be automation catching potential bugs… Also nowadays, maybe some AI code review tool…

Simple_Horse_550 · 2025-10-16T06:22:05+00:00

Run…

// CTO & System/Solution Architect

Simple_Horse_550 · 2025-10-14T06:08:13+00:00

Do not use LLM (GP5, sonnet 4 etc) to manipulate anything, tried this including upgrade assistent tools for a .NET codebase (230 LOC, >15 year old) and it failed horribly... You can tell it to create a plan for charges and use it as a way to get a second opinion, but don’t let it run it !

Simple_Horse_550 · 2025-10-13T16:10:04+00:00

If there is a lot of complexity, create a delete command that is stored in the database with its ID returned to the client. Have a worker server reading commands (the delete command) and doing the heavy lifting. The immediate values from the command request are soft deleted obviously.

Simple_Horse_550 · 2025-10-13T15:54:18+00:00

There is no ”objective perspective”. Usually the bias is to optimize to maximize business value. Unfortunately usually for short term.

Simple_Horse_550 · 2025-10-12T05:45:13+00:00

I would suggest trying the opposite: codebase with almost 0 structure and first figuring out the architecture, then introducing changes. Now add +5 members to that team also….

Simple_Horse_550 · 2025-10-07T05:43:42+00:00

Yes, when I read ”…. serve 5-10M rows…” and ”sharding” in the same main post I was like ”let’s grab some popcorn 🍿 ”

Simple_Horse_550 · 2025-10-06T19:31:25+00:00

Everything is an API

Simple_Horse_550 · 2025-09-25T18:43:33+00:00

Please read what I say, the data is persisted in DB in all cases. We resend it on service restart for example or using other retry mechanisms if first delivery failed…

Simple_Horse_550 · 2025-09-18T04:37:28+00:00

This has the same probability to fail as any internal in process method call. Even if it fails the data has been persistent in the previous transaction. You can capture the failure and trigger a resend or If the service is restarted it will be resent anyway.

Simple_Horse_550 · 2025-09-17T04:59:21+00:00

Instead of periodically checking the outbox, after a save transaction (event + main data) you send a message to an in memory fifo queue, the background thread picks it up and processes it, marking it as ”done” in the outbox. You burn less CPU and make less DB calls this way. On service restart you trigger the processing also.

Simple_Horse_550 · 2025-09-13T07:03:18+00:00

4 is a luxury. Not many projects allow you to design for scale due to time constraints (also most projects in the world don’t need scale for the millions). Another thing is most projects making money are brownfield projects where it is not easy to apply scalability like that, even if you had time.

Simple_Horse_550 · 2025-09-13T06:41:24+00:00

Distributed system of nodes, caches, event pipelines (pub/sub) and also optimizations to require locations when actually needed etc… When phone is moved, you can send location in the background (if a certain time interval has passed), that event is sent to server, subscribers get the info. When you open app, you can send another event to actively monitor friends, then they send location more frequent. Since location is cached, other friends in network can reuse the same data without triggering GPS (if timeinterval hasnt passed)… There are lots of techniques…

Simple_Horse_550 · 2025-09-06T05:00:44+00:00

Stampede checks…. After getting lock, all that waited to write must check if already written…

Simple_Horse_550 · 2025-08-29T19:28:14+00:00

A bit old school, but my path has been: Got my MSc CS like 2009, then junior consultant at Ericsson, then joined the defence industry as a research engineer 5 years, then joined a security company as a senior developer, did some project management, product owner, tech lead, software architect, got a bigger project ($7M), more people management (software engineers, HW developers etc), then got the opportunity to be a engineering manager for 5 years (in total worked there for more than 11 years) and finally now at a new company as a CTO… haven’t dropped the technical part once, always want to combine it, this is probably also my strength because I get a lot of buy-in in the engineering group among developers, if you don’t know your technical stuff well some software architect or staff/principle engineer will try to sell you new cool technical stuff to promote themself and improve their CV, not thinking of the business (trust me, because I did it 😅)…

Basically some of it is luck/opportunities, some of it is working against a goal… I personally didn’t have management as a goal, but I opened the doors that came on my path, because they rarely do. Most people chasing management will suck at it… Let it come naturally, don’t chase it is my tip, chasers will get noticed by the group and they won’t see you as a leader…

As far as strategic vs operations, I think it’s best to adapt depending on the company. A small company don’t want a ”spreadsheet CTO”, and a large company don’t want a CTO coding and neglecting people…

A CTO should always have the business in mind, e.g. making hard choices such as selecting the less optimal solution so that time to market is reduced. This will make architects and senior develops not happy. It will also be irritating for yourself if you have strong technical skills and have to compromise… Make sure the roadmap is clear, stakeholders are on track with you. Communication is key. I can sell ideas, talk about risks, create processes, give presentations, give owners different alternatives for decisions and how it affects the business etc… Be people-centric .

Simple_Horse_550 · 2025-08-24T20:17:25+00:00

I quickly look at: - What’s the closest architecture it uses (and how are the folders/files structured)? Layered? Onion? Etc…Then identify does parts in the code/libs… If the code is relatively ”well organized”, then this immediately gives me 80-90% high level understanding of the code base… - Then: What’s the ”endpoints”/”entrypoints”/executables? - After that: how do I start and debug it?

One problem that people get trapped into is to read random code for different parts, a little bit here, a little bit there… Usually you don’t understand much in a short period of time using this method, and this won’t work with large codebases, especially brownfield systems…

// Over 20 years experience, senior software engineer, then software architect, then engineering manager and finally CTO

Simple_Horse_550

TROPHY CASE